(50g) Programme to Produce a Cryptologically Interesting Random Bit

[Gerald H]

For no input the programme returns 1. or 0..

Code:

Size: 114.

CkSum: # 39464d

::
  CK0
  %RAN
  %MANTISSA
  a%>$
  DUPLEN$
  #1-DUP
  BINT2
  #/
  DROP
  #0=
  ITE
  ::
    #1-
    SWAP
    DEL_END$_
  ;
  SWAP
  ZEROSWAP
  BINT5
  ZERO_DO
  INDEX@
  DUP
  #+
  #>$
  NULL$
  FPTR F 1A
  COERCE
  ROT#+SWAP
  LOOP
  DROP
  %RAN
  % .9
  %>
  IT
  #1+
  DUPUNROT
  #-
  #>
  COERCEFLAG
;

[Gerald H]

Slightly improved programme:

Code:

Size: 91.

CkSum: # 47A7h

::
  CK0
  %RAN
  %MANTISSA
  a%>$
  CDR$
  CDR$
  DUPLEN$
  DUP
  BINT2
  #/
  DROP
  #0=ITE
  ::
    #1-SWAP
    CDR$
  ;
  SWAP
  ZEROSWAP
  BINT5
  ZERO_DO
  INDEX@
  #2*
  #>$
  NULL$
  FPTR F 1A
  COERCE
  ROT#+SWAP
  LOOP
  DROP
  DUPUNROT
  #-
  #>
  COERCEFLAG
;

[David Hayden]

I can't find a reference for FPTR F 1A. I figured that translates into address 01A00F but didn't find it in any of the entries files that I have. What does that do?

Thanks,
Dave

[DavidM]

(07-18-2023 04:02 PM)David Hayden Wrote:  I can't find a reference for FPTR F 1A. I figured that translates into address 01A00F but didn't find it in any of the entries files that I have. What does that do?

Thanks,
Dave

That is the post-dispatch subroutine for the UserRPL SREPL command. Calling that flashptr essentially gives you the "missing" SysRPL version of that command.

I'm pretty sure I've used that Flashptr quite a few times myself.

[Gerald H]

After some testing the programme in posting #1 has an average value nearer to 0.5 than that of posting #2 - Could some erudite individual venture a reason for different average values?

[DavidM]

(07-22-2023 09:04 AM)Gerald H Wrote:  After some testing the programme in posting #1 has an average value nearer to 0.5 than that of posting #2 - Could some erudite individual venture a reason for different average values?

I'm not qualified to answer your specific question as posted, but I am definitely aware that it is easy to introduce bias in PRNGs when applying digit manipulations to the results. I suspect there's a bias resulting from the method used in your second program, though it's not clear to me where it's coming from.

Of course you could simply test the RAND value as being > or < 0.5, but that is a rather blunt force method which disregards the "randomness" of the trailing digits to give its result.

If you want all of the RAND digits to have some influence in the output, something like this might work:

Code:

::
   CK0NOLASTWD          ( no arguments expected )
   %RAN                 ( next RAND result )
   OCRC SWAPDROP        ( obtain the user binary CRC of the RAND result )
   HXS>#                ( convert the CRC to a system binary number )
   ONE #AND             ( isolate the least significant bit from the CRC )
   UNCOERCE             ( map #0 or #1 to %0 or %1 )
;

I'm not an expert in PRNGs, so I won't guarantee that there's no bias in the above method. In fact, I suspect it's likely that there is some bias due to the checksum always including the same prologue data for each RAND result. That said, the averages for each block of 1 million I tested still seemed reasonable:
0.499529
0.499503
0.500005
0.500317
0.500096