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
;
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
;
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
(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.
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?
(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