Once upon a time I noticed a very small error in a calculation, performed on my HP-21.

2^30 (or 2**30, if that's more convenient for you) used to yield 1073741827 (no thousands separators in those days, sorry) which is less than a micropercent wrong. It didn't really bother me, until I computed it on my (new) HP-29C, which gave me the correct answer. Ever since I've been wondering why this difference occurred. For a long time I thought that the HP-21 always computes EXP(y*LN(x)) and that the HP-29C is so intelligent to perform a repeated multiplication whenever the y content is an integer value. A larger internal accuracy would also be possible, but there weren't any signs that this indeed is the case.

Does anyone know the HP-29C internals well enough to comment?



btw.

of course you can get the exact answer on an HP-21 as well:

2 ENTER ENTER ENTER * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

There is an article The New Accuracy: Making 2³=8 that discusses this. (It's in the November 1976 HP Journal, and reproduced on the HP Museum CD/DVD.)

That HP Journal issue focuses on the HP-67, 97, and 91, and the aforementioned article explains that the improved accuracy of the power function was achieved by performing all three steps (ln, *, exp) at 13 digit precision, instead of rounding all intermediary results to 10 digits like their predecessors. The older calcs basically did the same as executing those steps on the keyboard; the reason for this was to conserve ROM space.

With the increase in complexity of machines like the 67, 97, 91, and also the 19C/29C, HP needed to increase ROM space to a point where these precision/space tradeoffs no longer made sense. (Note that the simpler HP-25 still has the less-accurate implementation.)

- Thomas

Hi, Bram:

Bram posted:

"[...]of course you can get the exact answer on an HP-21 as well:

2 ENTER ENTER ENTER * * * * * * * * * * * * * * * * * * * * * * * * * * * * *"

Honestly, Bram, how unlike you ! You use your HP-21 as an ex-Ti user or something ! ;-)

Your sequence is 33 keystrokes long. You can do much better like this:


       2  ENTER * 

          ENTER ENTER * 

          ENTER * 

          ENTER * 

          ENTER * 

          X<>Y  /

which promptly returns the exact answer, 1073741824, in just 14 keystrokes. That's a full 19 (58%) less keystrokes. If the HP-21 had an x² function in a primary key, the savings would be truly dramatic.

I guess typing in the correct result does it in even less keystrokes :)

Well, not everybody knows 2^30, but I bet almost everybody here knows 2^10 = 1024.

So, use 1024 enter enter * *

for a grand total of 8 keystrokes.

While we're counting keystrokes...

It can be done in as few as five keystrokes on some machines. I don't think it takes more than seven on any HP RPN or RPL machine.

On those which do the power right AND has the y^x as a primary key, 2 ENTER 30 y^x works, of course. On some machines a shift key makes it six keystrokes.

On those which do not do the power right but has the x² as a primary, it can be done in six: 32768 x². A shift may make it seven.

On any RPN machine except the 80, 32768 ENTER * does it in seven. On the 80, merely replace the ENTER with SAVE.

And then there are the "cheats", of course. Under certain conditions, something like RCL 0 or GSB A may work. Or possibly even just a single keystroke, like x<>y.

I'm not sure about the algebraics like the 10 and 01, but I think 32768 * = would work.

Can anyone find a better solution, or a machine that requires more than seven keystrokes?

Quote:

---

Honestly, Bram, how unlike you !

---

Well, it depends ...

Suppose we'd try to find an optimum for the ease of keystrokes in stead of just the number. You're quite right that this sequence of multiplications is a bit ridiculous (seems I forgot the pc keystrokes ‘;’, ‘-’ and ‘)’) and of course there are other ways as already given elsewhere in this thread, but I can think of situations where just counting a single thing is easier than doing less, but different things. Moreover 2^31 would go in a similar way, whereas you’d have another least-number-of-keystrokes solution.

There'll be many different opinions on this matter, I'm sure.



The suggestion of "intelligence" in the HP-29C was at that time fed by some fortran knowledge; when the power is an integer value (and the base is any type), x^y isn't considered a mixed mode expression, type conversion does not take place and another internal algorithm is used than with float powers.

I wouldn't be surprised if HP did something similar in the HP-29C.

By now I understand otherwise (dank je wel, Thomas, voor de referentie naar de Journal).



Oh! and something about the TI-part; I hadn't even touched a TI when I bought my HP-21.
The brochure described something so perfect; there was no need to consider anything else. That wasn’t a bad conclusion, was it? At that time, I mean.

Very nice, but as I see the question, you've got to start with a 2, mandatorily, not 1024, or 32768, or 65536, or 33554432, or any other "magic number" that the oh-so-clever user happens to know beforehand it's an exact power of 2.

That being so, see in how many keystrokes you can do the feat. Else, you're plainly cheating by injecting into the computation magic numbers taken out of thin air.

Best regards from V.

From the previous responses, two out of three that discussed keystrokes didn't start with 2 (they both start with 1). That led me to think that the goal was to get the correct value of 2^30 into X. Whether it starts with 1, or 2, or pi, I took to be irrelevant. But I have been known to be wrong.

As another post points out, ease of keystrokes is not always the same thing as the minimum number of keystrokes. There used to be a concept of the half-keystroke (hitting the same key twice is easier than hitting two different keys).

If I had to compute 2^30 ONCE on the HP21, I'd probably fill the stack with 2s and hit * 29 times. If I had to compute more than about three different powers, I'd probably switch to a 25 and write a short iterative program that simply did a series of doublings.