HP calculators and decimal (BCD) floating-point precision...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

HP calculators and decimal (BCD) floating-point precision...

sur-behoffski
(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 HP-29C 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
built-in algorithms was performed in ** 13-digit ** 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 13-digit floating-point
values.  This would have been relevant where user-defined
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,

sur-behoffski etc etc

Reply | Threaded
Open this post in threaded view
|

Re: HP calculators and decimal (BCD) floating-point precision...

Dirk Laurie-2
2018-06-27 13:33 GMT+02:00 sur-behoffski <[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 HP-29C 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

Reply | Threaded
Open this post in threaded view
|

Re: HP calculators and decimal (BCD) floating-point precision...

Albert Chan
In reply to this post by sur-behoffski
My recollection is that all computation internally for the
built-in algorithms was performed in ** 13-digit ** 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 13-digit floating-point
values.  This would have been relevant where user-defined
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,

sur-behoffski 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

HP-35, HP-45 were doing math with 10 decimals (no internal precision)
HP 13 internal decimals were a response to TI full-page 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             fx-115ms   fx-260solar
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



Reply | Threaded
Open this post in threaded view
|

Re: HP calculators and decimal (BCD) floating-point precision...

Dirk Laurie-2
2018-06-27 16:52 GMT+02:00 Albert Chan <[hidden email]>:

> I was just reading some history of HP calculators
> http://history.siam.org/\/pdfs2/Kahan_final.pdf

Thanks for that link.

Reply | Threaded
Open this post in threaded view
|

Re: HP calculators and decimal (BCD) floating-point precision...

Albert Chan
In reply to this post by sur-behoffski

I don't know if the internal storage registers were limited to
10 digits, or if they also supported 13-digit floating-point
values.  This would have been relevant where user-defined
programs (and subroutines etc) were executed.

sur-behoffski 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.’