- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: The mysterious MTH$RANDOM
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 01:52 AM
09-12-2011 01:52 AM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 04:47 AM
09-12-2011 04:47 AM
Re: The mysterious MTH$RANDOM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 06:31 AM - edited 09-12-2011 08:01 AM
09-12-2011 06:31 AM - edited 09-12-2011 08:01 AM
Re: The mysterious MTH$RANDOM
>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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 07:53 AM
09-12-2011 07:53 AM
Re: The mysterious MTH$RANDOM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 10:50 AM
09-12-2011 10:50 AM
Re: The mysterious MTH$RANDOM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 04:42 PM
09-12-2011 04:42 PM
SolutionJeremy,
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-12-2011 06:48 PM
09-12-2011 06:48 PM
Re: The mysterious MTH$RANDOM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-13-2011 05:53 PM
09-13-2011 05:53 PM
Re: The mysterious MTH$RANDOM
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-13-2011 06:21 PM
09-13-2011 06:21 PM
Re: The mysterious MTH$RANDOM
Where are the MATH$ routines documented?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-13-2011 10:39 PM
09-13-2011 10:39 PM
Re: The mysterious MTH$RANDOM
>... routine been moved to a Microsoft forum?
It's a porting to Windows question?