Влияет ли знак на точность и точность чисел с плавающей запятой?

TLDR: Теоретически знак может влиять на результаты, на практике — нет.

Стандарт чисел с плавающей запятой — IEEE-754 . Он указывает, что знак кодируется в отдельном бите. Это означает, что, в отличие от целых чисел, в которых используется дополнение до двух, диапазон точно симметричен относительно нуля. Ни мантисса, ни показатель степени не зависят от знака. Поэтому знак не влияет на точность.

Однако IEEE-754 позволяет различные режимы округления работать с младшим битом мантиссы (внутренне процессор выполняет вычисления с большим количеством битов, а затем округляет до ближайшего представления с плавающей запятой). Если вы измените режим округления на положительную или отрицательную бесконечность, это повлияет на результаты. Но это делается редко (если вообще когда-либо), и вам придется согласиться на такое изменение поведения; это не значение по умолчанию.

Даже если вы пишете библиотеку, вероятно, проще просто обязать ее вызывать из стандартной математической среды. В противном случае вам, возможно, придется беспокоиться о перехвате математических данных и передаче сигналов NaN. Не каждая аппаратная реализация также поддерживает изменение режима округления, например, графические процессоры обычно этого не делают или только с помощью явных инструкций (CUDA , OpenCL ). Не обращать внимания на это также соответствует поведению GCC по умолчанию:

Без каких-либо явных опций GCC предполагает округление до ближайшего или четного и не заботится о передаче сигналов NaN.

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

Ожидание того, что диапазон симметричен, также заложено во многих кодах, включая стандартные библиотеки. Например, в C++ до C++11 было std::numeric_limits<float>::max() для наибольшего конечного положительного значения и std::numeric_limits<float>::min() для наименьшего ненулевого, нормализованного положительного значения. Если вам нужно было максимально отрицательное конечное значение, вам нужно было отрицать max().

Это изменилось только в C++11 с std::numeric_limits<float>::lowest(), но не изменилось для самого C, который использует аналогичные макросы float.h. Он также по-прежнему оставляет пробелы, например, нет прямого способа получить первое нормализованное отрицательное число ниже нуля. Стандарт ожидает, что вы просто будете отрицать min().

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

#include <stdio.h>
#include <fenv.h>
#pragma STDC FENV_ACCESS ON

int main()
{
    double a =  1.0 / 3.0;
    double b = -1.0 / 3.0;
    if (a != -b) printf("unexpectedly unequal #1\n");

    fesetround(FE_DOWNWARD);

    a =  1.0 / 3.0;
    b = -1.0 / 3.0;
    if (a != -b) {
        printf("unexpectedly unequal #2:\n");
        printf("a = % .20f\n", a);
        printf("b = % .20f\n", b);
    }
}

При компиляции под clang v. 14.0.3 на моем Mac (как C, так и C++) этот код печатает «неожиданно неравный #2», со значениями a и b, отображаемыми как:

a =  0.33333333333333331482
b = -0.33333333333333337035

[Оглядываясь назад, я впечатлен тем, что это сработало именно так. Либо clang отказывается выполнять свертывание констант с плавающей запятой во время компиляции, либо оценивает эффект вызова fesetround во время компиляции.]

[Также обратите внимание, что изменение режима округления повлияло на способ printf отображения чисел. При обычном округлении это были бы 0.33333333333333331483 и -0.33333333333333337034.]

Обновление: этот пример кода не работает (не печатает «неожиданно неравный #2») под gcc, я подозреваю, потому что gcc продолжает сворачивать константы во время компиляции. По крайней мере, в gcc v. 13.1.0 достаточно создать глобальные переменные double one = 1.0; и double three = 3.0;, а затем использовать one и three в различных вычислениях a и b.