On 09/ 6/10 09:17 PM, Simon King wrote:
Hi Dima!
On 6 Sep., 19:47, Dima Pasechnik<dimp...@gmail.com> wrote:
On the GAP support list we reached the conclusion that it is due to
endianness.
Is the endianness really different on sage.math and t2.math?
Yes. x86 are little endian. SPARC is big endian.
I can try the code if you want on my OpenSolaris system. That uses an Intel Xeon
processor, so is little endian.
This is actually a little ironic: At Sage Days XX in San Diego, a
couple of years ago, both Martin Albrecht and Michael Abshoff said
that probably my wrapper for C-MeatAxe (which is part of the package)
would not work in different endianness, due to my seemingly flawed way
of pickling matrix data.
Now, it turns out that this is no problem. I can read MeatAxe matrices
on t2.math that I saved on sage.math.
On sage.math:
sage: from pGroupCohomology.mtx import MTX
sage: M = MTX(27,[[randint(0,26) for _ in range(5)] for _ in
range(5)])
sage: print M
[17 9 14 0 10]
[15 14 19 3 19]
[16 3 19 23 8]
[ 7 24 3 2 24]
[19 3 20 1 2]
sage: save(M, 'matrixtest')
On t2:
sage: M = load('matrixtest.sobj')
sage: print M
[17 9 14 0 10]
[15 14 19 3 19]
[16 3 19 23 8]
[ 7 24 3 2 24]
[19 3 20 1 2]
But endianness strikes back in an unexpected way...
I used to work on a 24-bit machine. Either the most (or least), my memory fails
me, was in the middle!
I would be very weary of any random number generator that claims to be a good
source of random numbers if the output differs by platform or compilation mode.
Someone would need to check the numbers for randomless on these different systems.
There are a number of statistical tests for pseudo random number generators -
but I expect you know that anyway.
Cheers,
Simon
Dave
--
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
