[VA] "Introducing APRIL !" microchallenge

[Valentin Albillo]

  
Hi, all (this was a microchallenge so this post won't be too long),

Thank you very much for your interest in my microchallenge and your excellent posts. Indeed this was "a serious question" and indeed the author (that's me) "can be trusted", so this wasn't an April Fools' Day joke, despite the almost-unreadable text in white at the end of my OP which suggested the possibility (that was the joke !).

So, yes, there's a particular operation which returns some result when executed on an HP-33E/C and a different result when executed on a 'Nut' CPU calculator, i.e., HP-41C, HP-10C, HP-11C, HP-15C, et-c.). The difference is very slight, just 1 ulp for the instance I serendipitously found, but if used in a program, after a while the values obtained might diverge and the final result returned by the program might be very noticeably different, e.g. the difference between my program's result when run on an HP-33E/C (0.82806 65707) and when run on an HP-41C (0.82163 42352) was quite noticeable, some ~ 64,000,000 ulp ! Oops !!

After being bitten by it, which left me truly amazed, I carefully traced the program's execution (involving tracing stack's and storage registers' contents, which was very laborious and time-consuming because I had to do it on both machines, not just one as is the typical case, having to compare the data after each and every number-altering program step) and after 3,800+ program steps had been executed I eventually found the first instruction (a radians-to-degrees conversion, [->DEG] or [R-D]) where the values were different, namely this instance:

        HP-33C:   0.91528775  [->DEG] = 52.44212511

        HP-10C:   0.91528775  [->DEG] = 52.44212512
        HP-15C:   0.91528775  [->DEG] = 52.44212512
        HP-41C:   0.91528775  [ R-D ] = 52.44212512

so for this instruction and this particular 8-digit argument (0.91528775) there's a 1 ulp difference between the Spice HP-33E/C and the Nut HP-41C, HP-10C, HP-15C, ...

I then manually executed the equivalent conversion using 10-digit RPN user code (which is a less accurate way to proceed than using the 13-digit internal conversion) and found that the result is the same for all of them, namely the one the HP-33 [->DEG] built-in conversion produces:

        0.91528775 [ENTER] 180 [*] (164.7517950) [Pi][/] = 52.44212511

Now, to see which value was the one correctly rounded to 10 digits (not that there was much doubt) and also to look for a possible reason (which I also suspected: a borderline rounding case), I computed it using several much more accurate calcs:

        HP-71B:   DEG(0.91528775)           = 52.442125115 (12-digit result, uses 15-digit precision internally)
        Free42:   0.91528775 [->DEG]        = 52.442125115(02521 ...)
        Win10 :   0.91528775 [x]180[÷][Pi][=] 52.442125115 02521 ...

so it's clear that the correct result when rounded to 10 digits is 52.44212512, the one produced by the 'Nut' machines, while the Spice HP-33E/C's result differs by 1 ulp for the reasons J-F Garnier exposed in his post above, where he correctly suspected that [->DEG] was the actual culprit, whose very microcode he then proceeded to thoroughly analyze by looking at the VASM 41 for the HP-41 and using an emulator able to trace the code for the HP-33E, then comparing both implementations while extensively detailing his sleuthing process and final conclusions. A fantastic detective work, kudos to J-F !

Alas, he stopped short of giving an actual instance ("All we have to do now is to find an example") but he doesn't fool me, I take that statement as a polite way of letting me produce first the original instance I found several weeks ago, and I'm pretty sure he's already found and will produce a number of them after I've posted mine. If you want to have a go at it, let me assure you that it's not that difficult, I know of at least three different ways to produce more instances and J-F hinted at one, as we'll see next.

J-F also pointed out in general what I had observed in my particular sample instance, that the result truncated to 13 digits ends in ...502, which is extremely close to the borderline ...500, and this causes the HP-33E/C different (and inferior) implementation to produce the wrong 10-digit rounded result sometimes.

So there you are, after 40+ years I've discovered a new bug, which is not the result of an algorithmic error but of a non-optimal implementation of a simple conversion's internal arithmetic. It's also a nice real-life example of chaos: an extremely small, microscopic difference (1 ulp, the smallest possible) gets amplified until it quickly becomes macroscopic (64 million ulp) and thus very noticeable, possibly altering the whole computation, which in my case it did.

I may add more comments later but for now let's see yours first, as well as your own instances if you managed to produce some.

Thanks again to all of you who posted for your interest, contributions and comments, much appreciated, and in particular to J-F Garnier for his time, fantastic sleuthing and hard work, I'm honored to get his high-quality contributions to my humble productions.

Best regards.
V.