[PYTHONMAC-SIG] MacPython v1.5b3 / NumPy bugs?

[Rob Managan]

Tom Bridgman reported that RandomArray.py broke under 1.5
>>
>> 2) I reported this next problem in the NumPy that came with v1.5a4 and it
>> seems to still be there.  However, I suspect this is a NumPy specific
>> problem.  By just importing the RandomArray module, I get:
>>
>> >>>>> import RandomArray
>> >>Traceback (innermost last):
>> >>  File "<stdin>", line 1, in ?
>> >>  File "Macintosh HD:Development:Python v1.5:Python
>> >>1.5b3:Extensions:NumPy:NumPy:RandomArray.py", line 12, in ?
>> >>    seed()
>> >>  File "Macintosh HD:Development:Python v1.5:Python
>> >>1.5b3:Extensions:NumPy:NumPy:RandomArray.py", line 8, in seed
>> >>    x = int(t)
>> >>OverflowError: float too large to convert
>> >>>>>
>
>This is because MacPython time.time() can return a float that is bigger than
>can be represented in a signed int (but it could have been represented in a
>32bit unsigned int, had Python had such a type).
>
>>
Jack Jensen commented on this and my earlier fix:
>
>Yes, I noticed that. All the other fixes I tried (clamping the x value to 31
>bits, or by trickery converting the longint to the 32bit signed
>representation
>that corresponds to the unsigned value) have resulted in strange crashes
>inside ranlib.set_seeds(). It turns out that the library that underlies the
>ranlib module handles errors by calling printf() and then exit(); not very
>nice on the Mac because you never get to see the output:-(
>
>Apparently the numbers you give to ranlib.set_seeds() have to satisfy certain
>criteria, what are these criteria, matrix-folks? If I know these I can
>come up
>with two randomish numbers that match them for the mac...
>--

Having played with the URNG module some I relooked at this. My latest
attempt to fix this came up with this for the file RandomArray.py

def seed(x=0,y=0):
	if x == y == 0:
		import time
		t = time.time()
		import os
		if os.name == 'mac':
			t = t*1.e-3
		x = int(t)
		y = int((t-int(t))*1000000)
	ranlib.set_seeds(x,y)

seed()

The reason for singling out the macos is that most systems give you a time
that changes on roughly microsecond intervals so that there is a fractional
part to the time. MacPython is set to return integer seconds since 1904. So
there is no fractional part and y is always 0 under the old code. Therefore
I decided to take the time returned and divide by 1 thousand to provide a
fractional part. This also makes sure that t can be cast to an int (it is
at most a factor of 2 too large!). This should give reasonable values for x
and y. However, this is not adequate for modules with independant random
number generators (URNG, RNG) since the seed only changes once a second.
See Below. Busby claims that you arn't likely to get a 'bad' seed.

Fred Fritsch made this point about my work on URNG:
I would be more concerned by the coarseness of the clock--if two calls
are made within the same second they will get the same seed, defeating
the desire for independent streams.  (Not a problem for jobs restarted
at a later time, however.)

Lee Busby then added:
I think Fred's comment about coarseness of the clock is the only
possible worry.  You could handle that by arranging not to call mixranf
more than once per second, I suppose.  Or maybe there is some other
system call whose return value is somehow dependent on the
"instantaneous" state of the machine?  Be creative.  There aren't any
good or bad seeds.  Each one is just an entry point onto the specific
permutation of length 2**46 defined by a given multiplier.  (There
*are* many bad multipliers; in fact, practically all of them, but
that's a different question.)

*-*-*-*-*-*-*-*-*-*-**-*-*-*-*-*-*-*-*-*-*-
Rob Managan       mailto://managan@llnl.gov
LLNL                      ph:  510-423-0903
P.O. Box 808, L-183       FAX: 510-423-5804
Livermore, CA  94551-0808




_______________
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
_______________