<< Hmm. Have you compiled the C code and tested it? Just in case... it wouldn't be the first time that demo C code had some subtle mis-print in it. >>
Yes, I copied the C source file from the Mersenne Twister (MT) Web site into Project Builder on Mac OS X. It ran with out any error. I took the 1000 numbers and brought them into JMP for statistical analysis. They looked great. (JMP random number generators are based on this same MT algorithm now.)
<< To check further, knock up a little C prog to take a few numbers and do the various shifts/masks, and some Squeak code to do the same. Compare; it should at least illustrate where the differences are creeping in ot bite you. Chances are good that it is a single trivial typo-like error somewhere. >>
Thank you for the advice but now I suspect that it is probably not a typographical error (confirmed original C source) but a subtle difference in the behavior between Smalltalk and C when it comes to long unsigned integer operations. I just have no clue!
Again, thanks Tim for looking at this problem for me.
-Mark
Mark4Flies@aol.com is claimed by the authorities to have written:
<< To check further, knock up a little C prog to take a few numbers and do the various shifts/masks, and some Squeak code to do the same. Compare; it should at least illustrate where the differences are creeping in ot bite you. Chances are good that it is a single trivial typo-like error somewhere. >>
Thank you for the advice but now I suspect that it is probably not a typographical error (confirmed original C source) but a subtle difference in the behavior between Smalltalk and C when it comes to long unsigned integer operations. I just have no clue!
Actually in this part I was suggesting that it might be a simple typo in the _smalltalk_ and that by comparing the results of the shifts & masks in C with those in Smalltalk you could probably find out something.
I'm just looking at making a little plugin of it and wondering which of the varieties of numbers one really wants. The C file I downloaded seems to offer:- array initialisation of seeds plain init of seeds 32 bit int result 0 to 16rFFFFFFFF 31 bit 0 to 16r7FFFFFFF three different reals, [0,1], [0,1), (0,1) and [0,1) 53 bit resolution.
Obviously the simplest would be to drop everything but the plain init and 32 bit int result. One might reasonably cut it to 30bit positive SmallInteger results.
What would be most useful?
tim
OK, I have a working trivial plugin for this that just does a 30bit int for now. Seems to work ok - making a bag of 1000 values suggests it at least does a tolerable job. Though it does bother me a bit that in a whole load of tests I've not seen any number with less than a half-dozen digits. I'll let you numerics fanatics worry about that part.
So what sorts of values would be useful? Is just a 30bit int ok with any further cleverness being done in the image?
tim
On Tue, 30 Jul 2002, Tim Rowledge wrote:
OK, I have a working trivial plugin for this that just does a 30bit int for now. Seems to work ok - making a bag of 1000 values suggests it at least does a tolerable job. Though it does bother me a bit that in a whole load of tests I've not seen any number with less than a half-dozen digits.
Shouldn't you be expecting slightly less than 1 in 10,000 to be < 6 digits? Make a Bag of 100,000 of 'em and see if you get 10 or so less than 10^6.
Ian
Ian Piumarta ian.piumarta@inria.fr is claimed by the authorities to have written:
On Tue, 30 Jul 2002, Tim Rowledge wrote:
OK, I have a working trivial plugin for this that just does a 30bit int for now. Seems to work ok - making a bag of 1000 values suggests it at least does a tolerable job. Though it does bother me a bit that in a whole load of tests I've not seen any number with less than a half-dozen digits.
Shouldn't you be expecting slightly less than 1 in 10,000 to be < 6 digits? Make a Bag of 100,000 of 'em and see if you get 10 or so less than 10^6.
Err... guess so. I got 9 elements < 100000 out of 100000 randoms. I'll let somebody far more anal retentive than I do a ful anal-yis.
tim
squeak-dev@lists.squeakfoundation.org