DB48X: HP48-like RPL implementation for DM42

[c3d]

(07-24-2024 03:45 PM)jeanwilson Wrote:  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.

If you need to create a file locally, you can with something like this:

Code:

42 "/state/mystate.48s" STO

And then you have a file named "mystate.48s" that you can overwrite.

Quote: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%).

Thanks a lot for the verification and for reporting it!

Quote: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 ?

To me, you should just need a "git pull stable" to get the latest stable release. If that does not work, please share with me the instructions you are using.

Quote: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.

To be precise, it's "my" bignum calculation library. It was coded from scratch to accommodate the particular needs of DB48X in terms of speed and size. For example, precision is adjusted dynamically, so a constant like 1.23 in your program always takes 5 bytes only.

Quote: 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)?

This is documented in the "performance" section of the documentation.

Quote: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)?

Ah, interval arithmetic, one of my long dreams. Well, yes, it can be considered. It's not super high on my todo list at the moment, though.

Quote: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.

Good news!

Quote: 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.

The PrimeG2 uses hardware-accelerated floating-point. Generally, if you want to get similar performance out of your simulator, you need to select hardware acceleration and a precision of either 7 digits (FP32, i.e. C 'float') or 16 digits (FP64, i.e. C 'double').

However, that won't help your specific case, because the random number generator is only producing "decimal" objects, not "hwdouble" or "hwfloat". I only connect to hardware-accelerated functions when they exist, and there is no built-in ACORN generator in the current math library.

Quote: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)?

The DM32 is faster on battery, but the firmware at the moment does not boost the CPU clock when connected on USB, so the DM42 is faster on USB. The performance link I gave above also has DM32/DM42 comparisons if you want actual numbers.

Quote: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 !

On a Prime G1, this might be doable. On a G2, I think that nobody really knows how to create custom firmware. Maybe I'm wrong.