Определено ли поведение округления строковых к двойным методам?
В идеале метод строка-в-двойку всегда будет давать double значение которого было ближе всего к точному числовому значению указанной строки; например, поскольку "102030405060708072.99" находится всего в 7,01 от следующего большего значения, но на 8,99 от следующего меньшего значения, оно должно округляться до следующего более высокого значения. ни Convert.ToDouble ни String.Parse кажется, работает таким образом, однако; оба вызывают округление этого значения в меньшую сторону.
Похоже, что поведение состоит в том, чтобы игнорировать все, что находится за восемнадцатой цифрой, даже если значения за пределами этого холода влияют на то, как все округляется. Есть что-нибудь, что определяет такое поведение? Есть ли что-нибудь, что указывает, что каждое десятичное представление из 18 цифр или меньше будет всегда отображаться на double значение, которое находится не более чем на половине младшего разряда от точного представленного значения, несмотря на тот факт, что числа из 18 цифр или более могут быть сопоставлены значению, которое находится на расстоянии 9/16 младшего разряда от указанного значения?
Основано на том, почему преобразование в обе стороны через строку не безопасно для двойного? казалось бы, что поведение процедур преобразования может варьироваться в зависимости от платформы. В какой степени такое поведение является отклонением от спецификации, и в какой степени спецификация оставляет такое поведение открытым? Есть ли в какой-либо спецификации что-либо, что указывало бы, что добавление 0 до конца дробной части отформатированной double не повлияет на результат разбора?
Я ожидал бы, что методы с плавающей точкой должны определять степень точности, которую они обещают. В отсутствие какой-либо спецификации, противоположной, я ожидал бы, что методы с плавающей запятой дадут результат, который будет в пределах 1/2lsb от арифметически точного результата, который будет получен с некоторой комбинацией числовых операндов, которые были в пределах 1/2lsb из переданных значений, поскольку этот уровень точности часто может быть достигнут примерно за ту же цену, что и любой другой, но за его пределами часто гораздо дороже. Если методу потребуется больше времени для достижения большей точности, он должен указать это (чтобы поощрить код, который должен быть быстрым, но не нуждающимся в полной точности, чтобы рассмотреть более быструю n альтернативу). Код не должен для правильности требовать, чтобы метод, который он использует, был более точным, если только этот метод не обещает большей точности.
R опция форматирования для double Предполагается, что значения в.NET должны давать значение, которое при разборе будет соответствовать исходному операнду, но не указывает, какой метод синтаксического анализа следует использовать для достижения этого результата. Если кто-то хочет преобразовать значения с плавающей запятой в строки таким образом, чтобы гарантировать независимую от системы возможность приема-передачи, что нужно сделать, чтобы гарантировать, что любая законная реализация метода синтаксического анализа будет анализировать его таким же образом?
1 ответ
Я не знаю, поддерживает ли это C#, но стандартная методика (как, например, в стандартах C 99 и более поздних, а также в стандарте IEEE-754 2008 с плавающей запятой) заключается в использовании шестнадцатеричного формата с плавающей запятой, который может представлять число с плавающей запятой. точно без каких-либо округлений.