The mysterious MTH$RANDOM

[Jeremy Begg]

I'm in the process of porting a Pascal program from VMS to Windows and it looks like I'll need to reproduce the behaviour of the MTH$RANDOM routine.  (I know that a properly written application should be immune to differences in the internals of uniform random number generators but I suspect this one is not.)

The MTH$RANDOM documentation describes how the seed parameter is used and modified but it's a bit more cryptic about how the floating point result is produced.  So I dug up my VAX/VMS V5.0 source listings to see what happens.  I can follow the integer arithmetic on the seed up to the point where it uses a CVTF instruction to convert the updated seed to its F-floating equivalent.  The result at that point is a floating point number in the range 0..16777216.

What I don't understand is how this result is morphed into a number between 0 and 1.  Here's the code:

    SUBW    #24@7,R0    ;DIVF #^F2.0**24

                        ; the result is now in the

                        ; range 0.0 .. 1.0 exclusive

The MACRO-32 assembler encodes the "#24@7" parameter as an immediate-mode parameter with vaue 0C00 (hex), which makes sense because that's 24 x 128.  I can see that subtracting 3072 from R0 will affect the exponent part of the F-floating number stored in R0, but I don't see that it guarantees the result will be in the range 0..1.

Can someone enlighten me?

(And I'm yet to see how I might do this efficiently in the ported code. It might not be necessary; the program uses MTH$RANDOM in two ways and one of them examines only the modified seed.  With any luck that's all I'll need to worry about.)

Thanks,

Jeremy Begg

[Hoff]

I was going to suggest  using random() in the portable library or use random() or srandom() in the C library, but on re-reading this, you're asking a Windows question of OpenVMS folks here; that this question is not an OpenVMS question.  

Google finds the following documentation including an example of a simple non-crytographic generator; Google finds various hits for /windows random number generator/ and for /windows random number generator site:microsoft.com/ and related searches.  I'd expect Knuth would have some materials available, too.  Microsoft C likely contains random() and srandom(), or somebody has an implementation.  And the RandomNumberGenerator Class an the Random Class are available in something called ".NET framework 4".

Please also consider asking your future Microsoft Windows questions in a more appropriate forum, too.

[Dennis Handly]

>I can see that subtracting 3072 from R0 will affect the exponent part of the F-floating number stored in R0, but I don't see that it guarantees the result will be in the range 0..1.

If the number is between 0..16777216, then by fiddling with the exponent, you can scale that between 0..1.

Since 16777216 is 0x1000000 == 2 ** 24, which match your comments.  Not sure why you have 3072?

>value 0C00 (hex), which makes sense because that's 24 x 128.

Or really 12 * 256.  ;-)

Or did you say that because that's 24 << 7?

[abrsvc]

Based upon the comments in the macro code, it would appear that the resultant value withint R0 is a real number in the 2**24 range and is positive.  The SUBW is listed as equivalent to a DIVF by 2**24.  I haven't actually tried the bit manipulation, but it seems like the SUBW is a shortcut way to alter the floating point binary bits directly.  Realize that the VAX only had R0-R15 and no floating point registers.  Looking at the bit assignments for F-Floating numbers, the SUBW will alter the bits in the exponent section of the floating point format only..

Using a standard random number generator of a similar type should produce similar outcomes.  The MTH$Random generator is an extremely simplistic one the algorithm of which is readily reproduced in other standard generators.  The coding you reference is a shortcut used by the VAX team to speed up the code.  Similar techniques are probably available for other architectures, but I'd stick to standard calls.  Should your program be sensitive to this particular generator, perhaps a closer look at the code is needed to determine why the dependency exists to that it can be removed.

Dan

[jreagan]

Has this application run on Alpha or Itanium or just VAX.

On both of those, MTH$RANDOM is just a little jacket routine that calls MATH$RANDOM_F.  I don't know if MATH$RANDOM_F even returns the same sequence for a given seed compared to VAX.  You might want to check that.

If you've been using sequences for a given seed then perhaps you've already checked that your application doesn't care.

[John Gillings · Accepted solution]

Jeremy,

   What you're looking at is a hardware dependent hack which "optimises" a particular operation for a specific set of circumstances.

  Since the range of values in this case is an exact power of 2, division by that value can be achieved by the appropriate subtraction operation on the exponent field (you're old enough to have used logarithm tables, yes?). This kind of thing leads to obscure code, but the programmer is somewhat absolved by the comment explaining that it's the equivalent of a DIVF.

  The implication is that the subtraction is cheaper than a floating point division. Certainly true on most architectures. Ironically, the DECC compiler will use exactly the opposite optimisation in some circumstances on the Alpha platform (and possibly Itanium?), converting an integer division into convert int operands to float, float division, convert result float to int. Most surprisingly this is used even if the dividend is an exact power of 2 (it's probably too expensive to determine).

  Unless you're dealing with an extremely frequent code path, most of the time, it's probably better to write the "correct" code, and possibly let some clever compiler apply an architecture dependent hack like this. 

[Jeremy Begg]

Thanks John, straight to the point as always.  When you put it in terms of log tables (and yes I still have mine somewhere) it makes complete sense.

[John Gillings]

Why has a question about usage of a VAX instruction in the MACRO32 source code of an OpenVMS library routine been moved to a Microsoft forum? Weird!

[Jeremy Begg]

Hi John, it appears to return the same sequence.
Where are the MATH$ routines documented?

[Dennis Handly]

>... routine been moved to a Microsoft forum?

It's a porting to Windows question?