HP-17BII+ serial

[tomisan]

Just picked up a silver HP-17BII+ with serial CNA24609V7 from the UK Amazon site.

Haven't seen this format of the serial string with a "V" there before, but I assume the starting digit means it's manufactured in 2012?

It's nice to have 32KB, but too bad that the Solver is such a challenge with the L(x:expr) and G(x) functions especially.

Anyway, I have managed to enter most of my most important equations from my beloved HP-27S.

A random number generator is still a challenge. I use this equation for now:

RAN#=L(SEED:FP(9821xG(SEED)+.211327))

On first run (with SEED=0), RAN#=0.211327 as expected, but then the formula is evaluated twice for each run, so in effect I get every second term in the sequence. I can live with that, but wish I could make the Solver behave the way I want.

By the way, HP-27S on the other hand, will not solve the above formula if SEED=0. I don't know how the original HP-17BII behaves.

[Don Shepherd]

(02-01-2016 12:19 PM)tomisan Wrote:  I don't know how the original HP-17BII behaves.

Here are the results for the 17bii (and the 17b would be the same):

first run, .211327
second, .653794
third, .122201
fourth, .347348

So on the 17bii+, you must get .211327 and then .122201.

The only effective way of overcoming this problem is to get a 17b or 17bii. There are generally many available on the auction site. I highly recommend them.

[tomisan]

(02-01-2016 01:26 PM)Don Shepherd Wrote:  

(02-01-2016 12:19 PM)tomisan Wrote:  I don't know how the original HP-17BII behaves.

Here are the results for the 17bii (and the 17b would be the same):

first run, .211327
second, .653794
third, .122201
fourth, .347348

So on the 17bii+, you must get .211327 and then .122201.

Yes, exactly like that.

It's interesting that the Solver in the original 17BII does work with SEED=0.

My HP-27S with serial starting 2825 (week 25 1988) refuses. Just returns 0 as result. I have to make sure SEED <> 0 first.

I wonder how many different versions of the Solver there is?

[Don Shepherd]

(02-01-2016 03:24 PM)tomisan Wrote:  My HP-27S with serial starting 2825 (week 25 1988) refuses. Just returns 0 as result. I have to make sure SEED <> 0 first.

That is interesting, I wouldn't have expected that. I used to have a 27S and played around with its solver a bit and it seemed to work exactly like the 17b/17bii, but I guess something must be different in it. I know the 27S has trig and random number functions while the 17b's do not.

Thanks for pointing that out.

[rprosperi]

(02-01-2016 04:45 PM)Don Shepherd Wrote:  

(02-01-2016 03:24 PM)tomisan Wrote:  My HP-27S with serial starting 2825 (week 25 1988) refuses. Just returns 0 as result. I have to make sure SEED <> 0 first.

That is interesting, I wouldn't have expected that. I used to have a 27S and played around with its solver a bit and it seemed to work exactly like the 17b/17bii, but I guess something must be different in it. I know the 27S has trig and random number functions while the 17b's do not.

Thanks for pointing that out.

Out of curiosity, I tried on my late 27S, s/n 3224S04180.

My exact solver equation is:
RAN=L(RAN:FP(9821xG(RAN)+.211327)) (Including the # as shown above would not work, bringing up an invalid equation error, seemingly due to the "#" being an invalid variable name character).

I get the same results as you (Don) posted, so it did work with the initial 0 SEED. I guess that bug in early 27S machines was eventually fixed.

[Didier Lachieze]

(02-01-2016 12:19 PM)tomisan Wrote:  A random number generator is still a challenge. I use this equation for now:

RAN#=L(SEED:FP(9821xG(SEED)+.211327))

On first run (with SEED=0), RAN#=0.211327 as expected, but then the formula is evaluated twice for each run, so in effect I get every second term in the sequence. I can live with that, but wish I could make the Solver behave the way I want.
H
By the way, HP-27S on the other hand, will not solve the above formula if SEED=0. I don't know how the original HP-17BII behaves.

This equation works fine on my 27S 2821A:

RAN=FP(9821xG(RAN)+.211327)

I've removed the # as RAN# is a 27S native function from the Prob menu.

Starting with 0 STO RAN then you get:
first run, .211327
second, .653794
third, .122201
fourth, .347348

[Don Shepherd]

(02-02-2016 01:07 AM)Didier Lachieze Wrote:  I've removed the # as RAN# is a 27S native function from the Prob menu.

Aha, so that's why it wouldn't work on the 27S, RAN# is a function name (but not on the 17b's , obviously).

Thanks Didier, you da man.

[tomisan]

CORRECTION to my earlier post #3.

Yes indeed, when I happened to enter my own equation *correctly* into my HP-27S (and not using RAN# as it's a built-in function in the 27S), I do get the same result as other 27S owners have shown here!

Sorry for the confusion!

------------------------------------------------

As for the different behaviour of the Solver in 17BII+ and earlier models like the 27S and 17BII:

In "Technical Applications - Step-by-step solutions for your HP-27S or HP-19B calculator" there is a discussion on pages 14 and 15 how LET and GET change an equation.

..."When an unknown variable appears only once as a formal variable, the Solver can usually isolate a direct solution.

..."When the variable appears as the first argument of LET or as the argument of GET, it's not considered by the Solver in determining whether a direct solution can be found. Thus, a variable may occur many times in an equation, yet only once formally. In these instances, a direct solution may be found, but it will not normally be "correct" mathematically."

This doesn't fully apply to the HP-17BII+ and here lies much of the confusion I believe.

**Example 7 (from page 15 in Technical Applications)

A=G(A)+1

Enter the equation, press CALC and CLEAR DATA
Press A and
27S will display A=0
17BII+ will display A=1, apparently the correct answer.

Press A again and
27S will display A=1 which is what we might expect. Each press of A will increment A by 1, so 27S will show 2,3,4,...

However, 17BII will not increment A, A=1 is the final solution. This is not what we might expect!

**Example 8 (from page 15 in Technical Applications)

Q=L(A:A+1)

Enter the equation, press CALC and CLEAR DATA
Press Q and
27S will display Q=0
(However, if A is initialized first with A=0, then we get Q=1)

17BII+ will display Q=1, apparently the correct answer (no initialization necessary).

Further presses of Q on the 27S will display Q=1,2,3,... what we expect.

However, 17BII+ will display Q=3,5,7,... not what is expected!
(For each run, the 17BII+ will do an additional evaluation of the expression).

One way to simulate the behaviour of 27S is to enter
Q=L(A:A+1/2)
then store -0.5 in A before the first run.

---
According to Cyrille de Brébisson the Solver in 17BII+ is the same, but transcribed in C. The "direct" solver part however seems to use a slightly different algorithm.
http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=134189

I just wish that HP would have published a ""Technical Applications - Step-by-step solutions for your HP-17BII+ calculator"!

[Don Shepherd]

My advice today is the same as it was 8 years ago (in that thread you quoted): unless you want to be really, really frustrated and confused, get a 17b or 17bii. The solver on those machines works as a programmer would assume it would. There are at least two equations in the Applications Manual that work fine on the 17b/17bii, but won't work on the 17bii+ without some modifications. Cyrille has said in the past that the solvers are not exactly the same; Kinpo added an extra evaluation pass that causes unexpected and unwanted behavior, such as you experienced with your equation.

The 17b and bii are marvelous machines, and I continue to use them daily.

[tomisan]

(02-02-2016 04:38 AM)Don Shepherd Wrote:  My advice today is the same as it was 8 years ago (in that thread you quoted): unless you want to be really, really frustrated and confused, get a 17b or 17bii. The solver on those machines works as a programmer would assume it would. There are at least two equations in the Applications Manual that work fine on the 17b/17bii, but won't work on the 17bii+ without some modifications. Cyrille has said in the past that the solvers are not exactly the same; Kinpo added an extra evaluation pass that causes unexpected and unwanted behavior, such as you experienced with your equation.

The 17b and bii are marvelous machines, and I continue to use them daily.

Well, I have the HP-27S, one of my all-time fav HP calculators, but I keep running out of memory on it and the legibility of the display have started to nag me, so I was planning to sell it.

I was hoping the 17BII+ could be a replacement, but I might have to reconsider. It has the memory going for it and a very crisp and clear display.

I will do some more investigations of the Solver and make a decision.

[Elwin]

I did some tests with my silver 17BII+ and found something that allows you access all the numbers in the sequence while still iterating twice each time it runs.

RAN#=L(A:FP(9821xSEED+.211327))+0xL(SEED:G(A))

The first iteration is stored in RAN# and the second iteration is stored in SEED. Solving for RAN# a second time produces the third and fourth numbers in the sequence.

Nothing changes if you multiply the first L() by 0 instead of the second.

I haven't been able to figure out why it works this way.

[Don Shepherd]

(02-02-2016 05:56 AM)tomisan Wrote:  Well, I have the HP-27S, one of my all-time fav HP calculators, but I keep running out of memory on it and the legibility of the display have started to nag me, so I was planning to sell it.

I was hoping the 17BII+ could be a replacement, but I might have to reconsider. It has the memory going for it and a very crisp and clear display.

I will do some more investigations of the Solver and make a decision.

Here is another consideration.

If most of what you do with the solver is just standard equation solving things (that is, not using the L() and G() functions), the 17bii+ solver will work fine. I have noticed that the weird behavior only manifests itself if you use L() with a variable that is in the visible menu.

The extra memory and better display legibility of the plus is certainly an advantage. If you are going to have a lot of equations (and associated variables), keep in mind that some amount of memory must be free because it is required when you "compile" (CALC) your equations. I have one equation that is very big and when I CALC it the free memory goes from 48% to 26%. So you will always need enough memory so that you can CALC your most complex equation. I have 28 equations on my 17bii.

[tomisan]

(02-02-2016 02:40 PM)Don Shepherd Wrote:  

(02-02-2016 05:56 AM)tomisan Wrote:  Well, I have the HP-27S, one of my all-time fav HP calculators, but I keep running out of memory on it and the legibility of the display have started to nag me, so I was planning to sell it.

I was hoping the 17BII+ could be a replacement, but I might have to reconsider. It has the memory going for it and a very crisp and clear display.

I will do some more investigations of the Solver and make a decision.

Here is another consideration.

If most of what you do with the solver is just standard equation solving things (that is, not using the L() and G() functions), the 17bii+ solver will work fine. I have noticed that the weird behavior only manifests itself if you use L() with a variable that is in the visible menu.

The extra memory and better display legibility of the plus is certainly an advantage. If you are going to have a lot of equations (and associated variables), keep in mind that some amount of memory must be free because it is required when you "compile" (CALC) your equations. I have one equation that is very big and when I CALC it the free memory goes from 48% to 26%. So you will always need enough memory so that you can CALC your most complex equation. I have 28 equations on my 17bii.

Yes, I have noticed something similar with my 27S.

One interesting difference is that validation of an equation (after CALC) is much quicker on the 17BII+. Execution time is slower though.

BENCH:B=A+SIGMA(N:1:1E99:1:L(A:n))

After a 60 s run:
HP-27S: A=1683
HP-17BII+: A=1030

[Don Shepherd]

(02-02-2016 06:22 PM)tomisan Wrote:  

(02-02-2016 02:40 PM)Don Shepherd Wrote:  Here is another consideration.

If most of what you do with the solver is just standard equation solving things (that is, not using the L() and G() functions), the 17bii+ solver will work fine. I have noticed that the weird behavior only manifests itself if you use L() with a variable that is in the visible menu.

The extra memory and better display legibility of the plus is certainly an advantage. If you are going to have a lot of equations (and associated variables), keep in mind that some amount of memory must be free because it is required when you "compile" (CALC) your equations. I have one equation that is very big and when I CALC it the free memory goes from 48% to 26%. So you will always need enough memory so that you can CALC your most complex equation. I have 28 equations on my 17bii.

Yes, I have noticed something similar with my 27S.

One interesting difference is that validation of an equation (after CALC) is much quicker on the 17BII+. Execution time is slower though.

BENCH:B=A+SIGMA(N:1:1E99:1:L(A:n))

After a 60 s run:
HP-27S: A=1683
HP-17BII+: A=1030

I think you will be happy with either the 17b/bii or the bii+. Let us know what you decide.

By the way, do you know how to exit a \(\sum\) loop early? The Applications manual says you can't, but a fellow showed me how to do it once, with a minor constraint.

[rprosperi]

The 17BII+ (Silver) is a very nice machine overall, in fact this it what sits on my desk for daily "analysis" like balancing my checkbook. Feels nice, plenty fast, clock, alarms (like a I need another thing telling me I'm late), legible LCD, beautiful (to my eye at least).

But, for any solver activity, use the 17B or 17BII as Don has said. The newer machine is simply not reliable, or at the very least, not properly documented, to be useful for this application. And it's the worst kind of unreliable in that it doesn't produce error messages, it just delivers wrong answers that it presents as correct answers.

Over the years, many folks have "found a way to make it work right" but in the end, none have proven generally reliable.

Best solution: Have (at least) one of each for the different tasks.

The 27S is also reliable for solver use (as verified above I believe) but being Algebraic only, I simply can't do 'normal' calculations on it. Still love it though.

The best hypothetical non-42S Pioneer would be a 27S, in a 17BII+(S) chassis, with RPN. MANY folks here would buy one immediately. Or maybe 2. Or maybe more?

[Elwin]

(02-02-2016 09:25 AM)Elwin Wrote:  I did some tests with my silver 17BII+ and found something that allows you access all the numbers in the sequence while still iterating twice each time it runs.

RAN#=L(A:FP(9821xSEED+.211327))+0xL(SEED:G(A))

The first iteration is stored in RAN# and the second iteration is stored in SEED. Solving for RAN# a second time produces the third and fourth numbers in the sequence.

Nothing changes if you multiply the first L() by 0 instead of the second.

I haven't been able to figure out why it works this way.

As it turns out you can get the same results by just removing the G() from the original equation.

So RAN#=L(SEED:FP(9821xG(SEED)+.211327)) becomes
RAN#=L(SEED:FP(9821xSEED+.211327)) and the first number is stored in RAN# and the second number is stored in SEED.

[Don Shepherd]

(02-03-2016 01:51 AM)Elwin Wrote:  

(02-02-2016 09:25 AM)Elwin Wrote:  I did some tests with my silver 17BII+ and found something that allows you access all the numbers in the sequence while still iterating twice each time it runs.

RAN#=L(A:FP(9821xSEED+.211327))+0xL(SEED:G(A))

The first iteration is stored in RAN# and the second iteration is stored in SEED. Solving for RAN# a second time produces the third and fourth numbers in the sequence.

Nothing changes if you multiply the first L() by 0 instead of the second.

I haven't been able to figure out why it works this way.

As it turns out you can get the same results by just removing the G() from the original equation.

So RAN#=L(SEED:FP(9821xG(SEED)+.211327)) becomes
RAN#=L(SEED:FP(9821xSEED+.211327)) and the first number is stored in RAN# and the second number is stored in SEED.

But if you change G(SEED) to SEED, then SEED will appear in the displayed menu, which will allow the user to change it, and that may not be what you want.

[tomisan]

Don, thank you for recommending a 17BII instead.

I know I will never get used to how the L and G functions work on the 17BII+.

I found a 17BII on Ebay in mint condition for a very reasonable price, so I'm eagerly awaiting delivery of it now!

Although I'm no collector of HP calculators, I realised that with the incoming 17BII I will already have a small collection here:

HP-17BII
HP-17BII+
HP-27S
HP-30B
HP-41CX
HP-42S
HP-28S
HP-50G
HP-35S
HP-95LX
HP-200LX

[Don Shepherd]

(02-15-2016 08:09 AM)tomisan Wrote:  HP-17BII
HP-17BII+
HP-27S
HP-30B
HP-41CX
HP-42S
HP-28S
HP-50G
HP-35S
HP-95LX
HP-200LX

That is quite a good collection of very nice machines.

I used to have quite a few HP calculators but I cut back my collection a few years ago, keeping only a few 17b's and a couple of 12c's. And my one machine I will never part with, the HP-65, the first handheld programmable calculator. 1974 was a great year: the HP-65 was introduced, I got married, I got my graduate degree and my first professional programming job.

I think you will be happy with L() and G() on the 17bii.