[Caml-list] portablility of random.mli in the stdlib

[Caml-list] portablility of random.mli in the stdlib

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]


Hello,

Playing with my game (see my previous post), I saw that it seems that
the random number generator in not portable ... The same seed will not
give the same random sequence on a 32 bits and 64 bits machine ...

If you use Random.int, this seems normal ...

But if you use only Random.float or other functions consuming the same
number of bits, this
is not what I expected ....

What do other people think ? Is this a sort of bug ?

Cheers,
Chrisophe


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Caml-list] portablility of random.mli in the stdlib

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

Le 30/04/11 12:37, Christophe Raffalli a écrit :
> Hello,
>
> Playing with my game (see my previous post), I saw that it seems that
> the random number generator in not portable ... The same seed will not
> give the same random sequence on a 32 bits and 64 bits machine ...
>
In fact it was a change in random generator in ocaml 3.12

------------------------------------
        Objective Caml version 3.12.0+beta1

# Random.init 0;;
- : unit = ()
# Random.float 1.0;;
- : float = 0.849294619789682792
------------------------------------
        Objective Caml version 3.11.2

# Random.init 0;;
- : unit = ()
# Random.float 1.0;;
- : float = 0.454763353840783646


This means that any long living program should use its own random
generator ?

Cheers,
Christophe


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Caml-list] portablility of random.mli in the stdlib

[Török Edwin]

On 04/30/2011 02:14 PM, Christophe Raffalli wrote:
> Le 30/04/11 12:37, Christophe Raffalli a écrit :
>> Hello,
>>
>> Playing with my game (see my previous post), I saw that it seems that
>> the random number generator in not portable ... The same seed will not
>> give the same random sequence on a 32 bits and 64 bits machine ...
>>
> In fact it was a change in random generator in ocaml 3.12
> 
> ------------------------------------
>         Objective Caml version 3.12.0+beta1
> 
> # Random.init 0;;
> - : unit = ()
> # Random.float 1.0;;
> - : float = 0.849294619789682792
> ------------------------------------
>         Objective Caml version 3.11.2
> 
> # Random.init 0;;
> - : unit = ()
> # Random.float 1.0;;
> - : float = 0.454763353840783646
> 
> 
> This means that any long living program should use its own random
> generator ?
> 

Why should a random generator give the same results over multiple
versions and architectures?
Starting from same seed is useful only for debugging.

Best regards,
--Edwin

Re: [Caml-list] portablility of random.mli in the stdlib

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Le 30/04/11 13:26, Török Edwin a écrit :
> Why should a random generator give the same results over multiple
> versions and architectures?
To be able to replay a game on various architecture saving only the seed
and the user movement (which is very small).
> Starting from same seed is useful only for debugging.
This is really untrue in a lot of applications for instance in cryptography.
But I do not know if random.ml is good enough for assymetric cryptography
(where the secret key in the seed and the coding is simply xor with a
random sequence of bit)
This require not only passing all randomness test, but also making it
hard to recover the key from
a generated sequence of random bits.

Cheers,
Christophe



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: [Caml-list] portablility of random.mli in the stdlib

[Alexandre Pilkiewicz]

2011/4/30 Török Edwin <edwintorok@gmail.com>:
> On 04/30/2011 02:14 PM, Christophe Raffalli wrote:
>
> Why should a random generator give the same results over multiple
> versions and architectures?
> Starting from same seed is useful only for debugging.

I wrote a fuzzer once: the principle is to generate random entries for
a program, and see if it crashes. When it does, instead of printing
the entry in the log file, you just remember the seed that produced
the entry. With that, you are able to reproduce the crash easily

Cheers

Alexandre Pilkiewicz

Re: [Caml-list] portablility of random.mli in the stdlib

[Andrew]

> Why should a random generator give the same results over multiple
> versions and architectures?
> Starting from same seed is useful only for debugging.
>

In designing a game, you might find it convenient to use a given seed to encode a sequence of numbers (eg. level one is 
random seed 1524).

Another field where that could be useful is statistics; being able to reproduce your results is absolutely crucial. 
Taking random values is fine, but you can' just say you obtained a result without telling others how to reproduce it.

Andrew.

Re: [Caml-list] portablility of random.mli in the stdlib

[Andrei Formiga]

Yes, the RNG algorithm changed from 3.11 (linear feedback shift
register) to 3.12 (a lagged Fibonacci with some adaptations). Neither
are suitable for use with cryptography.

-- 
[]s, Andrei Formiga


2011/4/30 Christophe Raffalli <craff73@gmail.com>:
> Le 30/04/11 13:26, Török Edwin a écrit :
>> Why should a random generator give the same results over multiple
>> versions and architectures?
> To be able to replay a game on various architecture saving only the seed
> and the user movement (which is very small).
>> Starting from same seed is useful only for debugging.
> This is really untrue in a lot of applications for instance in cryptography.
> But I do not know if random.ml is good enough for assymetric cryptography
> (where the secret key in the seed and the coding is simply xor with a
> random sequence of bit)
> This require not only passing all randomness test, but also making it
> hard to recover the key from
> a generated sequence of random bits.
>
> Cheers,
> Christophe
>
>
>