(2 raisedTo: 128) atRandom hex
Gives me results like:
B990880B732110000000000000000001 BFD3A7B37FA750000000000000000001 E0A6F981C14DF0000000000000000001
Somehow I'm not buying the lower-order bits on this one. :)
-- Tim
"Timothy" == Timothy J Miller tmiller@mitre.org writes:
Timothy> (2 raisedTo: 128) atRandom hex Timothy> Gives me results like:
Timothy> B990880B732110000000000000000001 Timothy> BFD3A7B37FA750000000000000000001 Timothy> E0A6F981C14DF0000000000000000001
Timothy> Somehow I'm not buying the lower-order bits on this one. :)
It's pretty likely you have a 16-bit random generator, so there just aren't enough bits to make the low-order bits random in any way shape or form.
"Randal" == Randal L Schwartz merlyn@stonehenge.com writes:
"Timothy" == Timothy J Miller tmiller@mitre.org writes:
Timothy> (2 raisedTo: 128) atRandom hex Timothy> Gives me results like:
Timothy> B990880B732110000000000000000001 Timothy> BFD3A7B37FA750000000000000000001 Timothy> E0A6F981C14DF0000000000000000001
Timothy> Somehow I'm not buying the lower-order bits on this one. :)
Randal> It's pretty likely you have a 16-bit random generator, so there just aren't Randal> enough bits to make the low-order bits random in any way shape or form.
Err, uh, 64 bits of random. But still not enough for a 128-bit random number.
El 7/31/08 4:41 PM, "Randal L. Schwartz" merlyn@stonehenge.com escribió:
"Timothy" == Timothy J Miller tmiller@mitre.org writes:
Timothy> (2 raisedTo: 128) atRandom hex Timothy> Gives me results like:
Timothy> B990880B732110000000000000000001 Timothy> BFD3A7B37FA750000000000000000001 Timothy> E0A6F981C14DF0000000000000000001
Timothy> Somehow I'm not buying the lower-order bits on this one. :)
It's pretty likely you have a 16-bit random generator, so there just aren't enough bits to make the low-order bits random in any way shape or form.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
But (2 raisedTo: 128) atRandom could genetate 49572205802560219958060582892667404289
and 49572205802560219958060582892667404289 hex also is wrong print '254B42724A9684000000000000000001'
And I sorry to tell all this is a bug from 3.2 times. I know because I working on 3.2 and 3.10 derivative images now.
Edgar
Edgar J. De Cleene <edgardec2001 <at> yahoo.com.ar> writes:
But (2 raisedTo: 128) atRandom could genetate 49572205802560219958060582892667404289
and 49572205802560219958060582892667404289 hex also is wrong print '254B42724A9684000000000000000001'
Nah! hex is an excellent print, it is printStringBase: 16
10r49572205802560219958060582892667404289 = 16r254B42724A9684000000000000000001 -> true
On Jul 31, 2008, at 2:54 PM, Edgar J. De Cleene wrote:
But (2 raisedTo: 128) atRandom could genetate 49572205802560219958060582892667404289
and 49572205802560219958060582892667404289 hex also is wrong print '254B42724A9684000000000000000001'
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
hex(49572205802560219958060582892667404289)
'0x254b42724a9684000000000000000001L'
Hmmm. Clearly I'm missing something.
-- Tim
El 7/31/08 5:31 PM, "Timothy J Miller" tmiller@mitre.org escribió:
On Jul 31, 2008, at 2:54 PM, Edgar J. De Cleene wrote:
But (2 raisedTo: 128) atRandom could genetate 49572205802560219958060582892667404289
and 49572205802560219958060582892667404289 hex also is wrong print '254B42724A9684000000000000000001'
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
hex(49572205802560219958060582892667404289)
'0x254b42724a9684000000000000000001L'
Hmmm. Clearly I'm missing something.
-- Tim
Sorry by not thinking. Only see the 000000000000000001 end in your first and test 3.2 do same as 3.10 Once hex was removed from image ... http://bugs.squeak.org/view.php?id=6441 Edgar
El 7/31/08 5:31 PM, "Timothy J Miller" tmiller@mitre.org escribió:
On Jul 31, 2008, at 2:54 PM, Edgar J. De Cleene wrote:
But (2 raisedTo: 128) atRandom could genetate 49572205802560219958060582892667404289
and 49572205802560219958060582892667404289 hex also is wrong print '254B42724A9684000000000000000001'
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
hex(49572205802560219958060582892667404289)
'0x254b42724a9684000000000000000001L'
Hmmm. Clearly I'm missing something.
-- Tim
Sorry by not thinking. Only see the 000000000000000001 end in your first and test 3.2 do same as 3.10 Once hex was removed from image ... http://bugs.squeak.org/view.php?id=6441 Edgar
The problem is not in hex (although there are problems trying to get a hex representation of a IEEE float, which might be useful to some people). The reason I fixed hex was that the deprecation actually caused several problems, as I discussed on Mantis.
John P Foster.
Timothy J Miller <tmiller <at> mitre.org> writes:
(2 raisedTo: 128) atRandom hex
Gives me results like:
B990880B732110000000000000000001 BFD3A7B37FA750000000000000000001 E0A6F981C14DF0000000000000000001
Somehow I'm not buying the lower-order bits on this one. :)
Yes, bad!
I recommand you use the 'debug it' menu in the workspace and execute step by step in the debugger to understand what goes on...
The key is Random>>#nextInt: anInteger ^ (self next * anInteger) truncated + 1
Random>>#next uses Floating point arithmetic. Thus you get the 53 bits precision of a Float mantissa (IEEE 754 double). It then gets shifted (128-53) times. There's probably a trick that rounds Float last bit to zero (like round to nearest integer always occur). And you might be able to understand the trailing 1.
Worse, the default Random generator does a modulo (2 raisdeTo: 31) - 1. That is, it can generate at most (2 raisdeTo: 31) different numbers... That happens to be the number of SmallInteger in the system, so it probably works better for SmallIntegers. A different strategy should be adopted for LargePositiveInteger>>atRandom... Let us say current implementation is very limited...
I suggest you open a mantis account and report the issue at http://bugs.squeak.org
Nicolas
On Jul 31, 2008, at 3:01 PM, nicolas cellier wrote:
Random>>#next uses Floating point arithmetic. Thus you get the 53 bits precision of a Float mantissa (IEEE 754 double). It then gets shifted (128-53) times. There's probably a trick that rounds Float last bit to zero (like round to nearest integer always occur). And you might be able to understand the trailing 1.
Worse, the default Random generator does a modulo (2 raisdeTo: 31) -
That is, it can generate at most (2 raisdeTo: 31) different numbers... That happens to be the number of SmallInteger in the system, so it probably works better for SmallIntegers. A different strategy should be adopted for LargePositiveInteger>>atRandom... Let us say current implementation is very limited...
I suggest you open a mantis account and report the issue at http://bugs.squeak.org
First I'll dig into the Cryptography package and see what they did for large random numbers.
It certainly is inconsistent to have an Integer method that doesn't invisibly handle large ints.
-- Tim
"Timothy" == Timothy J Miller tmiller@mitre.org writes:
Timothy> It certainly is inconsistent to have an Integer method that doesn't Timothy> invisibly handle large ints.
The Integer method is fine. The problem is the lack of bits from the PRNG from class Random.
beginners@lists.squeakfoundation.org
-
Edgar J. De Cleene -
johnps11＠bigpond.com -
merlyn＠stonehenge.com -
nicolas cellier -
Timothy J Miller