Quick HP42S question

[Valentin Albillo]

.
Hi, all:

Just a quick HP42S question, as I don't have the manual at hand now and can't remember if it's even possible: How can you change the Polar/Rectangular mode programmatically ?

Manually from the keyboard is just a matter of setting the correct mode in the MODES menu, and programmatically you can test the current mode by checking whether Flag 73 is set or not.

But Flag 73 is a system flag and so it can't be set/cleared by the user. Are there some keywords that will change the mode from a running program (as part of an initialization procedure, for instance) ?

Sorry if this is a trivial question. Thanks.
V.
.

[ijabbott]

The quickest way is to select RECT or POLAR from the MODES menu in a program. But you can also select them from the CATALOG menu.

[Thomas Okken]

The RECT and POLAR commands from the MODES menu are programmable.

[Valentin Albillo]

(05-24-2020 11:37 PM)Thomas Okken Wrote:  The RECT and POLAR commands from the MODES menu are programmable.

Thank you very much, ijabbot and Thomas. I had located both functions in the catalog but mistook them for rectangular/polar conversions

By the way, Thomas, a question regarding Free42/BCD for Android (though I think it will be the same for other operating systems).

I've programmed the exact same algorithm for both Free42 and the HP-71B. The algorithm generates and uses many thousand random numbers, initialized with 1, SEED in Free42 and RANDOMIZE 1 in the HP-71B.

As I thought Free42 includes the exact same RNG that a physical HP42S uses (which was taken from the HP-71B), I expected both programs to give the same results, but upon running them I discovered that in fact they don't. Both sequences of random numbers stay the same for a while but after some time they begin to not be exactly alike and when the programs use them they give slightly different results, perhaps 2147 and 2148, respectively.

The question is: is the RNG in Free42 guaranteed to produce the exact same sequence of random numbers as a physical HP42S would, no matter how long, or will they eventually part ways ?

If the RNG in Free42 is actually different, how many random numbers will it provide before repeating ? I know the one in the HP-71B and so the HP42S will produce 1,000,000,000,000 random values before repeating, and the sequence passes the Spectral Test. Is this also the case for the one in Free42 or does it have a longer period ?

Thanks and best regards.
V.

[Thomas Okken]

(05-25-2020 12:17 AM)Valentin Albillo Wrote:  The question is: is the RNG in Free42 guaranteed to produce the exact same sequence of random numbers as a physical HP42S would, no matter how long, or will they eventually part ways ?

I won't go so far as to guarantee that the RNG in Free42 will produce the exact same sequence as the real HP-42S, but I believe the algorithms are the same (see https://www.hpmuseum.org/forum/thread-9556.html for an earlier discussion, including a link to the article where I found the algorithm). I tried comparing the Free42 RNG to Emu42, both starting from Memory Clear, and they returned identical sequences as far as I could tell... I don't remember how long I let the test run, whether it was hundreds or thousands of iterations or more. At what point do you see a divergence?

[Joe Horn]

(05-25-2020 12:17 AM)Valentin Albillo Wrote:  If the RNG in Free42 is actually different, how many random numbers will it provide before repeating ? I know the one in the HP-71B and so the HP42S will produce 1,000,000,000,000 random values before repeating...

According to Richard Nelson's article "HP’s Pseudorandom Number Generator" on page 58 of HP Solve #31 (April 2013), the PRNG used in most HP 12-digit-mantissa models from the '71 onward has a cycle length of 5E13, not 1E12.

Also, it produces the same cycle from the same seed on all models EXCEPT the 33s and 35s, which occasionally differ by one digit in the last place due to a bug they introduced in those models, namely, they round the output instead of truncating it like all the other models do. Example:

Seed the random number generator with the square root of 5. Then generate two random numbers. All the non-buggy models output this as the second one:

0.0593946804209

The 33s and 35s alone output this instead:

0.0593946804210

Richard's footnote about this discrepancy follows:

Quote:(7) Bug Hunter Joseph K. Horn explains: “Bottom Line: HP 33s and 35s programs that use random numbers cannot be relied upon to obtain precisely the same results as the other HP models that use the same RNG engine. This is critically important if the RNG is re-seeded with one of these different random numbers; in that case, the random number sequence in the 33s and 35s will diverge from the other models.”
Example of critical divergence: 11 RDZ RAND RDZ RAND RAND RAND --> (Note: RDZ is used to store the seed)
RPL models: 0.975035362027, 0.529463266203, 0.783522353434
33s & 35s: 0.826166290494, 0.626934236292, 0.213277976998
As you can see, the obtained sequence is totally different.

The DM42 agrees with the non-buggy outputs above. I do not have an HP-42S to check whether it is buggy, but the divergence that you are seeing MIGHT be caused by that. Please perform the square root of 5 seed test mentioned above and let us know what you get. Thanks!

[Gerald H]

Root 5 seed test on real 42S returned

........209

for ROM C (SNr 3144S) & for ROM A (SNr 2914S).

[Werner]

1 SEED
then produced 10 million random numbers, on Free2 and Emu42.
They're still the same.
Werner

[Joe Horn]

The following comment section in HP's original source code for the HP 48 series gives further support to the random number generator's period being 5E13 long if the seed ends in 1, 3, 7, or 9, which the RDZ code automatically does.

Code:

        STITLE    %RANDOMIZE
*****************************************************************
**
** Name: %RANDOMIZE
**
** Abstract: Updates [RNSEED] by user input (% <> 0) or by
**           the system clock (% = 0).
**
** Stack: % -->
**
** Exceptions: none
**
** Author: All inquiries may be addressed to the late great
**         Homer Russel, wherever he is.
**
** Algorithm:
**
**  x(n+1) = a * x(n) + c  (mod m)
**
**  here: a = 2851130928467  [= 67 (mod 200)]
**        c = 0
**        m = 10^15
**
**  If x(0) # 0  (mod 2) and x(0) # 0 (mod 5) then the period
**  is 5*10^13 (Theorem D, pg. 19 of Knuth Vol. 2).
**
***Date Changed      Programmer            Reason
***------------      ----------      -------------------
**  1/15/86         P. McClellan           packed
** 08/24/89         SB             BugFix: Use SysTime (Not TIME)
*****************************************************************

[ijabbott]

(05-25-2020 05:30 AM)Gerald H Wrote:  Root 5 seed test on real 42S returned

........209

for ROM C (SNr 3144S) & for ROM A (SNr 2914S).

Additionally, the 11 SEED RAN SEED RAN RAN RAN test produces the same sequence as the RPL models: 0.975035362027, 0.529463266203, 0.783522353434 (for ROM 42S-E).

The equivalent keystrokes on HP-27S (11 STO RAN# STO RAN# RAN# RAN#) produces the same sequence (for ROM 27S-E).

[J-F Garnier]

(05-25-2020 06:40 AM)Werner Wrote:  1 SEED
then produced 10 million random numbers, on Free2 and Emu42.
They're still the same.
Werner

Same for the HP-71B (emu71).

But...
the 100,000th number is .935105198 (with 3 tailing 0s)
the 1,000,000th number is .83105198 (with 4 tailing 0s)
the 10,000,000th number is .4105198 (with 5 tailing 0s)

Even if the period is in the range of 1E12-1E13, it seems there are correlations between numbers long before. Has this been already noticed? Probably not before the use of emulators/simulators and fast CPUs.

J-F

[ijabbott]

(05-25-2020 12:17 AM)Valentin Albillo Wrote:  I've programmed the exact same algorithm for both Free42 and the HP-71B. The algorithm generates and uses many thousand random numbers, initialized with 1, SEED in Free42 and RANDOMIZE 1 in the HP-71B.

As I thought Free42 includes the exact same RNG that a physical HP42S uses (which was taken from the HP-71B), I expected both programs to give the same results, but upon running them I discovered that in fact they don't. Both sequences of random numbers stay the same for a while but after some time they begin to not be exactly alike and when the programs use them they give slightly different results, perhaps 2147 and 2148, respectively.

The question is: is the RNG in Free42 guaranteed to produce the exact same sequence of random numbers as a physical HP42S would, no matter how long, or will they eventually part ways ?

I think we've established it's the same sequence now. The different results you see in your program must be due to arithmetical rounding differences elsewhere in the code, which is not surprising since Free42 BCD uses higher precision arithmetic than the 42S or 71B.

[Valentin Albillo]

.
Hi, all:

(05-25-2020 09:06 AM)J-F Garnier Wrote:  Same for the HP-71B (emu71).

But...
the 100,000th number is .935105198 (with 3 tailing 0s)
the 1,000,000th number is .83105198 (with 4 tailing 0s)
the 10,000,000th number is .4105198 (with 5 tailing 0s)

Even if the period is in the range of 1E12-1E13, it seems there are correlations between numbers long before. Has this been already noticed?

Thanks to all of you for your replies, I've checked right now and the sequence of random numbers generated from a seed of 1 is exactly the same for at least the first 100,000,000 random numbers in both Free42 and Emu71 and I see this as quite convincing evidence that they'll remain the same to the bitter end, the differences in my programs lie elsewhere.

As for the correlations, yes, I did notice it in August last year while vacationing. They're clearly exposed by running the following HP-71B program (the equivalent Free42 program does produce the exact same results):


      10 DESTROY ALL @ INPUT "K=";K
      20 FOR J=0 TO K @ N=10^J @ RANDOMIZE 1
      30 FOR I=1 TO N @ X=RND @ NEXT I
      40 DISP USING "10D,2X,Z.12D";N,X @ NEXT J

>RUN
K=
      8 [END LINE]

            N     N^th random number
     ---------------------------------
            1     0.731362440213
           10     0.723555832003
          100     0.056136887198
        1 000     0.411709251980
       10 000     0.823130519800
      100 000     0.935105198000
    1 000 000     0.831051980000
   10 000 000     0.410519800000
  100 000 000     0.205198000000

Not very random-looking, methinks, and that many trailing zeros ...

Regards.
V.

[Albert Chan]

(05-25-2020 02:35 PM)Valentin Albillo Wrote:              N     N^th random number
     ---------------------------------
            1     0.731362440213
           10     0.723555832003
          100     0.056136887198
        1 000     0.411709251980
       10 000     0.823130519800
      100 000     0.935105198000
    1 000 000     0.831051980000
   10 000 000     0.410519800000
  100 000 000     0.205198000000

Not very random-looking, methinks, and that many trailing zeros ...

This apply to any LCG RNG: seed * a mod m

k-th random number = seed * a^k mod m

If k = order(a,m), we have a^k mod m = 1
If k | order(a,m), we expect a non-random pattern for s = a^k mod m

Example, to reproduce above numbers:

>>> a, m = 2851130928467, 10**15
>>> seed = 10**14 + 11       # seed for RANDOMIZE 1
>>> for i in xrange(9):      # note: order(a,m) = 5E13
...     n = 10 ** i          # note: n | order(a,m)
...     s = pow(a,n,m)
...     print '%-9d %015d %015d' % (n, s, s*seed % m)
...
1         002851130928467  731362440213137
10        165777802909449  723555832003939
100       268739717018001  056136887198011
1000      573791750180001  411709251980011
10000     429375501800001  823130519800011
100000    439555018000001  935105198000011
1000000   975550180000001  831051980000011
10000000  755501800000001  410519800000011
100000000 555018000000001  205198000000011

Most significant digits are more random than least siginificant digits.
Thus, last 3 digits were chopped off, to produce RND()