[VA] "Introducing APRIL !" microchallenge

[Valentin Albillo]

  
Hi, all,

Let me introduce APRIL (Arithmetic Problem Recently Identified Locally), which is an arithmetic problem I recently identified locally while using some vintage HP calcs. My identification might be recent but the problem itself has been lurking unnoticed for 40+ years, AFAIK.

To wit, there's a purely arithmetic operation that produces a result when executed in one series ("Spice": HP-33E/C, HP-34C ...) and a different one when executed in another series ("Nut" CPUs: HP-41, HP-10C, HP-15C ...). The term "arithmetic operation" does include √x but excludes all transcendental functions, statistics-related ones, y^x, ->H.MS and ->HR.

I thought that by the early '80s all basic arithmetic firmware would be thoroughly debugged and essentially cast in stone but it seems it wasn't, which hit me hard when this purely arithmetic program of mine (dealing with values in the range [0.1 ... 1500]) would produce very different results when run on said HP calcs, so it took me some sleuthing to isolate the culprit.

Now that you know beyond a shadow of a doubt that there's one, see if you can find such a faulty arithmetic operation. Unless this is another elaborate April Fools' Day joke !!.

V.

[J-F Garnier]

Expressed in these terms, this challenge seems very vague, and almost impossible to investigate.
But - assuming it's a serious question, despite the white line - we can narrow the search with these considerations:
- the operation must be available on all cited machines,
- it is an arithmetic operation, excluding operations based on approximations (trig, log) and also excluding some operations that we know have problems on certain machines, such as >HMS.

Comparing the features of the two low-end machines, HP33E and 10C, we get:
- basic arithmetic operations: +, - , * and /
- 1/x, sqrt, x²
- pi, %
- INT, FRAC
- >DEG, >RAD
Furthermore (if we trust the author), the argument is in the range of 0.1..1500 excluding corner cases with very large or very small numbers.

Let's look closer at the suspects:
- the basic operations + - * and / are based on proven algorithms, and are at the bottom of our list of suspects,
- 1/x is just 1 divided by x, so belongs to the above category,
- same as x², that is x times x.
- sqrt could be a possible suspect, but again it relies on a solid algorithm,
- pi is just a constant, nothing special to expect here.
- % is basically divide by 100.
- INT and FRAC are simple operations, again nothing special to expect here.
- >DEG and >RAD are conversion operations, basically a multiplication or division, so we are back to the basic operation case.

It seems that all the suspects have good reasons to claim they are innocent.
We need to review again our list, but that will be for tomorrow...

J-F

[Paul Dale]

I think the key here is the series of operations. An incorrect rounding in any one of the these operations could easily cascade into a completely different result.

We know that the algorithms were improved for the Voyager series over the Spice. That the 41 has an improved algorithm also isn't a big surprise.

Finding a specific example is another matter.


Pauli

[Martin Hepperle]

Maybe Y^X should not be excluded?

The limited parameter range of only up to 1500 also suggests something like LN/LOG (excluded), e^X (excluded).

I read "series" as referring to Spice or non-Spice machines, not "series of operations".

[J-F Garnier]

(04-02-2022 08:13 AM)Martin Hepperle Wrote:  Maybe Y^X should not be excluded?

y^x is explicitly excluded, indeed there are easy-to-find differences with y^x between machines, for instance the recently discussed historic 3^201 test:
HP-33E: 7,968419661e95
HP-41C: 7,968419664e95

But here we are looking for arithmetic operations, not transcendental function approximations.

J-F

[C.Ret]

(04-01-2022 09:43 PM)J-F Garnier Wrote:  It seems that all the suspects have good reasons to claim they are innocent.
We need to review again our list, but that will be for tomorrow...

Since we are looking for a suspect that was silent for a so long time, we can't based you investigation only on suspicion. Any suspect have to be interrogated et tested.

Afaik, I just realize that I have only material from the "nut" part and no way to test any "spice" calculator

(04-02-2022 03:02 AM)Paul Dale Wrote:  I think the key here is the series of operations.

But, Valentin clearly indicate that there is only one specific operation that produces a different result !
Can not be due to the way several operations are chained or any cumulative error's handled.

(04-02-2022 08:13 AM)Martin Hepperle Wrote:  The limited parameter range of only up to 1500 also suggests something like LN/LOG (excluded), e^X (excluded).

We can trust the indications given by Valentin, if these operations have to be exclude, that is for sure that they are out of the scope.

But you observation about the given range [ 0.1 , 1500 ] is for sure of a primary importance and may certainly indicate something else that what we are suspecting.

At first, this interval makes me believe it is about any trigonometric operation.
But Valentin clearly state and insist about a true, simple and single arithmetic operation.

So, I will let apart sin, cos, tan and √× for the moment.

For the arithmetic operations [ + ] or [ - ] this range is safe and may produce the same results even between oldest and old calculettes.

For arithmetic operation [ × ] this range is safe enough to produce similar results between "spice" and "nuts".

For arithmetic operation [ ÷ ] this range trigger me.
In one direction, it looks really safe and difference may really surprise me. But what about the opposite direction ?

In one hand:
1500 [ENTER^] 0.1 [ ÷ ] may display 15000. on all HP calculators without any worry about the age or the exact technology of the specific model.

In the other hand:
0.1 [ENTER^] 1500 [ ÷ ] may not necessary display the same exact result.

Unfortunately, as I already say it, I have no "spice" to test, but the few models ("nut") I just test all display : 0.000066667

May the "spice" have display this result a different way ?
For example an alternative format close to 6.666666-05 ?

[ijabbott]

(04-01-2022 09:43 PM)J-F Garnier Wrote:  Comparing the features of the two low-end machines, HP33E and 10C, we get:
- basic arithmetic operations: +, - , * and /
- 1/x, sqrt, x²
- pi, %
- INT, FRAC
- >DEG, >RAD

You could include REC->POL in that list as long as you ignore the angular part of the result.

[J-F Garnier]

(04-02-2022 09:15 AM)C.Ret Wrote:  Afaik, I just realize that I have only material from the "nut" part and no way to test any "spice" calculator

You can use the MultiCalc emulator to check that there is no obvious differences.
But, as the most famous detectives, we don't need to go to the crime scene at first. We need first to use our small grey cells !

Quote:Unfortunately, as I already say it, I have no "spice" to test, but the few models ("nut") I just test all display : 0.000066667
May the "spice" have display this result a different way ?
For example an alternative format close to 6.666666-05 ?

No, I don't think it's a matter of display, it would be a too bad April Fool. I'm sure it is difference in the real numbers.

J-F

[Ángel Martin]

(04-02-2022 03:02 AM)Paul Dale Wrote:  We know that the algorithms were improved for the Voyager series over the Spice. That the 41 has an improved algorithm also isn't a big surprise.

But the 41 came out earlier than the Spice, so this would indicate a defect in the HP-33's version of the algorithms, which was later corrected for the Voyager, no?

[rprosperi]

(04-02-2022 12:42 PM)Ángel Martin Wrote:  

(04-02-2022 03:02 AM)Paul Dale Wrote:  I think the key here is the series of operations. An incorrect rounding in any one of the these operations could easily cascade into a completely different result.

We know that the algorithms were improved for the Voyager series over the Spice. That the 41 has an improved algorithm also isn't a big surprise.

But the 41 came out earlier than the Spice, so this would indicate a defect in the HP-33's version of the algorithms, which was later corrected for the Voyager, no?

No, the Spice models (all but the 34C) came out more than year earlier than the 41, while the 34C came out at the same time as the 41, as a lower-cost alternative.

[Ángel Martin]

(04-02-2022 12:56 PM)rprosperi Wrote:  

(04-02-2022 12:42 PM)Ángel Martin Wrote:  But the 41 came out earlier than the Spice, so this would indicate a defect in the HP-33's version of the algorithms, which was later corrected for the Voyager, no?

No, the Spice models (all but the 34C) came out more than year earlier than the 41, while the 34C came out at the same time as the 41, as a lower-cost alternative.

Thanks for the clarification Bob, I guess what tripped was that SOLVE and INTEG were present on the HP-34 but not on the 41C, so I assumed the 34C came later. But of course the 33C was an earlier model anyway....

[J-F Garnier]

Today we are the 2nd of April. No more joke, the Boss said "I want the culprit, now!".

We asked the Experts, they said: "The HP BCD math [in Spice/Voyager/Coconut machines] implements arithmetic algorithms described as 'infinite precision truncated to 13 digits', then rounded once to the user 10-digit result. All is fully deterministic, no approximation, no random rounding error, every machine is giving exactly the same result for a given operation, and the result is the best representation of the result with 10 digits. No doubt, no any piece of randomness, no place for different answers of any kind. Period".

So we are taking our list again, and assuming the Experts are right, we take as an hypothesis, in apparent contradiction with the OP's claim, that the arithmetic is right and without flaw. What can we still get out of our list of suspects?
Let's skip over +, -, *, /, 1/x, x².
Sqrt is basically (according to the same Experts) similarly implementing a pseudo-division (as the oldest of us may have learn at school loooong ago) and thus out of suspicion.
Let's forget %, INT and FRAC too.
PI is a constant, and we can easily check that its numeric value 3.141592654 is the best 10-digit representation of pi.

What is remaining now? The >DEG and >RAD function that are converting between radians and degrees using a constant ratio.
Can we really suspect them ? Well, "when you have eliminated the impossible, whatever remains, however improbable, must be the truth".
Let's see, the converting ratio is (pi/180) or (180/pi) of course, depending on the direction the conversion is done.
How can we check it?
Well, 1 >DEG gives 57.29577951, the best 10-digit representation of (180/pi), and
1 >RAD gives 0.01745329252 , the best 10-digit representation of (pi/180).

All this is perfectly correct but let's try now to do 7 >DEG. We should get 7*180/pi and we indeed get 401.0704566, the best representation of this value with 10 digits. Now notice that this is different from the user-level calculation (RPN style) 7 180 * PI / that gives 401.0704565 with an error of 1 ULP.
This proves that the >DEG and >RAD functions are using a high accuracy ratio value, presumably an internal 13-digit number, to guarantee the result.
Is it possible that some machines have a ratio value slightly wrong in the last places, that shows up only with certain numbers? How can we check it?
If this hypothesis is correct, then the problem would not be an arithmetic issue as such, but a simple programming flaw with no mystery.

Now that we have a plausible suspect, it's time to go back to the crime scene to look for evidences.
However, I need to stop my investigations for now, because I have a sextuple integral to compute for tomorrow morning :-)

J-F

[J-F Garnier]

(04-02-2022 03:02 AM)Paul Dale Wrote:  We know that the algorithms were improved for the Voyager series over the Spice. That the 41 has an improved algorithm also isn't a big surprise.

We know that the algorithms were improved with the 13-digit precision on the HP-22, 29C and following to make 2^3=8, but I don't remember that the Voyager machines were improved over the Spice.
Do you have more details, or references?

It seems that this is correct, at least for the y^x function, as I mentioned above with the 3^201 test, but I know it since only recently when I tried to run this test on the 33E and the 41C.
BTW, the 34C has the same improvement (for the 3^201 test) as the Voyager and the 41C.
But I really would like to know more (not directly related to the issue reported by Valentin).

J-F

[rprosperi]

(04-03-2022 02:33 PM)J-F Garnier Wrote:  We know that the algorithms were improved with the 13-digit precision on the HP-22, 29C and following to make 2^3=8, but I don't remember that the Voyager machines were improved over the Spice.

Do you mean HP-22 here J-F, I think you mean the HP-27? The 22 was introduced in Aug '75 together with the original HP-25.

OTOH, the HP-27 was introduced in May '76, just 2 months after the HP-91, which is the 1st machine with "The New Accuracy" as cited in the Nov '76 HP Journal.

Not surprisingly, the HP-25C introduced a month later retained the original HP-25 ROM so did not inherit this new accuracy, but the -67 and -97 the month after that and then the -29C six months later certainly did.

What a great year 1976 was for HP model introductions!

[Massimo Gnerucci]

(04-03-2022 04:16 PM)rprosperi Wrote:  What a great year 1976 was for HP model introductions!

Bicentennial calculators!

[J-F Garnier]

(04-03-2022 04:16 PM)rprosperi Wrote:  

(04-03-2022 02:33 PM)J-F Garnier Wrote:  We know that the algorithms were improved with the 13-digit precision on the HP-22, 29C and following to make 2^3=8, but I don't remember that the Voyager machines were improved over the Spice.

Do you mean HP-22 here J-F, I think you mean the HP-27? The 22 was introduced in Aug '75 together with the original HP-25.

No, I mean the HP-22, this already has been discussed :-)

Anyway, my question was about the changes in the Voyager family.

J-F

[rprosperi]

(04-03-2022 05:05 PM)J-F Garnier Wrote:  No, I mean the HP-22, this already has been discussed :-)

Having been in that conversation, one might think I'd recall the details, but alas, no...

But this is where we discussed the long-to-market timing of the -91 I've read about, which re-reading that thread now, all makes sense.

For the Voyager family, I don't believe there was any extensive work to improve accuracy; I believe even Kahan commented on this noting something like "there wasn't time" to further tune the core math routines but rather the aim was to focus on application layers above the core routines for things like Bonds in the 12C, and refining the Solver and adding Matrices in the 15C, etc.

[J-F Garnier]

(04-03-2022 09:01 PM)rprosperi Wrote:  

(04-03-2022 05:05 PM)J-F Garnier Wrote:  No, I mean the HP-22, this already has been discussed :-)

Having been in that conversation, one might think I'd recall the details, but alas, no...

Yes, we can't trust our memory, but the MoHPC is here to help. I just searched for "2^3 and accuracy" and that's it.
Also re-reading that thread, I found that the 3^201 test was already discussed too. That did I forget !

Thanks for the feedback on possible Voyager's changes.

Sorry Valentin for the digression, now it's time to go back to the "APRIL" case !

J-F

[Valentin Albillo]

.
Hi, all,

Thanks for your interest in my microchallenge and most definitely for your posts. I'll give here some comments to said posts so if you posted something, please read on. I also give a date for posting my "original solution", so to say. Let's begin ...

J-F Garnier Wrote:Expressed in these terms, this challenge seems very vague, and almost impossible to investigate.

Not so.

J-F Garnier Wrote:But - assuming it's a serious question [...] Furthermore (if we trust the author), [...]

How rude ! ... What did I ever do to you !?

C.Ret Wrote:Since we are looking for a suspect that was silent for a so long time, we can't based you investigation only on suspicion. Any suspect have to be interrogated et tested.

Very true.

C.Ret Wrote:Valentin clearly indicate that there is only one specific operation that produces a different result !

Replace that "only" by "at least" and then your assertion will be correct. I never said "only one", check my OP above if in doubt.

C.Ret Wrote:But you observation about the given range [ 0.1 , 1500 ] is for sure of a primary importance and may certainly indicate something else that what we are suspecting.

Not really, that's the approximate range of values my program dealt with, that 0.1 could be 0.0037, say, and that 1500 could be 1213.78, I gave it just to let it be known that neither extremely small nor extremely big values were involved, just "normal-ranged" values.

C.Ret Wrote:May the "spice" have display this result a different way ? For example an alternative format close to 6.666666-05 ?

Display format has nothing to do with this, the difference is between the values themselves, not how they're displayed, as J-F pointed out.

ijabbott Wrote:You could include REC->POL in that list as long as you ignore the angular part of the result.

No, you can't, I said "purely arithmetic operation", which polar-rectangular or vice versa conversions aren't, as they use trigs in both directions.

J-F Garnier Wrote:Sorry Valentin for the digression, now it's time to go back to the "APRIL" case !

Fantastic ! I'm sure you'll succeed.

Enough comments. I fully expect that some of you kind and capable readers will be able to pinpoint such an instance as the one I serendipitously discovered when running my program and finding the results inconsistent with one another.

I'll post the offending result as well as my original sleuthing and the culprit operation next Thursday, 7 so you have 3 more days to try and tackle it.

Be aware that if I see no signs of sufficient effort on your part my final post might well be along the lines of "Ha ha, it was just an elaborate April Fools' Day joke and you fell for it ! Let's forget about it !" and let the matter rest for another 40 years.

Best regards.
V.
Edit: Corrected misattributed quote.
Edit: Corrected the deadline, it was meant to be Thursday 7, not Friday 8, sorry.

[ijabbott]

(04-04-2022 06:37 PM)Valentin Albillo Wrote:  

ijabbott Wrote:You could include REC->POL in that list as long as you ignore the angular part of the result.

No, you can't, I said "purely arithmetic operation", which polar-rectangular or vice versa conversions aren't, as they use trigs in both directions.

One of the results of POL->REC is purely arithmetical. I thought it was worth mentioning because it might use higher precision intermediate values than the equivalent operation using squaring, summation and square root that would be rounded to "normal" precision at every intermediate step.