Итак простая задачка для Excel:
Встаем прямо на самую первую ячейку A1 и начинаем вводить числа в столбик(вводим число и Enter и так далее):
0,1
1
0,57
-0,68
0
-0,79
Готово!
Теперь формула в ячейку A7: =A1-СУММ(A2:A6)
Ответ ожидается равным нулю.
Сделайте форматы ячеек "Числовой", число десятичных знаков 20 и Вы увидите волшебное число: 0,00000000000000024980
Вы вот тут можете грешным делом захотеть упростить задачу и просто просуммировать все и получить ожидаемые 0.2
формула "=СУММ(A1:A6)" дает ответ: 0,20000000000000000000
И никакого фокуса не выйдет!
Так что секретная формула именно =A1 - СУММ(A2:A6)
(Хотя допускаю что есть и другие)
А Вы думаете предпоследнее число там зря?
Вставьте в ячейку A5 вместо нуля единицу и получите ответ: -1,00000000000000000000
Какие будут мнения?
P.S. Только что столкнулся и слегка ошарашен удивлен.
Пока не разбирался да и поздновато сегодня.
P.S.S.
Ячейки можно выбирать любые, я тут писал именно эти чтоб было понятно где что.
И эти числа не единственная комбинация.
Первоначальные числа в расчете которых я столкнулся с данным эффектом были совершенно большие, я их специально уменьшил.
Но эффект как видите остался.
Здравствуйте, Cicero, Вы писали:
C>Итак простая задачка для Excel: C>Встаем прямо на самую первую ячейку A1 и начинаем вводить числа в столбик(вводим число и Enter и так далее): C>0,1 C>1 C>0,57 C>-0,68 C>0 C>-0,79 C>Готово! C>Теперь формула в ячейку A7: =A1-СУММ(A2:A6) C>Ответ ожидается равным нулю. C>Сделайте форматы ячеек "Числовой", число десятичных знаков 20 и Вы увидите волшебное число: 0,00000000000000024980
Здравствуйте, T4r4sB, Вы писали:
TB>Не знаю, получается 0.2 и 1.2. Шо в уме, шо в екселе, шо в самодельном калькуляторе.
Давайте считать вместе:
сначала посчитаем сумму "СУММ(A2:A6) = 1+0,57-0,68-0,79
1) 1+0,57=1,57
2) 1,57-0,68=0,89
3) 0,89-0,79=0,1
т.о. СУММ(A2:A6)=0,1
теперь вычитаем это из A1.
A1 у нас тоже 0,1.
т.е. последнее действие:
4) 0,1-0,1 = 0
Здравствуйте, Cicero, Вы писали:
C>Здравствуйте, T4r4sB, Вы писали:
TB>>Не знаю, получается 0.2 и 1.2. Шо в уме, шо в екселе, шо в самодельном калькуляторе.
C>Давайте считать вместе: C>сначала посчитаем сумму "СУММ(A2:A6) = 1+0,57-0,68-0,79 C>1) 1+0,57=1,57 C>2) 1,57-0,68=0,89 C>3) 0,89-0,79=0,1 C>т.о. СУММ(A2:A6)=0,1 C>теперь вычитаем это из A1. C>A1 у нас тоже 0,1. C>т.е. последнее действие: C>4) 0,1-0,1 = 0
C>Где ошибка?
Почему из 0.1 вычитаем 0.1, если знак везде +?
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Ну это это к в C++ float или double. Смотри вещественные числа, Мантисса и Капулетты.
Если поля в Экселе указать как Number с 2 знаками после запятой, то он все красиво показывает.
Если формулу укзаать A1-A2-A3-A4-A5-A6-A7 то он ноль рисует. Видать SUM вносит погрешность.
Если есть желание — найдется 1000 возможностей.
Если нет желания — найдется 1000 причин.
Здравствуйте, Cicero, Вы писали: C>Давайте считать вместе:
А, я прочитал невнимательно. Я просто сумму взял :D
Мог бы не напускать туману, сразу предложить вбить в калькулятор
0.1-(1+0.57-0.68-0.79)
мой самодельный выдаёт 0.33881317890172013e-00019, например
Здравствуйте, CreatorCray, Вы писали:
TB>>мой самодельный выдаёт 0.33881317890172013e-00019, например
CC>Мой самодельный выдаёт 0 CC>Может ты свой неправильно готовишь?
Младшие биты мантиссы при конверсии из текстовых в плавучку это серьёзнейшая головная боль, даже массовые библиотечные реализации strtod() с компанией тут лажают. Зависание при конверсии пограничного значения (Java, PHP).
Или тут "Python now uses David Gay’s algorithm for finding the shortest floating point representation that doesn’t change its value", причём в обе стороны (результат точный, но сама конверсия значительно дороже, и её посчитали оправданной только недавно).
Здравствуйте, netch80, Вы писали:
CC>>Мой самодельный выдаёт 0 CC>>Может ты свой неправильно готовишь?
N>Младшие биты мантиссы при конверсии из текстовых в плавучку
Я забыл тег irony, my bad.
Мой калькулятор внутри все числа представляет в виде дроби. Там нет незапланированных ошибок округления.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Мой самодельный выдаёт 0 CC>>>Может ты свой неправильно готовишь? N>>Младшие биты мантиссы при конверсии из текстовых в плавучку CC>Я забыл тег irony, my bad.
Ну, будут ссылки для публики.
CC>Мой калькулятор внутри все числа представляет в виде дроби. Там нет незапланированных ошибок округления.
Это хорошо до момента вычисления sqrt(3). (Считаем, что я пометил <irony>.)
Здравствуйте, netch80, Вы писали:
CC>>Мой калькулятор внутри все числа представляет в виде дроби. Там нет незапланированных ошибок округления. N>Это хорошо до момента вычисления sqrt(3). (Считаем, что я пометил <irony>.)
А его всё равно точно вычислить нельзя по определению.
Просто говорим до какой точности хотим.
Здравствуйте, T4r4sB, Вы писали:
CC>>Может ты свой неправильно готовишь? TB>У меня обычный 10-байтовый плавучий, символьную арифметику я не мутил, конечно же. TB>Потому и результат такой, конечно.
Сорри, мне там надо было смайлик дописать, чота как то забыл.
Здравствуйте, Cicero, Вы писали:
C>Сделайте форматы ячеек "Числовой", число десятичных знаков 20 и Вы увидите волшебное число: 0,00000000000000024980 Phil Karlton was wrong
Здравствуйте, qwertyuiop, Вы писали:
Q>Раньше подобные удивленные посты появлялись в С/С++ не реже чем раз в месяц. Сейчас переехали в КСВ?
Да меня это удивило.
Я конечно понимаю приведенные выше обоснования.
Но когда вдруг 1-1!=0 как то странно.
Ну ок.
Вы скажете: надо просто округлять!
Но если исходные данные были допустим с точностью до сотых, и производились только два действия: сложение и вычитание, в результате мы должны так же получить максимум две цифры после запятой!
Здравствуйте, Cicero, Вы писали:
C>Но если исходные данные были допустим с точностью до сотых, и производились только два действия: сложение и вычитание, в результате мы должны так же получить максимум две цифры после запятой!
Безусловно. ) Только вот где вычислителю указано, что исходные данные предоставлены с точностью до сотых? )
Здравствуйте, Cicero, Вы писали:
C>Но если исходные данные были допустим с точностью до сотых, и производились только два действия: сложение и вычитание, в результате мы должны так же получить максимум две цифры после запятой!
Приведенные выше объяснения и ссылки говорят о том, что в историческом (оно же дефолтное) представлении нецелых чисел в компутерах невозможно хранить дробные данные с точностью до сотых, поэтому там где вам «очевидно», что хранится 0.1 — «на самом деле», хранится некое двоичное представление, довольно близкое к 0.1, но всё же не совершенно ему равное.
Это ужасно контр-интуитивная штука компьютерной математики. В многих/некоторых современных языках и средствах вычислений принимаются всякие обходные манёвры — от «округления перед выводом числа» (что даёт в некоторых случаях ещё БОЛЬШИЙ эффект неожиданности, поскольку print 0.1 + 0.2 напечатает 0.3, а print 0.1 + 0.2 == 0.3 напечатает false) до реального изменения внутренних структур для хранения данных. Последнее вроде как «самый правильный» вариант, но он чреват потерями производительности. Поэтому оставляют «резервный» способ хранения данных в таки более эффективном виде. Скажем, в Ruby:
# современная версия:
p 0.1+0.2
# => 0.30000000000000004
p 0.1+0.2 == 0.3
# => false
p Rational(1, 10)+Rational(2, 10)
# => (3/10) — точно, хотя не очень-то удобно
p Rational(1, 10)+Rational(2, 10) == Rational(3, 10)
# => true
# будущая (AFAIK) версия:
p 0.1+0.2
# => 0.3 — это как раз Rational число, точные но медленные вычисления
p 0.1f+0.2f
# => 0.30000000000000004f — а это «нативный» float, неточный но быстрый
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, CreatorCray, Вы писали:
TB>У меня обычный 10-байтовый плавучий, символьную арифметику я не мутил, конечно же.
Все промежуточные данные в long double? А платформа какая?
Здравствуйте, T4r4sB, Вы писали:
N>>Все промежуточные данные в long double? А платформа какая? TB>Да, в лонгдабле, платформы х86, х64.
Мнэээ... термин "x64" используется только на Windows. На Unix говорят x86_64 или amd64, совсем редко ix64. Поэтому я предполагаю, что у тебя обстановка — Windows. Но для виндовых компиляторов ("студия" и аналоги), long double это не отдельный тип, а алиас для 64-битного double, переведя внутри всё на SSE2 и исключая FPU. Ты уверен, что у тебя в этом всём реально используется 80-битный FPU-специфичный формат? (А иначе нет смысла говорить про long double и усложнять решение ради него)
И второе — насколько я вижу, для 32-битного режима, где используется FPU, на Windows по умолчанию включается в FPU точность double, а не long double (подтверждение). Формат хранения при этом в FPU остаётся long double, но все мантиссы округляются до 53 значащих бит. Поэтому, если ты не позаботился о смене режима, использование промежуточного хранения в 80-битном формате тут до лампочки.
Здравствуйте, Ops, Вы писали:
Ops>А какие еще варианты, чтобы внутреннее представление однозначно отображалось на 10-чное?
Только в реальных ситуациях это никому не нужно.
Здравствуйте, pagid, Вы писали:
Ops>>А какие еще варианты, чтобы внутреннее представление однозначно отображалось на 10-чное? P>Только в реальных ситуациях это никому не нужно.
IBM на zSeries и на Power6 сделала аппаратно (z9 — микрокодом, z10 — на ASIC), и хвастается этим:
* The key is preserving base 10 exponents wherever possible
* The conversion to binary floating point exponents can lead to repeat rounding errors and is therefore unsuitable for precision mathematics
И они же протолкнули этот вариант в IEEE 754-2008, причём в двух версиях — двоично кодированной мантиссой и десятичной в Chen-Ho 10:3 BCD (который оптимизирован для аппаратной конверсии в 3 десятичные цифры и обратно).
А ещё есть в C# встроенный Decimal (несовместимый с IEEE форматами).
Здравствуйте, netch80, Вы писали:
N>Мнэээ... термин "x64" используется только на Windows. На Unix говорят x86_64 или amd64, совсем редко ix64. Поэтому я предполагаю, что у тебя обстановка — Windows. Но для виндовых компиляторов ("студия" и аналоги), long double это не отдельный тип, а алиас для 64-битного double, переведя внутри всё на SSE2 и исключая FPU. Ты уверен, что у тебя в этом всём реально используется 80-битный FPU-специфичный формат? (А иначе нет смысла говорить про long double и усложнять решение ради него)
Да я знаю, что тупорылые индусы из микрософта просрали лонгдабл.
Если б я хотел ссе, я бы не выбирал лонгдабл, не?
Я писал свой калькулятор на Дельфи-7, там всё в порядке.
N>И второе — насколько я вижу, для 32-битного режима, где используется FPU, на Windows по умолчанию включается в FPU точность double, а не long double (подтверждение). Формат хранения при этом в FPU остаётся long double, но все мантиссы округляются до 53 значащих бит. Поэтому, если ты не позаботился о смене режима, использование промежуточного хранения в 80-битном формате тут до лампочки.
Я в начале принудительно меняю контрольное слово.
А вообще если у тебя есть пример выражения, отличающего 8 от 10 байт, то можно проверить.
Здравствуйте, netch80, Вы писали:
N>IBM на zSeries и на Power6 сделала аппаратно (z9 — микрокодом, z10 — на ASIC), и
Так и Интела начиная с 8080 и до x86 была какая-то поддержка BCD, но в x64 вроде как отказались, за ненадобностью.
N>А ещё есть в C# встроенный Decimal (несовместимый с IEEE форматами). N>Так что "никому не нужно" — спорное утверждение
Разумеется спорное.
Но постоянно вопрошающим на форуме про неожиданно замеченные эффекты представления flоat, точно нужно не BCD
Здравствуйте, pagid, Вы писали:
P>Здравствуйте, netch80, Вы писали:
N>>IBM на zSeries и на Power6 сделала аппаратно (z9 — микрокодом, z10 — на ASIC), и P>Так и Интела начиная с 8080 и до x86 была какая-то поддержка BCD,
Только целочисленная. Медленная и тупая, по одной цифре за раз.
P> но в x64 вроде как отказались, за ненадобностью.
Да. Потому что в таком виде она точно никому не нужна.
P>Но постоянно вопрошающим на форуме про неожиданно замеченные эффекты представления flоat, точно нужно не BCD
А вдруг они пересядут на zSeries и будут считать свои финансовые отчёты долго и счастливо
Здравствуйте, eskimo82, Вы писали:
E>Про виртуальный деструктор не хочеш поведать ?
Не хочу. Если интересно, сам найдешь, где про него почитать.
E> На само деле 0.1 != 0.1
И в каком же ЯП/архитектуре 0.1!= 0.1 ?
только не нужно фантазий о том, что первое "0.1" это в машинном представлении float, а второе "0.1" это то, что у тебя в голове, или в арифметике, или наоборот. И там написано именно "0.1", а не результат каких либо вычислений.
Здравствуйте, T4r4sB, Вы писали:
TB>Да я знаю, что тупорылые индусы из микрософта просрали лонгдабл. TB>Если б я хотел ссе, я бы не выбирал лонгдабл, не? TB>Я писал свой калькулятор на Дельфи-7, там всё в порядке.
Хм, я ожидал скорее какой-нибудь адаптации gcc в стиле mingw, но не Delphi
Прикольно, будем знать, что там сохранили работу с FPU и этот тип.
TB>Я в начале принудительно меняю контрольное слово.
Тогда вопросов нет.
TB>А вообще если у тебя есть пример выражения, отличающего 8 от 10 байт, то можно проверить.
Я как-то на SO отвечал по этому поводу, там не выражение, а сложение в цикле, но результаты разные для этих двух режимов.
А выражение — тут можно сделать какую-то банальность в духе "какой, милые, у нас сегодня эпсилон на дворе?" В C (для FreeBSD) это будет так:
#include <ieeefp.h>
#include <stdio.h>
volatile double dsum = 1.0;
volatile long double tsum = 1.0;
int main() {
#pragma STDC FENV_ACCESS ON
fpsetprec(FP_PD); // set FPU precision to 53 bits
dsum = dsum + 1.0e-19;
fpsetprec(FP_PE); // set FPU precision to 64 bits
tsum = tsum + 1.0e-19;
printf("%d %d\n", (dsum != 1.0), (tsum != 1.0));
return 0;
}
Здравствуйте, netch80, Вы писали:
N>Только целочисленная. Медленная и тупая, по одной цифре за раз.
Угу. Но почему целочисленная? просто с фиксированной точкой.
N>А вдруг они пересядут на zSeries и будут считать свои финансовые отчёты долго и счастливо
А без zSeries никакого счастья в финансовых расчетах конечно же нет.
И откуда это всплили финансовые расчеты, вроде как в топике их никто еще не упоминал. К слову, ТС для финансовых расчетов стоит посоветовать установить соответствующий формат ячеек и не парится на тему как там ёксель считает, в float, в fixed или в BCD
Здравствуйте, pagid, Вы писали:
N>>Только целочисленная. Медленная и тупая, по одной цифре за раз. P>Угу. Но почему целочисленная? просто с фиксированной точкой.
Фигня в том, что просто для фиксированной точки достаточно двоичной арифметики с финальным делением на 100 или какая там дробность предполагается для этих целей.
А вот данный BCD вообще имел смысл только в применении типа "контроллер в часах", что перестало быть актуальным ещё в 286. Вот там быстро (потому что процессор тормозной что тётя Песя) выполнить сложение двух-трёхзначных BCD чисел и сразу их показать без мучительного деления на 10 — да, это была важная задача.
А сейчас всё это, мягко говоря, решается иначе, если вообще ставится в таком виде. Например, сверхсложная задача "разделить с остатком на 10", которая убивала 086-й тактов на сто, сейчас превращается тактов в 8 вместе с вычислением остатка (за счёт обратного умножения), и это при несравнимой тактовой частоте
Я не уверен, что имело смысл сохранять эти команды даже для 32-битной версии, но там, скорее всего, сэкономили на отмене старых возможностей.
N>>А вдруг они пересядут на zSeries и будут считать свои финансовые отчёты долго и счастливо P>А без zSeries никакого счастья в финансовых расчетах конечно же нет.
Ну почему, есть ещё Power6
P>И откуда это всплили финансовые расчеты, вроде как в топике их никто еще не упоминал.
Ну для меня это умолчательная интерпретация типа "а накойхер я ещё буду использовать Excel, кроме как для мелкофинансового — для всего остального есть более подходящие средства".
И оно же поясняет, откуда берутся такие пользователи, которые страдают по поводу "ах, оно мне тут показало 0.30000000000000004! Конец света!!!адынадын", не понимая, что двоичные расчёты с округлением промежуточных результатов до нужного количества десятичных цифр _более_ точны, чем расчёты по основанию 10. (Кто может опровергнуть?) Единственные два фактора, которые тут могут как-то сыграть —
1) Это формально более высокая точность представления в decimal-форматах (64 бита => гарантированных 16 цифр, вместо условных 15.95). Но я не представляю себе ситуации, когда это важнее повышения drift'а при base=10;
2) Inexact exception в этом случае не имеет ложноположительных срабатываний.
P>К слову, ТС для финансовых расчетов стоит посоветовать установить соответствующий формат ячеек и не парится на тему как там ёксель считает, в float, в fixed или в BCD
Наверно, так. Если скорость не убьётся (кто их знает...)
Здравствуйте, netch80, Вы писали:
N>Хм, я ожидал скорее какой-нибудь адаптации gcc в стиле mingw, но не Delphi N>Прикольно, будем знать, что там сохранили работу с FPU и этот тип.
Что значит "сохранили", семёрка это 2002й год, 90% дельфистов до сих пор на ней по-моему сидит, потому что дальше глюкодромы пошли.
N>А выражение — тут можно сделать какую-то банальность в духе "какой, милые, у нас сегодня эпсилон на дворе?" В C (для FreeBSD) это будет так:
Не, мой калькулятор не может циклы.
Что-то типа ((a+b)^2-b^2-a^2)/(2*a*b) для сильно разных а и бэ.
Здравствуйте, netch80, Вы писали:
N>А вот данный BCD вообще имел смысл только в применении типа "контроллер в часах"
Калькулятор же, такой с кнпочками и индикатором с цифрами.
N>Ну почему, есть ещё Power6
Осталось узнать с какой целью это добро использовать. Чтобы гарантировать отсутствие удивления у ТС?
Здравствуйте, T4r4sB, Вы писали:
N>>Хм, я ожидал скорее какой-нибудь адаптации gcc в стиле mingw, но не Delphi N>>Прикольно, будем знать, что там сохранили работу с FPU и этот тип. TB>Что значит "сохранили",
При переходе 32->64. Я же правильно понял, что оно включает 64-битную версию?
TB>семёрка это 2002й год, 90% дельфистов до сих пор на ней по-моему сидит, потому что дальше глюкодромы пошли.
У меня скоро ребёнок будет на ней в школе чего-то терзать, тогда посмотрю плотнее.
N>>А выражение — тут можно сделать какую-то банальность в духе "какой, милые, у нас сегодня эпсилон на дворе?" В C (для FreeBSD) это будет так:
TB>Не, мой калькулятор не может циклы. TB>Что-то типа ((a+b)^2-b^2-a^2)/(2*a*b) для сильно разных а и бэ.
Здравствуйте, pagid, Вы писали:
N>>А вот данный BCD вообще имел смысл только в применении типа "контроллер в часах" P>Калькулятор же, такой с кнпочками и индикатором с цифрами.
Ну PC-то не калькулятор
N>>Ну почему, есть ещё Power6 P>Осталось узнать с какой целью это добро использовать. Чтобы гарантировать отсутствие удивления у ТС?
Я там рядом написал. Есть в IEEE стандарте такая штука — Inexact exception. Возникает, когда результат не может быть представлен точно в целевом формате, и округлённый результат отличается от точного. По умолчанию выключено, и применяется дай бог чтобы в 0.01% случаев, но применяется, и поддерживается всеми соответствующими стандарту реализациями.
Так вот — имея десятичную плавучку и включив Inexact exception на все операции, можно быть уверенным, что именно расчёты финансового типа (в которых основные операции это сложение, вычитание, умножение и процент), если сработали без исключения, дадут точный результат (а на стрёмные случаи типа "разделить на 3 части" или "14% от некруглой суммы в центах" можно это исключение и временно маскировать, с соответствующей обработкой результата). И это будет работать для любых представлений типа "точность до копейки", "точность до 0.01 цента" и тому подобное.
А если считать в двоичной, то этих Inexact'ов будет миллионы, начиная с начальной конверсии — нельзя простейшее 0.1 точно представить в двоичной.
Поэтому предпочитают вести все финансовые расчёты в десятичном формате.
Кстати, если кто-то скажет, что все проблемы решаются фиксированной точкой — не решаются они, по крайней мере без дополнительных средств. Потому что, когда будут складывать, например, в 32 битах 2 раза по 20 миллионов неважно каких попугаев, но с точностью до сотых, результат вылезет за пределы int. И в любой битности нет гарантии, что где-то не будет переполнения — а в таких задачах формальные гарантии критичны. Для этого ввели группу стандартов Language Independent Arithmetic, которые абстрактны до предела, но говорят, что ситуации типа подобных переполнений должны детектироваться. И в плавучке соответствовать им проще, чем в целых числах.
Здравствуйте, netch80, Вы писали:
N>При переходе 32->64. Я же правильно понял, что оно включает 64-битную версию?
Нет, я думал, ты про платформу оси.
Там только 32, конечно.
TB>>Не, мой калькулятор не может циклы. TB>>Что-то типа ((a+b)^2-b^2-a^2)/(2*a*b) для сильно разных а и бэ.
N>Тут же циклов нет, тупое сложение.
Ну так я и говорю — пример без циклов, от которого колбасит плавучку.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Cicero, Вы писали:
C>>Но если исходные данные были допустим с точностью до сотых, и производились только два действия: сложение и вычитание, в результате мы должны так же получить максимум две цифры после запятой!
_>Безусловно. ) Только вот где вычислителю указано, что исходные данные предоставлены с точностью до сотых? )
Ну как минимум точность исходных данных об этом однозначно говорит.
Большую точность никак не получить.
E>>Про виртуальный деструктор не хочеш поведать ? P>Не хочу. Если интересно, сам найдешь, где про него почитать.
Неудивительно это, форум то для тебя не профильный.
E>> На само деле 0.1 != 0.1 P>И в каком же ЯП/архитектуре 0.1!= 0.1 ?
Во всех.
P>только не нужно фантазий о том, что первое "0.1" это в машинном представлении float
Бинго! Еще чуть-чуть и ты догадаешся что 0.1 не представляется точно в машином виде никак.
Здравствуйте, , Вы писали:
E>Неудивительно это, форум то для тебя не профильный. E>Бинго! Еще чуть-чуть и ты догадаешся
E> что 0.1 не представляется точно в машином виде никак.
Из этого никак не следует, что 0.1 != 0.1
E>Во всех.
А по существу сказать как всегда нечего
Здравствуйте, Cicero, Вы писали:
_>>Безусловно. ) Только вот где вычислителю указано, что исходные данные предоставлены с точностью до сотых? ) C>Ну как минимум точность исходных данных об этом однозначно говорит. C>Большую точность никак не получить.
Я что-то пропустил? ) Исходные данные были заданы в виде 0,1+-0,01? )
Здравствуйте, T4r4sB, Вы писали:
N>>При переходе 32->64. Я же правильно понял, что оно включает 64-битную версию? TB>Нет, я думал, ты про платформу оси. TB>Там только 32, конечно.
Тогда как-то сложно говорить "платформа x64".
TB>>>Не, мой калькулятор не может циклы. TB>>>Что-то типа ((a+b)^2-b^2-a^2)/(2*a*b) для сильно разных а и бэ. N>>Тут же циклов нет, тупое сложение. TB>Ну так я и говорю — пример без циклов, от которого колбасит плавучку.
Здравствуйте, netch80, Вы писали:
N>Только целочисленная.
Без плавучки, но не целочисленная.
N> Медленная и тупая, по одной цифре за раз.
По две же!
P>> но в x64 вроде как отказались, за ненадобностью. N>Да. Потому что в таком виде она точно никому не нужна.
Дроби гораздо более эффективные.
P>>Но постоянно вопрошающим на форуме про неожиданно замеченные эффекты представления flоat, точно нужно не BCD N>А вдруг они пересядут на zSeries и будут считать свои финансовые отчёты долго и счастливо
Очень сильно сомневаюсь.
Здравствуйте, netch80, Вы писали:
N>Так вот — имея десятичную плавучку и включив Inexact exception на все операции, можно быть уверенным, что именно расчёты финансового типа (в которых основные операции это сложение, вычитание, умножение и процент), если сработали без исключения, дадут точный результат
Здравствуйте, CreatorCray, Вы писали:
N>>Так вот — имея десятичную плавучку и включив Inexact exception на все операции, можно быть уверенным, что именно расчёты финансового типа (в которых основные операции это сложение, вычитание, умножение и процент), если сработали без исключения, дадут точный результат
CC>Дроби решают это всё просто по определению.
Какая реализация дробей? В ней есть гарантия, что, например, все случаи переполнения одного компонента отловлены, а не случилось тихое обрезание до младших N бит?
При требовании методики расчётов "всё представляем в десятичном виде и округляем до указанных десятичных долей" (требуемой во многих финансовых расчётах), как будет форсироваться, что знаменатель дроби — всегда степень десятки, и чем в таком случае это будет лучше явного представления степени того же знаменателя в виде порядка?
Имеет ли данная реализация дробей требуемые по LIA представления особых значений, и если да, то чем она выгоднее?
Если выполнишь все описанные требования и ещё и уложишься в разумный размер представления, может оказаться, что твоя версия на дробях ничуть не лучше.
Иначе для чего было придумывать, например, Decimal в C#?
Здравствуйте, CreatorCray, Вы писали:
N>> Медленная и тупая, по одной цифре за раз. CC>По две же!
Принимаю поправку, но для данного вопроса несущественно.
P>>> но в x64 вроде как отказались, за ненадобностью. N>>Да. Потому что в таком виде она точно никому не нужна. CC>Дроби гораздо более эффективные.
См. соседний ответ.
P>>>Но постоянно вопрошающим на форуме про неожиданно замеченные эффекты представления flоat, точно нужно не BCD N>>А вдруг они пересядут на zSeries и будут считать свои финансовые отчёты долго и счастливо CC>Очень сильно сомневаюсь.
Здравствуйте, T4r4sB, Вы писали:
N>>Я его там привёл следом, кусок кода.
TB>Я не могу в калькулятор забивать куски кода, я могу забивать в него только выражения, мы же калькулятор проверяем, а не Дельфи?
TB>Могу сказать, что "1+1e-19-1" вывело "0.10842021724855044e-00018", а вот "1+1e-20-1" вывело 0
Ну с поправкой — что и требовалось. Несмотря на возмущённые выражения, ты таки выцепил, что именно считать. Именно так, если для 1e-19 значение ненулевое, то там внутренние расчёты таки в 64 битах мантиссы, как для честного long double. Для double минимальным значением, на котором получалось бы не 0, было бы 2.220446049250313e-16. Квест пройден.
Здравствуйте, netch80, Вы писали:
N>Несмотря на возмущённые выражения, ты таки выцепил, что именно считать.
Я вроде как чётко сказал несколько раз, что мне нужно именно выражение, а не код, и поэтому я ждал чёткого ответа, в котором не требуется ничего выцеплять.
Здравствуйте, netch80, Вы писали:
N>Какая реализация дробей?
BigNumber m_numerator, m_denominator;
N> В ней есть гарантия, что, например, все случаи переполнения одного компонента отловлены, а не случилось тихое обрезание до младших N бит?
Каждое число — безразмерное. Сколько надо — столько и будет, пока в память вмещается. В 99% рабочего диапазона они за машинное слово не вылазят, для остальных случаев работает "длинная" математика.
N>При требовании методики расчётов "всё представляем в десятичном виде и округляем до указанных десятичных долей" (требуемой во многих финансовых расчётах), как будет форсироваться, что знаменатель дроби — всегда степень десятки
Не надо это форсировать. 1.0 будет храниться как 1/1, 0.5 как 1/2, 0.55 как 11/20
Округляем "выступающие части" если выясняется что они требуют округления в точке, когда его надо гарантировать. Такое случается в случае деления или вычислении процентов. Да и то часто округляется только последний результат всей цепочки формул.
N>Имеет ли данная реализация дробей требуемые по LIA представления особых значений, и если да, то чем она выгоднее?
А накой они надо в финансовых расчётах? Бесконечности, корни, log, sin, cos и т.п. смысла не имеют и не используются. Деление на ноль всегда приводит к exception.
Весь смысл работы с дробями когда надо обеспечить lossless computations. А там все "неточные" значения не имеют смысла.
N>Иначе для чего было придумывать, например, Decimal в C#?
Надо бы спросить тех, кто придумал.
Именно так, если для 1e-19 значение ненулевое, то там внутренние расчёты таки в 64 битах мантиссы, как для честного long double. Для double минимальным значением, на котором получалось бы не 0, было бы 2.220446049250313e-16. Квест пройден.
