Как стать автором
Обновить

Комментарии 30

Как бы самое технически интересное (письма и посты) и не переведено.
Зато смешные x.9999abcd числа, да
Я уж было начал их сравнивать, пытаясь «реверснуть реализацию алгоритма» автора статьи. Правда, после 10-го числа (и увидев, что до конца статьи их еще больше) пришел к выводу, что все-таки рандом.

При этом как минимум .9999973251 встречается дважды.
так вперед, сел и перевел…
Я так и не понял, почему штеуд затроллили?
Ошибка довольно маленькая, плюс надеяться на точность ограниченных флоатов — это странно.
Что значит «надеяться»? У флоатов есть гарантированная оценка точности операций, и есть целая теория оценки погрешности вычислений, опирающаяся на неё
Кроме уже сказанного про теорию погрешности вычислений (которая уже очень хорошо развита) — IEEE754, в частности, добивался, чтобы была возможность гарантированно повторить одни и те же результаты — даже если они заведомо неточны — на любых соответствующих стандарту системах, и результаты должны совпадать. Любые подобные «незначительные ошибки в десятом знаке» нарушают гарантию воспроизводимости и ставят под сомнение все результаты расчётов.
Вообще-то если уж так досконально, то следовало бы указать:
Что событие произошло на самом деле 30 октября в 12 часов 18 минут 32.0005 секунды
а 30 октября в 12 часов 18 минут 31.9995 секунды.

А не писать околополуночные даты в никому не привычном формате.
А не писать околополуночные даты в никому не привычном формате.

Borlandовский формат прям.
А причем тут все-таки Pentium Pro? Он же был анонсирован в конце 1995-го?
Причём здесь Pentium Pro?
Это не Pentium Pro.
Это был первый Pentium модели на 60 и 66 мгц. Мне вот даже довелось такой в руках подержать.
В заголовке указан Pentium Pro.
Ну и, кстати, ранние степпинги Pentium 75/90/100 тоже содержали этот баг.
Все таки хорошо что нашли данную ошибку. Неизвестно какие редкие ошибки еще существуют в современных процессорах.
Не значительные, не влияющие на работу обычного пользователя
Они постоянно появляются. Например, «замерзание» SkyLake, которое лечится новым микрокодом, или ошибки в TSX, которые не лечатся (соответственно, всё до SkyLake реально не умеет TSX). Да и вообще, новый микрокод всегда что-то лечит :)
Разница с описанной в статье ситуацией — что ведущие производители 1) поняли, что лучше сразу сказать об ошибке, чем долго и нудно заметать под ковёр и в итоге таки потерять в репутации, 2) научились продумывать методы программного лечения (даже если это выключение недоработанных режимов или активация более медленного аналога).
Ошибки сейчас тоже встречаются. Только уже, наверное, причины другие.
Вот что покажет калькулятор если использовать только числа -8.88 и 1/-1:
Калькулятор на мак
-8.879999999999999 * 1
= -8,88

-8.799899999999999 / 1
= -8,7999

-8.799899999999999 / 1 * 1
= -8,7999

-8.799899999999999 / 1 * 1 * -1
= 8,7999

8,88
= 8,88

-8.879999999999999
= -8,88

Мне кажется, калькуляторы должны считать не с помощью float и double, а «посимвольно», «столбиком». На скорость появления ответа для человека это не повлияет, но зато таких странных результатов не будет.
Даже калькулятор от Microsoft умеет в длинную арифметику. И ещё лет пятнадцать назад умел. И есть куча библиотек для этого. Так что — Apple «молодцы».
Дефолтный калькулятор под линуксом даёт такие же результаты, Wolframalpha и Mathematica — тоже. Дело не в Apple.
Я думаю в Wolframalpha и Mathematica, в отличии от штатного калькулятора точность округлений настраивается. По крайней мере в MathCad точно настраивалась.
Не могу понять, зачем человеку в базовом калькуляторе настраивать точность. MathCad и Mathematica — пакеты для вычислений, вполне логично, что там доступна подобная опция.
Я нигде не писал что в калькуляторе обязательно должна настраиваться точность. Я вам попытался донести почему в Wolframalpha и Mathematica такой результат вполне нормален.

Так как калькуляторе точность не настраивается (кстати, а почему нет?), было бы логично видеть в нём максимально точный результат.

Кстати, дабы быть совсем объективным, в штатном калькуляторе Windows 7, вышеприведённых округлений не происходит.
Это как? Каждый разряд записывать в отдельный int что-ли? А потом считать?
Представляете себе во сколько раз сложнее будет такая «арифметика»?

Или это только для приложения «калькулятор»? А остальное оставить с ошибками? Типа пишем медицинский софт как есть, «если че потом в виндовс-калькуляторе проверим»?
Для этого давно сделаны отдельные библиотеки/классы, например BigDecimal в Java
Поэтому в десятке сделали новый, модный калькулятор. Который считает быстро, но пока он запустится уже успеваешь забыть зачем его запускал.
Ну и деньги считать во float это тоже хороший такой выстрел в ногу.
История стоила Intel более половины прибыли за последний квартал 1994 года — $475 000 000.

Из чего, интересно, сложились столь высокие убытки? Тем более, что даже массового отзыва процессора не было
Intel не смогла определить число выпущенных дефектных процессоров… Intel заявила, что они не считают необходимым отзывать процессор

Или это с учетом упущенной прибыли?
Странно, что баг впервые не был замечен в Monte-Carlo расчётах. В некоторых их реализациях такой баг был бы очень заметен в выходном массиве данных, как заметны, например, особенности любых генераторов псевдослучайных чисел.
из той же оперы
хотел ссылку вставить. https://habrahabr.ru/post/171359/
Странно, я в то время где-то читал, что «ошибка проявляется только в cyrix-ах».
Зарегистрируйтесь на Хабре , чтобы оставить комментарий