Как хранится с плавающей запятой? Когда это имеет значение?

Я помню, что 32-битная плавающая точка хранится с использованием 24 бит для фактического числа, а оставшиеся 8 бит используются как степень 10, определяя, где находится десятичная точка.

Я немного забыл об этом, хотя ...

Стандарт - IEEE 754.

Конечно, есть и другие способы хранения чисел, когда IEE754 недостаточно хорош. Такие библиотеки, как BigDecimal в Java, доступны для большинства платформ и хорошо соответствуют числовому типу SQL. Символы могут использоваться для иррациональных чисел, а отношения, которые не могут быть точно представлены в двоичном или десятичном формате с плавающей запятой, могут быть сохранены в виде отношения.

Этот статья, озаглавленный «Числа с плавающей запятой стандарта IEEE 754», может быть полезным. Честно говоря, я не совсем уверен, что понимаю ваш вопрос, поэтому я не уверен, что это будет полезно, но я надеюсь, что это будет.

Да есть Стандарт IEEE для двоичной арифметики с плавающей запятой (IEEE 754)

При хранении в двоичном формате число делится на три части: знак, показатель степени и дробь.

В основном, что вам нужно беспокоиться о числах с плавающей запятой, так это ограниченное количество цифр точности. Это может вызвать проблемы при проверке равенства или если вашей программе действительно требуется больше цифр точности, чем дает вам этот тип данных.

В C++ хорошее практическое правило - думать, что число с плавающей запятой дает вам 7 цифр точности, а двойное - 15. Кроме того, если вам интересно узнать, как проверить равенство, вы можете посмотреть цепочку вопросов это.

Что касается второй части вашего вопроса, если производительность и эффективность не важны для вашего проекта, я предлагаю вам передавать данные с плавающей запятой в виде строки по TCP / IP. Это позволяет избежать таких проблем, как выравнивание байтов, и упростит отладку.

Если вас действительно беспокоят ошибки округления с плавающей запятой, большинство языков предлагают типы данных, которые не содержат ошибок с плавающей запятой. SQL Server имеет типы данных Decimal и Money. .Net имеет тип данных Decimal. Они не имеют бесконечной точности, как BigDecimal в Java, но они точны до количества десятичных знаков, для которых они определены. Таким образом, вам не нужно беспокоиться о том, что значение доллара, которое вы вводите как 4,58 доллара, будет сохранено как значение с плавающей запятой 4,579999999999997.

Как уже упоминалось, Статья в Википедии о IEEE 754 хорошо показывает, как числа с плавающей запятой хранятся в большинстве систем.

А теперь вот несколько распространенных ошибок:

• Самая большая проблема в том, что вы почти никогда не хотите сравнивать два числа с плавающей запятой на равенство (или неравенство). Вместо этого вы захотите использовать сравнения больше / меньше.
• Чем больше операций вы выполняете с числом с плавающей запятой, тем более значительными могут быть ошибки округления.
• Точность ограничена размером дроби, поэтому вы не сможете правильно складывать числа, разделенные несколькими порядками. (Например, вы не сможете добавить 1E-30 к 1E30.)

In follow up to this question, it appears that some numbers cannot be represented by floating point at all, and instead are approximated.

Правильный.

How are floating point numbers stored? Is there a common standard for the different sizes?

Как уже упоминалось в других плакатах, почти исключительно IEEE754 и его преемник IEEE754R. Поиск в Google дает тысячи объяснений вместе с битовыми шаблонами и их объяснениями. Если у вас все еще есть проблемы с его получением, есть два распространенных формата FP: IBM и DEC-VAX. Для некоторых эзотерических машин и компиляторов (BlitzBasic, TurboPascal) есть несколько нечетные форматы.

What kind of gotchas do I need to watch out for if I use floating point? Are they cross-language compatible (ie, what conversions do I need to deal with to send a floating point number from a python program to a C program over TCP/IP)?

Практически нет, они кросс-языковые.

Очень редко встречающиеся причуды:

• IEEE754 определяет sNaN (сигнальные NaN) и qNaN (тихие NaN). Первые вызывают ловушку, которая заставляет процессор вызывать подпрограмму обработчика, если она загружена. Последние этого не делают. Поскольку разработчикам языков не нравилась возможность того, что sNaN прерывают их рабочий процесс и поддерживая их, принудительно поддерживают подпрограммы-обработчики, sNaN почти всегда незаметно конвертируются в qNaN. Так что не полагайтесь на исходное преобразование 1: 1. Но опять же: это очень редко и происходит, только если NaN присутствуют.

• У вас могут возникнуть проблемы с порядком байтов (байты находятся в неправильном порядке), если файлы между разными компьютерами используются совместно. Это легко обнаружить, потому что вы получаете NaN для чисел.