[VA] "Introducing APRIL !" microchallenge

[J-F Garnier]

As promised, a few additional (and longer) comments:

(04-07-2022 04:07 AM)Valentin Albillo Wrote:  Thanks again to all of you [..] 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.

You're welcome, Valentin. It is a kind of tribute for all the challenges you concocted during all these years, and that I enjoyed, even if I didn't participate to all (but to most of them, I believe).
Furthermore, the subject of this microchallenge was, by chance, one of my primary interests, meaning the BCD algorithms of the HP calculators.

I'm mainly interested by the 71B and generally the Saturn implementation, but when you look at the Coconut or Woodstock processors and so-called microcodes, you are immediately in a familiar land.
For instance, when I had to identify the >DEG and >RAD algorithms in the 33E, without sources or entry points, what I did in the emulator is to fill the program memory with >DEG (or >RAD) and a final GTO 1, and run it. Breaking the execution a few times bring me soon in a familiar code with successive addition (or subtraction), register shift, and nibble pointer movement that I recognized as the 13-digit multiplication (or division) code. And the rest was not too difficult.


Some results.
Valentin guessed it right, a few days ago I identified several numbers that give different answers with >DEG .

To achieve my goal, I chose to write a short RPN code on Free42 that mimics the 13-digit computations of the 41C and 33E.
I fed it with random numbers and looked for the differences after rounding to 10 digits.
The code is at the end of this post, for the curious (I didn't clean it, so not necessary great programming, but I added comments to document it)

Here are a few examples with >DEG (spaces added for legibility):
1.67 94 93 89
1.61 16 94 84
1.10 94 96 008

I mentioned it already but >RAD on the 33E has a similar problem, for instance with:
89.92 93 93 42
74.64 51 01 72
88.84 66 525

(I deliberately chose a few "nice looking" numbers, there are many others)


A comment about the "error".
When we say the 33E has a 1 ULP error for some numbers, it's not really correct.
We should say the 33E answer is 1 ULP below the "best representation".
Both the 41C and 33E have an error of about 0.5 ULP error relative to the exact value, +0.5 ULP for one, -0.5 ULP for the other.
For the engineer this is not a problem, the error is (almost) the same on both machines.
This puts the issue in its real perspective.


A funny case.
I found a funny case with >RAD :
85.31 68 68 31 >RAD (another "nice looking" number...)
--> 1.489060260 on the 41
--> 1.489060259 on the 33E.
At the light of what I explained, you may say: OK the 33E rounded it down because of the few ULP internal error, and the 41C is right.
But NO! In this particular case, the 33E is right, and the 41C is wrong !
The exact value (here from Free42: 1.489060259499910...) is so close to the ...500 limit for rounding that the small inaccuracy in the internal [PI/2] constant (in excess) makes the 41C jump to the wrong side of the fence for rounding.


The best for the end.
I will end with a very special, quasi-mystic number I found by chance with >DEG.
The number is
*** 1.23 78 465 ***
and >DEG gives
--> 70.92338014 on the 41
--> 70.92338013 on the 33E.

Isn't it a wonderful number? See:
8 digits only, with all the digits 1 to 8,
more important, with the digits exercising the 3 rows
of the calculator numeric keypad in turn,
with the keys from left to right except the last two swapped,
as if it was designed to be keyed in our machines.

It seems to tell us "Hey I've been waiting 40 years
to demonstrate the change in the algorithm of >DEG !"
But here I'm leaving the world of computer science...

J-F

Code:

; Free42 prog for >DEG diff searching

 00 { 105-Byte Prgm }

 01▸LBL "SVA"
FIX 09  ; display mode for rounding to 10 digits
STO 00  ; input : number of iterations
0 STO 02  STO 03  STO 05 ; init some vars
; note: 13-digit [PI/4]=0.7853981633975 is in R04
PI  SEED ; init rnd seed

 10▸LBL 00
RAN  0.7  ×  1  +  ; ran# between 1 and 1.7
1ᴇ9 ×  IP  1ᴇ9  ÷  ; truncate to 10 digits
STO 01 ; copy
; simulate 33E >DEG
RCL 04  ÷   ; [PI/4] /
XEQ 01      ; truncate to 13 digits
4.5 ×       ; 45 * (don't care on xpon)
XEQ 01       ; truncate to 13 digits
RND          ; round to 10 digits
STO 02
; simulate 41C >DEG aka R-D
RCL 01       ; recall # under test
9  ×         ; 90 * (no needed to truncate, it fits)
RCL 04 ENTER  +  ÷   ; [PI/2] /
XEQ 01       ; truncate to 13 digits
RND          ; round to 10 digits
STO 03       ; for later inspection if needed
; compare
RCL 02  
X≠Y? XEQ 02  
DSE 00  GTO 00
RCL 00  RTN ; ends with 0 in X

 47▸LBL 01   ; truncate a number 1<=x<10 to 13 digits
1ᴇ12  ×  IP  1ᴇ12  ÷
RTN

 54▸LBL 02    ; sub for diff processing
RCL 01 STOP    ; for instance recall # under test and display
RTN

END