HP-17bII+ Solve Compatibility Issues

[Robert Prosperi]

After reading the interesting thread started by Gerson last week “A very long HP-17BII equation”, I’ve been exploring using advanced features of the HP-17bII+ solver (new, silver model), such as the LET() & GET() functions, and some of the other techniques noted in the “Technical Applications” manual for the HP-27S and HP-19B, which share the same Solver application as the -17 series. There are indeed problems using these features, as even basic sample programs from the manual cannot be duplicated. BTW, some pretty interesting stuff in this manual which greatly extends the power of this Solver if you have not checked it out (available on the Museum DVD, which I highly recommend to all).

After researching all the forum HP-17xxx archives and articles, I’ve found numerous references to the 17bII+ having solver incompatibilities and troubles, and also having issues with variable updates, etc. but generally without stating which HP-17bII+ version.

Also, although I’ve read that the LET and GET functions are not documented anywhere, in fact they ARE documented in the HP-17bII+ printed manual (I have a copy, Ed. 2, January 2004) as well as in the PDF version available from HP’s support website.

In summary, it appears these functions worked correctly on the 17B and 17BII but were not documented for these models, whereas they are documented, but do not work correctly on the 17bII+ models.

As I and many others really like the HP-17bii+ (silver model), I’d like to ask the forum experts to please clarify a few points so we can hopefully use this machine with confidence:

1. Is the “old” HP-17bII+ functionally identical to the “new” (silver) HP-17bII+? Differences?

2. Are the issues with using the LET() an GET() functions documented somewhere? Are there workarounds for these issues or are they simply buggy and unreliable?

3. What are the variable update limitations? Again, can it be used reliably with some precautions or is it just unpredictable?

4. I found a solver program by W. B. Maguire II, to calculate “Epsilon” on the 17 which uses the LET/GET functions, which generated the same result on my 17bII+ as on my 17BII, but surprisingly it was MUCH slower on the newer machine. I’ve read the new 17bII+ uses a newer, faster processor as compared to the prior 17 family members, in addition to the much larger RAM; is slower solver performance than the 20+ year older machines typical?

I’ve done some testing and am willing to continue to try to find these answers, but don’t want to waste time if these answers are known, and particularly not if the new machine is simply buggy and unreliable due to a poor port to the new h/w.

All comments are welcome.

--bob prosperi

[Mike (Stgt)]

Is it realy an issue of SOLVE or just L() and G()? There are solver differences of HP-42S and Free42, but on HP's calculators (inlcuding HP200LX) the solvers are quite similar. So could you please show, where you found discrepancies? (Or give a hint or link where they are described.)

Ciao.....Mike

[Don Shepherd]

Quote:

---

Is the “old” HP-17bII+ functionally identical to the “new” (silver) HP-17bII+? Differences?

---

Yes, they are exactly the same, solver functionality-wise.

Quote:

---

Are the issues with using the LET() an GET() functions documented somewhere? Are there workarounds for these issues or are they simply buggy and unreliable?

---

The issues are mostly just documented in the pages of this forum. There are some workarounds. For example, the equations in the Technical Applications Manual for the 27S and 19B for prime factors and least common multiple/greatest common divisor will not work on the 17bii+'s, although they work fine on the 17b and 17bii. I posted the workarounds in a thread many years ago. Let me know if you can't find that thread and I'll post them again.

Quote:

---

What are the variable update limitations? Again, can it be used reliably with some precautions or is it just unpredictable?

---

The short answer is that if you use the Let() function to update menu variables (that is, variables that appear in the menu) in your solver equation, you won't get the results you would expect. This is due to the fact that the 17bii+ solver does an extra evaluation pass while solving the equation, so your variables are actually updated twice, which causes erroneous results. If you never use the L() function to update a menu variable, you won't experience this problem.

Quote:

---

I found a solver program by W. B. Maguire II, to calculate “Epsilon” on the 17 which uses the LET/GET functions, which generated the same result on my 17bII+ as on my 17BII, but surprisingly it was MUCH slower on the newer machine. I’ve read the new 17bII+ uses a newer, faster processor as compared to the prior 17 family members, in addition to the much larger RAM; is slower solver performance than the 20+ year older machines typical?

---

Cyrille has said that the processor on the 17bii+'s is not as efficient as the processor in the original 17b's and bii's. This, coupled with the extra evaluation pass I mentioned above, accounts for the relative slowness of some equations on the plusses.

[Robert Prosperi]

Don:

Thanks for the detailed reply; my review of all the HP-17 articles in the archives and articles revealed you to be a true HP-17 fan, thanks for all your contributions.

Quote:

---

The issues are mostly just documented in the pages of this forum. There are some workarounds. For example, the equations in the Technical Applications Manual for the 27S and 19B for prime factors and least common multiple/greatest common divisor will not work on the 17bii+'s, although they work fine on the 17b and 17bii. I posted the workarounds in a thread many years ago. Let me know if you can't find that thread and I'll post them again.

---

Of course, the LCM/GCD is the sample program I started with on my silver 17bii+. Ahhh luck! I believe I have reviewed all the HP-17 archive threads and articles as noted, and though I have seen many references to workarounds existing, I have not been able to find the details themselves. Perhaps the answers were posted in a thread or aticle not containing "HP-17", since the subject solver is also in several others. Please do point me to the notes if you can or re-post when convenient.

Quote:

---

The short answer is that if you use the Let() function to update menu variables (that is, variables that appear in the menu) in your solver equation, you won't get the results you would expect. This is due to the fact that the 17bii+ solver does an extra evaluation pass while solving the equation, so your variables are actually updated twice, which causes erroneous results. If you never use the L() function to update a menu variable, you won't experience this problem.

---

By "...update menu variables..." are you referring to what the TAM calls 'formal' variables? Not exactly clear on what you mean by updating these variables within the L() function. Does this mean doing something like EQ=A+L(A:A+1)+....?

I also tried some basic things like changing 0xL(F:A*B)+... to L(F:A*B)x0... speculating that the bII+ parser may be dropping this part of the equation before the assignment since it is = 0, but this does not seem to have any affect, so bad guess.

I would appreciate any pointers you have on these things. I love this machine, and hope the workarounds don't make using the solver too tedious, as if it isn't already a bit so (though some of the trig equations I've seeb Gerson and others create for this machine are truly amazing and have convinced me that my pain tolerance entering equations without cut/copy/paste is apparantly quite low).

Thanks

--bob prosperi

[Don Shepherd]

I think I must have deleted the article that described the workarounds for gcd/lcm and prime factors at some point. No problem, here is a pdf that has the contents of that article:

pdf file

Quote:

---

By "...update menu variables..." are you referring to what the TAM calls 'formal' variables? Not exactly clear on what you mean by updating these variables within the L() function. Does this mean doing something like EQ=A+L(A:A+1)+....?

---

Yes, formal variables. Yes, like loading A with A+1, that's the kind of thing that won't work on the plusses.

The TAM also says you can't exit a loop early; actually, you can as long as you want to end the program at that point! Just store the value of interest in a formal variable and do a divide by zero or log(0). The equation will terminate, but you can RCL the variable where you stored something right before the divide by 0 and the value will be there. I used this method for a prime factor finder that is much faster than the one in TAM (article).

I really enjoy investigating the "equation as program" possibilities of the 17b and 17bii solvers. I don't use my 17bii+ anymore because it's just too darned frustrating.

Edited: 23 Apr 2013, 9:29 a.m. after one or more responses were posted

[Gerson W. Barbosa]

Quote:

---

I don't use my 17bii+ anymore because it's just too darned frustrating.

---

I don't mean to be mean, but...

[Don Shepherd]

Yes, but under that beautiful exterior lies a solver that %$#@!*.

:)

edit: oh, I just noticed the minus!!

Edited: 22 Apr 2013, 10:07 p.m.

[Gerson W. Barbosa]

There's always hope HP sees this, works overnight and comes up with a real 17II+ tomorrow morning :-)