Функция Round?

  • Автор темы Автор темы alexstudent
  • Дата начала Дата начала
ZhAN
А зачем в данном месте округление тарифа?
Либо храните в системе не округленные числа, либо пишите механизм вычисления последнего платежа как Всего-Выплачено )
 
А если округлить до 1.93, то будет 20 в плюсе? :) Бизнес такой бизнес.
Просто разбивать нужно не на равные части.
 
Вы получили договор страхования на руки где застраховали что то, страховая сума составила 100 000
Вам рассчитали тариф 7,70
подгонка по ваше утверждение - не более того
сумма м.б. любой
 
Вы как клиент хотите этот платеж разбить на 4 части, а СК должна отобразить тариф периода и суму периода
Итого тариф периода 7,7/4 =1,925 округляем получаем 1,92
Округление бабла - гениальная идея. Вот тока почему сразу до сотен не округлять? Тариф будет 1900, а сэкономленную на округлении сотку денег попилить с клиентом ;-)
Вы пытаетесь решить такую задачу: разбить произвольную сумму денег на N равных платежей, таким образом, чтобы каждый платеж был кратен 10. Проблемы возникли не из-за функции округления, а из-за того, что эта задача в принципе нерешаемая.
Никакой алгоритм округления вас не спасет: при округлении всегда появляется погрешность, при совершении операций с округленными величинами погрешность накапливается. Подробности по ссылке lmike-а про точность вычислений.
Повторю еще разок мантру: использование чисел с плавающей точкой для финансовых операций должно приравниваться к преступлению.
 
можно смотреть с разных сторон и спорить долго, а вы посмотрите со стороны программиста у которого есть четкое тз, и тогда станет понятно что иногда проще согласиться чем объяснить, что секса не будет. :-)
 
можно смотреть с разных сторон и спорить долго, а вы посмотрите со стороны программиста у которого есть четкое тз, и тогда станет понятно что иногда проще согласиться чем объяснить, что секса не будет. :-)
Соглашаться можно с кем угодно и с чем угодно, но если ТЗ требует того, что написано выше, его нельзя назвать чётким. Попробуйте всё-таки объяснить заказчику, что сумму в 11 у.е. невозможно разделить на 2, 3, и т.д. равных платежа. В конце-концов, ТЗ пишут люди, а людям свойственно ошибаться. Предложите выпустить дополнение к ТЗ, учитывающее данную проблему, если отступления от ТЗ недопустимы.
 
можно смотреть с разных сторон и спорить долго, а вы посмотрите со стороны программиста у которого есть четкое тз, и тогда станет понятно что иногда проще согласиться чем объяснить, что секса не будет. :-)
Я как раз со стороны программиста и выступаю.
Четкость ТЗ и его выполнимость - не одно и то же:
Иногда таки нужно менять ТЗ. Вариантов масса, часть здесь привели: отказаться от округлений, мириться с погрешностью, делать платежи не равными, всегда округлять в пользу компании и т.п.
P.S. Вы в примере измените кол-во периодов на 3 или 6 и подумайте, что будете делать в этом случае.
 
P.S. Вы в примере измените кол-во периодов на 3 или 6 и подумайте, что будете делать в этом случае.

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

:D
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!