Financial HP Calculator: Amortisation with Payments at begin of period

[Gil]

Take PV=10000
FV = 0
I%Y = nominal 12
P/Y = 12 (or 1)
Total of Payments 60 (or 5 if P/Y=1)
Mode of Payments =Begin
Then Solve for corresponding Payments

B1) Go to Armotize Plan
Choose 60 (or 5 if P/Y=1) for Payments
Press Armotize —> Balance ± 0

B2) Repeat A)
with same initial data, PV = 10000
Go to Armotize Plan
Choose 30 (or 1 if P/Y=1 and total N=5) for Payments
Press Amortize
Repeat the process once for the remaining 30 Payments
—> Final Balance ≠ zero on my HP50G (final balance = -75.8524360235)
(Or, if P/Y=1 and total N=5), repeat the process 4 times with each time only 1 Payment to be amortized:
Interests on my HP50G are given as 5 times = 0, but 0 should be always valid once, ie only for the very first (amortisation) Payment during the whole amortisation process. With P/Y=1 and total N=5, amortizing 5 times, each time with 1 Payment, gives an unwished final balance of -2384.3630331).

Could somebody owning a financial calculator (HP, TI, CASIO, etc.) check that "logical" (payments at beginning, —> interest each time for a period = 0 —> interest = 0) but confusing" issue, that does not correspond to the wished result?

Many thanks in advance for your painstaking.

I understand now, in that special case of PMT at begin, that, after launching the first time the amortisation with the initial chosen number of Payments (in my case, 30) and pressing B—>PV, we are back at the normal situation "Payments at the End".
Therefore, to get the expected/wished next amortisation results with the HP50G, we have simply to return to main, initial menu (the one that solved for PMT) and modify the settings: a) change N=60 into N-"previous already amortised payments", ie N-30 = 60-30 =30, and b) let here, now, option END payment (instead of BEGIN) and then only carry on normally with the usual amortisation.

Not very complicate, indeed, but needs attention/reasoning, and consequent manipulations/changes (back once in the previous PMT Solver menu and back to amortisation menu).

Regards,
Gil

[Werner]

Both the 17BII and the 12C get this right.
(on the 12C, remember to set N=0 before doing AMORT)
No difference between amortizing 60 payments in one go, or 30 twice, BEGIN mode.
(Plus42 also gets it right)
the 49G exhibits the same erroneous behavior. It would seem no-one noticed up till now!

Cheers, Werner

[Gil]

Thanks, Werner, for your reply.

I saw that unexpected — but understandable — issue when checking the given results by the HP50G with my own complete TVM-Growth-Amortisation program that includes the possibility of C/Yr ≠ P/R and Payment-Growth≠0.

By the way, how do handle your different calculators models the case of rounding each intermediate result to the cent (2 RND)?

The HP50G, with its own built-in program, looks if 2 (3, 4, etc.) FIX was set and then execute "2 RND".

As far as I am concerned, when amortising at the very beginning for the first time, I decided to allocate, on stack level 2, once a value of 1 (for rounding) or 0 (exact, no rounding) to a variable called rd just before entering, on level 1, the wished number of payments to be amortised the first time; then, the 2nd group, the 3rd group, etc. of amortising payments don't require the above setting on level 2, but just on level 1 the required new payments to be amortised.

Then, for each intermediary result — new p, new int — , if variable rd = 1, then the program executes 2 RND.

The option would be not to test anything,
but executing the 2 commands in a row —>STR OBJ—>,
having set previously (or not for no rounding) the mode 2 FIX to see the rounding effects.

I don't know which solution is the most appropriate: the latter one from the built-in convention calculator program, or the one obliging you to enter once, in level 2, if rounded results are wished or not.

Commentaries about the above welcome.

Regards,
Gil

[Werner]

(06-06-2024 01:28 PM)Gil Wrote:  By the way, how do handle your different calculators models the case of rounding each intermediate result to the cent (2 RND)?

All of the built-in solvers (12C,17BII,Plus42) rely on the display mode (FIX 2) to round to 2 digits;
For my Gradual Payment Mortgage Amortisation equation, that won't work as there is no 'round to display mode' function, only RND(X: D) with D meaning to D places, absolute (D positive) or significant (D negative), so I just included an extra parameter D, and set that to 2 for rounding to cents or -12 for no rounding at all.

Cheers, Werner

[Gil]

But for your "Gradual Payment Mortgage Amortisation equation", I presume that you calculate the initial PMT1 with full precision. It's only for the amortisation schedule with effective payments, interests and balance that you round the intermediate result with 2 RND instruction. Right? And as I understood, you leave the user round the intermediate results with 3 or more digits?

[Werner]

(06-06-2024 02:48 PM)Gil Wrote:  But for your "Gradual Payment Mortgage Amortisation equation", I presume that you calculate the initial PMT1 with full precision.

Yes

Quote: It's only for the amortisation schedule with effective payments, interests and balance that you round the intermediate result with 2 RND instruction. Right?

with RND(..: D), yes

Quote: And as I understood, you leave the user round the intermediate results with 3 or more digits?

? Don't know what you mean here.
Do you mean the gradually growing payments? No, I leave them at full precision and use the rounded value for interest and balance calculations, but I do not store the rounded value in the PMT variable.

W.

[Gil]

"Do you mean the gradually growing payments? No, I leave them at full precision and use the rounded value for interest and balance calculations, but I do not store the rounded value in the PMT variable."

If interests are calculated to the cent, ie with 2 digits after the comma, then if PMT1 is found equal to 2511.73389, the client should start paying — theorically—, in the armotization plan, exactly (2511.73389; 2 RND) = 2511.73.
It seems, however, that it is not what I understood from the above.

From my logic above, but I seem to be wrong?, if the growing payments show a yearly increase of 5%, then the second payment should be equal to ("exactly 2511.73" ×( 1+5/100/12); 2 RND). Or not?

Another point
Why do you use negative integer before RND command?
Is full precision not equivalent to simple 12 RND?
So that x RND, with x=0, 1, 2...11,12, should be enough to tackle all possible choices. Right?

Thanks again for your explanations and co-operation, Werner.

Regards,
Gil

[Werner]

(06-06-2024 04:05 PM)Gil Wrote:  If interests are calculated to the cent, ie with 2 digits after the comma, then if PMT1 is found equal to 2511.73389, the client should start paying — theorically—, in the armotization plan, exactly (2511.73389; 2 RND) = 2511.73.
It seems, however, that it is not what I understood from the above.

From my logic above, but I seem to be wrong?, if the growing payments show a yearly increase of 5%, then the second payment should be equal to ("exactly 2511.73" ×( 1+5/100/12); 2 RND). Or not?

I'm not sure what "exactly" it should be, but I find it more logical - and ever so slightly more accurate - to calculate the successive payments as (if payments change after a year, not every month)

PMT=2511.73389 (result of GPM solve)

then

PMT-1 = RND(PMT;2) = 2511.73
PMT-2 = RND(PMT*1.05;2) = 2637.32
PMT-3 = RND(PMT*1.05^2;2) = 2769.19
..

while here it doesn't make any difference (so far), it occasionally results in a cent more or less.. and a smaller resulting balance after amortization ;-)

Quote:Another point
Why do you use negative integer before RND command?
Is full precision not equivalent to simple 12 RND?
So that x RND, with x=0, 1, 2...11,12, should be enough to tackle all possible choices. Right?

positive numbers 0-11: the number of decimals
negative number 1-12: the number of significant digits

RND(1.23456789E-5;8)= 1.235E-5
RND(1.23456789E-5;-8)=1.2345679E-5

Cheers, Werner

[Gil]

Do you really mean
PMT-1 = RND(PMT;2) = 2511.73
PMT-2 = RND(PMT*1.05;2) = 2637.32
PMT-3 = RND(PMT*1.05^2;2) = 2769.19

or rather

PMT-1 = RND(PMT;2) = 2511.73
PMT-2 = RND(PMT-1*1.05;2) = 2637.32
PMT-3 = RND(PMT-1*1.05^2;2) = 2769.19,
having the initial payment PMT-1 as reference for successive growth?

Depending on your confirmation or not I might change my program calculation for the successive PMT-i.

For the PMT-11, we might
have then "my" 4091.34350092 —>. 34
instead of your 4091.34983732 —>. 35, ie a cent of difference...

Interesting would be to know the most general banking use in that matter, though, of course, the difference is quite ridiculous here.

Regards,
Gil

[Gil]

After reflection, Werner, I think that your view makes sense:
for the mortgage calculation, we have try to be as near as possible to the original PMT found without the rounding in order to finish with a balance as close as possible to the target zero value.