Comments 75
В принципе, достаточно доходчиво объяснено. А то оооочень много личностей даже понятия не имеют что там внутри double. Буду теперь новичкам этот пост показывать. Спасибо.
Очень интересный пост, очень понятно объясняется и главное по полочкам.
Но все равно силился час пока прочел и смог запомнить хотя бы часть.
Огромное спасибо.
Но все равно силился час пока прочел и смог запомнить хотя бы часть.
Огромное спасибо.
Огромное спасибо за пост! Пару поправок:
1. портабельность
2. int должен быть не только 32-битным, но и little-endian (x86, к примеру)
1. портабельность
2. int должен быть не только 32-битным, но и little-endian (x86, к примеру)
Про порядок байт — под вопросом
Смотря оговорена ли endianness для float'ов в IEEE или же наследует int'овую
Согласен.
Для заинтересовавшихся: раздел A Final Comment по ссылке www.quadibloc.com/comp/cp0201.htm
Для заинтересовавшихся: раздел A Final Comment по ссылке www.quadibloc.com/comp/cp0201.htm
Портабельность → переносимость
Мне всегда казалось, что Floating Point всеже подразумевает плавающую точку.
В смысле термин буржуйский и перевод нужен нормальный, а то както в шок вводит немного.
Я консультировался с разработчиками стандартов в Украине. Оба перевода правильные, а в стандартах пишут через слеш (плавающая точка/запятая). Последний мне показался самобытнее и ближе к традиции.
лучше бы проконсультировался с правилами русского языка…
> Любознательный читатель вероятно уже замеЛил
>Последний мне показался самобытнее и ближе к традиции.
Как по мне, так лучше бы «ближе к общепринятой терминологии» (а то «ближе к традиции» порой приводит к «блогозаписи» и прочим «междумордиям»).
Но на то вы и автор, чтобы решать самостоятельно.
Как по мне, так лучше бы «ближе к общепринятой терминологии» (а то «ближе к традиции» порой приводит к «блогозаписи» и прочим «междумордиям»).
Но на то вы и автор, чтобы решать самостоятельно.
Ну это как бы не для лингвистов перевод. А для программистов, которые ещё со времён совка называем это арифметикой с плавающей запятой.
Давайте ещё команды ассемблера на русский язык, корректно переведём.
Давайте ещё команды ассемблера на русский язык, корректно переведём.
UFO just landed and posted this here
Нормальный перевод. У них запятая иногда — разделитель троек десятичных разрядов. У нас же запятая отделяет дробную часть. Так что 1,001 чревато мисспеллингом =)
Статья — торт.
>компьютер должен оперировать рациональными числами, которых, как известно, континуум
Извиняюсь за занудство, но рациональных чисел все-таки счетное число. Это поменьше чем континуум.
Извиняюсь за занудство, но рациональных чисел все-таки счетное число. Это поменьше чем континуум.
Самое главное не сказано в статье — нельзя использовать float/double для рассчетов с деньгами. Только числа с фиксированой запятой. Иначе на огруглениях можно много потерять и потом баланс не сойдется.
Согласен. Тем более, если мы будем считать миллиарды, можем потерять не только копейки, но и рубли.
на этом в Англии один подросток банк на несколько тысяч фунтов обставил
вообще-то double (64-bit) хранит 53 двоичных цифры (+ 11 цифр экспоненты + 1 цифру знака), а это чуть больше 19 десятичных цифр. Соответственно, при счёте миллиардов мы не только не потеряем ни копейки, но даже учтём миллиардные доли копейки
чёрт, соврал, речь про extended — 80-bit — именно такие регистры в математических сопроцессорах, наследниках i8087. Они помнят по 19 знаков.
double, конечно, помнит чуть больше 15 знаков. Ну то есть, если считать миллиарды, то учтём только лишь стотысячные доли копейки, какая жалость
double, конечно, помнит чуть больше 15 знаков. Ну то есть, если считать миллиарды, то учтём только лишь стотысячные доли копейки, какая жалость
Все зависит от того, что мы с этими числами будем делать. Кроме округления при представлении источником ошибок являются арифметические операции, которые тоже вносят погрешность. Эффект получается кумулятивный.
>Ну то есть, если считать миллиарды, то учтём только лишь стотысячные доли копейки, какая жалость
Что случится после 100 миллионов операций с погрешностью в стотысячные доли копеек каждая?
Что случится после 100 миллионов операций с погрешностью в стотысячные доли копеек каждая?
Во-первых, это зависит от рода операций, а во-вторых — погрешности не растут линейно.
Если вы имеете ввиду сложение близких по порядку чисел, т.е. определённых с одинаковой абсолютной погрешностью, то абсолютная погрешность их суммы будет в sqrt(100 миллионов) раз больше.
Если вы имеете ввиду сложение близких по порядку чисел, т.е. определённых с одинаковой абсолютной погрешностью, то абсолютная погрешность их суммы будет в sqrt(100 миллионов) раз больше.
>… во-вторых — погрешности не растут линейно.
Конечно, не линейно. Иногда они имеют свойство перемножаться, т.е. расти экспоненциально :) Грубо говоря, не «100М * 0.0000001», а «1.0000001^100М», а это уже са-а-аффсем другой разговор получится.
Вы, безусловно, правы, и всё зависит от рода операций, но я думаю, финансисты будут очень возражать, если им сказать «наша система в целом работает нормально, но на некоторых операциях может накапливаться погрешность» %)
Конечно, не линейно. Иногда они имеют свойство перемножаться, т.е. расти экспоненциально :) Грубо говоря, не «100М * 0.0000001», а «1.0000001^100М», а это уже са-а-аффсем другой разговор получится.
Вы, безусловно, правы, и всё зависит от рода операций, но я думаю, финансисты будут очень возражать, если им сказать «наша система в целом работает нормально, но на некоторых операциях может накапливаться погрешность» %)
Хорошо, предположим что ваш тезис о недопустимости финансовых расчетов с помощью арифметики с плавающей точкой верен. А какие в таком случае альтернативы? Если имеется счет, на который была внесена сумма в ххх.xx рублей с процентной ставкой yy.yy% в месяц и накопительным процентом (я забыл как называется этот термин правильно) — то какая сумма должна быть на счете через z1 дней, если через z2 дней клиент захочет снять треть вклада? Посчитайте это без использования плавающей точки, перемножьте на количество клиентов в банке и сравните получившиеся погрешности. Так или иначе придется «вручную» совершать те же операции нормализации и округления до приемлемых порядков.
На самом деле главный затык даже не в округлении как таковом, а именно в плавающей точке и в ограниченности длины мантиссы. При добавлении малых величин к большим, младшие разряды могут банально потеряться, т.к. просто не влезут в мантиссу.
Простой пример: просуммировать числа вида 1/n при n от 1 до какого-нибудь K. При малых K нет никакой разницы, суммировать от меньшего к большему или от большего к меньшему. Но как только K cтановится достаточно большим, разница становится заметной на глаз.
Простейший тест:
даст разницу 0.000007 для 1К итераций, 0.000009 для 10К итераций и 0.000023 для 20К итераций. А казалось бы, «от перестановки мест слагаемых сумма не меняется»… :)
Происходит это вот почему:
При подсчёте sum1 в неё сразу кладётся 1, фиксируя экспоненту, после чего начинают добавляться всё более мелкие числа. В итоге последние из них банально «обрубаются» (если не полностью, то частично), т.к. попросту не влазят в мантиссу.
При подсчёте sum2, напротив, сначала берутся более мелкие числа, которые накапливаются постепенно, отбрасывая младшие разряды по одному по мере роста экспоненты.
Конечно, double немного «отодвигает» эту проблему, но в некоторых особо точных расчётах и его может не хватить (особенно с учётом накладывающейся погрешности округления).
Простой пример: просуммировать числа вида 1/n при n от 1 до какого-нибудь K. При малых K нет никакой разницы, суммировать от меньшего к большему или от большего к меньшему. Но как только K cтановится достаточно большим, разница становится заметной на глаз.
Простейший тест:
#include <stdio.h>
void main(int argc, char* argv[]) {
float sum1 = 0.f;
float sum2 = 0.f;
int n = 20000;
int i;
printf("%i numbers\n", n);
for ( i = 1; i <= n; ++i ) {
sum1 += 1.f / i;
sum2 += 1.f / (n + 1 - i);
}
printf("%f\n", sum1 - sum2);
}даст разницу 0.000007 для 1К итераций, 0.000009 для 10К итераций и 0.000023 для 20К итераций. А казалось бы, «от перестановки мест слагаемых сумма не меняется»… :)
Происходит это вот почему:
При подсчёте sum1 в неё сразу кладётся 1, фиксируя экспоненту, после чего начинают добавляться всё более мелкие числа. В итоге последние из них банально «обрубаются» (если не полностью, то частично), т.к. попросту не влазят в мантиссу.
При подсчёте sum2, напротив, сначала берутся более мелкие числа, которые накапливаются постепенно, отбрасывая младшие разряды по одному по мере роста экспоненты.
Конечно, double немного «отодвигает» эту проблему, но в некоторых особо точных расчётах и его может не хватить (особенно с учётом накладывающейся погрешности округления).
> но в некоторых особо точных расчётах и его может не хватить
вот это я и пытаюсь спросить — каким образом вы собираетесь делать «особо точные расчеты», если не использовать те же алгоритмы с увеличенной разрядностью? ладно, умножение в столбик я представляю как реализовать. а деление и прочие синусы?
вот это я и пытаюсь спросить — каким образом вы собираетесь делать «особо точные расчеты», если не использовать те же алгоритмы с увеличенной разрядностью? ладно, умножение в столбик я представляю как реализовать. а деление и прочие синусы?
>вот это я и пытаюсь спросить — каким образом вы собираетесь делать «особо точные расчеты», если не использовать те же алгоритмы с увеличенной разрядностью?
Считать и целую, и дробную части как отдельные целые (сбрасывая определённый старший разряд из копеек в рубли переполнении). Тем самым можно и рубли посчитать до милионов, и копейки до миллионных долей, «мантисса» получается достаточно широкой, а точка зафиксирована (в простейшем случае — ровно на середине).
Считать и целую, и дробную части как отдельные целые (сбрасывая определённый старший разряд из копеек в рубли переполнении). Тем самым можно и рубли посчитать до милионов, и копейки до миллионных долей, «мантисса» получается достаточно широкой, а точка зафиксирована (в простейшем случае — ровно на середине).
Бухгалтерские рассчёты традиционно организованы как операции с фиксированной запятой. Именно так:
только лишь с той разницей, что достаточно мелкие числа вообще непредставимы при таком подходе. Фиксируя запятую, мы фиксируем экспоненту. Фиксированная запятая означает фиксированную абсолютную погрешность. Т.е. считаем мы всегда с точностью «до копейки», неважно, что именно считаем — копейки или миллиарды рублей.
Мы не приобретаем дополнительной точности при округлении. Напротив, для достаточно мелких (но ещё представимых) чисел округление приводит к катастрофическому росту относительной погрешности. Как вы понимаете, этого не происходит для чисел с плавающей запятой, кроме денормализованных, которые фактически есть числа с фиксированной запятой. Для них округление всегда происходит в далёком младшем разряде, относительная погрешность округления всегда не более 2^-52 (для double).
Для организации фиксированной запятой используется обычная целочисленная арифметика, которая гораздо проще, а значит надёжнее и быстрее. (Запятая фактически появляется только при выводе чисел на экран.)
Этого вполне достаточно для бухгалтерии. Там очень сильно ограничен диапазон чисел, с которыми они работают, и большой диапазон чисел, который даёт плавающая запятая, просто не нужен. А (не нужной им) точностью они готовы пожертвовать в пользу надёжности и скорости (вспомните, всё это образовалось полвека назад, когда компьютеры были большими).
При подсчёте sum1 в неё сразу кладётся 1, фиксируя экспоненту, после чего начинают добавляться всё более мелкие числа. В итоге последние из них банально «обрубаются» (если не полностью, то частично), т.к. попросту не влазят в мантиссу.
только лишь с той разницей, что достаточно мелкие числа вообще непредставимы при таком подходе. Фиксируя запятую, мы фиксируем экспоненту. Фиксированная запятая означает фиксированную абсолютную погрешность. Т.е. считаем мы всегда с точностью «до копейки», неважно, что именно считаем — копейки или миллиарды рублей.
Мы не приобретаем дополнительной точности при округлении. Напротив, для достаточно мелких (но ещё представимых) чисел округление приводит к катастрофическому росту относительной погрешности. Как вы понимаете, этого не происходит для чисел с плавающей запятой, кроме денормализованных, которые фактически есть числа с фиксированной запятой. Для них округление всегда происходит в далёком младшем разряде, относительная погрешность округления всегда не более 2^-52 (для double).
Для организации фиксированной запятой используется обычная целочисленная арифметика, которая гораздо проще, а значит надёжнее и быстрее. (Запятая фактически появляется только при выводе чисел на экран.)
Этого вполне достаточно для бухгалтерии. Там очень сильно ограничен диапазон чисел, с которыми они работают, и большой диапазон чисел, который даёт плавающая запятая, просто не нужен. А (не нужной им) точностью они готовы пожертвовать в пользу надёжности и скорости (вспомните, всё это образовалось полвека назад, когда компьютеры были большими).
Надо показать эту статью Навальному =)
Добавлю, что в .NET можно использовать decimal для рассчетов с деньгами
надо было еще про денормализованные числа написать
Всегда было гораздо интереснее — как именно нужно изменить знакомые формулы, чтобы компьютер с плавающей запятой считал по ним точнее (ну хотя бы вообще получал хоть что-то похожее).
А то есть вот такая формула для синуса (ряд Маклорена): x-x^3/3!+x^5/5!-…
Хорошая формула. Радиус сходимости — бесконечность. Только вот если считать с её помощью на компьютере (скажем, заканчивать, когда очередное слагаемое меньше затребованной погрешности), чуть отойдёшь от нуля — и всё, получаются совершенно несуразные результаты…
А то есть вот такая формула для синуса (ряд Маклорена): x-x^3/3!+x^5/5!-…
Хорошая формула. Радиус сходимости — бесконечность. Только вот если считать с её помощью на компьютере (скажем, заканчивать, когда очередное слагаемое меньше затребованной погрешности), чуть отойдёшь от нуля — и всё, получаются совершенно несуразные результаты…
Простого ответа нет — есть целая теория как делать формулы более устойчивыми к арифметике с плавающей запятой, основанная на анализе погрешности и алгебре. Несколько примеров с доказательствами есть в этой книжке.
Это наука называется «вычислительные методы» :-)
Уильям Кэхэн написал программу на Си (есть версия и для Фортрана), которая позволяет проверить удовлетворяет ли связка «архитектура+компилятор+опции» IEEE754.
От людей, занимающихся мат моделированием на физ-техе, слышал, что Fortran используется для этих целей как раз потому, что на всех платформах выдаёт один и тот же результат для операций с плавающей точкой. Это его главное преимущество в глазах учёных перед другими языками. Однако из ваших слов следует, что это не так. Объясните, пожалуйста: меня обманули? Или чего-то недосказали?
быть не может. Фортран — компилируемый, значит в итоге получим машинный код, который выполняется на конкретной машине, у которой конкретная архитектура АЛУ, либо если оное отсутствует, какая-то конкретная библиотека эмуляции арфиметики. Вот и получили запвисимость от реализации.
Фортран используется исключительно по традиции:
в университетах живёт, здравствует и преподаёт куча именитых аксакалов, которые слышать не хотят про C, Python и т. п. и библиотеки вычислений с произвольной точностью
есть куча прекрасной учебной и справочной литературы по численным методам с примерами и даже готовыми текстами программ на Фортране. В качестве примера вспоминается двухтомник Хайрера, Нёрсета и Виннера про численное решение систем дифференциальных уравнений с упоминанием исходных текстов знаменитых и нашумевших в своё время программ Дормана-Принса
есть куча самих этих программ и библиотек на Форнтране. Хотя некоторые библиотеки в принципе можно скомпоновать с модулями, написанными на других языках, есть и такие, которые не скомпонуешь
в университетах живёт, здравствует и преподаёт куча именитых аксакалов, которые слышать не хотят про C, Python и т. п. и библиотеки вычислений с произвольной точностью
есть куча прекрасной учебной и справочной литературы по численным методам с примерами и даже готовыми текстами программ на Фортране. В качестве примера вспоминается двухтомник Хайрера, Нёрсета и Виннера про численное решение систем дифференциальных уравнений с упоминанием исходных текстов знаменитых и нашумевших в своё время программ Дормана-Принса
есть куча самих этих программ и библиотек на Форнтране. Хотя некоторые библиотеки в принципе можно скомпоновать с модулями, написанными на других языках, есть и такие, которые не скомпонуешь
Простите за занудство, но у вас в табличке «x > y? y: x» повторяется дважды.
Уж больно статья хорошая, хочется, чтобы даже досадных опечаток в ней не было. :)
Уж больно статья хорошая, хочется, чтобы даже досадных опечаток в ней не было. :)
Про округление: помимо описанного способа округления, используемого по умолчанию, стандарт IEEE 754-2008 предусматривает еще 4 режима округления: в сторону 0, +inf, -inf и до ближайшего в сторону 0.
Также стандарт определяет два типа NaN: Quiet и Signaling. Первый молча передает значение NaN в последующие вычисления, в то время как операции над вторым приводят к исключению.
Про денормализованные числа полезно знать, что работа с ними, даже если она реализована в железе, как правило, выполняется гораздо медленнее (в десятки раз), чем с нормализованными числами. Поэтому в приложениях, нечувствительных к точности, но где важно быстродействие (3D графика, обработка сигналов), зачастую используется режим flush-to-zero. Многие FPU такой режим поддерживают аппаратно.
Это так, небольшие дополнения. Статья суперская!
Также стандарт определяет два типа NaN: Quiet и Signaling. Первый молча передает значение NaN в последующие вычисления, в то время как операции над вторым приводят к исключению.
Про денормализованные числа полезно знать, что работа с ними, даже если она реализована в железе, как правило, выполняется гораздо медленнее (в десятки раз), чем с нормализованными числами. Поэтому в приложениях, нечувствительных к точности, но где важно быстродействие (3D графика, обработка сигналов), зачастую используется режим flush-to-zero. Многие FPU такой режим поддерживают аппаратно.
Это так, небольшие дополнения. Статья суперская!
Что такое субнормальные денормализованные (subnormal) числа рассмотрим на простом примере. Пусть имеем нормализованное представление с длиной мантиссы P=3 (бита) и диапазоном значений экспоненты -1≤E≤2. В этом случае получим 16 чисел:
В вашем примере длина мантиссы 2 бита.
float a=0.5; int n = *((int*) &a); float b = *((int*) &(++n)); ...
s/float b = *((int*) &(++n));/float b = *((float*) &(++n));/... if (aInt < 0) aInt = 0x80000000 - aInt; ... if (bInt < 0) bInt = 0x80000000 - bInt; ...
Для знаковых целых:
0x80000000 <= aInt
0x80000000 <= bInt
Поэтому должна быть либо сумма:
aInt = 0x80000000 + aInt;
...
bInt = 0x80000000 + bInt;
либо разность с обратным знаком:
aInt = aInt - 0x80000000;
...
bInt = bInt - 0x80000000;
Ну, или:
...
/*
if (aInt < 0)
aInt = 0x80000000 - aInt;
...
*/
aInt &= 0x7fffffff;
...
/*
if (bInt < 0)
bInt = 0x80000000 - bInt;
...
*/
bInt &= 0x7fffffff;
Да, вы правы. Большое спасибо за замечания!
Вам спасибо, статья отличная!
статья полезная, но не стоило менять правильное на неправильное))
В приведенной ссылке www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm, функция AlmostEqual2sComplement написана корректно.
Там именно должно быть
Потому что порядок float совпадает с порядком sign-and-magnitude integer. В то время как процессоры оперируют two's complement integer. Чтобы найти расстояние между двумя float в ulp, нужно одно перевести в другое и это делается через
Обрезка знакового бита через
Плюс, есть еще замечательные грабли, которые имеются и у Bruce Dawson.
В приведенной ссылке www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm, функция AlmostEqual2sComplement написана корректно.
Там именно должно быть
if (aInt < 0)
aInt = 0x80000000 - aInt;
Потому что порядок float совпадает с порядком sign-and-magnitude integer. В то время как процессоры оперируют two's complement integer. Чтобы найти расстояние между двумя float в ulp, нужно одно перевести в другое и это делается через
0x80000000 - aInt для отрицательных float.Обрезка знакового бита через
&= 0x7fffffff; приведет к тому, что функция будет считать равными числа отличающиеся знаком (например +1 будет равен -1)Плюс, есть еще замечательные грабли, которые имеются и у Bruce Dawson.
int intDiff должен быть unsigned int, тогда будет использоваться беззнаковое сравнение (по правилам сравнения С), иначе если в abs случится переполнение, её результат будет интерпретирован как отрицательный и if (intDiff <= maxUlps) вернет истину для совершенно разных чисел.Большое спасибо за содержательную критику!
Я внес исправления в программу, но теперь возникает вопрос с исключением. Не возникнет ли целочисленное переполнение в этом случае? И не приведет ли это к замедлению программы?
Будет время, сосредоточусь и проверю. )
Я внес исправления в программу, но теперь возникает вопрос с исключением. Не возникнет ли целочисленное переполнение в этом случае? И не приведет ли это к замедлению программы?
Будет время, сосредоточусь и проверю. )
Целочисленные операции не вызывают исключения при переполнении (по крайней мере на архитектурах, где описываемый трюк работает) и соответственно не будет никакого замедления, просто результат обрежется.
В нашем случае все еще проще, результат который возвращает abs может не поместиться в диапазон положительных значений int, но unsigned int точно хватит.
(тк сумма или разность может быть в общем случае длиннее на 1 бит, например 0b1111+0b1111=0b11110)
Вообще в x86(_64) операции сложения и вычитания одинаковы для знаковых и беззнаковых операндов (собственно поэтому там используется two's complement форма для отрицательных чисел — оптимизация).
Но вот операции сравнения уже различны. Для одного и того же бинарного значения в регистре разные операции сравнения интерпретируют его как знаковое или беззнаковое. Какую операцию использовать мы указываем компилятору через тип переменной (кстати интересно почему abs возвращает int а не unsigned).
ЗЫ все это достаточно сложно прочитать с листа. Легче всего написать тестовую программу. Для float можно сделать почти полный перебор всех возможных входных значений)_
В нашем случае все еще проще, результат который возвращает abs может не поместиться в диапазон положительных значений int, но unsigned int точно хватит.
(тк сумма или разность может быть в общем случае длиннее на 1 бит, например 0b1111+0b1111=0b11110)
Вообще в x86(_64) операции сложения и вычитания одинаковы для знаковых и беззнаковых операндов (собственно поэтому там используется two's complement форма для отрицательных чисел — оптимизация).
Но вот операции сравнения уже различны. Для одного и того же бинарного значения в регистре разные операции сравнения интерпретируют его как знаковое или беззнаковое. Какую операцию использовать мы указываем компилятору через тип переменной (кстати интересно почему abs возвращает int а не unsigned).
ЗЫ все это достаточно сложно прочитать с листа. Легче всего написать тестовую программу. Для float можно сделать почти полный перебор всех возможных входных значений)_
А вот мы сейчас это все будем читать, долго и вдумчиво. И наверное даже отправим на Киндл, да. А автору поставим плюс в карму фигурально и буквально, ибо верной дорогой идет.
Отличный пост.
Сейчас при приеме вычислительных техзаданий появилась новая мода как Bitwise Reproducibility, это полная ж для оптимизирующих компиляторов, которые любят менять местами порядок выполнения операций.
Кстати есть отдельный вопрос как ловить NaN'ы (мы их так и читаем нанЫ :)
-Слышь, у меня нанЫ в программе повалили, шоделать?).
В фортране есть ключи компилятора, которые позволяют вываливаться в эксепшн при возникновении NaN/Inf. Для gfort -ffpe-trap=invalid,zero,overflow, для ifort -fpe0, для C/C++ несколько сложнее, нужно менять код (в районе main()) и вызывать такую вот функцию:
feenableexcept(FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
Еще бы на целочисленную арифметику (переполнение) уметь генерировать эксепшны… Но это я уже мечтаю, да :)
Кстати есть отдельный вопрос как ловить NaN'ы (мы их так и читаем нанЫ :)
-Слышь, у меня нанЫ в программе повалили, шоделать?).
В фортране есть ключи компилятора, которые позволяют вываливаться в эксепшн при возникновении NaN/Inf. Для gfort -ffpe-trap=invalid,zero,overflow, для ifort -fpe0, для C/C++ несколько сложнее, нужно менять код (в районе main()) и вызывать такую вот функцию:
feenableexcept(FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
Еще бы на целочисленную арифметику (переполнение) уметь генерировать эксепшны… Но это я уже мечтаю, да :)
зачем эксепшены? в x86 для этого carry-флаг есть.
add RAX,RBX
jc >label
Окей, как заставить один из общеупотребимых компиляторов проверять этот флаг?
А почему эксепшн — так если у меня индекс переполняется, то мне как раз и нужно «все, приехали» — выпадение в кор, с генерацией дампа, бэктрейса, чтобы подставив отладчик я за два прогона нашел в каком месте оно валится и какой локал у меня при этом.
А почему эксепшн — так если у меня индекс переполняется, то мне как раз и нужно «все, приехали» — выпадение в кор, с генерацией дампа, бэктрейса, чтобы подставив отладчик я за два прогона нашел в каком месте оно валится и какой локал у меня при этом.
NaN с любым логическим выражением вернет ложь. Отсюда,
if (a!=a) printf("Оппа, NaN..."); 
не во всех языках есть NaN
например перловый undef не есть NaN в чистом виде, там undef вполне определенное значение… (ой, а может оно тоже последние биты теряет… в ядро не лазил, сорри)
а для полезности перловиков, да и не только их — используйте Big Int для денег и их копеек — оно разряды не теряет ибо их нет.
например перловый undef не есть NaN в чистом виде, там undef вполне определенное значение… (ой, а может оно тоже последние биты теряет… в ядро не лазил, сорри)
а для полезности перловиков, да и не только их — используйте Big Int для денег и их копеек — оно разряды не теряет ибо их нет.
Небольшое уточнение. На самом деле операция с NaN не возвращает ложь. Это компилятор так трактует. Не могу сказать по поводу SSE, но на FPU операция сравнения возвращает 3 флага:
www.felixcloutier.com/x86/FCOM:FCOMP:FCOMPP.html
То есть когда мы пишем:
if (a==a) printf(«не NaN»)
мы можем получить 3 разных состояния в регистрах:
C3 = 0; C2 = 0; C0 = 0 — значит числа не равны
С3 = 1; C2 = 0; C0 = 0 — значит числа равны
С3 = 1; C2 = 1; C0 = 1 — как минимум один из операндов NaN
Т.е. это 3 разных результата, и обычно компиляторы третье состояние трактуют как False (несмотря на то что C3 = 1, что соответствует True для операции сравнения).
www.felixcloutier.com/x86/FCOM:FCOMP:FCOMPP.html
То есть когда мы пишем:
if (a==a) printf(«не NaN»)
мы можем получить 3 разных состояния в регистрах:
C3 = 0; C2 = 0; C0 = 0 — значит числа не равны
С3 = 1; C2 = 0; C0 = 0 — значит числа равны
С3 = 1; C2 = 1; C0 = 1 — как минимум один из операндов NaN
Т.е. это 3 разных результата, и обычно компиляторы третье состояние трактуют как False (несмотря на то что C3 = 1, что соответствует True для операции сравнения).
Я понимаю, топик про float, но, взглянув на картинку, не могу удержаться.
CL-USER(1): (+ 1/5 1/5)
2/5
:P
CL-USER(1): (+ 1/5 1/5)
2/5
:P
Однозначно торт.
Какие преимущества дает смещение порядка?
Извините за тупость и глупый вопрос, но разложите кто-нибудь более детально формулу получения из 1.01e-3 числа 0,15625. Очень хочется разобраться во всем, но своих мозгов что-то не хватает…
Здесь мы имеем дело с двоичным представлением числа «101» со сдвигом запятой на несколько разрядов влево. 1,01 — это двоичное представление, означающее 1*20 + 0*2-1 + 1*2-2 (где * — умножение). Сдвинув запятую на три позиции влево получим «1,01e-3» = 1*2-3 + 0*2-4 + 1*2-5 = 1*0,125 + 0*0,0625 + 1*0,03125 = 0,125 + 0,03125 = 0,15625.
Извиняюсь за подъем старой темы, но корректно обращаться к компонентам float можно бы с помощью C union. Например:
Можно еще членом union сделать массив из 4-х unsigned char и смотреть каждый байт.
Но тут есть неопределенности. Во первых, некоторые казалось бы хорошо знакомые
процессоры, например i8051 — Big Endian и байты расположены «наоборот».
Во вторых, чтобы снять зависимость от sizeof long надо писать тип как uint32_t
из stdint.h (мой Keil не умеет).
P.S. Одна из наиболее корректных реализация эмуляции IEEE-754 — Berkeley SoftFloat
www.jhauser.us/arithmetic/SoftFloat.html
можно посмотреть как сделано.
union fl {
float f;
unsigned long l;
};Можно еще членом union сделать массив из 4-х unsigned char и смотреть каждый байт.
Но тут есть неопределенности. Во первых, некоторые казалось бы хорошо знакомые
процессоры, например i8051 — Big Endian и байты расположены «наоборот».
Во вторых, чтобы снять зависимость от sizeof long надо писать тип как uint32_t
из stdint.h (мой Keil не умеет).
P.S. Одна из наиболее корректных реализация эмуляции IEEE-754 — Berkeley SoftFloat
www.jhauser.us/arithmetic/SoftFloat.html
можно посмотреть как сделано.
Sign up to leave a comment.
Что нужно знать про арифметику с плавающей запятой