ZhAN
А зачем в данном месте округление тарифа?
Либо храните в системе не округленные числа, либо пишите механизм вычисления последнего платежа как Всего-Выплачено )

 

А если округлить до 1.93, то будет 20 в плюсе? Бизнес такой бизнес.
Просто разбивать нужно не на равные части.

 

20 денежек в минусе

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

 

Вы получили договор страхования на руки где застраховали что то, страховая сума составила 100 000
Вам рассчитали тариф 7,70

подгонка по ваше утверждение - не более того
сумма м.б. любой

 

Вы как клиент хотите этот платеж разбить на 4 части, а СК должна отобразить тариф периода и суму периода
Итого тариф периода 7,7/4 =1,925 округляем получаем 1,92

Округление бабла - гениальная идея. Вот тока почему сразу до сотен не округлять? Тариф будет 1900, а сэкономленную на округлении сотку денег попилить с клиентом ;-)
Вы пытаетесь решить такую задачу: разбить произвольную сумму денег на N равных платежей, таким образом, чтобы каждый платеж был кратен 10. Проблемы возникли не из-за функции округления, а из-за того, что эта задача в принципе нерешаемая.
Никакой алгоритм округления вас не спасет: при округлении всегда появляется погрешность, при совершении операций с округленными величинами погрешность накапливается. Подробности по ссылке lmike-а про точность вычислений.
Повторю еще разок мантру: использование чисел с плавающей точкой для финансовых операций должно приравниваться к преступлению.

 

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

 

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

Соглашаться можно с кем угодно и с чем угодно, но если ТЗ требует того, что написано выше, его нельзя назвать чётким. Попробуйте всё-таки объяснить заказчику, что сумму в 11 у.е. невозможно разделить на 2, 3, и т.д. равных платежа. В конце-концов, ТЗ пишут люди, а людям свойственно ошибаться. Предложите выпустить дополнение к ТЗ, учитывающее данную проблему, если отступления от ТЗ недопустимы.

 

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

Я как раз со стороны программиста и выступаю.
Четкость ТЗ и его выполнимость - не одно и то же: http://alex-aka-jj.livejournal.com/66984.html
Иногда таки нужно менять ТЗ. Вариантов масса, часть здесь привели: отказаться от округлений, мириться с погрешностью, делать платежи не равными, всегда округлять в пользу компании и т.п.
P.S. Вы в примере измените кол-во периодов на 3 или 6 и подумайте, что будете делать в этом случае.

 

P.S. Вы в примере измените кол-во периодов на 3 или 6 и подумайте, что будете делать в этом случае.

Хорошо то что период может быть только полугодие и получится 2-мя платежами, или поквартально 4-мя платежами, все остальное идет одноразовым платежом.

 

Хорошо то что период может быть только полугодие и получится 2-мя платежами, или поквартально 4-мя платежами, все остальное идет одноразовым платежом.

Это "Хорошо" лично для вас - плохо