PPC Journal V2N6 - TVM i% unknown on HP-65

[AndiGer]

Found an interesting program on Gene Wright's homepage on solving TVM with I% unknown to run on a 65.
http://www.rskey.org/gene/calcgene/ann65i.htm

Unfortunately the program does not do what is promised.
The description is incorrect in the meaning that it will not show 0,00 after entering N, PMT, PV, FV but just the entered value (I% known does). Statement 63 will give key code 33 (STO not RCL).

And another thing: If I press B the programm never terminates. Guess it should be the first statement so that RTN stops the calculation.

Anbody out there who still owns PPC Journal V2N6 p. 14 and 15 or a copy of it and can give the answer where is the problem in the given code?

Thanx
Andi

[Gene]

Sorry for the delay. Here are the relevant two pages. I can't do the checking at the moment.

HP 65 program listing

[SlideRule]

Yes, there are differences in the transposed & the original program listings. In short, a line of code is missing between lines 47 & 48;
47...81........./
.......34 01....RCL 1
48...32.........f-1

AND a miscode at line 72 (73 w inserted code);
72...35 22...g X<>Y?
was interpreted as
72...35 22...g X<=Y?
rather than
72...35 21...g X<>Y?

kinda like the STO RCL code transpose mentioned earlier.

As far as the LBL's returning 0, only claimed for the 'other' prgm, not this one {sorry}

Hope this helps!

BEST!

SlideRule

[Dieter]

(10-15-2015 12:35 AM)SlideRule Wrote:  In short, a line of code is missing between lines 47 & 48

In Gene's listing it's actually between line 46 and 47. But the first two lines (LBL B) are missing, so after adding these it should be between line 48 and 49:

Code:

48   81     /
49   34 01  RCL 1
50   32     f-1
51   61     TF 1
...

(10-15-2015 12:35 AM)SlideRule Wrote:  AND a miscode at line 72 (73 w inserted code);
72...35 22...g X<>Y?
was interpreted as
72...35 22...g X<=Y?
rather than
72...35 21...g X<>Y?

No, there is no error at this point. The correct instruction is X≤Y?, or key code 35 22. Here the original listing is wrong! The program finds an iterative solution for the interest rate in R2, and right before this command it adds a correction term (ST0+2) and checks whether its absolute value is sufficiently small. If not ((1E–6 ≤ |correction| which means |correction| ≥ 1E–6), it jumps back and does another iteration. If the X≤Y? test is replaced with X≠Y? the program will almost certainly loop forever ...unless the applied correction term happens to be exactly 1E–6. So yes, the X≤Y? test in Gene's transscription is correct.

BTW Gene, maybe you should repair the formatting of this code on rskey.org from line 71ff. And in both HP65 annuity programs the first two lines are missing (LBL B resp. LBL A).

I tried this program on an HP41 and in some cases it converged to a solution, in others it didn't. Maybe I got the input values wrong, possibly with wrong signs. At least I did not get the results I expected. Can someone provide a sample problem for this program?

Dieter

[SlideRule]

Dieter

Thanks for the more intense review.
My post was a first casual review of ...
1- validate a problem(s)
2- locate possible origin(s)
3- NOT suggest a solution(s)
... since I did NOT author any of the source material.

I agree, a composite-redacted version should be published w/ ALL typos, omissions, etc reaccomplished. Again, thanks for the follow-up.

BEST!

SlideRule

[SlideRule]

[/color]

(10-12-2015 09:24 PM)Gene Wrote:  HP 65 program listing

My re-type of the ORIGINAL 65 program code. My redactions are in RED
[attachment=2668]

Maybe a basis for a clear/clean code?

BEST!

SlideRule

[AndiGer]

First of all: Thank Gene for the fast publishing of the original document pages.
I would never ever have found where is the problem of the missing statement (RCL 1) without that.

Also thanks to you others for reviewing and discussing that topic.

gx<=y to compare with E-6 was clear to me (although the original document gives gx<>y).
It was also clear to me to add the missing LBL B at the beginning.

I just now ran the program only with basic values. The result given was correct.
N=5
PMT=500 (Ordinary Annuity - "End")
PV=0
FV=-3000
Result I%=9,12806

Andi

[SlideRule]

(10-15-2015 04:54 PM)AndiGer Wrote:  First of all: Thank Gene for the fast publishing of the original document pages.
I just now ran the program only with basic values. The result given was correct.

My second atempt at a CLEAN program listing.

[attachment=2670]

BEST!

SlideRule

[Dieter]

(10-15-2015 04:54 PM)AndiGer Wrote:  I just now ran the program only with basic values. The result given was correct.
N=5
PMT=500 (Ordinary Annuity - "End")
PV=0
FV=-3000
Result I%=9,12806

Fine. How many iterations were required?
I did a quick and dirty test on an HP41 and convergence was quite slow.

Did the program also return the correct value for BEG mode (flag 1 set)?
This should yield 6,14024%.

I also tried a different algorithm with a usual Newton iteration with quadratic convergence, and the result was returned after 4 resp. 3 iterations.

BTW, does this program use the same sign convention for PV, PMT and FV as later HPs or is it different in this regard?

Dieter

[AndiGer]

Running with flag 1 set (begin mode) yields 6.14021. Nearly correct ;-).
Needs 11 iterations if I counted correctly.

Running in end mode with my given values needs 3 iterations.

Andi

[Dieter]

(10-16-2015 04:52 PM)AndiGer Wrote:  Running with flag 1 set (begin mode) yields 6.14021. Nearly correct ;-).
Needs 11 iterations if I counted correctly.

Running in end mode with my given values needs 3 iterations.

Yes, that's what I also noticed: End mode works fine, but in Begin mode convergence is very slow, comparable to simple bisection. There must be something wrong with the program. Maybe someone can take a closer look.

In the meantime I tried a different approach. Since I do not own an HP65 maybe someone else may try this code.
IMPORTANT: all data is entered according to the sign convention of later HP calculators!

Code:

 01  LBL
 02  B
 03  RCL 1
 04  RCL 3
 05  x
 06  RCL 4
 07  +
 08  RCL 5
 09  +
 10  RCL 5
 11  RCL 4
 12  -
 13  RCL 1
 14  x
 15  /
 16  2
 17  x
 18  STO 2
 19  LBL 1
 20  EEX
 21  3
 22  /
 23  1
 24  +
 25  1
 26  g x=y?
 27  GTO
 28  2
 29  RCL 2
 30  +
 31  STO 6
 32  RCL 1
 33  CHS
 34  g
 35  y^x
 36  STO 7
 37  RCL 5
 38  x
 39  1
 40  RCL 7
 41  -
 42  RCL 3
 43  x
 44  RCL 2
 45  /
 46  STO 8
 47  f
 48  TF 1
 49  RCL 6
 50  x
 51  +
 52  RCL 4
 53  +
 54  RCL 8
 55  RCL 2
 56  /
 57  RCL 3
 58  RCL 2
 59  /
 60  f
 61  TF 1
 62  RCL 3
 63  +
 64  RCL 5
 65  -
 66  RCL 7
 67  x
 68  RCL 1
 69  x
 70  RCL 6
 71  /
 72  -
 73  /
 74  STO
 75  +
 76  2
 77  GTO
 78  1
 79  LBL 2
 80  RCL 2
 81  EEX
 82  2
 83  x
 84  RTN
 85  LBL
 86  A
 87  STO 1
 88  RTN
 89  LBL
 90  C
 91  STO 3
 92  RTN
 93  LBL
 94  D
 95  STO 4
 96  RTN
 97  LBL
 98  E
 99  STO 5
100  RTN

This version also handles the case that i% is zero (or nearly so). The iteration exits if the last correction term (or i itself) is less than 5 E–7. Your example in Begin mode now requires just three iterations.

Dieter

[SlideRule]

(10-16-2015 06:39 PM)Dieter Wrote:  ... Since I do not own an HP65 maybe someone else may try this code...
... 19 LBL 1 ...
... 79 LBL 2 ...

these two lines are problematic for the 100 steps on my HP-65. I'll try the coding on another model.

BEST!

SlideRule

[Dieter]

(10-16-2015 10:13 PM)SlideRule Wrote:  these two lines are problematic for the 100 steps on my HP-65. I'll try the coding on another model.

Arrghhh... I forgot that on the 65 all labels require two steps... #-\
I'll see if I can save two so that it all fits in 100 steps.

For the time being you may omit the LBL E part and store FV manually in R5. Or remove the first steps (LBL B) and run the program with RTN R/S.

Dieter

[AndiGer]

Dieter, all,

I always omit the statements after Dieter's step 85, i.e. code for LBL A, LBL C, LBL D, LBL E but manually store the required values in registers 1, 3, 4 and 5. That's what the code in those labels simply does.
This way you can save several steps. The program could even have several more steps.

I will try Dieter's modified code on my 65 when I find some time.

Andi

[Thomas Klemm]

(10-16-2015 06:39 PM)Dieter Wrote:  Since I do not own an HP65 maybe someone else may try this code.

There's a HP-65 Emultator.

Cheers
Thomas

[SlideRule]

(10-17-2015 10:47 AM)AndiGer Wrote:  ... omit the ... code for LBL A, LBL C, LBL D, LBL E but manually store the required values in registers 1, 3, 4 and 5 ...

see attached

[attachment=2674]

hope I'm typo free

BEST!

SlideRule

[Dieter]

(10-17-2015 01:56 PM)SlideRule Wrote:  see attached
(...)
hope I'm typo free

Ah, my experimental program. ;-)

There is an error in the keycode of the y^x command. But, more important, the remark between step 4 and 5 in the user instructions was taken from the original PPC version, while my program uses the same sign convention as later HPs, i.e. PV, PMT and FV may be positive or negative. That's why there is a minus instead of a plus in the initial guess calculation.

Sure, all the stuff starting at LBL A can be removed if the input values are stored directly in R1...R5. The idea was – like in the original program – that the keys of the second annuity program (the one that solves for the other variables) are mirrored so that the user only has to load another card while the A...E keys do the same as before. If this part is removed the code can be improved in several ways. For instance the program may exit if the initial guess is exactly zero (in this case that's the exact solution), or the program may check the relative instead of the absolute error after each iteration.

Dieter

[AndiGer]

(10-17-2015 08:07 PM)Dieter Wrote:  Sure, all the stuff starting at LBL A can be removed if the input values are stored directly in R1...R5. The idea was – like in the original program – that the keys of the second annuity program (the one that solves for the other variables) are mirrored so that the user only has to load another card while the A...E keys do the same as before.

... and the keys to behave like they are used on HP business calculators (HP-22, HP-10(b), HP-17(b), ...)

Edit:
Tried just now - it works great! End mode 4 iterations, Beg mode 3.
(of course used y^x code 05)

Andi

[Dieter]

(10-18-2015 08:08 AM)AndiGer Wrote:  ... and the keys to behave like they are used on HP business calculators (HP-22, HP-10(b), HP-17(b), ...)

This is another detail where earlier and later calculators differ. The first business oriented device, the HP80, had its five TVM keys in the order n i PMT PV FV. So did the HP22, as well as this annuity program for the HP65. Later models however used n i PV PMT FV (which seems a bit more logical). This still is the standard today.

Dieter

[TASP]

Don't want to derail the thread, but not worth it's own topic:

before the HP80, were there any desk top machines with the " n i PMT PV FV " keys and the random input of the variables ??