Re: [Numpy-discussion] Problems with long
On Jan 26, 2008 12:39 AM, Tom Johnson [EMAIL PROTECTED] wrote: Hi, I'm having some troubles with long. from numpy import log log(8463186938969424928L) 43.5822574833 log(10454852688145851272L) type 'exceptions.AttributeError': 'long' object has no attribute 'log' Numpy uses the standard C functions, so can't represent very large integers exactly. However, given the precision of the log function, it might be reasonable to truncate the digits and write the Python long as a float before conversion. That's what Python does. In [6]: import math In [7]: math.log(10454852688145851272L) Out[7]: 43.793597916587672 In [8]: float(10454852688145851272L) Out[8]: 1.045485268814585e+19 Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numscons 0.3.0 release
On Jan 26, 2008 1:05 AM, David Cournapeau [EMAIL PROTECTED] wrote: Charles R Harris wrote: On Jan 25, 2008 11:30 PM, David Cournapeau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Charles R Harris wrote: snip It varies with the Linux distro. The usual convention (LSB, I think) uses /usr/local/lib64, but Debian and distros derived from Debian use /usr/local/lib instead. That's how it was the last time I checked, anyway. I don't know what Gentoo and all the others do. Grrr, that's annoying. Do you know any resource which has clear explanation on that ? (reading LSB documents do not appeal much to me, and I would only do that as a last resort). The Debian folks will tell you that they did it right and everyone else screwed up horribly O_o. Well, as arrogant as debian folks may be, they are almost always right :) I will take a look at the debian maintainer guide, then. Anyway, it looks like they put the 32 bit stuff in lib32, so if a distro has a lib32, then you can figure the 64 bit stuff is in lib. Those are the only two variations I know of. What 64 bit windows does, I have no idea. Windows and 64 bits, here is something which scares me. I also have to see how solaris does it. But anyway, since vmware can run 64 bits OS on my 32 bits linux, things should be easier. ISTR that Solaris does it the Debian way. I wouldn't put money on it without checking, though. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numscons 0.3.0 release
On Jan 25, 2008 11:30 PM, David Cournapeau [EMAIL PROTECTED] wrote: Charles R Harris wrote: snip It varies with the Linux distro. The usual convention (LSB, I think) uses /usr/local/lib64, but Debian and distros derived from Debian use /usr/local/lib instead. That's how it was the last time I checked, anyway. I don't know what Gentoo and all the others do. Grrr, that's annoying. Do you know any resource which has clear explanation on that ? (reading LSB documents do not appeal much to me, and I would only do that as a last resort). The Debian folks will tell you that they did it right and everyone else screwed up horribly O_o. Anyway, it looks like they put the 32 bit stuff in lib32, so if a distro has a lib32, then you can figure the 64 bit stuff is in lib. Those are the only two variations I know of. What 64 bit windows does, I have no idea. 32-bit (compat) libraries 64-bit (native) libraries Fedora Core /lib/, /usr/lib/ /lib64/, /usr/lib64/ Debian /lib32/, /usr/lib32/ /lib/, /usr/lib/ Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numscons 0.3.0 release
Charles R Harris wrote: On Jan 25, 2008 11:30 PM, David Cournapeau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Charles R Harris wrote: snip It varies with the Linux distro. The usual convention (LSB, I think) uses /usr/local/lib64, but Debian and distros derived from Debian use /usr/local/lib instead. That's how it was the last time I checked, anyway. I don't know what Gentoo and all the others do. Grrr, that's annoying. Do you know any resource which has clear explanation on that ? (reading LSB documents do not appeal much to me, and I would only do that as a last resort). The Debian folks will tell you that they did it right and everyone else screwed up horribly O_o. Well, as arrogant as debian folks may be, they are almost always right :) I will take a look at the debian maintainer guide, then. Anyway, it looks like they put the 32 bit stuff in lib32, so if a distro has a lib32, then you can figure the 64 bit stuff is in lib. Those are the only two variations I know of. What 64 bit windows does, I have no idea. Windows and 64 bits, here is something which scares me. I also have to see how solaris does it. But anyway, since vmware can run 64 bits OS on my 32 bits linux, things should be easier. Thanks for the info, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems with long
Tom Johnson wrote: Hi, I'm having some troubles with long. from numpy import log log(8463186938969424928L) 43.5822574833 log(10454852688145851272L) type 'exceptions.AttributeError': 'long' object has no attribute 'log' The problem is that the latter long integer is too big to fit into an int64 (long long) and so it converts it to an object array. The default behavior of log on object arrays is to look for a method on each element of the array called log and call that. Your best bet is to convert to double before calling log log(float(10454852688145851272L)) -Travis O. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] segfault problem with numpy and pickle
to, 2008-01-24 kello 13:18 -0700, David Bolme kirjoitti: A am having some trouble when pickling numpy arrays. Basically I use one python script to create the array and then pickle it. When I load the pickled array using a different python script it appears to load fine. When I try to perform a matrix multiply on the array with a vector (using dot) python crashes with a segmentation violation. The array contains 64bit floating point numbers and has a shape of (47, 16384) and the vector has a shape of (16384,1). Other shapes I have tested also have this problem. A workaround is to create a new array that is initialized with the data from the first. For example: This probably is the same problem as bug #551, http://projects.scipy.org/scipy/numpy/ticket/551 Summary: The cause is not known at this point, but so far appears to have something to do with SSE2 optimized ATLAS library. Are you using Atlas library on Mac OS X, and if yes, which version? Do you have SSE2 optimizations enabled? What happens if you try to use a non-SSE2-optimized Atlas, eg. by pointing LD_LIBRARY_PATH (I'm not sure this works on Mac, but I assume so...) to non-optimized Atlas libraries: LD_LIBRARY_PATH=/usr/lib/atlas python crasher.py -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] segfault problem with numpy and pickle
I think you are right. This does seem to be the same bug as 551. I will try a non optimized ATLAS to see if that helps. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] major bug in fromstring, ascii mode
In the course of trying to parse ascii times, I ran into a puzzling bug.
Sometimes it works as expected:
In [31]:npy.fromstring('23:19:01', dtype=int, sep=':')
Out[31]:array([23, 19, 1])
But sometimes it doesn't:
In [32]:npy.fromstring('23:09:01', dtype=int, sep=':')
Out[32]:array([23, 0])
In [33]:npy.__version__
Out[33]:'1.0.5.dev4742'
In [34]:npy.fromstring('23:09:01', dtype=int, sep=':', count=3)
Out[34]:array([23, 0, 16])
In [35]:npy.fromstring('23 09 01', dtype=int, sep=' ', count=3)
Out[35]:array([23, 0, 9])
In [36]:npy.fromstring('23 09 01', dtype=int, sep=' ')
Out[36]:array([23, 0, 9, 1])
Maybe it is a problem specific to int conversion; examples that fail
with int work with float:
In [37]:npy.fromstring('23 09 01', dtype=float, sep=' ')
Out[37]:array([ 23., 9., 1.])
In [38]:npy.fromstring('23:09:01', dtype=float, sep=':')
Out[38]:array([ 23., 9., 1.])
Eric
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
