Random Number (RND) Problem

[Walter Henn]

According to the PB documentation for PB/CC, the RND function returns an extended precision value that is >= 0 and < 1. However, when you do a hex dump of the RND value assigned to an EXT variable (retrieving the 10 bytes stored in memory for the EXT value) using the code below, the lower four bytes of the stored variable never seem to change, seeming to suggest that the RND function does not return an extended precision value.

I'd really appreciate comments on this post before I request support regarding this issue.

' rnd_test.bas
' PB/CC 4.04
 
#DEBUG ERROR ON
#DIM ALL
#REGISTER ALL
#COMPILE EXE
 
FUNCTION hex_data_dump(BYVAL value AS EXT)AS STRING
'retrieve 10-byte memory contents of ext variable
 
LOCAL mem_bytes AS STRING
LOCAL byte_counter AS LONG
LOCAL address AS DWORD
 
mem_bytes = ""
address = VARPTR(value) + 9 'Address of most significant byte
FOR byte_counter = 1 TO 10
    mem_bytes = mem_bytes + HEX$(PEEK(BYTE, address),2)
    DECR address
NEXT byte_counter
FUNCTION = mem_bytes
 
END FUNCTION
 
 
FUNCTION PBMAIN () AS LONG
 
LOCAL z AS EXT
LOCAL counter AS LONG
LOCAL hex_string AS STRING
 
FOR counter = 1 TO 10000000
    IF counter MOD 100000 = 0 THEN PRINT FORMAT$(counter, "#,") 'print counter every 100000
    z = RND
    hex_string = hex_data_dump(z)'Assign memory contents for EXT variable z to hex_string.
    IF MID$(hex_string, 13) <> "00000000" THEN 'Test whether lower four bytes of EXT variable are all zeroes.
        PRINT "EXT lower 4 bytes not all zeroes!",  hex_string
        WAITKEY$
    END IF
NEXT counter
 
PRINT "end of program"
WAITKEY$
 
END FUNCTION

[Paul Dixon]

Walter,
the value returned is an extended precision representation of the 32 bit number used by the random number generator.

Paul.

[Walter Henn]

Walter,
the value returned is an extended precision representation of the 32 bit number used by the random number generator.
Paul.

Thanks, Paul. However, the documentation states: RND and RND() return a random Extended-precision value that is less than 1, but greater than or equal to 0. It doesn't say anything about "an extended precision representation of the 32 bit number used by the random number generator." If your statement is true, at the very least, the documentation on this function is very misleading.

[Tim Schachter]

I know I must be missing some important fact. Where does it say that the lower 4 bytes will always be different?

[Walter Henn]

I know I must be missing some important fact. Where does it say that the lower 4 bytes will always be different?

It doesn't say anywhere that the lower 4 bytes will always be different. My point is that the lower 4 bytes never are different. If these bytes never change, then the stored value of RND in an EXT variable does not have the 18 bits of precision associated with EXT variables.

[John Gleason]

By coincidence I just did this all-in-one function two days ago. It's just a few ticks slower than RND.

FUNCTION rndExt() AS EXT
'-----------------------------------------------------------------------------------------
'creates an EXT random test value from 0 to +0.9999... (or -0.9999... to +0.9999...
'if you uncomment the noted 5 lines) where each of the 18 digits are statistically random.
'Period is ~2^61 (2*10^18) EXT values before repeating--many years.
'-----------------------------------------------------------------------------------------
  STATIC eqp, oneTime, rndL AS LONG, eq AS QUAD
  STATIC mwcSoph, mwcRandom, mwcCarry AS LONG

  IF oneTime = 0 THEN
     !nop                    ;< alignment nops
     !nop
     !nop
     !nop                    ;< alignment nops
     oneTime = 1             'this section only needed once per program run.
     eqp = VARPTR(eq)
     mwcSoph   = &h68131E4B  'fixed sg-prime constant. Leave intact
     mwcRandom = &ha5b218da  'you choose user seed1, can be any LONG > 1 or < -1
     mwcCarry  = &h3fe8700c  'user seed2, any positive LONG less than &h68131E4B (mwcSoph) and > 1
'=====================================================================
'    comment next 3 lines to make a fixed start position every run
     !dw &h310f              ;time stamp counter to vary seed1
     !add mwcRandom, eax     ;vary seed1
     mwcCarry = mwcCarry + TIMER * 18 'and vary seed2 a bit.
'=====================================================================
     EXIT IF                 'skip past the following GOSUB routine
     sRandomLong:            'here we generate a random LONG from 0 to &hffffffff
        !mov eax, mwcSoph
        !mov ecx, mwcRandom
        !mul ecx
        !add eax, mwcCarry
        !adc edx, 0
        !mov mwcRandom, eax
        !mov mwcCarry,  edx
        !mov rndL, eax
     RETURN                  'done generating, rndL holds final value
  END IF

     GOSUB sRandomLong       'sub to generate LONG rnd value
     POKE LONG, eqp, rndL
     DO                      'DO LOOP runs avg. of 2.3 loops / rndExt. It's needed for perfectly linear distribution
        GOSUB sRandomLong
        !and rndL, &h0fffffff
        POKE LONG, eqp+4, rndL
     LOOP WHILE eq > 999999999999999999

'-----------------------------------------------------------------------------------------
'you can uncomment the following 5 commented lines to make it -0.9999... to +0.9999...
'-----------------------------------------------------------------------------------------
'      GOSUB sRandomLong       'make it 50/50 + and -
'      IF rndL < 0 THEN        'finally divide it to make its range 0 to .999999999999999999
         FUNCTION = eq /  1000000000000000000  '<< always leave uncommented
'      ELSE
'         FUNCTION = eq / -1000000000000000000
'      END IF

END FUNCTION

[Tim Schachter]

I think your point is lost on a reasonable person. I'm sure you aren't trying to be a troll, but others might think so. The RND function does what it says it will do.

[Walter Henn]

By coincidence I just did this all-in-one function two days ago. It's just a few ticks slower than RND.

John, thank you very much for posting your routine for doing what PowerBASIC claims to be doing (based on their documentation of RND). Until PB gives us a routine for generating extended precision random numbers (if ever), I'll be using yours. :goldcup:

[Walter Henn]

I think your point is lost on a reasonable person. I'm sure you aren't trying to be a troll, but others might think so. The RND function does what it says it will do.

And I presume that you think you're a reasonable person! Stating that, "the RND function does what it says it will do," is simply a statement that is completely without merit, because it does not address any of the points about RND that I've made in my previous posts. If you're up to that task, then I'll be happy to respond to your posts. Otherwise, you're wasting our time!

[Rodney Hicks]

Of course, if those four bytes did change, the number may not be >0 and <1. Have you checked that?
Rod

[Tim Schachter]

I'm sure you have your reasons, but almost everyone dislikes a troll.

[Walter Henn]

I'm sure you have your reasons, but almost everyone dislikes a troll.

Which explains why you are so disliked! Maybe you should just stick to Cafe PowerBASIC, a less demanding forum.

[Edwin Knoppert]

Sorry.. i just blinked my eyes, was there another topic to have us a laugh??

[Walter Henn]

Of course, if those four bytes did change, the number may not be >0 and <1. Have you checked that?
Rod

Yes! The bytes in question are least significant bytes.

[Bob Zale]

Which explains why you are so disliked! Maybe you should just stick to Cafe PowerBASIC, a less demanding forum.

Walter,

We don't allow personal attacks here. Please try to keep your emotions in control.

Bob Zale
PowerBASIC, Inc.

[Walter Henn]

Walter,
We don't allow personal attacks here. Please try to keep your emotions in control.
Bob Zale
PowerBASIC, Inc.

Why the blinders on, Bob? Just four posts back, I was personally attacked by Tim Schlachter. Why weren't you concerned about his emotions? I simply responded in kind.

I'm sure you have your reasons, but almost everyone dislikes a troll.

I would sincerely hate to think that my criticism of PowerBASIC documentation on this thread led to this biased treatment.

[Michael Mattias]

Only 8 bytes of the 10 are the signficand, the other two bytes are sign and exponent.

With the value of RND() constrained to 0<n<1, the sign and exponent will never change.

Why you don't get 8 bytes changing instead of 6 (I'm taking your word for it, I did not try this myself) is a mystery.. or maybe because it's because the number is RANDOM and you just did not try enough times to see it change.

Then again, you are assuming the PB EXT format is this particular IEEE format. I don't believe that is documented anywhere.

[Rodney Hicks]

Have you tried your function on John Gleason's random numbers?
I would but I suspect there might be an error in your code as you read the bytes. Suspect, not saying there is. However, I could not get the if condition to trip on numbers up to 2,000,000,000.

Rod

[Walter Henn]

Only 8 bytes of the 10 are the signficand, the other two bytes are sign and exponent.

With the value of RND() constrained to 0<n<1, the sign and exponent will never change.

Why you don't get 8 bytes changing instead of 6 (I'm taking your word for it, I did not try this myself) is a mystery.. or maybe because it's because the number is RANDOM and you just did not try enough times to see it change.

Then again, you are assuming the PB EXT format is this particular IEEE format. I don't believe that is documented anywhere.

Thanks for your post, Michael.

I tried to be clear in my statement that the four lower bytes of the value of RND did not change. Perhaps it would have been clearer if I had used the term, "four least significant bytes."

Your statement that the exponent for the value of RND (in the most significant two bytes) never changes is not true. The exponent does change. I checked.

As far as your statement that, "maybe because it's because the number is RANDOM and you just did not try enough times to see it change," if you think about it, the least significant bytes should be changing rapidly if these bytes figured into the value of RND.

I strongly believe that the PB EXT format is definitely based on the IEEE standard. Unfortunately, this is very important information that is not documented in the manual. It would be great if Bob Zale had confirmed or denied this, since it has been brought up many times in this forum. If you're reading this post, Bob, can we get an answer to this?

[Walter Henn]

Have you tried your function on John Gleason's random numbers?
I would but I suspect there might be an error in your code as you read the bytes. Suspect, not saying there is. However, I could not get the if condition to trip on numbers up to 2,000,000,000.

Rod

Actually, I made sure that the function for retrieving the stored bytes of an EXT variable agreed with John Gleason's posting of an alternative technique on this forum (his technique, of course, is better).