50g: an interesting RAND anomaly
|
03-20-2018, 05:47 PM
Post: #21
|
|||
|
|||
RE: 50g: an interesting RAND anomaly
And here is HP's original annotated source code for the HP 48's RAND and RANDOMIZE functions, which I think uses the same algorithm as Cyrille's code in the previous posting in this thread.
Code: STITLE %RAN <0|ΙΈ|0> -Joe- |
|||
03-21-2018, 02:10 AM
(This post was last modified: 03-21-2018 02:27 AM by DavidM.)
Post: #22
|
|||
|
|||
RE: 50g: an interesting RAND anomaly
Cyrille and Joe, thanks for the source listings. For what it's worth, I already knew the algorithm (I had previously disassembled it with Nosy). I've actually been using it in the last few versions of the list randomizer in the ListExt library (LSHUF). While I'm sure I should have already recognized why the anomaly occurred, I'm afraid it wasn't (and still isn't) abundantly obvious to this casual observer. But the identified anomaly was simply evidence of the bigger issue for me, which is that using MOD on an unaltered seed is definitely not an appropriate way to reduce the seed to an integer in a specified range.
I get the sense from Cyrille's and others' responses that I should simply do the extra multiplication (seed range * CEIL) instead of trying to find a faster integer-based method of converting the seed. I was hoping that there would be a more efficient way, given that the RAND function itself had already done most of the heavy lifting. I'm already using the Saturn+ opcodes in other parts of this command (when available, of course), so I'll do the same here. That should mitigate some of the performance degradation from the extra multiplication. I had thought of doing that with the RAND function in the past (specifically the section where the previous seed is multiplied by 2851130928467), but thought it would be safer not to mess with it. I may revisit that now. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: