Ну у меня сейчас вроде везде округляется всё где теоретически может быть дальше 0.01, эт вовремя этот баг нашел, ещё не сразу понял где подвох, думал я что-то пропустил, хотя по сути такой нюанс и пропустил..
Спасибо Вам! 🚬
Ну я примерно понял что там где-то спрятаны ещё циферки.. А как пофиксить такой результат?
ООО, вот буквально только что решил вопрос "красиво":
round((round(2.15,2)-round(2.15,2)),2)=0;
Ух, аж как гора с плеч. Оно кстате в ненужную сторону врядле округлит? (из 2.15 не выйдет 2.14 или 2.16?) А эт, может ещё как-то можно пофиксить?
И round() часом не выдаст NaN в самый неподходящий момент?
Так у меня при простом отнимании такое вышло т.е NaN, получается 2.15-2.15=-4.4408920985006E-16
первое число было достато из базы, а второе число вышло в результате 5.4-3.25=2.15, при этом если 0+2.15, то выходит 2.15, также пробывал 1+2.15 тоже норм, ещё пробывал (2.15-2.15=-4.4408920985006E-)+1=1
Поидее еслиб 2.15 было не число, то при прибавлении 1 или 0, выходилабы билиберда, а оно всё норм считает. Вообще первый раз такую аномалию обнаружил на ровном месте.. 🙅
И вот только что ещё затестил:
round((2.15-2.15),2)=-0
2.15-2.15=-4.4408920985006E-16
Получается и округлить не вышло. Как вообще лучше пофиксить такие дела?
Так а как хранить в копейках? Допустим мне пришло число 11.5, допустим уберу по хитрому запятую и 115 умножу на 10, выйдет 1115, далее мне например нужно вырезать с этого числа 70% и потом от этих 70% вырезать ещё 10%, далее отнять это от основной суммы и результаты распихнуть в 3 ячейки. (ну это алгоритм типичной партнёрки с рефами, цифры конечно же разные могут быть)
Так вот как ни крути, получается что выходят дробные числа.
Так вот если всё что ниже копейки не важно, то при расчётах можно делать intval(float) или он может выдать Nan? И опять же при выходе и входе ВСЁ РАВНО дробные числа выходят и гипотетически при конвертации 123000 в 12.3 может выйти этот Nan?
Или всётаки с типом данных DECIMAL(19,2) можно смело делать подсчёты, всё норм будет сохранятся а базу и глюк (NaN) может быть только с числами близкими к нулю?
И можно ли как-то конвертить числа NaN в нормальное дробное число?---------- Добавлено 30.06.2016 в 16:55 ----------
Версия sql 5.1.66-0+squeeze1
Так в принципе и с типом данных decimal(19,2) нормально сохраняет дроби, ну покайнемере у меня с типом FLOAT была ошибка в том, что вместо нуля (2.15-2.15), сохраняло в базу -4.4408920985006E-16, а вот после исправления типа данных с float на decimal(19,2), это дело норм сохранило и записало 0 (может с другими цифрами будут нюансы, не знаю).
Но далее у меня идут другие вычисления с дробными числами, которые точно будут больше 0 и мне их потом скорее всего придётся записывать в файл, ну и не хотелось бы чтоб выходили Nan числа. ИЛи Nan только с числами близкими к нулю могут быть? Вообще как-то культурно "фильтровать" т.е конвертить NaN в float можно? Я уже совсем запутался.
Зараннее спасибо за ответ.
Да мне всё что ниже сотых 0.01 - не нужно, я и так округляю в меньшую сторону)
Так что остановился на формате decimal(19,2)
Ещё мучал вопрос что за число -4.4408920985006E-16, оказывается это число 0, надеюсь с нормальными числами которые больше нуля - таких нюансов не будет..
Кстати вопрос, а если у меня при вычислениях вместо 7.77 выйдет число типа NaN, то при сохранение в базу оно сохранится нормально?
Ну теперь буду знать, спасибо. Если честно до этого не было надобности в точных подсчётах, возможно не замечал эти косяки.. В целом если юзать в базе DECIMAL с настройкой (19,2), то числа типа -4.4408920985006E-16 нормально сохраняются, получается если вывести на экран то что в переменной, то будет фигня, а вот в базу сохранилось как мне нужно 2.15
Уже в базе заменил все типа данных с FLOAT на DECIMAL, так что думаю норм будет.
Всем огромное спасибо. Реально 10 часов сидел ковырял это дело, мозг отключился. Всем добра и удачи!
Да я в ручную в базу пихал число 2.5 и 3.5 и 5.4, далее 5.4-3.5=2.5 и вот потом начались нюансы уже с этим "вычисленным" 2.5.
Вообще да, в базе float везде у меня. Поставил тип полей DECIMAL, теперь там дробные числа не сохраняются.. Ааааа, вот заметил прикол, при создании DECIMAL там было 10,0 формат, погуглил немного и поменял на 19,2
И о чудо, в базу всё записалось как надо, а вот на экран вывел результат "вычисления" из переменной и получилось -4.4408920985006E-16
Я так понял главное чтоб в базе норм было, а то что оно там в переменной коряво хранится эт можно забить болт на это?? В целом доволен, спасибо.
---------- Добавлено 30.06.2016 в 04:53 ----------
И как с допустимой погрешностью сравнить если 2.25==2.25 не работает? Этож элементарные числа вроде как..
Калькулятор же на компе работает норм? Та и в инете куча сайтов где реальные вычисления есть и всё без проблем..
Чтоб купить жене шубу и сапоги эт надо в МММ бабло вкладывать как Лёня Голубков)
Сергей Мафроди (основатель МММ) эт мой дружбан кстате, он мне мой сайт о бомжах даже рекламировал: https://www.youtube.com/watch?v=Gyl4E4EcPdc
---------- Добавлено 06.02.2015 в 00:51 ----------
Там такое барахло продают, народ постоянно споры открывает, меня лично китайцы раз 5 уже кинуть пытались, только через споры всё разруливаю.. Заказал помню куртку за 20 баксов, пришло такое говно, как буд-то с бомжа сняли, даже материал как-будто на солнце выгорел и 5 раз стирался, вообщем как у нас сэконд хенд только ещё и ширпотреб.., кстате рукава ещё короткие были, хотя размер мой. Ну и то цвет не тот, то товар от картинки координально отличается либо пишут оригинал, а присылают дешевую подделку. Также часто посылки вообще не приходят, хотя бывало бабки вернут, а посылка потом через месяц всётаки приходит.., особенно такая шляпа в групповых покупках..
Да, там просто они что-то тестировали и цифра в куках у меня висела, а бабло на счету оказывается было, то-то я смотрю странно что 2 бакса пол года висит.. Попробуй у себя куки почистить и кеш браузера, хотя если у тя недавно цифра менялась, то у тя дело не в браузере..
Всё норма, вопрос решили, просто нужно было кэш в браузере обновить))) Всем успешных выплат на адмитад без задержек и побольше дохода!
