Arnd Baecker wrote:
That is great news! I also get this on my 64 Bit machine!
Wonderful...
Just in case it has fallen through the cracks: Concerning the check_integer problem:
def check_integer(self): from scipy import stats a = stats.randint.rvs(1,20,size=(3,4)) fname = tempfile.mktemp('.dat') io.write_array(fname,a) b = io.read_array(fname,atype=N.Int) assert_array_equal(a,b) os.remove(fname)
Executing this line by line shows the error for b = io.read_array(fname,atype=N.Int)
Doing b = io.read_array(fname) reads in the array, but it gives floats.
However, b = io.read_array(fname,atype=N.Int32) works.
If this is the intended behaviour (also on 32Bit), the unit test should be changed accordingly...
What is the type of 'a' (i.e. stats.randint.rvs(1,20,size=(3,4)) ) on your platform? This does look like a problem of type mismatch on 64-bit that we can handle much better now. It looks like randint is returning 32-bit numbers, but N.Int is 'l' which on your 64-bit platform is a 64-bit integer. This would definitely be the problem. I've changed the test...
BTW: wouldn't io be much better in newcore instead of newscipy? It seems like something of very common use.
Yes, that is a strong possibility. The only issue is that scipy arrays can now be directly written to files (using the tofile method) and read from files (using fromfile function). The scipy.io code essentially re-does all of that (but not for the new flexible arrays). It would need to be adapted before I think it would be a good fit. -Travis