Вещественные числа: стандарт IEEE 754

В блоке 2 мы разбирали позиционные системы счисления, но только для целых чисел: разряды имели веса $2^0$, $2^1$, $2^2$, … Никто, однако, не запрещает продолжить эту же линейку в другую сторону.

В десятичной записи мы это делаем не задумываясь: 3,25 – это 3 единицы, 2 десятых и 5 сотых, то есть веса разрядов после запятой равны $10^{-1}$, $10^{-2}$, $10^{-3}$. В двоичной системе всё устроено так же, только веса – отрицательные степени двойки: 1/2, 1/4, 1/8, 1/16.

Двоичная дробь – запись числа в двоичной системе, в которой разряды после запятой имеют веса $2^{-1}$, $2^{-2}$, $2^{-3}$ и так далее.

Разберём 101,11₂:

4 + 0 + 1 + 0,5 + 0,25 = 5,75. Это та же развёрнутая форма числа из урока 2.4, просто с продолжением в отрицательные степени.

Здесь i пробегает номера разрядов: для целой части – 0, 1, 2, …, для дробной – −1, −2, −3, … Никакого особого правила для дробной части нет, это одна и та же формула.

Полезно сразу заметить одно следствие, к которому мы вернёмся во второй половине урока: точно записать конечным числом двоичных разрядов можно только те дроби, знаменатель которых – степень двойки. 0,5, 0,25, 0,75, 0,125 – записываются. А вот 0,1 в этот список не попадает.

Самая очевидная идея – договориться раз и навсегда, где стоит запятая. Например, в восьмибитной ячейке отвести 4 бита целой части и 4 бита дробной. Тогда 0101,1000 – это 5,5.

Формат с фиксированной запятой – представление, в котором количество разрядов до и после запятой задано заранее и одинаково для всех чисел.

Способ рабочий, его до сих пор применяют там, где важна предсказуемость (например, в финансовых расчётах и в микроконтроллерах без блока вещественной арифметики). Но для универсального типа он плох, и вот почему.

Все биты жёстко поделены между «крупным» и «мелким», и подвинуть эту границу нельзя. Дадим больше битов целой части – сможем хранить огромные числа, но потеряем мелкие: минимальный шаг станет слишком грубым. Дадим больше дробной – научимся различать тысячные доли, но потолок опустится до смешного.

Вернитесь к вопросу из начала урока: масса Земли – $6 \cdot 10^{24}$, заряд электрона – $1{,}6 \cdot 10^{-19}$. Между ними 43 порядка. Чтобы фиксированная запятая покрыла оба, потребовалось бы порядка 150 битов на число – и почти все они в каждом конкретном случае были бы нулями. Расточительно.

При этом заметьте: сами эти числа короткие. В каждом всего две значащие цифры. Дорого стоит не точность, а размах.

Люди столкнулись с этой проблемой задолго до компьютеров и решили её так: записывать отдельно значащие цифры и отдельно порядок величины.

Радиус Земли – 6 371 000 м, но физик напишет $6{,}371 \cdot 10^6$. Заряд электрона – $1{,}602 \cdot 10^{-19}$ Кл. В обеих записях две части: значащие цифры (6,371 и 1,602) и показатель степени (6 и −19). Размах хранится в показателе и стоит копейки, а точность – в цифрах, и их количество можно зафиксировать.

Ровно эту идею и переносят в двоичную систему.

Формат с плавающей запятой – представление числа в виде произведения знака, мантиссы и степени основания: $\pm m \cdot 2$ᵉ. Позиция запятой не закреплена, а задаётся порядком e – отсюда и название: запятая «плавает».

Мантисса – значащие цифры числа. Порядок – показатель степени, определяющий масштаб.

Как в научной записи мантиссу принято приводить к виду «одна цифра до запятой» (6,371, а не 63,71), так и в двоичной записи мантиссу нормализуют: приводят к виду 1,xxxx. Например, 5,75 = 101,11₂ = 1,0111₂ · 2².

До середины 1980-х каждый производитель делал вещественную арифметику по-своему: своё число битов под мантиссу, свои правила округления, своё поведение при делении на ноль. Одна и та же программа на двух машинах могла выдать разные ответы, и переносить численные расчёты было мучением.

Порядок навёл стандарт IEEE 754, принятый в 1985 году. Главным его архитектором был математик Уильям Кэхэн, получивший за эту работу премию Тьюринга в 1989 году; обкатывались идеи стандарта ещё раньше – в математическом сопроцессоре Intel 8087 (1980), в разработке которого Кэхэн участвовал как консультант. Сегодня IEEE 754 поддерживают практически все процессоры и языки программирования, поэтому одно и то же вычисление даёт одинаковый результат везде.

Стандарт описывает несколько форматов; школьнику достаточно двух:

Обратите внимание на терминологическую ловушку: слово float в разных языках означает разные форматы. В C и Java float – это 4 байта, а 8 байтов называются double. В Python float – это binary64, всегда 8 байтов, и никакого 4-байтного вещественного типа в языке нет. Дальше в уроке под «вещественным числом» подразумевается binary64.

Разберём формулу по частям – каждое поле решает свою задачу.

Знак S (1 бит). Ноль – число положительное, единица – отрицательное. Здесь, в отличие от целых чисел из урока 5.2, знак действительно хранится отдельным флажком: множитель (−1)ˢ просто переворачивает результат. Дополнительный код тут не нужен – вещественные числа складываются не одной схемой сумматора, а отдельным блоком процессора, который знаки и так разбирает.

Мантисса M (52 бита) и бесплатный 53-й бит. Мы договорились нормализовать мантиссу к виду 1,xxxx. Но тогда старший бит всегда единица – а зачем хранить бит, значение которого известно заранее? Его и не хранят: в память идут только цифры после запятой, а единица подразумевается. Этот приём называют скрытым (неявным) старшим битом, и он даёт лишний разряд точности бесплатно: хранится 52 бита, а работает мантисса как 53-битная. Именно поэтому в формуле стоит $1 + M/2^{52}$, а не просто $M/2^{52}$.

Порядок E (11 битов) и смещение. Порядок должен уметь быть и положительным, и отрицательным (для $6 \cdot 10^{24}$ и для $1{,}6 \cdot 10^{-19}$). Но хранится он не в дополнительном коде, а со смещением: в поле пишут не сам порядок, а порядок плюс 1023. Хотите порядок 0 – записываете 1023; хотите −5 – записываете 1018.

Зачем так? Чтобы вещественные числа можно было сравнивать, как обычные целые: при смещённом порядке большему числу соответствует большая беззнаковая битовая комбинация, и процессору для сравнения не нужны никакие проверки знаков. С дополнительным кодом это свойство сломалось бы.

Одиннадцать битов дают значения поля от 0 до 2047, но крайние два зарезервированы под особые случаи (о них ниже), так что реальный порядок укладывается в диапазон от −1022 до 1023. Отсюда и границы типа: максимальное вещественное число – около $1{,}8 \cdot 10^{308}$, минимальное нормализованное положительное – около $2{,}2 \cdot 10^{-308}$.

Пройдём весь путь на числе, которое уже разбирали.

1. Записать модуль в двоичной системе: 5,75 = 101,11₂.
2. Нормализовать – сдвинуть запятую так, чтобы слева осталась одна единица: 101,11₂ = 1,0111₂ · 2². Порядок получился 2.
3. Знак: число положительное, S = 0.
4. Порядок: 2 + 1023 = 1025 = 10000000001₂ (11 битов).
5. Мантисса: берём цифры после запятой нормализованной записи – 0111 – и дополняем нулями справа до 52 битов: 0111000…0.

Итого в памяти:

0 10000000001 0111000000000000000000000000000000000000000000000000
S   порядок                       мантисса

Проверим формулой: $(-1)^0 \cdot (1 + 0{,}4375) \cdot 2^2 = 1{,}4375 \cdot 4 = 5{,}75$. Сходится.

Заметьте, что мантисса дополнялась нулями и уложилась ровно. Так бывает не всегда – и вот это «не всегда» и есть главный сюжет второй половины урока.

Виджет ниже показывает ту же раскладку живьём. Что стоит попробовать:

• Сверьте поля с нашим разбором: порядок 10000000001, мантисса 0111 и дальше нули.
• Нажмите «0,1» и посмотрите на строку «в памяти лежит ровно» – она объяснит весь остаток урока.
• Нажмите «$2^{53}$», а затем «следующее ▸»: шаг сетки окажется равен 2, то есть соседнего целого числа там просто нет.
• Нажмите «∞» и «NaN» – это особые значения, к ним мы вернёмся ниже.

Мы дошли до вопроса из начала урока. Попробуем перевести 0,1 в двоичную дробь.

Алгоритм обратный тому, что был в уроке 2.5 для целых чисел: там мы делили на основание и собирали остатки, здесь дробную часть надо умножать на 2 и собирать целые части.

Целая часть произведения на каждом шаге и есть очередной бит, а в работу идёт то, что осталось после запятой:

Последняя строка повторяет вторую: дробная часть вернулась к прежнему значению – значит, дальше всё повторится, и повторяться будет вечно:

$0{,}1_{10}$ = 0,0001100110011001100…₂ – период 0011 без конца.

Причина ровно та, о которой мы говорили после формулы: 0,1 = 1/10, а $10 = 2 \cdot 5$. Множитель 5 в знаменателе не сводится к степеням двойки, поэтому конечной двоичной записи у одной десятой нет.

И здесь стоит остановиться, потому что это не «баг компьютера». Ровно то же самое происходит в привычной десятичной системе: 1/3 = 0,333… – и никого это не смущает, мы просто знаем, что три в знаменателе «не дружит» с десяткой. У двоичной системы свой список неудобных знаменателей, и десятка в нём есть. Дроби вроде 0,5 или 0,25 записываются идеально, а самая бытовая на вид 0,1 – нет.

Мантисса хранит 52 бита, значит бесконечную последовательность приходится обрубить и округлить. В памяти вместо 0,1 оказывается ближайшее представимое число – очень близкое, но не равное.

Ниже тот же алгоритм пошагово. Прокрутите трассировку до шага, где переменная num снова становится равна 2, и сравните с первой итерацией. Как только состояние повторилось, дальнейшее поведение цикла предопределено – этим и доказывают, что дробь бесконечна.

Теперь ответ собирается сам. В памяти лежат не 0,1 и 0,2, а ближайшие к ним представимые числа:

Обратите внимание: 0,1 и 0,2 округлились вверх, а 0,3 – вниз. Сложив два первых числа, мы получаем значение чуть больше трёх десятых, а константа 0.3 – чуть меньше. Это разные числа, и 0.1 + 0.2 == 0.3 даёт False. Точная сумма выглядит так: 0,3000000000000000444089209850062616…, и Python печатает её как 0.30000000000000004. В виджете выше это кнопка «0,1 + 0,2» – сравните её результат с кнопкой «0,3».

Тогда законный вопрос: почему print(0.1) показывает аккуратное 0.1, а не длинный хвост? Потому что при выводе Python округляет – он печатает кратчайшую десятичную запись, которая однозначно соответствует этому набору битов. Раз никакое другое вещественное число не читается как «0.1», незачем пугать человека тридцатью знаками. Хвост можно увидеть, если попросить явно – например, вывести число с 20 знаками после запятой (f'{0.1:.20f}' из урока 1.7).

Ошибка в $4 \cdot 10^{-17}$ кажется безобидной. Опасно другое: она накапливается. Если в цикле сто раз прибавить по 0,1, сумма не будет равна 10 – отклонение сложится сто раз. А если результат такого цикла используется как условие выхода или как время, последствия могут быть очень серьёзными.

Практическое правило, которое стоит принять сразу и навсегда:

Вещественные числа не сравнивают на точное равенство. Вместо «равны ли» спрашивают «достаточно ли близки».

Три приёма:

1. Сравнение с допуском. Проверять не a == b, а abs(a - b) < 1e-9. Величина допуска (её часто называют «эпсилон») выбирается по смыслу задачи: для геометрии на школьных масштабах хватит $10^{-9}$, для физических расчётов может понадобиться другое значение.
2. Допуск подбирают под масштаб чисел. Для чисел порядка $10^{15}$ разница в $10^{-9}$ попросту недостижима: сетка представимых значений там грубее самого допуска, и проверка никогда не сработает. В таких случаях сравнивают не саму разницу, а её долю от величины чисел. В Python это давно написано за нас, но пользоваться готовыми наборами инструментов мы научимся позже – сначала нужны функции.
3. Не накапливать сумму там, где можно посчитать. Если нужно пройти значения 0,1, 0,2, … 1,0 – лучше вести целочисленный счётчик и делить его на 10 на каждом шаге, чем прибавлять 0,1 к переменной. Целые числа в Python точны, и ошибка не накопится.

И отдельно про деньги: суммы не хранят во float. Самый простой приём доступен уже сейчас – считать всё в копейках целыми числами: арифметика тогда точна, а рубли получаются делением только при выводе. Так устроены банковские и бухгалтерские программы.

Мы упоминали, что два крайних значения поля порядка зарезервированы. Вот под что.

Порядок из всех единиц – это не число, а маркер:

• мантисса нулевая → бесконечность, inf (со знаком, то есть бывает и -inf);
• мантисса ненулевая → NaN (Not a Number) – «не число», результат бессмысленной операции вроде «бесконечность минус бесконечность» или корня из отрицательного числа.

У NaN есть удивительное свойство, прописанное в стандарте: он не равен даже самому себе. Сравнение x == x для NaN даёт False – это единственный такой случай во всей арифметике, и именно так наличие NaN обычно и проверяют.

Порядок из всех нулей – тоже особый случай. Он означает, что скрытого старшего бита нет, и число читается как 0,$xxxx \cdot 2^{-1022}$. Если мантисса нулевая – это ноль. И тут вылезает любопытная деталь: знак-то хранится отдельным битом, поэтому нулей формально два – +0.0 и −0.0. Стандарт требует, чтобы при сравнении они считались равными, так что заметить разницу в обычной программе почти невозможно. Ненулевая мантисса при нулевом порядке даёт субнормальные числа – они позволяют плавно дотянуться от $2{,}2 \cdot 10^{-308}$ до самого нуля, постепенно теряя точность.

Небольшая, но полезная деталь про Python: 1 / 0 бесконечности не даст – это исключение ZeroDivisionError, язык считает такую запись ошибкой программиста. А вот получить inf переполнением можно: если умножать большое число на 10, в какой-то момент результат перестанет влезать в 8 байтов и превратится в inf. Обратите внимание на контраст с уроком 5.2: у целых чисел в Python переполнения нет вовсе, у вещественных – есть, потому что размер жёстко фиксирован.

53 бита мантиссы соответствуют примерно 15–17 значащим десятичным цифрам. «Примерно» – потому что двоичные разряды не переводятся в десятичные ровно: 15 значащих цифр воспроизводятся гарантированно, 17 хватает, чтобы записать любое вещественное число и прочитать обратно без потерь.

Отсюда следствие, которое многих застаёт врасплох: у больших вещественных чисел не бывает мелкого шага. Мантисса фиксированной длины, поэтому чем крупнее число, тем грубее сетка представимых значений. Начиная с $2^{53} = 9\,007\,199\,254\,740\,992$ соседние целые числа перестают различаться: значение на единицу больше просто не имеет представления, и оба превращаются в одно и то же вещественное число. Для чисел порядка $10^{18}$ минимальный различимый шаг – уже сотни.

Поэтому большие целые значения (идентификаторы, счётчики, суммы в копейках) во float не переводят: целочисленный тип в Python точен при любом размере, а вещественный – только пока число не выросло. Это, кстати, ровно та причина, по которой числа в 5.2 мы разбирали отдельно: int и float – не «одно и то же с разной точностью», а два разных инструмента.

Всё разобранное выше выглядит академично ровно до того момента, когда за числами стоит что-то тяжёлое и быстрое. Две истории, ставшие хрестоматийными.

Ariane 5, рейс 501, 4 июня 1996 года. Первый запуск новой европейской ракеты-носителя закончился разрушением аппарата примерно через 37 секунд после старта. Разбор показал, что причина – в программе инерциальной навигационной системы. Там 64-битное вещественное значение, связанное с горизонтальной скоростью, преобразовывалось в 16-битное знаковое целое.

Дальше всё складывается из того, что мы уже знаем. Диапазон 16-битного знакового целого – от −32 768 до 32 767 (урок 5.2). У Ariane 5 траектория была куда более энергичной, чем у предшественницы Ariane 4, и значение вышло за эту границу. Преобразование не состоялось, система зафиксировала ошибку и передала в бортовой компьютер диагностический код – а тот принял его за данные о полёте, отклонил сопла до упора, и ракету разрушили нагрузки.

Самое поучительное – почему проверки не было. Модуль был унаследован от Ariane 4 без изменений; на Ariane 4 такое значение физически не могло возникнуть, а проверку диапазона сознательно не поставили, чтобы сэкономить процессорное время. Ни одно вычисление в этой истории не было выполнено неверно. Ошиблись в другом: приняли за неизменное свойство мира то, что было всего лишь свойством прежней ракеты.

И вторая история – прямо про нашу одну десятую. 25 февраля 1991 года в Дахране комплекс ПВО Patriot не смог перехватить баллистическую ракету; погибли 28 американских военнослужащих. Внутренние часы комплекса отсчитывали десятые доли секунды, и значение 0,1 хранилось в 24-битном регистре с фиксированной запятой – то есть с той самой обрезанной двоичной дробью. Крошечная погрешность каждого такта накапливалась, и после примерно ста часов непрерывной работы расхождение времени достигло примерно 0,34 секунды. Для цели, летящей со скоростью около полутора километров в секунду, это ошибка в расчёте положения на сотни метров (в отчёте расследования – около семисот) – система искала цель не там.

Формат здесь другой, не IEEE 754, но корень тот же: 0,1 не имеет точного двоичного представления, а маленькая ошибка, повторённая миллион раз, перестаёт быть маленькой.

Соберём в одном месте всё, что касается именно Python.

• Тип float – это binary64, всегда 8 байтов. Никакого 4-байтного вещественного типа в языке нет; в отличие от int, размер здесь фиксирован, поэтому переполнение (превращение в inf) возможно.
• Целые числа в Python точны при любом размере – если задача позволяет обойтись целыми, вопрос погрешности снимается полностью. Отсюда и приём с копейками.
• Округлять для вывода умеет знакомая round(): round(0.1 + 0.2, 2) даёт 0.3. Но это именно вывод – в памяти по-прежнему лежит ближайшее представимое число.
• Есть в Python и типы, считающие точно в десятичной системе, и типы для обыкновенных дробей. Они лежат в отдельных наборах инструментов, которые нужно подключать, – вернёмся к ним, когда пройдём функции.

И честная оговорка, чтобы не возникло перекоса: float – нормальный рабочий инструмент, а не мина. Все физические расчёты, графика, машинное обучение, численные методы работают на нём, потому что исходные данные там всё равно измерены с погрешностью, гораздо большей $10^{-16}$. Знать про округление нужно не чтобы избегать float, а чтобы не проверять его значения на точное равенство и не хранить в нём деньги.

Как записать 0,1 в биты? Ответ, честный до конца: точно – никак. Можно записать ближайшее представимое число, и стандарт IEEE 754 гарантирует, что оно действительно ближайшее и что на любой машине окажется одним и тем же. Но равенства одной десятой не будет никогда.

Это не изъян компьютеров и не недоделка стандарта. Точно так же в десятичной системе не записывается 1/3 – просто у двоичной системы свой список неудобных знаменателей, и десятка в него попала.