[Numpy-discussion] Suggested change for NaN, Infs float-int conversion
Hi,
When converting arrays from float to ints, I notice that NaNs, Infs,
and -Infs all get the minimum integer value:
flts = np.array([np.nan, np.inf, -np.inf])
flts.astype(np.int16)
array([-32768, -32768, -32768], dtype=int16)
However, setting NaNs into integer arrays gives a value of 0
ints = np.array([1])
ints.dtype
dtype('int32')
ints[0] = np.nan
ints
array([0])
whereas Inf or -Inf raise an error (as Josef pointed out recently):
ints[0] = np.inf
Traceback (most recent call last):
File ipython console, line 1, in module
OverflowError: cannot convert float infinity to long
ints[0] = -np.inf
Traceback (most recent call last):
File ipython console, line 1, in module
OverflowError: cannot convert float infinity to long
Matlab seems more consistent and sensible here:
flts = [NaN Inf -Inf];
int32(flts)
ans =
0 2147483647 -2147483648
ints = int32([1 1 1]);
ints(:) = [NaN Inf -Inf]
ints =
0 2147483647 -2147483648
Is there a route to change towards the matlab behavior? Or at least
make numpy behavior self-consistent?
Best,
Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] glibc error
David Cournapeau wrote: Hoyt Koepke wrote: SNIP Actually, I would advise using only 3.8.2. Previous versions had bugs for some core routines used by numpy (at least 3.8.0 did). I am a bit surprised that a 64 bits-built atlas would be runnable at all in a 32 bits binary - I would expect the link phase to fail if two different object formats are linked together. Linking 32 and 64 bit ELF objects together in an extension will fail on any system but OSX where the ld will happily link together anything. Since that linker also does missing symbol lookup at runtime you will see some surprising distutils bugs when you thought that the build went perfectly, i.e. scipy 0.6 would not use the fortran compiler I would tell it to use, but one extension would use gfortran instead of sage_fortran when it was available in $PATH. sage_fortran would would just inject an -m64 into the options and call gfortran. But with a few fortran objects being 32 bit some extensions in scipy would fail to import and it took me quite a while to track this one down. I haven't had time to test 0.7rc2 yet, but hopefully will do so in the next day or two. cheers, David Cheers, Michael ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy and the ACML
Hmmm. I'm at a bit of a loss to understand why it isn't working for you.
How is it failing ?-- is the output of python setup.py build simply
giving blas not found, or is it something more complex? Did you
remove the previous build directory, and the previous install
directory?
Have you changed the site.cfg in the numpy directory where setup.py
resides? -- this should be the important one -- and also in
numpy/distutils? --this shouldn't matter, but might be worth a try.
I'm no expert at debugging, but the class that's doing the work in
finding these libraries is deep in distutils:
Configuration in numpy/distutils/misc_util.py
George.
2009/1/24 Gideon Simpson simp...@math.toronto.edu:
That's not working for me. Any thoughts on how to troubleshoot it?
-gideon
On Jan 24, 2009, at 6:18 PM, George Nurser wrote:
I did manage to get it working.
I remember that both libcblas.a (or a link to it) and libacml.so had
to be in the same directory.
Also I had to comment out lines 399-400 of setup.py:
# if ('NO_ATLAS_INFO',1) in
blas_info.get('define_macros',[]):
# return None # dotblas needs ATLAS, Fortran compiled
blas will not be sufficient
In my site.cfg I have
[blas]
blas_libs = cblas, acml
library_dirs = /noc/users/agn/ext/AMD64/acml/ifort64/lib
include_dirs = /noc/users/agn/ext/AMD64/acml/ifort64/include
[lapack]
language = f77
lapack_libs = acml
library_dirs = /noc/users/agn/ext/AMD64/acml/ifort64/lib
include_dirs = /noc/users/agn/ext/AMD64/acml/ifort64/include
Both libcblas.a (or a link to it) and libacml.so are in
/noc/users/agn/ext/AMD64/acml/ifort64/lib
HTH. George.
2009/1/24 Gideon Simpson simp...@math.toronto.edu:
I've tried building CBLAS, which seems to run properly by itself, but
numpy is still having difficulty. I've got the following in my
site.cfg:
[blas_opt]
library_dirs = /usr/local/nonsystem/simpson/CBLAS/lib/LINUX:/usr/
local/
nonsystem/simpson/acml4.2.0/gfortran64/lib
include_dirs = /usr/local/nonsystem/simpson/CBLAS/include:/usr/local/
nonsystem/simpson/acml4.2.0/gfortran64/include
libraries = cblas, acml
[lapack_opt]
library_dirs = /usr/local/nonsystem/simpson/CBLAS/lib/LINUX:/usr/
local/
nonsystem/simpson/acml4.2.0/gfortran64/lib
include_dirs = /usr/local/nonsystem/simpson/CBLAS/include:/usr/local/
nonsystem/simpson/acml4.2.0/gfortran64/include
libraries = cblas, acml
I also created a symbolic link in /usr/local/nonsystem/simpson/CBLAS/
lib/LINUX, from cblas_LINUX.a to libcblas.a.
Is there an easier way to check if numpy is locating the libs other
than doing python setup.py build, and looking at the output?
-gideon
On Jan 24, 2009, at 4:05 PM, Pauli Virtanen wrote:
Sat, 24 Jan 2009 15:26:17 -0500, Gideon Simpson wrote:
Nadav-
That doesn't quite seem to work for me. I added:
[blas_opt]
library_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/
lib
include_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/
include
libraries = acml
[lapack_opt]
library_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/
lib
include_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/
include
libraries = acml
to my site.cfg with no luck. Somewhere else, people indicated that
the
ACML lacked a CBLAS which was necessary to make this work.
Yep, IIRC you needed also CBLAS. (I think I got Numpy Scipy linked
against ACML at some point, but it's been a while and I've forgotten
details...) There's a CBLAS here:
http://www.netlib.org/blas/blast-forum/cblas.tgz
So, I think you need to compile it link it with ACML, and add it
in
site.cfg with ACML libs.
--
Pauli Virtanen
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Suggested change for NaN, Infs float-int conversion
2009/1/25 Matthew Brett matthew.br...@gmail.com: When converting arrays from float to ints, I notice that NaNs, Infs, and -Infs all get the minimum integer value: flts = np.array([np.nan, np.inf, -np.inf]) flts.astype(np.int16) array([-32768, -32768, -32768], dtype=int16) However, setting NaNs into integer arrays gives a value of 0 I find this behaviour surprising too. There is a ticket at http://projects.scipy.org/scipy/numpy/ticket/980 Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Suggested change for NaN, Infs float-int conversion
On Sun, Jan 25, 2009 at 4:35 AM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
When converting arrays from float to ints, I notice that NaNs, Infs,
and -Infs all get the minimum integer value:
flts = np.array([np.nan, np.inf, -np.inf])
flts.astype(np.int16)
array([-32768, -32768, -32768], dtype=int16)
However, setting NaNs into integer arrays gives a value of 0
ints = np.array([1])
ints.dtype
dtype('int32')
ints[0] = np.nan
ints
array([0])
whereas Inf or -Inf raise an error (as Josef pointed out recently):
ints[0] = np.inf
Traceback (most recent call last):
File ipython console, line 1, in module
OverflowError: cannot convert float infinity to long
ints[0] = -np.inf
Traceback (most recent call last):
File ipython console, line 1, in module
OverflowError: cannot convert float infinity to long
Matlab seems more consistent and sensible here:
flts = [NaN Inf -Inf];
int32(flts)
ans =
0 2147483647 -2147483648
ints = int32([1 1 1]);
ints(:) = [NaN Inf -Inf]
ints =
0 2147483647 -2147483648
Is there a route to change towards the matlab behavior? Or at least
make numpy behavior self-consistent?
Best,
Matthew
As we discussed in another thread, I think that the silent conversion
of nan to zero should not be done, since it is too much a source of
errors. Users should be forced to set nans to a valid number
explicitly.
Josef
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] glibc error
Rebuilding the library against ATLAS 3.8.2 with lapack 3.1.1 seems to have done the trick. I do get one failure: == FAIL: test_umath.TestComplexFunctions.test_against_cmath -- Traceback (most recent call last): File /usr/local/nonsystem/simpson/lib/python2.5/site-packages/nose/ case.py, line 182, in runTest self.test(*self.arg) File /usr/local/nonsystem/simpson/lib/python2.5/site-packages/ numpy/core/tests/test_umath.py, line 268, in test_against_cmath assert abs(a - b) atol, %s %s: %s; cmath: %s%(fname,p,a,b) AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath: (1.31695789692-1.57079632679j) -- -gideon On Jan 25, 2009, at 5:46 AM, Michael Abshoff wrote: David Cournapeau wrote: Hoyt Koepke wrote: SNIP Actually, I would advise using only 3.8.2. Previous versions had bugs for some core routines used by numpy (at least 3.8.0 did). I am a bit surprised that a 64 bits-built atlas would be runnable at all in a 32 bits binary - I would expect the link phase to fail if two different object formats are linked together. Linking 32 and 64 bit ELF objects together in an extension will fail on any system but OSX where the ld will happily link together anything. Since that linker also does missing symbol lookup at runtime you will see some surprising distutils bugs when you thought that the build went perfectly, i.e. scipy 0.6 would not use the fortran compiler I would tell it to use, but one extension would use gfortran instead of sage_fortran when it was available in $PATH. sage_fortran would would just inject an -m64 into the options and call gfortran. But with a few fortran objects being 32 bit some extensions in scipy would fail to import and it took me quite a while to track this one down. I haven't had time to test 0.7rc2 yet, but hopefully will do so in the next day or two. cheers, David Cheers, Michael ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Having trouble installing Numpy on OS X
I ended by giving up and grabbing the binary. I'll get 2.5 for Numpy too. I did grab Xcode 2.5, which has gcc 4.0.1. I didn't feel up to manually doing a complete change to the latest gcc, at least while my needs are being met. Thanks, Nat On Jan 24, 2009, at 9:04 PM, Michael Abshoff wrote: Robert Kern wrote: On Sat, Jan 24, 2009 at 18:31, Nat Wilson njwilso...@gmail.com wrote: It throws this out. Python 2.6.1 (r261:67515, Jan 24 2009, 16:08:37) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type help, copyright, credits or license for more information. import os os.urandom(16) '\xe0;n\x8a*\xb4\x08N\x80\xef\x9b*\x06\x1b\xc4' Well, looking at the C code for random_seed(), I don't see a way for it to return NULL without having an exception set (assuming that the Python API calls aren't buggy). Except maybe the assert() call in there. When you built your Python, are you sure that -DNDEBUG was being used? Well, the gcc used to compiler Python is rather ancient and that gcc release by Apple has the reputation to be buggier than a Florida swamp in July and at least for building Sage it is blacklisted. So I would suggest updating gcc by using some more recent XCode and trying again. Cheers, Michael ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] glibc error
Sun, 25 Jan 2009 10:44:15 -0500, Gideon Simpson wrote: Rebuilding the library against ATLAS 3.8.2 with lapack 3.1.1 seems to have done the trick. I do get one failure: == FAIL: test_umath.TestComplexFunctions.test_against_cmath -- Traceback (most recent call last): File /usr/local/nonsystem/simpson/lib/python2.5/site-packages/nose/ case.py, line 182, in runTest self.test(*self.arg) File /usr/local/nonsystem/simpson/lib/python2.5/site-packages/ numpy/core/tests/test_umath.py, line 268, in test_against_cmath assert abs(a - b) atol, %s %s: %s; cmath: %s%(fname,p,a,b) AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath: (1.31695789692-1.57079632679j) Same as http://scipy.org/scipy/numpy/ticket/977, fixed in trunk. -- Pauli Virtanen ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Academic citation ?
All, What is the most up-to-date way to cite Numpy and Scipy in an academic journal ? Thanks a lot in advance P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Academic citation ?
David, Thanks, but that's only part of what I need. I could also refer to Travis O's paper in Computing in Science and Engineering, but I wondered whether there wasn't something more up-to-date. So, other answers are still welcome. P. On Jan 25, 2009, at 8:17 PM, David Warde-Farley wrote: I believe this is what you're looking for: http://www.scipy.org/Citing_SciPy On 25-Jan-09, at 6:45 PM, Pierre GM wrote: All, What is the most up-to-date way to cite Numpy and Scipy in an academic journal ? Thanks a lot in advance P. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
