On the GAP support list we reached the conclusion that it is due to endianness. (I can reproduce this behaviour on a MacOSX PPC machine) It can also be noted that apparently GAP uses an old Mersenne Twister code, whereas it is known to be buggy in exactly this way (endianness!), and fixes exist...
If there is a pseudorandom numbers guru that can fix the GAP code in GAPROOT/src/integer.c quickly, it would be great, but it could be a while otherwise... Using an external pseudorandom generator does not seem to be feasible, as it's not going to be used by GAP internals without much hacking. Dima On Sep 7, 1:09 am, Mike Hansen <mhan...@gmail.com> wrote: > On Mon, Sep 6, 2010 at 4:55 AM, Simon King <simon.k...@nuigalway.ie> wrote: > > The remaining problem concerns the random generator of GAP. It behaves > > differently on T2 than on any other machine that I have access to. > > My guess is that it is due to the endianness of the machine. For > example, check out this snippet from sage.misc.randstate: > > # GAP's random number generator initialization > # (in integer.c, in FuncInitRandomMT) takes its > # seed as a string, then converts this string into > # an array of 32-bit integers just by casting the > # pointer. Thus, the result depends on the > # endianness of the machine. As a workaround, we > # swap the bytes in the string ourselves, so that > # GAP always gets the same array of integers. > > If you're using GAP from withing Sage, you might just want to do > current_randstate().set_seed_gap() to initialize the random number > generators. Note that both of the following are reset: > > prev_mersenne_seed = gap.Reset(gap.GlobalMersenneTwister, > mersenne_seed) > prev_classic_seed = gap.Reset(gap.GlobalRandomSource, > classic_seed) > > --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
