Ошибка Round-дважды в методе .NET Double.ToString

Ответ 1

Итак, из ваших экспериментов кажется, что Double.ToString не делает правильного округления.

Это довольно неудачно, но не особенно удивительно: правильное округление двоичных к десятичным преобразованиям является нетривиальным, а также потенциально довольно медленным, требующим многоточечной арифметики в угловых случаях. См. David Gay dtoa.c code здесь для одного примера того, что связано с правильно округленным преобразованием double-to-string и string-to-double. (Python в настоящее время использует вариант этого кода для своих преобразований float-to-string и string-to-float.)

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

Может существовать предел, определенный реализацией, по числу значимые цифры, которые могут быть преобразованы с правильным округлением в и из поддерживаемых двоичных форматов. Этот предел H должен быть таким, что H ≥ M + 3, и должно быть, что H неограничен.

Здесь M определяется как максимум Pmin(bf) по всем поддерживаемым двоичным форматам bf, а так как Pmin(float64) определяется как 17, а .NET поддерживает формат float64 с помощью типа Double M должен быть не менее 17 в .NET. Короче говоря, это означает, что если .NET будет следовать стандарту, он будет обеспечивать корректное округленное преобразование строк, по меньшей мере, до 20 значащих цифр. Таким образом, похоже, что .NET Double не соответствует этому стандарту.

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

EDIT: Jeppe Stig Nielsen указывает, что страница System.Double в MSDN заявляет, что

Двойной соответствует стандарту IEC 60559: 1989 (IEEE 754) для двоичных арифметика с плавающей запятой.

Мне не ясно, что именно этот оператор соответствия должен охватывать, но даже для более старой версии IEEE 754 в 1985 году описанное преобразование строк нарушает требования двоичного к десятичному значению этого стандарта.

Учитывая это, я с радостью повышу свою оценку до "возможной ошибки".

Ответ 2

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

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

31.0000000000000480 = 0x403f00000000000e
31.0000000000000497 = 0x403f00000000000e
31.0000000000000515 = 0x403f00000000000e

Как отмечалось несколькими другими, это связано с тем, что ближайший представимый двойник имеет точное значение 31.00000000000004973799150320701301097869873046875.

Есть два дополнительных аспекта, которые следует учитывать при прямом и обратном преобразовании IEEE 754 в строки, особенно в среде .NET.

Сначала (я не могу найти первичный источник) из Википедии мы имеем:

Если десятичная строка, содержащая не более 15 значащих десятичных знаков, преобразуется к двойной точности IEEE 754, а затем преобразован обратно в тот же число значащих десятичных чисел, то окончательная строка должна соответствовать оригинал; и если двойная точность IEEE 754 преобразуется в десятичная строка с не менее чем 17 значащими десятичными знаками, а затем преобразованная назад, чтобы удвоить, то окончательное число должно соответствовать оригиналу.

Поэтому, в отношении соответствия стандарту, преобразование строки 31.0000000000000497 в double не обязательно будет одинаковым при преобразовании обратно в строку (слишком много десятичных знаков).

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

Кроме того, документация по Double.ToString() показывает, что она определяется спецификатором числового формата текущих настроек культуры.

Возможное полное объяснение:

Я подозреваю, что двойное округление происходит примерно так: начальная десятичная строка создается на 16 или 17 значащих цифр, потому что это требуемая точность для конверсии "туда и обратно", дающая промежуточный результат 31.00000000000005 или 31.000000000000050. Затем из-за настроек культуры по умолчанию результат округляется до 15 значащих цифр, 31.00000000000001, поскольку 15 значащих десятичных цифр являются минимальной точностью для всех удвоений.

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

Ответ 3

Вопрос: Разве это не ошибка?

Да. См. этот PR на GitHub. Причина округления дважды AFAK - для вывода "симпатичного" формата, но он вводит ошибку, как вы уже обнаружили здесь. Мы попытались его исправить - удалите прецизионное преобразование на 15 цифр, прямо перейдите к преобразованию точности 17 цифр. Плохая новость - это потрясающее изменение и многое сломает. Например, один из тестовых примеров сломается:

10:12:26 Assert.Equal() Failure 10:12:26 Expected: 1.1 10:12:26 Actual: 1.1000000000000001

Фиксирование повлияет на большой набор существующих библиотек, поэтому, наконец, этот PR уже закрыт. Тем не менее, команда .NET Core по-прежнему ищет шанс исправить эту ошибку. Добро пожаловать, чтобы присоединиться к обсуждению.

Ответ 4

У меня более простое подозрение: виновником, скорее всего, является оператор pow = > **; Хотя ваш номер точно представлен как двойной, для удобства (силовому оператору требуется много работы для правильной работы), мощность рассчитывается по экспоненциальной функции. Это одна из причин, по которой вы можете оптимизировать производительность умножая число раз вместо использования pow(), потому что pow() очень дорогой.

Таким образом, он не дает вам правильного 2 ^ 48, но что-то немного неправильное и поэтому у вас проблемы с округлением. Проверьте, что именно возвращается 2 ^ 48. Забастовкa >

EDIT: Извините, я просмотрел только проблему и дал неправильное подозрение. Там есть известная проблема с двойным округлением на процессорах Intel. Более старый код использует внутренний 80-битный формат FPU вместо инструкций SSE, который, вероятно, чтобы вызвать ошибку. Значение записывается точно в регистр 80 бит, а затем округленный дважды, поэтому Джеппе уже нашел и аккуратно объяснил проблему.

Это ошибка? Ну, процессор делает все правильно, это просто проблема в том, что Intel FPU внутренне имеет более высокую точность для плавающих точек операции.

ДАЛЬНЕЙШАЯ РЕДАКТИРОВКА И ИНФОРМАЦИЯ: "Двойное округление" является известной проблемой и явно упоминается в "Справочнике по арифметике с плавающей точкой" Жан-Мишеля Мюллера и др. и др. в главе "Необходимость для пересмотра "под" 3.3.1 Типичная проблема: "двойное округление" на стр. 75:

Используемый процессор может предложить внутреннюю точность, которая шире чем точность переменных программы (типичный пример это формат с двойным расширением, доступный на платформах Intel, когда переменные программы являются одноточечными или с двойной точностью числа с плавающей запятой). Иногда это может иметь странные побочные эффекты, поскольку мы увидим в этом разделе. Рассмотрим программу C [...]

#include <stdio.h>

int main(void) 
{
  double a = 1848874847.0;
  double b = 19954562207.0;
  double c;
  c = a * b;
  printf("c = %20.19e\n", c);
  return 0;
}

32bit: GCC 4.1.2 20061115 для Linux/Debian

С Compilerswitch или с -mfpmath = 387 (80 бит-FPU): 3.6893488147419103232e + 19 -march = pentium4 -mfpmath = sse (SSE) или 64-бит: 3.6893488147419111424e + 19

Как объясняется в книге, решение для несоответствия - это двойное округление с 80 бит и 53 бит.