200LX, 17b, 19b - Solver Problem?

[Peter A. Gebhardt]

Dear fellow forists,

just stumbled over an issue with the solver which did manifest in "jumps" of a solution value after a discrete change of the variable T in the following equation.

The equation resembles the built-in routine called "STAFF" in the German finance menu of 17bx and 19bx respectively (only international versions of the calculators mentioned do have it in their ROMs).

The routine is from the German Manual of the 17b (the one in the 17bII+ manual contains errors).

T=17:    

T=18:    

T=19:    

Graphing the behavior of below equation for results of T on the HP Emulator results in:

   

Code:


0*(#YRS+NOM%+PV+PMT+FV+T+#P+#C)

+0*
( L(I,NOM%/(100*#C))
 +L(ADJ1,#P/#C+G(I)*((#P/#C+1)/2-T*#P/360))
 +L(N,RND(#YRS*360:8)*#C/360)
 +L(#PP,1-T*#P/360+FP(G(N))*#P/#C)  
 +L(ADJ2,IP(G(#PP))
    +G(I)*IP(G(#PP))
    *(FP(G(#PP))-1+G(#PP))/(2*#P)*#C
  )
)
=
FV
+( PMT*G(ADJ1)*USFV(G(I)*100:IP(G(N)))
  +PV*(1+G(I))^IP(G(N))
 )*(1+G(I)*FP(G(N)))
+PMT*G(ADJ2)

The example I've tested with is here (from p. 295 of the German 17bII+ manual):

   

Any ideas what goes wrong here?
TIA.
Peter

[rprosperi]

Possibly a typo in the equation, but without the original, it's impossible for us to verify, and unfortunately, the German 17B manual is not included in the MoHPC Document set.

Which emulator are these screen shots from? From the size, I'd guess some sort of 200LX emulator? Have you tried on a genuine 200LX?

(And do you know where the 200LX emulator is available?)

As has been well documented before, the solver in both of the 17BII+ models (Gold and later Silver) has at least one bug; this equation would not run correctly in those models (using the 0*( stuff ) format will force all variables to be shown, which leads to an incorrect number of loops in the initial phase of the solver run). This same bug could possibly be present in the 200LX emulator (maybe even present in the 200LX too, though I've never heard this is the case)?

[Peter A. Gebhardt]

Thanks for commenting!

(06-29-2019 07:07 PM)rprosperi Wrote:  Possibly a typo in the equation, but without the original, it's impossible for us to verify, and unfortunately, the German 17B manual is not included in the MoHPC Document set.

Here we go:    

Quote:Which emulator are these screen shots from? From the size, I'd guess some sort of 200LX emulator? Have you tried on a genuine 200LX?

Error was first seen on 200LX.

Quote:(And do you know where the 200LX emulator is available?)

It's from the discs of the 200LX Connectivity Pack.

Quote:As has been well documented before, the solver in both of the 17BII+ models (Gold and later Silver) has at least one bug; this equation would not run correctly in those models (using the 0*( stuff ) format will force all variables to be shown, which leads to an incorrect number of loops in the initial phase of the solver run). This same bug could possibly be present in the 200LX emulator (maybe even present in the 200LX too, though I've never heard this is the case)?

The 200LX was the origin of my investigation.

The next sentence is wrong! See results below!
Using an international 17b or the silver 17II+ with GERMAN with the ROM STAFF TVM routines produces no errors as described above. No "jumps" in the FV results.

I'll enter the equation into the respective solver of the 17b & 17bII+ later and will report.

Best regards
Peter (on Forum since 2006)

[Peter A. Gebhardt]

Entered equation into 17bII+ CNA726000094 with identical results. Didn't spend the time of doing it for the old 17b.

So, either the equation OR the solver root finding algorithm are the culprit.

The results for the built-in ROM routines for STAFF for 17b & 17bII+ are identical:

T=17 => -179.079,57
T=18 => -179.085,65
T=19 => -180.403,61 *** Now it becomes VERY interesting ... ***

Best regards,
Peter

[rprosperi]

(06-29-2019 08:35 PM)Peter A. Gebhardt Wrote:  Entered equation into 17bII+ CNA726000094 with identical results. Didn't spend the time of doing it for the old 17b.

Definitely try it on the old 17b, that is known to be correct, while the 17bII+ is known to have the bug. If the results are different, you can (almost?) always conclude the 17bII+ is wrong, and if 17bII+ and 200LX emulator provide the same results, I'd say this shows that the 200LX solver has the same bug as both 17bII+ machines.

If so, Dave Britten will be crushed...

[Peter A. Gebhardt]

Did you see the TVM STAFF ROM Bug for T=19 above?

Best regards,
Peter

PS: The 200LX Solver is older than the 17bII+

   

[rprosperi]

(06-29-2019 09:57 PM)Peter A. Gebhardt Wrote:  Did you see the TVM STAFF ROM Bug for T=19 above?

I'm confused... in that same post you write:

Entered equation into 17bII+ CNA726000094 with identical results. Didn't spend the time of doing it for the old 17b.

and

The results for the built-in ROM routines for STAFF for 17b & 17bII+ are identical.

These seem to conflict, no?

Oh! You're mentioning the STAFF ROM routines are both the same. OK, got it.

I've no idea what the STAFF program is, but it's possible that specific equation/program does not encounter the bug; some equations do and some don't, so STAFF working is not proof the bug is not there.

Make sense?

[Dave Britten]

(06-29-2019 09:40 PM)rprosperi Wrote:  

(06-29-2019 08:35 PM)Peter A. Gebhardt Wrote:  Entered equation into 17bII+ CNA726000094 with identical results. Didn't spend the time of doing it for the old 17b.

Definitely try it on the old 17b, that is known to be correct, while the 17bII+ is known to have the bug. If the results are different, you can (almost?) always conclude the 17bII+ is wrong, and if 17bII+ and 200LX emulator provide the same results, I'd say this shows that the 200LX solver has the same bug as both 17bII+ machines.

If so, Dave Britten will be crushed...

Is there a simple test case for said bug? If so, I can give it a quick test run on my 200LX. So far, I haven't run into any solver anomalies on it, but I haven't used it as extensively as Don and his 17BII, for example.

[rprosperi]

(06-29-2019 10:56 PM)Dave Britten Wrote:  Is there a simple test case for said bug? If so, I can give it a quick test run on my 200LX. So far, I haven't run into any solver anomalies on it, but I haven't used it as extensively as Don and his 17BII, for example.

Though I've found many over the years, I don't have one at hand; I likely would not have documented a formula that failed, I would have moved to a known good machine (17B,17BII,19B,19BII, 27S) and then moved along. For a (short) while, I could remember the exact offending sequences, but eventually I simply heeded Don's advice, and just reach for a 17BII when using the Solver.

While far from simple, I suppose the above equation is a likely candidate, but that's pretty long and tedious for a quick test.

[Dave Britten]

I just tried a couple of the examples in the thread linked below, and they appeared to work correctly. So I don't think it's the infamous 17bii+ solver bug affecting the 200LX.

https://www.hpmuseum.org/forum/thread-11...04928.html

[rprosperi]

(06-30-2019 12:27 AM)Dave Britten Wrote:  I just tried a couple of the examples in the thread linked below, and they appeared to work correctly. So I don't think it's the infamous 17bii+ solver bug affecting the 200LX.

https://www.hpmuseum.org/forum/thread-11...04928.html

Good news! I'd hate to think HP used the Kinpo code from the 17bII+ for the Solver in the 200LX. If only they had done just the opposite, the problem never would have come up and marred the otherwise excellent 17bII+ machines.

[Peter A. Gebhardt]

Quote:Is there a simple test case for said bug? If so, I can give it a quick test run on my 200LX. So far, I haven't run into any solver anomalies on it, but I haven't used it as extensively as Don and his 17BII, for example.

Sorry, no.

I'll try to construct one from the underlying formulas for the German accounting method for savings accounts, where the STAFF (Staffelzins) method originated from.

I'm also currently testing outside the calculator realm with another desktop program, which i use for assessment reports.

And also shall cross-check with my 17bII S/N: 3611M00944.

Best regards
Peter

[Peter A. Gebhardt]

Problem eventually solved. But further testing is needed.

Starting with

Code:

L(#PP,1-T*#P/360+FP(G(N))*#P/#C)

as

Code:

P=1-T*#P/360+FP((720+210+T)/360)*#P/#C)

it was easily seen by the result of P, that only the last digit of the result
could have an influence onto the IP(#PP) further down the road.

By changing the expression to

Code:

+L(#PP:RND(1-T*#P/360+FP(G(N))*#P/#C:13)) ! 2 less than precision 15 on 200LX !

the results are now exactly as when calculated with the respective ROM routines.

(For 17b/19b it therefore should be precision 9 - 2 = 7.)

Also the plot of the equation for T is now w/o any steps.

That leads to the assumption, that any solver equation which allows for forward/backward solving in all variables should show stair-step free plots in the respective vars if mathematically sound.

Your comments are welcome.

Thanks again,
Peter