Threaded Mode | Linear Mode

Valentin Albillo · (This post was last modified: 04-11-2022 01:26 AM by Valentin Albillo.)

.
Hi, Bob,

(04-07-2022 10:59 PM)rprosperi Wrote: It's interesting to me that in his OP, Valentin commented about how the different machines "...produce very different results when run on said HP calcs".

In these cases, the results differ by about 1E-9. Can that really be considered a very different result, or am I missing something?

I couldn't comment earlier because doing it would spoil a key ingredient of my solution to the challenge featured in [VA] SRC #011 - April 1st, 2022 Bizarro Special, but now that I've published my solution there's nothing to spoil anymore, so I'll tell you how I discovered that the ->DEG instruction gave different results for some arguments when executed in the HP33E and in the HP-41C (where it's called R-D), so you'll perfectly understand my "very different results" statement. Let's see ...

My SRC#11 thread asked for a program written for the HP-10C which would return the numeric value of a sextuple integral with three correct digits. Of course I knew that the one and only way to perform the feat would be using a Monte Carlo cubature method (nothing else would fit at all) and that required evaluating the integrand for a given number of samples, each requiring the generation and use of six pseudo-random numbers.

Due to the extremely little RAM available (79 bytes) and the lack of both a built-in RNG (Random Number Generator) and subroutines, an RPN user-code RNG had to be implemented and duplicated six times while having decent quality, so I decided to use the RNG I discovered and advocated 40+ years ago in PPC CJ, which features the ->DEG radians-to-degrees instruction, i.e. using the built-in value for 180/Pi as a suitable multiplier.

So far, so good. I readily wrote a 49 step HP-10C program and as I had no HP-10C available, I executed it on the HP-33E, the most similar model, strictly using HP-10C capabilities (i.e. no subroutines, which the HP-33E has but the HP-10C lacks) and RAM limitations (i.e. 79 bytes for program and storage registers). As a test, I used 1 as the seed, and 100 as the number of samples, like this:

    1 [STO 3] 100 [R/S] -> 0.8281 (0.82806 65707)

I was pretty confident that running this same program and test on an actual HP-10C would produce the exact same result, but just in case I ran it on the HP-41C (with GTO step changed to GTO label but otherwise identical), like this:

    1 [STO 03] 100 [R/S] -> 0.8216 (0.82163 42352)

and lo and behold, to my utter amazement the results were noticeably different, ~64 million ulp different no less !! Of course, I was intent in discovering where did the computations first differ, so I executed both programs using 10, 20, ..., 90, 100 samples, and the only different result was the one for 100 samples, while up to 90 samples they all were identical.

I then refined the search by executing both programs for 91, 92 ... samples and though the 91 runs were identical, using 92 samples gave these results:

    HP-33E: 92 samples -> 0.8561 (0.85609 10158) RCL  3 = 0.33190 28200 (seed at the end)
    HP-41C: 92 samples -> 0.8561 (0.85609 10161) RCL 03 = 0.33190 33900 (ditto)

and it can be seen that the results differ by 3 ulp while the final seeds differ by 5,700 ulp.

Now, running it using again 92 samples but stopping the program after the 91th sample had been processed and single-stepping (while stack-tracing) through the 92th sample's processing, I finally discovered that the X-register had a different value after executing steps 28 and 29, namely:

    Step           X in HP-33E      X in HP-41C
    ----------------------------------------------
    28  RCL 3     0.91528 77500    0.91528 77500   (identical seed)
    29  ->DEG    52.44212 511     52.44212 512     (1 ulp difference)

This is the very first time both programs differ, and the results in the X-register after executing ->DEG (R-D in the HP-41C) with the exact same argument 0.91528 77500 differed by 1 ulp. By this time ->DEG (R-D) had been executed 550 times flawlessly but the 551th time it gave a 1 ulp difference, which is the minimum possible but still a difference.

If it had remained a 1 ulp difference until the execution's end it would be little problem. But as seen above, by the time the 92th sample had been processed, the difference had grown to 3 ulp. and by the time the 100th sample had been processed and the program halted, the difference had exploded to 64 million ulp.

This explosion is caused by the fact that the result of ->DEG applied to the seed in R3 is reduced to its fractional part and then stored back ("feeded back") in R3 as the new seed and so the error compounds over time and essentially explodes in a chaotic way.

That's one of the effects of chaos: any difference in the initial conditions, however small, causes completely different results over time, so the final result essentially can't be predicted after a while.

Just to give an example taken from real life, if I remember correctly the position of Pluto in its orbit can be predicted with great accuracy over the next 10-20 million years or so, but after that, although the orbit path remains predictable, the position of Pluto in its orbit can't be correctly predicted anymore, it could be near its perihelion, near its aphelion, or somewhere in between.

P.S.: Besides the HP-33E and the HP-41C, I also ran the program and test case on the HP-15C, which agreed with the HP-41C's result, but to be extra sure I asked Didier Lachieze to run it on his physical HP-10C, which he most kindly did, and the result again agreed with the HP-15C's and HP-41C's, even when using up to 1,312 samples.

Best regards.
V.
Edit: added link to Lyapunov Time (Wikipedia)