о странном баге

[avva]

Если вы вдруг еще не знаете, то в Excel 2007 обнаружился смешной баг: если умножить, например, 77.1*850, то вместо правильного ответа 65535 Excel напишет 100,000 (сто тысяч). Он при этом сохраняет у себя в памяти правильный ответ, и если, например, его далее умножить на 2, то правильно покажет 131070, а не 200000. Но показывает он неправильно - причем только результаты некоторых операций, которые по идее должны быть равны 65535 или 65536, и только этим двум числам.

Более подробный анализ показал, что на самом деле суть в том, что ошибка происходит при выводе на показ одного из 12 чисел, чрезвычайно близких к 65535 или 65536, но не равных им в точности - например, 65534.99999999995. При умножении, скажем, 77.1*850 в ответе получается не в точности 65535, а одно из этих чисел, из-за неточностей, присущих операциям с плавающей точкой.

Но вот что интересно. Об этом баге отписались уже все кто мог. И сам Майкрософт, и сайты технологических новостей, и вся компьютерная блогосфера, начиная с самого популярного среди программистов блоггера Джоэля. Корпоративный блог Wolfram использовал этот случай, чтобы пропиарить Mathematica. Итд. итп.

И при этом ни у кого нет ни малейшего понятия о том, как этот баг мог случиться (ну, кроме программистов Excel в Майкрософте, а они не признаются).

Как полагается любым компетентным хакерам, мы сразу узнаем 65535 - это 2^16-1. Сразу становится ясно, что это наверняка что-то связанное с неправильной интерпретацией битового значения числа с плавающей точкой. Но вот загвоздка! когда действительно смотришь на эти битовые значения, то ничто подобное не вырисовывается. Никак не получается понять, что такого можно неправильно сделать с теми 12 числами, чтобы воспринять их как 100,000 или 100,001.

Должен признаться, что меня это смешит. Джоэль, и десятки других блоггеров вслед за ним, с умным лицом рассказывают читателям об операциях с плавающей точкой, о представлении чисел в этом формате, о неизбежных погрешностях, о сложностях... а объяснить, как такой баг мог бы возникнуть, совершенно не могут - и тогда становится неясно, какое вообще отношение к этой истории имеют эти объяснения и ликбезы. Может, дело вовсе не в плавающей точке. Единственная версия, которая у меня есть - и это даже версией назвать нельзя: этот баг демонстрирует, что Excel работает с числами как-то исключительно странно и извращенно, возможно, через несколько слоев плохопонятых и неадекватных библиотек, и где-то в иерархии никому до конца не понятных классов происходит какой-то глупый сбой, суть которого не имеет даже и смысле предполагать, потому что она скорее всего навязана этой глупой иерархией, а не какой-то "красивой и простой" причиной вроде неправильной интерпретации битов.

Comments

[ohtori.livejournal.com]

Ну что-то типа "если число равно 100000 минус один, то записать туда 100000".
При этом автор ещё и забыл 0x поставить.
"Excel работает с числами как-то исключительно странно и извращенно, возможно, через несколько слоев плохопонятых и неадекватных библиотек" - это и так было очевидно.
(Понабрали индусов по объявлениям, теперь получают то, чего заслуживают.)

[itman.livejournal.com]

65536 = 0x10000, а не 0x100000

[spamsink]

этот баг демонстрирует, что Excel работает с числами как-то исключительно странно и извращенно

Вот ыменно. У меня было предположение, что какой-то умник решил воспользоваться командами двоично-десятичной арифметики, до сих пор живущими в x86 ISA.

[http://users.livejournal.com/d_m_/]

Возможно, это 12 чисел просто захардкодили? :)

[pappadeux.livejournal.com]

What about Excel for Itanium ?

[nchaly.livejournal.com]

Может, что-то вроде
string visible;
double x;
try
{
x = calculate(formula);
visible = tostring(x);
}
catch
{
visible = "100000"; //oh, dude, fixme, when you have a minute...
}
cell.text = visible;
cell.value = x;

[avva.livejournal.com]

Хаха, вот это был бы номер :)

Нет, сомневаюсь все же, но какая живописная версия!

[http://users.livejournal.com/d_m_/]

Это как раз дополнительный аргумент в пользу версии. В условии было 0x10000, а в присваивании 100000. Из-за лишнего нуля менее заметно отсутствие 0x.

[ohtori.livejournal.com]

Так ведь индусов понабрали. Вот и будут теперь все обтекать.
(Как-то недавно публиковали в сети групповую фотографию разработчиков IE7 - так лучшей рекламы альтернативных браузеров я бы не придумал, даже если бы очень старался.)

[ohtori.livejournal.com]

Коммент рулит, да.

[kcmamu.livejournal.com]

Versija takaja: bylo 0x10000, no "x" gde-to poterjali, i stalo 010000; no uvideli, chto porjadok sovsem ne tot, i podumali, chto po oshibke cifry pereputalisj. Ispravili na 100000.

[spamsink]

Не знаю. В ней тоже ошибка? Вроде бы Итаниум умеет эмулировать x86, так что такой вариант теоретически возможен.

[ly0lik.livejournal.com]

yet another Easter Egg?:)

[spamsink]

Другой вариант заключается в том, что "для скорости" перевод в десятичный вид делается не традиционным образом по одной цифре зараз, а lookup-ом по паре (порядок, несколько старших цифр мантиссы), а потом делается коррекция последней значащей цифры, если надо. Ну и повторили подвиг Пентиума в таблице недоставало пары последних элементов.

[msh.livejournal.com]

Какой-нибудь старый кривой код форматирования с обработкой по два байта, где перепутали > и >=

[trurle.livejournal.com]

Судя по описаниям бага, проблема в форматировании а не в вычислениях или представлении числа.

[slobin.livejournal.com]

Когда-то давно я работал на СМ-3, на которой не было аппаратных команд умножения и деления (целочисленных, о плавающей точке речь вообще не шла). Это два действия делались какими-то стандартными библиотеками, не помню какими. И написал я как-то генератор случайных чисел, что-то вроде ((n * 25173) + 13849) mod 65536 (сразу после написания этого выражения специально нашёл и скачал Грогоно и убедился, что цифры помню верно; вот ведь ерунда в памяти застревает ;-). Довольно быстро оказалось, что в некоторый повторяющийся момент он падает с ошибкой. Тогда я перебрал в цикле все 65536 произведений вида 25173 * n (перебрать 2^32 на тогдашней технике было нереально) и обнаружил, что на двух не то трёх из них библиотечное умножение слетает с ошибкой. Отчего, почему? До сих пор не знаю. Двадцать два года прошло.

... Удивительное - рядом, но оно запрещено ...

[cema.livejournal.com]

И при этом ни у кого нет ни малейшего понятия о том, как этот баг мог случиться (ну, кроме программистов Excel в Майкрософте, а они не признаются).

Да интерн какой-нибудь напортачил.

[ygam.livejournal.com]

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

Я работал в Майкрософт Оффисе в 1994-1998 гг.; в Экселе тогда был и финн, и француз вьетнамского происхождения, и русская. Как будто тогда в продукте не было багов.

[ygam.livejournal.com]

Нет. Эксель написан на си.

[ohtori.livejournal.com]

Возможно, среди чукчей тоже можно найти умнейших людей очень высокой квалификации.
Двух.
Или трёх.
В Майкрософт Оффисе баги были всегда, это верно. Но не настолько же тупые...
Или настолько же?

[ohtori.livejournal.com]

Да, похоже именно на это.
Причём всё это вынесено куда-то в define, которые определены где-то в совершенно другом месте и в другом файле, поэтому на глаз распознать ошибку нереально.

[ygam.livejournal.com]

А таковой существует? На Альфе AXP когда-то был Оффис, но он работал в 32хразрядном режиме.

[ygam.livejournal.com]

Были еще тупее. И несколько там оставил я, родимый. Вы их запишете на счет моей национальности?

Извините, я не могу вас воспринимать всерьёз, и поэтому не стану отвечать подробнее.

[ohtori.livejournal.com]

Да я вроде ничего серьёзного здесь и не пишу, так что никаких обид быть не может.