Это шутка?

быдлокод

Ну ладно.

https://en.wikipedia.org/wiki/IEEE_754

• Числовой тип имеет проблемы с точностью.

0.1 + 0.2 === 0.30000000000000004;

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

• NaN не является обозначением числа, а само по себе является числом.

typeof NaN === "number"
// Чтобы сделать ситуацию ещё более трудной, NaN не равно самому себе
NaN != NaN
NaN !== NaN

// Проверяется, является ли "х" числом "NaN".
x !== x
// Это - правильный способ тестирования
isNaN(x)

Здесь показано, как должно быть согласно IEEE754. Снова проблема в непродуманном выборе IEEE754 со стороны разработчика или конструктора языка.

Это шутка?

Разница в две копейки это очень серьёзно. Самое главное, какого хрена одно и тоже ПО на одних и тех же исходных данных выдаёт разные результаты.

Читать тут

404

Хранить деньги во float - ламерство. Для этого есть спец. типы (Decimal, BigDecimal, типа того), не теряющие точность. На худой конец в long int в копейках.

Это азы программирования, алё.

Снова проблема в непродуманном выборе IEEE754 со стороны разработчика или конструктора языка.

Да это понятно, но мы имеем дело с тем, что имеем. Олап компоненты платные, закрытые и никто в их кишки не залезет.

Хранить деньги во float - ламерство. Для этого есть спец. типы (Decimal, BigDecimal, типа того), не теряющие точность

Да как будто я их туда засунул.

Разница в две копейки это очень серьёзно. Самое главное, какого хрена одно и тоже ПО на одних и тех же исходных данных выдаёт разные результаты.

ну тут 0.30000000000000004 погрешность не две копейки, а гораздо меньше. Просто округляйте до сотых

Ну тогда страдать. Потеря точности в IEEE754 - норма.

Искать в сети Floating-Point Arithmetic )

Просто округляйте до сотых

+1. Хотя если у вас на тех же x86-ых всё работает, то очень может быть что дело в чём-то другом.

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

ну тут 0.30000000000000004 погрешность не две копейки, а гораздо меньше

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

Поделись.

вроде бы не первое апреля уже

Две копейки могут набежать или не набежать при изменении порядка сложения. Поскольку олап читает из БД наверняка, то так и может получиться, если в каком-то запросе порядок записей недетерминирован (а такое бывает часто).

И такое может проявляться именно на старых пнях? Тут вопрос не в том, что ошибка, а в том, что ошибки разные.

Да хватит угрорать, тут и так всем плохо:)

Неее. У нас исторически олап для бухов, там все отчёты.

А какого ответа ты ждёшь?

Ну отключи гипертрединг, хз. Запусти в виртуалке с одним ядром. Назови свой десктоп решением™ и продай бухам за 100500.

ну тут 0.30000000000000004 погрешность не две копейки, а гораздо меньше

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

Плавающая точка почему так называется знаишь?

Мне интересно чисто теоретически, насколько разница в сложении флоатов на x86 и x64-86 может отличаться.

Я так думою,

на x86 может промотиться до 80 бит FPU, а на x86_64 считается в 64-битах в MMX-регистрах.

P. S. Это если собирается для x86 и x86_64 отдельно. Если просто x86-код запускается на x86_64 — ХЗ.

P. S. Это если собирается для x86 и x86_64 отдельно. Если просто x86-код запускается на x86_64 — ХЗ.

Понятно, что ничего не понятно. Дали какие-то «сорцы», где всё упирается в либу хз как собранную и из чего. Так и работаем.

ну тут 0.30000000000000004 погрешность не две копейки, а гораздо меньше. Просто округляйте до сотых

А если там будет 0.2999999999999998, в какую сторону округлять?

ТС, выкинь float и используй decimal. А автору кода ввали леща.

Плавающая точка почему так называется знаишь?

Понятно, что там могут быть неточности, что, реально настолько, чтобы 10к раз сложить и получить разницу в сотые? Как это можно воспроизвести?

гораздо меньше

От операций с этими числами зависит. Мой любимый камент на эту тему: https://habr.com/ru/post/305276/#comment_9692112

ТС, выкинь float и используй decimal. А автору кода ввали леща.

Автор кода на другом конце шарика. Код покупной и написан в конце нулевых каким-то чехом. Дельфисты прихерачили всё мышкой и в продакшон.

Автор кода на другом конце шарика.

Единственная причина, которая может помешать тебе подвергнуть его праведному гневу – это если он умер и креминован. Потому что если он просто умер, то ты всё ещё можешь найти его могилу, откопать его останки и насрать в пустые глазницы его черепа.

Код покупной и написан в конце нулевых каким-то чехом. Дельфисты прихерачили всё мышкой и в продакшон.

В таком случае этот софт надо выкинуть к чёртовой матери. Я не шучу сейчас. Если его авторы были настолько дебилами, то там вполне могут быть косяки ещё хуже. Либо беги из этой конторы со всех ног.

Да куда бежать, везде карантин.

а на этом конце шарика сидят говношлёпы, которые почему-то называют себя инженерами, и радостно гыгыкают «ууу, флот делает бум». прелесть какая.

а на этом конце шарика сидят говношлёпы, которые почему-то называют себя инженерами

Да, не говори.

Удалённая работа спасёт отца русской демократии!

Нет, это может проявляться на любых компах, если использовать неточное представление денежных величин. Для сложения. Если есть умножение/деление, то даже точное представление не помогает. Например, поделить 100=00 рублей на 3 и опять помножить на 3 - получится 99=99. А если сначала помножить на 3, а потом поделить, то 100=00. Ну и НДС всякий, конечно же.

Разный порядок слагаемых может возникнуть из-за обработки на клиенте запроса select float from table, если порядок записей может меняться. Насчёт обработки на стороне сервера уже так точно не скажу, емнип там обычно есть тип BCD, в к-ром всё и хранят.

Раз они платные продай их обратно. Ещё и взыщи за то что атмту впаривают за деньги

А, так у тебя ошибка разная при одинаковых данных, но на разных архитектурах?

Раз они платные продай их обратно. Ещё и взыщи за то что атмту впаривают за деньги

Лучше иск на 1 млн. баксов подать «за моральный ущерб».

на x86 и x86_64 не отличается. На x87 float 80битный

А, так у тебя ошибка разная при одинаковых данных, но на разных архитектурах?

Да. Не скажу точно какие там архитектуры, но подозреваю, что всякое старьё. У нас в конторе у всех x64 и результаты одни и те же. Даже потестить косяки не у кого.

Даже потестить косяки не у кого.

В QEMU запусти же ну.

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

Там венду надо ставить, не хочу.

float 32 бита и 80 на x87
double 64 и 80 соответственно
В x86_64 по дефолту x87 не юзается. Но можно вроде как указать -mfpmath=x87 и будет юзаться. Влияет это только на вычисления, calling conversion не должно затрагивать

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

Если используется x87 то float длиннее

Да, там всё обновляется автоматом. Там хпшка еще может где-то стоять, я даже не видел эти компы.

Бухгалтерия - важнейшее место на любом предприятии. Я бы на твоём месте себя преодолел, если уж это тебе поручили. Т.к. воспроизвести ошибку всё же надо. Иначе будешь гадать и шансы угадать не очень большие… У всяких SQL-серверов обычно бывает трассировка, её можно включить, посмотреть, какие делает отчёт запросы, воспроизвести их и что-нибудь в этом роде.

а кстати чё это они упоролись в 1980г делать 80бит?