andrey_anonymousdbpatchесли вон то число взять как угол в радианах, да в последнюю пятерку заменить на 6, какое уголовое отконение даст это в масштабах нашей Галактики (берем катеты равными диаметру Галактики, насколько изменится гипотенуза?)
Угловое - 1e-56 радиана
Гипотенуза - прирастет примерно на 9,4607304725808E-23 мм, а что?

а, ну да, 9.5E-23 мм на масштабе Галактики - это нет, не астрономическая величина, конечно же нет :)

andrey_anonymousdbpatchа, ну да, 9.5E-23 мм на масштабе Галактики - это нет, не астрономическая величина, конечно же нет :)
А какое отношение 9.5E-23, которое легко представимо в number, имеет к double порядка .1 , которое нельзя точно представить в number в контексте дискуссии?

как говорилось выше - тут сыр бор зашел о возможности использовать double для бухгалтерско-финансовых данных.
мы (я и коллеги) в бытность делали практическое исследование (и даже методом брутфорса и формально), все везде вмещалось

но проверить астрономические величины мы не могли (это заняло бы миллиарды триллионов лет), с тех пор я и забыл про эту особенность, в святой наивности полагая, что number это superset double (знаков-то больше влазит)

оказалось что не прав в части астрономической величины мантиссы и вот похоже да, каких-то немыслимо мелких дробных, за что уже три раза покаялся.

но моя неправота к бухгалтериям не имеет применения, так что....

Сергей Арсеньевdbpatchно моя неправота к бухгалтериям не имеет применения, так что....
Если нужна управляемая точность используй BigDecimal. :)

решение довольно "упоротое", если честно.

я сам больше склоняюсь (в теории) к варианту fixed pointer, от int64 (или int128), где соглашение весьма просто
- integer задает число копеек (или десятитысячных копеек, в случае цены).

библиотека для финансовых вычислений (на том-же C++) делается на 1-2-3, скорость наибольшая

на практике же так и используется который год тот самый double с поправкой округлений на операциях умножить и разделить

andrey_anonymousdbpatchя сам больше склоняюсь (в теории) к варианту fixed pointer, от int64 (или int128), где соглашение весьма просто
- integer задает число копеек (или десятитысячных копеек, в случае цены).
В IEEE-754-2008 появился decimal.
Скоро во всех утюгах планеты!
:)

это вот этот который? https://en.wikipedia.org/wiki/Decimal_floating_point
не взлетит. его даже к GNU C толком привинтить не смогли (в документации есть, по факту просто так скомпилировать не получится).

кроме того, нативная реализация там только лишь на некоторых IBM pSeries, zSeries (не только лишь не все), в остальных случаях натужная софтовая реализация аля Number (который, впрочем, аппаратно могут тоже, не только лишь не все).

в этом варианте правильно считать финансы в Integer-ах как копейки выглядит перспективнее, осталось только нативного int128 дождаться (в x64 там все мрачно, через два 64-х битных числа все сделано на ассемблере)

andrey_anonymousdbpatchэто вот этот который? https://en.wikipedia.org/wiki/Decimal_floating_point
не взлетит. его даже к GNU C толком привинтить не смогли (в документации есть, по факту просто так скомпилировать не получится).
https://software.intel.com/en-us/cpp-compiler-18.0-developer-guide-and-reference-intel-extensions-qintel-extensions

ерунда это все, аппаратной поддержки нет, они лишь подключают софтварную библиотеку
https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library

по поводу поддержки этого Decimal и вовсе анекдот - в clang задавали вопрос, нужен ли он. никто за годы ни разу не обратился за поддержкой
http://releases.llvm.org/3.8.1/tools/docs/UsersManual.html#gcc-extensions-not-implemented-yet

а в gcc его похоже IBM самолично впливала, ей зачем-то было нужно, так этим практически никто похоже не пользуется

так что насчет всех пылесосов я бы не зарекался :)

andrey_anonymousdbpatchаппаратной поддержки нет, они лишь подключают софтварную библиотеку
Как только интел разродится железякой - так сразу и появится во всех утюгах.
Подозреваю, что дело вообще может ограничиться микрокодом.
А случится это, как только интел увидит возможность поднять денег на массовой адаптации бухгалтерского ПО под decimal :)
микрокодом там точно не ограничится, не тот уровень (банально - слишком много кода, хотя они могут реализовать лишь базовые +-*/, всякие аркатангенсы навечно оставить в софте)

а реализовывать все в кремне аля x87 - бесцельное удорожание и прочий рост тепловыделений
да и старые процессоры куда девать? в общем мертворожденное это все, яж говорю - не взлетит.

кроме того, никто из девелоперов не хочет это использовать - 95% оных не читало даже https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

только только научились кое-как копейки в double считать, и тут опять переучиваться?

да, ссылку выше даже я не прочитал, не дочитал и до пятой части, забросил, слишком скучно и непонятно для "бухгалтера"

andrey_anonymousdbpatchа реализовывать все в кремне аля x87 - бесцельное удорожание и прочий рост тепловыделений
На минуточку x87 годы назад тупо перебрался под общую крышку с CPU, потому для просто поддержки формата и расчетов с ним все что надо - добавить десятичный порядок.
Куда старые процессоры девать?
Да как обычно - на помойку, уж сколько поколений сменилось - и то лишь в случае, если современные FPU не позволяет решить задачу работы с десятичным порядком на уровне микрокода... Те же P6/P7 ведь микрокодом обошлись, не?

P7 как говорит википедия - это Итаник. но если речь про P6 + Netburst то они померли естественным путем в связи с массовым переходом на x64

даже при всех очевидных бенефитах x64 для сервера - процесс помирания был очень долгим, растянулся на лет так 14 минимум и до сих пор еще не закончился (RHEL 5/6 x32 все еще саппортится)


в остальном же все печально - линкеры по дефолту компилируют в очень ограниченный сабсет x64 команд (хотя нужно отдать должное, туда по умолчанию много чего включено, тот-же SSE2), а вот всякие новые фишки вроде AVX или CRC (_mm_crc32_u64 интринзик) - это лишь удел отдельно взятых функций, которые на старте проверяют поколение процессора и подсовывают или себя или софтовый "универсальный" аналог

а теперь представь себе ситуацию с базовым числовым типом - как это будет выглядеть? всякие инлайнинги отпадают как класс (ты не заменишь их на старте), т.е. только прыжки в библиотеки даже для суммирования, а это опять ТООООРМОЗА, в сравнении.

кому это вообще будет надо? т.е. в массы это все никак не пойдет.

а микрокод процессора не умеет прыгать сам в userspace библиотеки, там или всё, или ничего

andrey_anonymousdbpatchа теперь представь себе ситуацию с базовым числовым типом - как это будет выглядеть?
Да так и будет - одна сборка для ущербных, другая - для "продвинутых".
Ведь сегодня никого не удивляет 5-6 сборок любого современного продукта под различные платформы, верно?

под платформы - пока не удивляет, хотя тенденция на тотальную замену всех этих монстров из 90-х и 00-х на x64 она вовсю шурует по планете (терабайты оперативки на x64 уже никого не удивляют, кому еще нужны эти big-endian - загадка, вон даже линукс окончательно оказывается от поддержки big-endian power)

но decimal number - это не тот случай, чтоб под него отдельную сборку делать

для разработчика это двойной pain - мало просто собрать, этож еще и тесты надо отдельно прогнать, а оно ему надо?

andrey_anonymousdbpatchдля разработчика это двойной pain - мало просто собрать, этож еще и тесты надо отдельно прогнать, а оно ему надо?
Надо конечно.
Некоторые IT-манагеры до сих пор мечтательно закатывают глаза, вспоминая, сколько распилили освоили на решении "проблемы 2000", которая яйца выеденного не стоила.
А тут вообще золотая жила из серии (для тех, кто помнит arvid и первые цифровые видеоформаты) "Прорыв года! Наконец-то фидошники научились использовать видеокассеты для хранения видеофильмов!"

ой да ладно, ArVid отмер раньше, чем качественные .avi появились.

а манегеры - они вон как-то не сильно на M7 по причине нативного number переходят, так что мимо.

andrey_anonymous754-2008: Числа. С. Плавающей. Точкой. Теперь. Можно. Использовать. Для. Десятичных. Вычислений.


ты это сначала манагеру донеси, что для того, чтоб считать дебет и кредит всенепременно нужно что-то, отличное от double
если сразу не уволят "за несоотвествие" - расскажешь, чем все закончилось?

andrey_anonymousdbpatchсначала манагеру донеси, что для того, чтоб считать дебет и кредит всенепременно нужно что-то, отличное от double
Неправильно ты, дядя Федор, бутерброд ешь.
Манагеру глубоко фиолетово на double и даже на triple.
Манагеру дай денег заработать.
А тотальная замена железа - это же золотое дно.
Кароч, когда интел расчехлится - вангую новую инкарнацию "проблемы 2000 года", что-то вроде "проблемы приблизительности точных вычислений". Эксперты статеек тиснут много новых, вендоры HW отрапортуют о новой супе-пупер-платформе, которая "считает точно", вендоры всяких аксапт срочно выпустят "advanced" версию продукта...
Индустрии давно не хватает драйва.

так уже тискали, толку с того?

манагеру нужно пояснить финдиректору, зачем нужен мульен денег. с x64 это было просто - "у нас так много данных, что в память не вмещается".

а пояснить "нам нужен новый способ что правильно копейки считать" - вызовет лишь хохот в наблюдательном совете,
типо "блин, а что, мы все эти годы как-то неправильно деньги считали? иди иди, шутка не удалась".