unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* Random numbers (again) broken on 64-bit platforms
@ 2010-07-26 21:01 Andreas Rottmann
  2010-07-27  8:52 ` Andy Wingo
  0 siblings, 1 reply; 6+ messages in thread
From: Andreas Rottmann @ 2010-07-26 21:01 UTC (permalink / raw)
  To: Guile Development

Hi!

After pulling from Git today, I noticed that `random' is still/again
broken on 64-bit platforms:

scheme@(guile-user)> (random (ash 1 32))
ERROR: In procedure random:
ERROR: Argument 1 out of range: 4294967296

This looks like being caused by
b606ff6af9c9ec7fc3c4473c09ce1e95c18f024a, which doesn't take into
account (in scm_random) that an INUM may well exceed 32 bits on 64-bit
platforms. I'll try to come up with a patch for that, unless someone
beats me to it.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Random numbers (again) broken on 64-bit platforms
  2010-07-26 21:01 Random numbers (again) broken on 64-bit platforms Andreas Rottmann
@ 2010-07-27  8:52 ` Andy Wingo
  2010-08-01 18:44   ` Andreas Rottmann
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2010-07-27  8:52 UTC (permalink / raw)
  To: Andreas Rottmann; +Cc: Guile Development

Heya,

On Mon 26 Jul 2010 23:01, Andreas Rottmann <a.rottmann@gmx.at> writes:

> scheme@(guile-user)> (random (ash 1 32))
> ERROR: In procedure random:
> ERROR: Argument 1 out of range: 4294967296

Well, it's not a segfault at least :)

The point of that change was to indicate that the RNG did not return
sizeof(unsigned long) bits of randomness; it always returned 32
bits. See the note in "BSD Random Number Functions" in libc's manual:

     *NB:* Temporarily this function was defined to return a `int32_t'
     value to indicate that the return value always contains 32 bits
     even if `long int' is wider.  The standard demands it differently.
     Users must always be aware of the 32-bit limitation, though.

I'll fix this now to avoid the error, but there is still work to do on
the RNG -- we really need to update the RNG, I think. Brian Gough, the
GSL maintainer, says MT19937 is the one to use, and specifically the new
SIMD version at
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html. We
should replace our MWC RNG with that one.

Would you be interested in doing this? We would need some test
suites too, I think, and possibly changes to the scm_t_rng structure.

Cheers,

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Random numbers (again) broken on 64-bit platforms
  2010-07-27  8:52 ` Andy Wingo
@ 2010-08-01 18:44   ` Andreas Rottmann
  2010-08-01 19:57     ` Andy Wingo
  0 siblings, 1 reply; 6+ messages in thread
From: Andreas Rottmann @ 2010-08-01 18:44 UTC (permalink / raw)
  To: Andy Wingo; +Cc: Guile Development

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

Andy Wingo <wingo@pobox.com> writes:

> Heya,
>
> On Mon 26 Jul 2010 23:01, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> scheme@(guile-user)> (random (ash 1 32))
>> ERROR: In procedure random:
>> ERROR: Argument 1 out of range: 4294967296
>
> Well, it's not a segfault at least :)
>
> The point of that change was to indicate that the RNG did not return
> sizeof(unsigned long) bits of randomness; it always returned 32
> bits. See the note in "BSD Random Number Functions" in libc's manual:
>
>      *NB:* Temporarily this function was defined to return a `int32_t'
>      value to indicate that the return value always contains 32 bits
>      even if `long int' is wider.  The standard demands it differently.
>      Users must always be aware of the 32-bit limitation, though.
>
> I'll fix this now to avoid the error, but there is still work to do on
> the RNG -- we really need to update the RNG, I think. Brian Gough, the
> GSL maintainer, says MT19937 is the one to use, and specifically the new
> SIMD version at
> http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html. We
> should replace our MWC RNG with that one.
>
I've spotted an issue with your fix: the way 64-bit random numbers are
generated in scm_random() is bogus; to test that, I used the following
code:

(define (random-max n iterations)
  (let loop ((i 0) (result 0))
    (if (< i iterations)
        (loop (+ i 1) (max (random n) result))
        result)))

(random-max #x1ffffffff 10000000)

If you try this, you'll notice that `random-max' returns a much lower
number than it should. The attached patch hopefully fixes this issue


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: random64-fix-2.diff --]
[-- Type: text/x-diff, Size: 3413 bytes --]

From: Andreas Rottmann <a.rottmann@gmx.at>
Subject: Fix the range of `random' on 64-bit platforms

For > 32 bit integers still in the fixnum range, scm_random() would
return random numbers with a lower range than specified.

* libguile/random.c (scm_i_mask32): New static inline function.
  (scm_c_random): Use `scm_i_mask32'.
  (scm_c_random64): New function, 64-bit variant of scm_c_random.
  (scm_random): Use `scm_c_random64' instead of forming the 64-bit random 
  number in a bogus way.
* libguile/random.h: Added `scm_c_random64'.

---
 libguile/random.c |   42 +++++++++++++++++++++++++++---------------
 libguile/random.h |    1 +
 2 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/libguile/random.c b/libguile/random.c
index 83870f6..c0a3e04 100644
--- a/libguile/random.c
+++ b/libguile/random.c
@@ -241,21 +241,42 @@ scm_c_exp1 (scm_t_rstate *state)
 
 unsigned char scm_masktab[256];
 
-scm_t_uint32
-scm_c_random (scm_t_rstate *state, scm_t_uint32 m)
+static inline scm_t_uint32
+scm_i_mask32 (scm_t_uint32 m)
 {
-  scm_t_uint32 r, mask;
-  mask = (m < 0x100
+  return (m < 0x100
 	  ? scm_masktab[m]
 	  : (m < 0x10000
 	     ? scm_masktab[m >> 8] << 8 | 0xff
 	     : (m < 0x1000000
 		? scm_masktab[m >> 16] << 16 | 0xffff
 		: scm_masktab[m >> 24] << 24 | 0xffffff)));
+}
+
+scm_t_uint32
+scm_c_random (scm_t_rstate *state, scm_t_uint32 m)
+{
+  scm_t_uint32 r, mask = scm_i_mask32 (m);
   while ((r = state->rng->random_bits (state) & mask) >= m);
   return r;
 }
 
+scm_t_uint64
+scm_c_random64 (scm_t_rstate *state, scm_t_uint64 m)
+{
+  scm_t_uint64 r;
+  scm_t_uint32 mask;
+
+  if (m <= SCM_T_UINT32_MAX)
+    return scm_c_random (state, (scm_t_uint32) m);
+  
+  mask = scm_i_mask32 (m >> 32);
+  while ((r = ((scm_t_uint64) (state->rng->random_bits (state) & mask) << 32)
+          | state->rng->random_bits (state)) >= m)
+    ;
+  return r;
+}
+
 /*
   SCM scm_c_random_bignum (scm_t_rstate *state, SCM m)
 
@@ -377,17 +398,8 @@ SCM_DEFINE (scm_random, "random", 1, 1, 0,
       return scm_from_uint32 (scm_c_random (SCM_RSTATE (state),
                                             (scm_t_uint32) m));
 #elif SCM_SIZEOF_UNSIGNED_LONG <= 8
-      if (m <= SCM_T_UINT32_MAX)
-        return scm_from_uint32 (scm_c_random (SCM_RSTATE (state),
-                                              (scm_t_uint32) m));
-      else
-        {
-          scm_t_uint64 upper, lower;
-          
-          upper = scm_c_random (SCM_RSTATE (state), (scm_t_uint32) (m >> 32));
-          lower = scm_c_random (SCM_RSTATE (state), SCM_T_UINT32_MAX);
-          return scm_from_uint64 ((upper << 32) | lower);
-        }
+      return scm_from_uint64 (scm_c_random64 (SCM_RSTATE (state),
+                                              (scm_t_uint64) m));
 #else
 #error "Cannot deal with this platform's unsigned long size"
 #endif
diff --git a/libguile/random.h b/libguile/random.h
index 512b7d2..2f1f0f6 100644
--- a/libguile/random.h
+++ b/libguile/random.h
@@ -67,6 +67,7 @@ SCM_API double scm_c_uniform01 (scm_t_rstate *);
 SCM_API double scm_c_normal01 (scm_t_rstate *);
 SCM_API double scm_c_exp1 (scm_t_rstate *);
 SCM_API scm_t_uint32 scm_c_random (scm_t_rstate *, scm_t_uint32 m);
+SCM_API scm_t_uint64 scm_c_random64 (scm_t_rstate *state, scm_t_uint64 m);
 SCM_API SCM scm_c_random_bignum (scm_t_rstate *, SCM m);
 
 \f
-- 
tg: (7387c23..) t/random64-fix-2 (depends on: master)

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]


> Would you be interested in doing this? We would need some test
> suites too, I think, and possibly changes to the scm_t_rng structure.
>
Sorry, I don't have the inclination to work on this ATM. Also, random
number tests are kinda hard to write -- it's random stuff, after all
:-).

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: Random numbers (again) broken on 64-bit platforms
  2010-08-01 18:44   ` Andreas Rottmann
@ 2010-08-01 19:57     ` Andy Wingo
  2010-08-01 22:06       ` No Itisnt
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Wingo @ 2010-08-01 19:57 UTC (permalink / raw)
  To: Andreas Rottmann; +Cc: Guile Development

Hi,

On Sun 01 Aug 2010 20:44, Andreas Rottmann <a.rottmann@gmx.at> writes:

> I've spotted an issue with your fix: the way 64-bit random numbers are
> generated in scm_random() is bogus;

Grr, indeed. Fix applied, thanks.

>> Would you be interested in [importing another rng]? We would need
>> some test suites too, I think, and possibly changes to the scm_t_rng
>> structure.
>>
> Sorry, I don't have the inclination to work on this ATM. Also, random
> number tests are kinda hard to write -- it's random stuff, after all
> :-).

Too bad, we could really use it, and now is the time for any needed ABI
breaks. Thanks anyway for the fix!

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Random numbers (again) broken on 64-bit platforms
  2010-08-01 19:57     ` Andy Wingo
@ 2010-08-01 22:06       ` No Itisnt
  2010-08-02  7:11         ` Andy Wingo
  0 siblings, 1 reply; 6+ messages in thread
From: No Itisnt @ 2010-08-01 22:06 UTC (permalink / raw)
  To: Andy Wingo; +Cc: Guile Development

On Sun, Aug 1, 2010 at 2:57 PM, Andy Wingo <wingo@pobox.com> wrote:
> Hi,
>
> On Sun 01 Aug 2010 20:44, Andreas Rottmann <a.rottmann@gmx.at> writes:
>
>> I've spotted an issue with your fix: the way 64-bit random numbers are
>> generated in scm_random() is bogus;
>
> Grr, indeed. Fix applied, thanks.
>
>>> Would you be interested in [importing another rng]? We would need
>>> some test suites too, I think, and possibly changes to the scm_t_rng
>>> structure.
>>>
>> Sorry, I don't have the inclination to work on this ATM. Also, random
>> number tests are kinda hard to write -- it's random stuff, after all
>> :-).
>
> Too bad, we could really use it, and now is the time for any needed ABI
> breaks. Thanks anyway for the fix!

I may have time for doing this later on but definitely not this month;
do you guys have any sort of time frame for a release?

And also: is there any way to set the lower bound of a random call?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Random numbers (again) broken on 64-bit platforms
  2010-08-01 22:06       ` No Itisnt
@ 2010-08-02  7:11         ` Andy Wingo
  0 siblings, 0 replies; 6+ messages in thread
From: Andy Wingo @ 2010-08-02  7:11 UTC (permalink / raw)
  To: No Itisnt; +Cc: Guile Development

Hi,

On Mon 02 Aug 2010 00:06, No Itisnt <theseaisinhere@gmail.com> writes:

> I may have time for doing [rng work] later on but definitely not this
> month; do you guys have any sort of time frame for a release?

Very cool!

We plan to release a 1.9.12 within a week or two, then 2.0 should be the
next one. I know we've been slipping with our self-imposed deadlines,
but it does feel like we're getting closer.

> And also: is there any way to set the lower bound of a random call?

I don't think so, no. One can of course call random with the range, and
add an offset.

Cheers,

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-08-02  7:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-26 21:01 Random numbers (again) broken on 64-bit platforms Andreas Rottmann
2010-07-27  8:52 ` Andy Wingo
2010-08-01 18:44   ` Andreas Rottmann
2010-08-01 19:57     ` Andy Wingo
2010-08-01 22:06       ` No Itisnt
2010-08-02  7:11         ` Andy Wingo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).