

(Replying directly to the list; sorry, as usual, for breaking any
relevant threads.)
In the distant past, I owned, and loved to use it for many years,
a HP29C with *CONTINUOUS MEMORY!!!!* Also, it had 98 steps for
programming algorithms.
IIRC (but the Web is not backing me up here), there was a second
"Applications Book" of useful problem and elegant algorithms for
solutions... authored by William Kahan.
Anyway, to get to the point of HP calculators and the present
precision discussion:
My recollection is that all computation internally for the
builtin algorithms was performed in ** 13digit ** registers,
and the final result was rounded to ten digits for display.
I don't know if the internal storage registers were limited to
10 digits, or if they also supported 13digit floatingpoint
values. This would have been relevant where userdefined
programs (and subroutines etc) were executed.
My recollection may be incorrect... but if not, it may explain
some of the results that people have been talking about.
cheers,
surbehoffski etc etc


20180627 13:33 GMT+02:00 surbehoffski < [hidden email]>:
> (Replying directly to the list; sorry, as usual, for breaking any
> relevant threads.)
>
> In the distant past, I owned, and loved to use it for many years,
> a HP29C with *CONTINUOUS MEMORY!!!!* Also, it had 98 steps for
> programming algorithms.
>
> IIRC (but the Web is not backing me up here), there was a second
> "Applications Book" of useful problem and elegant algorithms for
> solutions... authored by William Kahan.
I never knew that one, but I knew and loved
Computational Analysis with the HP 25 Pocket Calculator
by Peter Henrici


My recollection is that all computation internally for the builtin algorithms was performed in ** 13digit ** registers, and the final result was rounded to ten digits for display.
I don't know if the internal storage registers were limited to 10 digits, or if they also supported 13digit floatingpoint values. This would have been relevant where userdefined programs (and subroutines etc) were executed.
My recollection may be incorrect... but if not, it may explain some of the results that people have been talking about.
cheers,
surbehoffski etc etc
I was just reading some history of HP calculators <a href="http://history.siam.org/\/pdfs2/Kahan_final.pdf">http://history.siam.org/\/pdfs2/Kahan_final.pdf
HP35, HP45 were doing math with 10 decimals (no internal precision) HP 13 internal decimals were a response to TI fullpage ad (p. 145)
Type in you telephone numbers.
Now, take the logarithm Now, hit the exponential key Do you get your numbers back ? You do on our calculator ...
Why decimal math [1] ? (page 137, For humans, decimal is best)
HP34C (HP41C too ?) NiCad leaking batteries (page 148)
History of HP12C (page 151)
Why HP15C so rare (page 158)
The HP 12C was successful enough that they were willing to take my advice about building the
15C, but not take my advice about how many to build. They wanted a third of my figure, and
Harms did half again what they wanted, and that’s what they were doing. So they never did set up another production line. In consequence, the market was starved. There were waiting lists, and that window closed, and so I never did get the calculators into the hands of sufficiently many students to change the ways in which professors would issue assignments, and that was a bitter disappointment. It colored my relations with this particular group at HP. I continued to work with them for a couple of years, but my heart just wasn’t in it anymore.
[1] I like decimal calculator with its WYSIWYG numbers Binary calculator is also OK (say, doing it in Lua)
What bugs me is mixing them together (binary + fake decimal)
This is how my Casio(s) do roundings ... total mess
expression fx115ms fx260solar 1e10 + .50  1e10 0 0 1e10 + .79  1e10 0 0 1e10 + .80  1e10 0 0.8 1e10 + .94  1e10 0 0.9 1e10 + .95  1e10 1 0.9 1e10 + .99  1e10 1 0.9


I don't know if the internal storage registers were limited to 10 digits, or if they also supported 13digit floatingpoint values. This would have been relevant where userdefined programs (and subroutines etc) were executed.
surbehoffski etc etc
Internal storage registers were limited to 10 digits.
Again, WYSIWYG
Unlike TI, exponential of log will not be able to recover original. HP was marketing this as a feature, not a bug.
It was the TI calculators that are buggy ... ingenius !
<a href="http://history.siam.org/\/pdfs2/Kahan_final.pdf">http://history.siam.org/\/pdfs2/Kahan_final.pdf (page 146)
“... in order to be honest, round every result back to ten digits even if you carry thirteen to compute it.” And I said, “If you do that, then each operation, taken by itself, will give you a rather honest answer, and you can explain this log exponential thing. That’s easy because when you take the log, you’ve got the right log. It’s correct to within just a little bit worse than half a unit in the last digit of the display. Then you can say ‘Now, it’s that error that propagates when you take the exponential because, if we recovered your telephone number, we’d be getting the exponential not of the number that you see before you. It would have to be the exponential of something else.’

