Почему "dtoa.c" содержит так много кода?
Я буду первым, кто признает, что мои общие знания низкоуровневого программирования немного скудны. Я понимаю многие основные понятия, но не использую их на регулярной основе. При этом я был совершенно изумлен тем, сколько кода было необходимо для dtoa.c.
Последние пару месяцев я работал над реализацией ECMAScript на C# и замедлял заполнение дыр в моем движке. Прошлой ночью я начал работать над Number.prototype.toString, который описан в разделе 15.7.4.2 спецификации ECMAScript (pdf). В разделе 9.8.1 ПРИМЕЧАНИЕ 3 предлагает ссылку на dtoa.c, но я искал проблему, поэтому я ждал ее просмотра. Вот то, что я придумал.
private IDynamic ToString(Engine engine, Args args)
{
var thisBinding = engine.Context.ThisBinding;
if (!(thisBinding is NumberObject) && !(thisBinding is NumberPrimitive))
{
throw RuntimeError.TypeError("The current 'this' must be a number or a number object.");
}
var num = thisBinding.ToNumberPrimitive();
if (double.IsNaN(num))
{
return new StringPrimitive("NaN");
}
else if (double.IsPositiveInfinity(num))
{
return new StringPrimitive("Infinity");
}
else if (double.IsNegativeInfinity(num))
{
return new StringPrimitive("-Infinity");
}
var radix = !args[0].IsUndefined ? args[0].ToNumberPrimitive().Value : 10D;
if (radix < 2D || radix > 36D)
{
throw RuntimeError.RangeError("The parameter [radix] must be between 2 and 36.");
}
else if (radix == 10D)
{
return num.ToStringPrimitive();
}
var sb = new StringBuilder();
var isNegative = false;
if (num < 0D)
{
isNegative = true;
num = -num;
}
var integralPart = Math.Truncate(num);
var decimalPart = (double)((decimal)num.Value - (decimal)integralPart);
var radixChars = RadixMap.GetArray((int)radix);
if (integralPart == 0D)
{
sb.Append('0');
}
else
{
var integralTemp = integralPart;
while (integralTemp > 0)
{
sb.Append(radixChars[(int)(integralTemp % radix)]);
integralTemp = Math.Truncate(integralTemp / radix);
}
}
var count = sb.Length - 1;
for (int i = 0; i < count; i++)
{
var k = count - i;
var swap = sb[i];
sb[i] = sb[k];
sb[k] = swap;
}
if (isNegative)
{
sb.Insert(0, '-');
}
if (decimalPart == 0D)
{
return new StringPrimitive(sb.ToString());
}
var runningValue = 0D;
var decimalIndex = 1D;
var decimalTemp = decimalPart;
sb.Append('.');
while (decimalIndex < 100 && decimalPart - runningValue > 1.0e-50)
{
var result = decimalTemp * radix;
var integralResult = Math.Truncate(result);
runningValue += integralResult / Math.Pow(radix, decimalIndex++);
decimalTemp = result - integralResult;
sb.Append(radixChars[(int)integralResult]);
}
return new StringPrimitive(sb.ToString());
}
Может кто-нибудь с большим опытом в программировании низкого уровня объяснить, почему dtoa.c имеет примерно в 40 раз больше кода? Я просто не могу представить, чтобы C# был намного более продуктивным.
5 ответов
dtoa.c содержит две основные функции: dtoa(), которая преобразует double в строку, и strtod(), которая преобразует строку в double. Он также содержит множество вспомогательных функций, большинство из которых предназначены для собственной реализации арифметики произвольной точности. Утверждение dtoa.c о славе заключается в правильности этих преобразований, что в общем случае возможно только с помощью арифметики произвольной точности. Он также имеет код для правильного округления в четырех различных режимах округления.
Ваш код только пытается реализовать эквивалент dtoa (), и, поскольку он использует числа с плавающей запятой для своих преобразований, не всегда получит их правильными. (Обновление: подробности см. В моей статье http://www.exploringbinary.com/quick-and-dirty-floating-point-to-decimal-conversion/.)
(Я много писал об этом в своем блоге, http://www.exploringbinary.com/. Шесть из моих последних семи статей были посвящены только преобразованиям strtod (). Прочтите их, чтобы увидеть, насколько сложно это сделать. правильно округленные преобразования.)
Получение хороших результатов для преобразования между десятичным и двоичным представлениями с плавающей запятой является довольно сложной задачей.
Основным источником трудностей является то, что многие десятичные дроби, даже простые, не могут быть точно выражены с помощью двоичной плавающей запятой - например, 0.5 может (очевидно), но 0.1 не могу. И, идя другим путем (от двоичного к десятичному), вы обычно не хотите абсолютно точный результат (например, точное десятичное значение ближайшего числа к 0.1 который может быть представлен в IEEE-754-совместимом double на самом деле 0.1000000000000000055511151231257827021181583404541015625) так что вы обычно хотите немного округления.
Таким образом, преобразование часто включает приближение. Хорошие процедуры преобразования гарантируют получение максимально возможного приближения в пределах определенных ограничений (размер слова или количество цифр). Вот откуда большая часть сложности.
Взгляните на цитируемую в комментарии статью в верхней части dtoa.c реализация, Clinger's Как читать числа с плавающей запятой точно, для понимания проблемы; и, возможно, статья Дэвида М. Гея (автор) " Правильно округленные двоично-десятичные и десятично-двоичные преобразования".
(Кроме того, в более общем плане: что должен знать каждый компьютерщик об арифметике с плавающей запятой.)
Если взглянуть на это достаточно быстро, то значительная часть версии C имеет дело с несколькими платформами, и, похоже, этот файл предназначен для общего использования в компиляторах (C & C++), битах, реализациях с плавающей запятой и платформах.; с тоннами #define настраиваемость.
Я также думаю, что код в dtoa.c может быть более эффективным (независимо от языка). Например, кажется, что он делает некоторую путаницу, которая в руках эксперта часто означает скорость. Я предполагаю, что он просто использует менее интуитивный алгоритм по соображениям скорости.
Краткий ответ: потому что dtoa.c работает.
В этом и заключается разница между хорошо отлаженным продуктом и прототипом NIH.