[M3devel] random.longint()?

[Jay K]

I'm just going to leave it alone.
There's already code that checks BITSIZE(INTEGER) and makes one or two calls accordingly.


More interesting probably..but again probably nothing from me..is using modern OS
sources of randomness, entropy, random numbers.


http://www.opengroup.org/onlinepubs/007908799/xsh/drand48.html
http://en.wikipedia.org/wiki/CryptGenRandom


You know..sometimes underlying system doesn't offer much and you do it yourself.
Sometimes the underlying systems catch up..


 - Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] random.longint()?
> Date: Thu, 20 May 2010 06:44:37 -0700
> From: mika at async.async.caltech.edu
>
>
> I would be a bit careful here. Presumably there are a lot of subtypes
> of Random.T out there that override methods in various ways... Layering
> longint on top of multiple calls to integer (rather than the other way
> around) seems like the safe approach to getting things working.
>
> Mika
>
> Jay K writes:
>>
>>In libm3 there is random number generation.
>>In libm3 that is code that wants 8 random bytes.
>>=A0 If integer is 4 bytes=2C it calls random.integer() twice=2C else if it =
>>is 8=2C once.
>>
>>It seems natural that we should provide random.longint()?
>>
>>And then the other code can just use it?
>>
>>Someone can look into the random number generator and
>>=A0- make sure it is actually "correct" for 64bit integer?
>>=A0- and if so=2C change the lowest level to use LONGINT
>>=A0=A0 and layer integer over it? -- not sure how=2C presumably
>>=A0=A0 taking only the lower 32bits loses too much randomness?
>>
>>
>>This is what I get for looking into why we are ever asked to extract 0 bits=
>>..
>>
>>"Everywhere I look=2C I see bugs." (topic of a separate mail)
>>
>>=A0- Jay
>>
>> =