Равенство чисел с плавающей запятой после сохранения/загрузки/перемещения

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

В этом случае да, простое перемещение их не приведет к изменению значений. При выполнении операций над значениями ваша интуиция может нуждаться в разъяснении. В частности, результат любой операции должен быть таким же, как если бы FPU выполнял операцию с полной (то есть произвольной) точностью, а затем только округлял результат, чтобы он соответствовал соответствующему (например, 32-битному двоичному числу с плавающей запятой). Следовательно, для ЦП, который реализует IEEE754 с плавающей запятой, любое округление будет детерминированным — это причина оператора 0.1 + 0.2 != 0.3.

Обратите внимание, что, используя C, вы усложнили это с помощью двух механизмов; 1. C не требует семантики IEEE754; 2. C будет автоматически преобразовывать между значениями float и double (т. е. 32-битные и 64-битные двоичные числа IEEE754 с плавающей запятой на распространенных архитектурах). Эти две особенности могут означать, что код может не делать того, что ожидает наивный читатель.

В качестве более полного примера я поместил следующий код в обозреватель компилятора Godbolt :

#include <math.h>

int explicit_nan(float * restrict a, float * restrict b, float val) {
    *a = val;
    *b = val;
    return isnan(val) ? 1 : *a == *b;
}

int implicit_nan(float * restrict a, float * restrict b, float val) {
    *a = val;
    *b = val;
    return *a == *b;
}

Ключевое слово limited необходимо, иначе Clang компилирует код в защитном режиме, предполагая, что он может быть вызван следующим образом:

char data[sizeof(float) + 1];
explicit_nan((float*)(data), (float*)(data+1), 1.f);

Это приводит к тому, что запись в b изменяет значение a. По-видимому, вас не волнует этот случай, но компилятор C не может быть таким снисходительным.

Можно увидеть, что код explicit_nan компилируется в код, который всегда возвращает 1 (путем установки EAX), в то время как код implicit_nan выполняет только сравнение переданного параметра, чтобы NaN обрабатывались правильно в небольшом объеме кода.

Убеждение вашего коллеги может быть основано на правилах C и C++.

C и C++ позволяют вычислять выражения с плавающей запятой с большей точностью, чем номинальные типы операндов.

Например, учитывая все float переменные, d = a + b - c; можно вычислить с помощью double арифметики. Правила требуют, чтобы при сохранении результата в d он преобразовывался обратно в номинальный тип float. Однако в промежуточных вычислениях можно использовать double. Например, если a равно 2³⁰, b равно 1, а c равно 2³⁰, это выражение даст 0 при вычислении с использованием float арифметики, потому что сложение 2³⁰ и 1 даст 2³⁰ (поскольку 2³⁰+1 не представимо в формат, обычно используемый для float, поэтому он округляется до представимого значения), а затем вычитание 2³⁰ дает 0. Однако, если используется арифметика double, то сложение дает 2³⁰+1, а вычитание 2³⁰ дает 1.

Это не отличается от того факта, что при наличии всех переменных unsigned char выражение оценивается с использованием int арифметики и может давать результаты, отличные от тех, которые были бы получены с использованием только unsigned char арифметики. Например, при a = 100, b = 3, d = 3 * a / b ; даст 100, поскольку используется int арифметика. Если бы использовалась арифметика unsigned char, 3 * a дало бы 44 (300−256), а деление на 3 дало бы 14. Так что это не только проблема с плавающей запятой; это проблема того, как язык программирования оценивает выражения.

Стандарты C и C++ также требуют, чтобы их операнды приводились к целевому типу, а также выполнялись присваивания.

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

То, что вы написали, эквивалентно

float a = 1.0;
float b = 1.0;
int equal = a == b;

(использование указателей ничего не меняет в отношении стандарта C). Итак, для переменной a1.0 интерпретируется в некотором формате оценки F (в зависимости от FLT_EVAL_METHOD, см. ISO C17 5.2.4.2.2p9), затем преобразуется в float и сохраняется в a. То же самое для b. Как правило, сохранение/чтение значений не должно их изменять, если только это явно не указано (например, стандарт ISO C17 прямо говорит в 6.2.6.2p3, что в реализациях, поддерживающих отрицательные целые нули, отрицательный нуль может стать нормальным нулем, когда хранится).

Чтобы ответить на вопрос, сначала рассмотрим преобразование константы 1.0 (в виде строки) в F в обеих строках. ISO C17 говорит в 6.4.4.2p5: «Все плавающие константы одной и той же исходной формы должны преобразовываться в один и тот же внутренний формат с одним и тем же значением». Таким образом, вы получите одинаковое значение (в формате оценки F) в обоих случаях. Но обратите внимание, что если бы у вас были 1.0 и 1.00 соответственно, вы могли бы получить разные значения (маловероятно, в частности, потому что 1.0 точно представим и достаточно прост, но не запрещен стандартом C).

Затем рассмотрим преобразование полученного значения в float. ISO C17 6.3.1.5p1 гласит: «Когда значение реального плавающего типа преобразуется в реальный плавающий тип, если преобразованное значение может быть точно представлено в новом типе, оно остается неизменным». Это случай значения 1, если 1.0 (используется в примере) был преобразован в 1, так что equal в этом случае будет 1. Но если 1.0 было преобразовано в какое-то другое значение, не представимое в float, я думаю, что equal может быть 0 (стандарт C не требует, чтобы преобразование некоторого значения в какой-либо тип всегда давало один и тот же результат, и обратите внимание, что, в частности, это не тот случай, когда изменяется режим округления).