Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 From: lnxfdw <lnxfdw@xxxxxxxxx>
 Date: Thu, 16 Aug 2007 19:23:34 0000
On Aug 16, 4:33 am, Christoph Widmer <cwid...@xxxxxx> wrote:
I have an 17BII (not the plus) but as far as I can tell the stack works
just as an ordinary oldfashioned fourlevel stack. I still have a
manual from a 17BII+ which broke, and this manual is full of obviously
nonsensical mistakes (German translated from English by a Chinese). I
would suspect that this is either plain wrong or at least a very quirky
way of describing the functioning of the stack.
lnx...@xxxxxxxxx schrieb:
On Aug 16, 2:09 am, lnx...@xxxxxxxxx wrote:
I have a new HP17BII+ calculator that I am learning about. I also
have older calculators including in particular a 1983 HP 12c, a
HP15c, HP25c, and others. Part of the below is what I read in the
manual ,part is what I observed, and part is what I inferred.
Does anyone know where I can find more or have more information on
whether the RPN stack in fact works like the below and maybe why?
I have read on a couple of collection sites that it is a Bug ... but,
I am wondering if in fact this was intentional since it has not been
fixed ( i.e., maybe it is supposed to be like a dynamic stack in
programming)?
THE HP 17BII+ RPN Mode Stack

In he HP 17BII+ RPN mode ... initially only the permanent x register
exists. Then as data is entered onto the stack or consumed from the
stack, the stack size varies. The size varies over a range from 1 to
4 levels deep depending upon the amounts of data entered and
consumed.
Therefore, at most, the HP 17BII+ stack is composed of one permanent X
register and three nonpermanent registers labeled y,z, and t:
X receives the "calculator line", Status:permanent memory, present
always, head of the "dynamic stack"
Y accumulator, Status: nonpermanent, created and destroyed as
needed
Z temporary, Status: nonpermanent, created and destroyed as needed
T top, Status: nonpermanent, created and destroyed as needed
Pressing [SHIFT], [CLR DATA] destroys the y, z, and t registers
resetting the calculator to its initial state of having an x register
only.
The above is unlike my HP 12c, HP15c, HP25c, and other HP RPN / RPL
calculators.
Thanks in advance,
{fdw}
Actually, scratch my RPL comment ... it is like RPL somewhat but, the
stack can only grow to 4 levels not to all of memory. {Fdw}
Christoph:
Thanks for looking at this. This is a curiosity only, I don't think
is changes RPN operations ... it is something I noticed right away.
If you take the time to do the below and view something different
then
let me know. Also, let me say that I ran out of time to clean all of
the
language up so if you can look past that
I neglected to say ... a little sleepy last night that I now have both
models: (1) a 1995, Singapore, HP17BII and (2) a new HP17BII+. I
also
admit that I have had and used the HP12c since it was new in 1983.
The
following is how I first noticed a difference.
On the 1983 HP 12c an RPN only calculator I observed the following:
(1) [f] [REG] resets the x,y,t,z registers to zero.
(2) Rolling the stack with [R Down Arrow] after preforming (1) above
"appears" to the viewer to move through the cleared stack in
sequential order. Whether it does or not, I don't know.
(3) Performing step (1) and then performing a keystroke hitting the
number 1 puts the digits 1. in the x register. Rolling the
stack
with [R Down Arrow] 4 times appears to move me through the stack
ending with a 1.00 as expected.
(4) Performing a keystroke hitting the number 2 puts the 2. digit in
the x register and moves the digits 1.00 to the y register.
Rolling the
stack with [R Down Arrow] 4 times appears to move me through the
stack.
I see the following sequence in order: "2. 1.00 0.00 0.00 2.00."
The point is
here the viewer sees the x,y,z, and t or at least appears to
(i.e., what
else would the roll down keystroke be for?).
Now for the HP17BII and for the HP17BII + change steps 1 through 4
to conform
to the calculators. I would have expected before having these that
test on both
would have repeated exactly my experience with the HP12c and others.
On the HP 17BII and the HP 17BII+ perform the following:
(1) HP 17BII: [gold shift] [Clear Data] / HP 17BII+: [gold shift] [CLR
DATA]
(2) Rolling the stack with [gold shift] [R Down Arrow] four times
after preforming
step (1) above "appears" to the viewer to move through the
cleared stack in
sequential order. Whether it does or not, we don't know.
(3) Performing step (1) and then performing a keystroke hitting the
number 1 puts the digit 1 on the calculator line. Rolling the
stack with [gold shift]
[R Down Arrow] 4 times appears to "enter" the digit 1 into the x
register
and does not appear to move me through the stack. All I see is "1
1.00 1.00
1.00 1.00" when I might expect to see "1. 0.00 0.00 0.00 1.00"
Further, when I
perform an [x<>y] exchange I view a zero from the y register but,
that "roll down"
produced a "1.00"? From that one may infer that for the HP17BII/
HP17BII+
implementation that "rolling through the stack" does not occur ...
all one really sees
is the data in the x register viewed over and over.
(4) Next beginning with 1.00 in the x register I perform a keystroke
placing the
number 2 puts on the calculator line. Rolling the stack
with [R Down Arrow] 4 times appears to "enter" the digit 2.00
into the x register
and moves the digit 1 to the y register. Rolling the stack
with [R Down Arrow] 4 times appears to "enter" the digits 2.00
into the x register
and moves the digits 1.00 into the y register. Rolling the stack
does not appear to
move me through a complete stack on moves me through the x and y
registers. All I
see is "2 1.00 2.00 1.00 2.00" when I expect to see "2. 1.00 0.00
0.00 2.00." So
at best here we are only rolling the "x" and "y" registers and are
not getting a
view of the "y" and "t" registers ... if they even exist!
Further, when I perform an [x<>y] exchange I view the digit "1"
from the y register.
So one might infer that for the HP17BII/HP17BII+ implementation
that "rolling through
a complete stack" does not occur ... all you really see is the
data in the x register
and y register viewed over and over (i.e, the first two elements
of a dynamic stack?).
So, at least on my equipment, the HP12c and the HP17BII/HP17BII+
perform differently
when going through the steps above. I am not sure that "plain wrong"
or "quirky" would
apply here ... but might say that they do test "different" than say
the HP12c. The "creation/destruction mechanism" described in the
first post was a guess only ... I would imagine only the firmware
developers know for sure. I was really curious as to whether
this was a "feature" from the new HP ... I liked the old one better
but, we make do with
what we have.
Thanks again for your time and consideration of this matter.
Frank
.
 FollowUps:
 Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 From: Christoph Widmer
 Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 References:
 HP17BII+ RPN Mode "variable length stack" bug or implementation
 From: lnxfdw
 Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 From: lnxfdw
 Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 From: Christoph Widmer
 HP17BII+ RPN Mode "variable length stack" bug or implementation
 Prev by Date: Re: Anywhere to purchase RAM card for 48GX?
 Next by Date: Re: What happens if you erase everything in your HOME directory?
 Previous by thread: Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 Next by thread: Re: HP17BII+ RPN Mode "variable length stack" bug or implementation
 Index(es):
Relevant Pages
