PERL результат сложения

Из template toolkit нельзя вызвать функции форматирования,
лучше конечно перобразования (деньги счет любят).

а в чём проблема? тебя удивляет сам результат или как получить более точный результат?

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

питон:

>>> 33.61 + 234000 - (0 + 106698.39 + 127300)

35.21999999997206

>>> 33.61 - 127300+ 234000 - 106698.39

35.220000000001164

информатика - лженаука :)

Всё правильно, не всякое десятичное число можно представить в двоичном виде.

my $number = sprintf "%.2f", 35.2199999999721;

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

"Не храните деньги во float-ах" - первая заповедь разработчика бизнес-софта.

Всё правильно, не всякое десятичное число (дробь) можно представить в двоичном виде...

...в виде конечной дроби.

Вот так-то лучше :)

template::toolkit этого не понимает, есть + - / *.
Вызвать sprintf "%.2f", 35.2199999999721 нельзя из шаблона.
Пример: [% hash_var.sum1 * hash_var.ostatok - ... %]

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

Проблема не в хранении в базе, а в сложении внутри шаблона.

я конечно может чего не знаю, но шаблон - это как выглядит, а в каких единицах денежка - логика, которая должна быть в контроллере, если такой есть либо в базе. у тебя ведь постгрес - о большем и мечтать не надо: создай функцию foo - и вперёд: select bar, foo(zoo) from mymoney where I am weasel

> Проблема не в хранении в базе, а в сложении внутри шаблона.

Проблема в выборе неправильного типа. Целые числа замечательно складываются безо всех описанных тобой артефактов.

Программа может показаться простой :)
В PostgreSQL хранится таблица itog:
doc_id int, org_id int, varname varchar(30),
varvalue(double precision) - одна запись на одну переменную.
Можно заменить на:
doc_id int, org_id int, varname varchar(30), varvalue(text) - одна
запись на весь шаблон.
В базе числа хранятся нормально: select * from itog;
выдает тоже самое, что ввел пользователь.

Представитель организации заполняет данные, сохраняет и печает отчет
из браузера. В головной организации смотрят на итог по всем
организациям одного документа и печатают отчет.
Раньше все отчеты привозили в формате Excell и объединяли все
файлы вручную или забивали заново с бумаги.

Шаблон (html + input поля), имена полей даются при создании шаблона
почти произвольно. Логики в шаблоне почти нет, могут быть выражения
типа "Итог (строки 1+2-9)", которые обновляются перед печатью.
Сохраняются в базе все поля с типом input независимо от названия,
этим занимается AJAX/JQuery.
Вот на этих строках "итог" и появилась проблема округления/печати.

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

Ошибка, нужно читать так:
"Можно заменить на:
doc_id int, org_id int, var_name_value (text)
- одна запись на весь шаблон."

(33.61*100 + 234000*100 - (0*100 + 106698.39*100 + 127300*100))/100 = 35.22

Неожиданный выход из ситуации.
Подробно не тестировал на другой комбинации цифр.

ППЦ. Этим людям доверяют считать деньги...

\dT numeric