DB48X: HP48-like RPL implementation for DM42

[jeanwilson]

Thank you Christophe for your follow-up concerning the problem of saving states from the DM32 calculator (db50x). As I wrote, this minor problem remains easy to get around by downloading previously named state files.

Furthermore, congratulations on successfully completing an elegant implementation of the ACORN random number generation algorithm (ACORN is a family of pseudo-random number generators, invented by R. S. Wikramaratna). This fairly recent (2010s) and very effective technology had interested me since a few months, but I had not managed to figure out how to initialize the process (either I did not find the right documentation or maybe the implementation is really so simple that it seems to be beyond my understanding !).

The alternatives that I anticipated before were technologies dating from the early 1990s (see ref 1, 2 & 3) and turned out to be significantly less advanced and much simpler than what you implemented (they were strictly linear multiplicative congruence methods, which I do not believe that they now satisfied all of the more advanced statistical tests of the TestU01 v1.2.3 suite). What you have achieved is therefore particularly remarkable in terms of speed of execution and I thank you for it. What I have been able to verify so far is that your method satisfies the Kolmogorov-Smirnov criterion with flying colors (cor coef: 99.998%).

I was able to verify this by calculating the CDF distribution directly on the DM32 calculator (so in the db50x v7.11 environment, on a relatively small sampling of 100,000 draws). It would have been preferable to sample from a larger number of random draws using the much greater execution speed of the simulator but it appears that this is impossible for me at the moment because I only have access to the firmware version v.7.10. Indeed, since you upgraded to the most recent versions 7.10 and 7.11, I noticed that (on a Win10 platform and the Fedora Remix environment) the simulator was built each time with the penultimate version number (so recently, 7.10 rather than the most recent version 7.11). I tried to directly address the most recent version in the GitHub repository during the git clone operation but without success because I cannot find the right syntax. Do you have any suggestions ?

A few quick questions.
1. I believe that you are now using the Bignum calculation library instead of the original IEEE 754-2008 128-bit library. Is this indeed the case (as I understand it, to free up more flash memory)? Does the loss of execution speed become significant in this case? Is it proportional to the chosen precision (or to the number of bits required)?
2. Is it then possible with the type of library used to consider a direct implementation of interval arithmetic (similar to what is available in the Longfloat 3.1b package for the HP 50g calculator)?

(1) VAN ES, A. J., GILL, R. D., &0 VAN PUTTEN, C. (1983). Random number generators for a pocket calculator. Statistica Neerlandica, 37,95-102.
(2) PATRICK, O. (1993) A theoretical and empirical comparison of mainframe, microcomputer, and pocket calculator pseudorandom number generators. Behavior Research Methods. Instruments. & Computers. 25 (3). 384-395
(3) KNUTH, D.E. (1981), The art of computer programming, Vol. 11, Seminumerical algorithms (2nd edition),Addison-Wesley, Reading, Massachusetts.

EDIT
Correction to my request/problem regarding the emulator:
I just rebuilt the emulator and this time the most recent version (v7.11) was produced! So false alarm. And taking advantage of its speed I launched a simulation of a billion random draws, just to check if the period is larger than this number. And it appears to be verified after 26 hours of calculation on the db48x emulator! A lame comparison with the Prime G2 emulator which has lower precision (15 digits rather than 24) using its own random number generator (algorithm unknown) shows also a period of at least a billion obtained in less than 52 minutes.

Two other quick questions:
3. I have not transferred the firmware from the db48x to my DM42 calculator. But I was wondering if the execution speed is actually faster for the db50x (on the DM32 calculator) given that the processor has a clock frequency twice as fast? If not, is it due to the different calculator operating systems (DMCP)?
4. Is it possible one day to try adapting the db48x firmware on the HP Prime G2, which would definitely make it an incredible beast as the fastest and most interesting variable precision RPL calculator one could dream of ... (the six F1 to F6 buttons being AlphaApps, AlphaSymb, AlphaLeftArrow, AlphaRightArrow, AlphaHelp and AlphaEsc)? Let's numerically fantasize !