Округление в таблице амортизации

В настоящее время я пишу программу C, которая, помимо прочего, создает и распечатывает таблицу амортизации с номерами, округленными до двух цифр. Я получаю правильные цифры во всем мире, то есть: month_payment = main_paid + interest_paid, за исключением последней строки (последний платеж), где иногда мои результаты не складываются, а один на один. Например:Округление в таблице амортизации

MonthlyPay: 88,83, PrinPaid: 87,96, IntPaid: 0,88

Конечно, глядя на результаты напечатанных 6 цифр это легко понять, почему это происходит:

MonthlyPay: 88.834637, PrincPaid : 87.955087, IntPaid: 0.879551

Каков наилучший способ справиться с такой ситуацией?
Что делают финансовые учреждения?

источник

2016-11-12 JSz

Последняя строка в амортизации обычно отличается. Его нужно вычислять несколько иначе, чем другие строки. Окончательный платеж должен быть последним балансом плюс проценты за последний период, так как это сумма, которая приводит к нулю окончательного баланса. Вы можете делать расчеты в гроши, чтобы бороться с ошибкой округления. Для максимального реализма убедитесь, что все округление дробных копеек находится в пользу банка. –

. Я делаю вычисления несколько иначе для последнего платежа, и именно поэтому у меня такие проблемы округления. В любом случае, я закончил создание простой процедуры, которая проверяет, равна ли сумма округленных процентов и основного платежа ежемесячной оплате, а если нет, то она добавляет один копейки к ежемесячной оплате или выплате процентов. Это похоже на хак, но это работает как шарм. И это всегда благоприятствует банку. – JSz

@JSz - Звучит как правильное решение для меня. –

Нет стандарта.

Есть те, кто говорит, "Once you round, use the rounded value for all further totals."

Есть другие, которые не согласны, говорят, что you should sum the unrounded values to avoid accumulated rounding error. Например, 0.0666 + 0.0666 + 0.0666 + ... 15 раз должно приблизительно равняться 1.0000, но если округлять каждый член до 2 десятичных знаков перед суммированием, то получается 0.07 * 15 = 1.05! Итак, это аргумент в пользу использования неосновных значений. Ваш пошаговый только один-единственный-один, потому что у вас есть только два срока, которые вы суммируете.

Я думаю, что в конечном счете вы должны учитывать плюсы и минусы каждого метода. Кто будет интересоваться ошибками округления? Просто программисты? Учет? Клиенты? Как это влияет на этих людей? И вы можете выпустить инструкцию, которая очищает двусмысленность, например "Values displayed to 2 decimal places.", и в этом случае вы вообще ничего не крутите, а просто показываете первые два десятичных знака везде.

источник

2016-11-12 03:37:25

Я попытался использовать округленные значения в вычислении, но это просто не работает здесь. Во-первых, в некоторых случаях наблюдались огромные кумулятивные ошибки по сравнению с расчетами, не использующими округленные значения. Для двоих, в одном случае процентная ставка, округленная до ближайшего цента, оказалась равной месячной оплате! Это наверняка приведет к тому, что на меня кричит интересная таблица амортизации. – JSz

Округление в таблице амортизации

ответ

Смежные вопросы