из БД MySQL из поля float(4,1) в MaskEdit заношу число 63,6. в MaskEdit-е вижу 63,5.
маска MaskEdit-а "00,0;1;_". одни числа отображаются корректно, другие изменяются на одну десятую
то вверх, то вниз.
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
21-05-2020 09:11 | Комментарий к предыдущим ответам
Чисто для общего развития и маленький ликбез... В бухгалтерии, согласно приказа МинФин-а, свое округление... Суть которого в том, что типа в четных случаях округление в минус, в нечетных - в плюс. Есть даже всем известный парадокс (в инете можно найти) про "откуда рубль взялся". Т.е. если рассчитывается зарплата на сто человек, то нечетные по ведомости могут получить лишнюю копейку, а четные - такой возможности лишены...
18-05-2020 13:35 | Комментарий к предыдущим ответам
Да это понятно. Ног написать то все равно хочется :-)
А насчет бухгалтерии... настоящую официальную бухгалтерию не делал. Но вот когда для внутреннего использования делал систему распределения поступающих сумм на кучки в соответствии с набором формальных правил, то заранее оговорил точность расчетов и кучку, куда будут добавляться погрешности округления. Так что конфликтов не было.
18-05-2020 13:12 | Комментарий к предыдущим ответам
>>> А для типа currency сработает
А в бухгалтерии такие операции существуют? Обычно там всякие суммирования-вычитания, процентики... Главное - это копеечку не потерять в одну сторону. Помню, писал программу (на PHP правда), там протокол выводился с точностью до двух знаков (ну вполне логично, рубли-копейки), а вот в базе данных было что-то типа decimal(20,4), то есть 4 знака. И вот товарищи бухгалтера нашли (потому что они ВРУЧНУЮ ведомости пересчитывали), что кое где лишние копейки "набегают" из-за округления.
Так что для бухгалтерии в ЛЮБОМ случае нужно представление в "человекочитаемом" формате: 33 копейки (или 0,33 рубля). И обратно для человека должно появиться 99 копеек, а не рубль. Такие дела.
18-05-2020 01:21 | Комментарий к предыдущим ответам
>>> обусловленными использованием floating-point типов для подсчета денег
Ничего не понимаю. В Delphi есть специальный тип currency (ссылка на справку по последнему RAD Studio, но работает даже в Delphi 2006 точно, вроде как и в Delphi 7.0 было, в более старых точно не знаю). Поменять Double или Extended на Currency - это как два пальца. И ничего изобретать не надо, поддержка встроена. То есть использование самопальных типов (с учётом того, что перекрытие операторов в отличии от сишечки, в Delphi завезли буквально пару лет назад, да и то ограниченно) связано с некоторыми трудностями (надо пользоваться чем-то типа A.Add(B) вместо человеческого A+B), то для встроенного Currency этой проблемы даже быть не может!
17-05-2020 14:23 | Комментарий к предыдущим ответам
В случае чего вкладчики Сбера пострадают по-любому ;-)
А так, когда в очередной раз повозишься с ошибками округления, обусловленными использованием floating-point типов для подсчета денег, возникает дикое желание реализовать арифметику рациональных чисел. Честную... как учили: хранит два числа — числитель и знаменатель дроби. Числитель — целое, знаменатель — натуральное. По идее, для денег должно хватить, так как обычно при расчете сумм документов не используются ни корни, ни логарифмы.
Удерживает от данного шага только то, что все равно никто не будет переделывать программы на работу с новым типом данных.
15-05-2020 22:49 | Комментарий к предыдущим ответам
To Василий: Кстати, в некоторых скриптовых языках (например, AutoHotkey) совершенно случайно заметил такую штуку: числа с плавающей точной сравниваются знаком = совершенно корректно и, как бы это странно ни было, но код вида:
a:=1;
a:=a/3;
a:=a*3;
if a=3 then ...
работать будет (хотя в "честных" языках программирования - нет). Как "внутри" сделано - не знаю, но есть подозрение, что внутри всё хранится в виде строк, а как только происходит операция - строка автоматом конвертируется в подходящий тип данных.
12-05-2020 08:34 | Вопрос к автору: запрос дополнительной информации
Вы сформулируйте четко, чего добиться хотите. Просто заява одни числа отображаются корректно, другие изменяются на одну десятую то вверх, то вниз изначально тянет на клюкву. В статье Вам на пальцах пояснили, что есть число с плавающей запятой и корректные методы оценки величин этих чисел (применение знака "=" - это моветон).
Василий, спасибо за ссылку.
в базе числа имеют формат float(4,1).
пока попробовал использовать FormatFloat, вроде ошибка перестала вылазить, но я не уверен, что это решение.
А Вы храните все числа в integer или bigint-ах. А визуализацию делайте через IntToStr и вставляйте точку или запятую куда нужно...
А если реально хотите понять эти "фокусы", то Вам сюда - http://www.delphikingdom.com/asp/viewitem.asp?catalogid=374 .
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
