[Numpy-discussion] Portable macro to get NAN, INF, positive and negative zero

Hi, For the record, I have just added the following functionalities to numpy, which may simplify some C code: - NPY_NAN/NPY_INFINITY/NPY_PZERO/NPY_NZERO: macros to get nan, inf, positive and negative zeros. Rationale: some code use NAN, _get_nan, etc... NAN is a GNU C extension, INFINITY i

Re: [Numpy-discussion] Numpy documentation: status and distribution for 1.3.0

On Wed, Mar 11, 2009 at 3:22 AM, Pauli Virtanen wrote: > Tue, 10 Mar 2009 15:27:32 +0900, David Cournapeau wrote: >> For the upcoming 1.3.0 release, I would like to distribute the (built) >> documentation in some way. But first, I need to be able to build it :) > > Yep, buildability would be a nic

Re: [Numpy-discussion] Automatic differentiation (was Re: second-order gradient)

There are several possibilities, some of them are listed on http://en.wikipedia.org/wiki/Automatic_differentiation == pycppad http://www.seanet.com/~bradbell/pycppad/index.xml pycppad is a wrapper of the C++ library CppAD ( http://www.coin-or.org/CppAD/ ) the wrapper can do up to second order de

Re: [Numpy-discussion] Numpy documentation: status and distribution for 1.3.0

Wed, 11 Mar 2009 16:20:47 +0900, David Cournapeau wrote: > On Wed, Mar 11, 2009 at 3:22 AM, Pauli Virtanen wrote: [clip] >> Sphinx 0.5.1 worksforme, and on two different Linux machines (and >> Python versions), so I doubt it's somehow specific to my setup. > > Yes, it is strange - I can make it w

Re: [Numpy-discussion] What is the logical value of nan?

Charles R Harris wrote: > It isn't 0 so it should be True. Any disagreement?... Chuck NaN is not a number equal to 0, so it should be True? NaN is not a number different from 0, so it should be False? Also see Pearu's comment. Why not raise an exception when NaN is evaluated in a boolean context

Re: [Numpy-discussion] What is the logical value of nan?

Charles R Harris wrote: > > #include > #include > > int main() { >double nan = sqrt(-1); >printf("%f\n", nan); >printf("%i\n", bool(nan)); >return 0; > } > > $ ./nan > nan > 1 > > > So resolved, it is True. Unless specified in the ISO C

Re: [Numpy-discussion] Numpy documentation: status and distribution for 1.3.0

Pauli Virtanen wrote: > > Did you check Pythonpath and egg-overriding-pythonpath issues? There's > also some magic in the autosummary extension, but it's not *too* black, > so I'd be surprised if it was behind these troubles. > I think the problem boils down to building from scratch at once.

Re: [Numpy-discussion] What is the logical value of nan?

Sturla Molden wrote: > Charles R Harris wrote: > >> #include >> #include >> >> int main() { >>double nan = sqrt(-1); >>printf("%f\n", nan); >>printf("%i\n", bool(nan)); >>return 0; >> } >> >> $ ./nan >> nan >> 1 >> >> >> So resolved,

Re: [Numpy-discussion] array 2 string

On 10 Mar 2009, at 10:33 AM, Michael S. Gilbert wrote: > On Tue, 10 Mar 2009 17:21:23 +0100, Mark Bakker wrote: >> Hello, >> >> I want to convert an array to a string. >> >> I like array2string, but it puts these annoying square brackets >> around >> the array, like >> >> [[1 2 3], >> [3 4 5]]

Re: [Numpy-discussion] What is the logical value of nan?

--- On Wed, 3/11/09, Bruce Southey wrote: > From: Bruce Southey > Subject: Re: [Numpy-discussion] What is the logical value of nan? > To: "Discussion of Numerical Python" > Date: Wednesday, March 11, 2009, 10:24 AM > > This is one link that shows the different representation of > these > numb

Re: [Numpy-discussion] What is the logical value of nan?

On Wed, Mar 11, 2009 at 8:24 AM, Bruce Southey wrote: > Sturla Molden wrote: > > Charles R Harris wrote: > > > >> #include > >> #include > >> > >> int main() { > >>double nan = sqrt(-1); > >>printf("%f\n", nan); > >>printf("%i\n", bool(nan)); > >>retu

Re: [Numpy-discussion] Portable macro to get NAN, INF, positive and negative zero

On Wed, Mar 11, 2009 at 12:43 AM, David Cournapeau < da...@ar.media.kyoto-u.ac.jp> wrote: > Hi, > >For the record, I have just added the following functionalities to > numpy, which may simplify some C code: >- NPY_NAN/NPY_INFINITY/NPY_PZERO/NPY_NZERO: macros to get nan, inf, > positive and

[Numpy-discussion] Don't call e Euler's constant.

Traditionally, Euler's constant is 0.57721 56649 01532 86060 65120 90082 40243 10421 59335 93992... see wikipedia. The constant e is sometimes called Euler's number -- shouldn't that be Napier or Bernoulli in a pc world -- but I think

Re: [Numpy-discussion] Don't call e Euler's constant.

as long as we all agree that e has a value of 2.71828 18284 59045 23536, its just a matter of semantics. the constant you reference is indicated by greek lower gamma Chris On Wed, Mar 11, 2009 at 11:39 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Traditionally, Euler's constant is

Re: [Numpy-discussion] Don't call e Euler's constant.

On Thu, Mar 12, 2009 at 12:39 AM, Charles R Harris wrote: > Traditionally, Euler's constant is 0.57721 56649 01532 86060 65120 90082 > 40243 10421 59335 93992... You're right, Euler constant is generally gamma. Euler number is not that great either (euler numbers in geometry for example), so I ju

Re: [Numpy-discussion] What is the logical value of nan?

Sturla Molden wrote: > Why not raise an exception when NaN is evaluated in a boolean > context? bool(NaN) has no obvious interpretation, so it should be > considered an error. +1 Though there is clearly a lot of legacy around this, so maybe it's best to follow C convention (sigh). Bruce Southey

Re: [Numpy-discussion] What is the logical value of nan?

On Wed, Mar 11, 2009 at 11:06 AM, Christopher Barker wrote: > Sturla Molden wrote: > > Why not raise an exception when NaN is evaluated in a boolean > > context? bool(NaN) has no obvious interpretation, so it should be > > considered an error. > > +1 > > Though there is clearly a lot of legacy aro

Re: [Numpy-discussion] What is the logical value of nan?

On Wed, Mar 11, 2009 at 11:41 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Wed, Mar 11, 2009 at 11:06 AM, Christopher Barker < > chris.bar...@noaa.gov> wrote: > >> Sturla Molden wrote: >> > Why not raise an exception when NaN is evaluated in a boolean >> > context? bool(NaN) h

[Numpy-discussion] Intel MKL on Core2 system

Hi, I noticed the following in numpy/distutils/system_info.py while trying to get numpy to build against MKL: if cpu.is_Itanium(): plt = '64' #l = 'mkl_ipf' elif cpu.is_Xeon(): plt = 'em64t' #l = 'mkl_em64t'

Re: [Numpy-discussion] What is the logical value of nan?

Charles R Harris wrote: > > Raising exceptions in ufuncs is going to take some work as the inner > loops are void functions without any means of indicating an error. > Exceptions also need to be thread safe. So I am not opposed but it is > something for the future. > I just saw David Cournapeau

Re: [Numpy-discussion] Intel MKL on Core2 system

A Wednesday 11 March 2009, Ryan May escrigué: > Hi, > > I noticed the following in numpy/distutils/system_info.py while > trying to get numpy to build against MKL: > > if cpu.is_Itanium(): > plt = '64' > #l = 'mkl_ipf' > elif cpu.is_Xeon(): >

Re: [Numpy-discussion] What is the logical value of nan?

On Wed, Mar 11, 2009 at 12:19 PM, Sturla Molden wrote: > Charles R Harris wrote: > > > > Raising exceptions in ufuncs is going to take some work as the inner > > loops are void functions without any means of indicating an error. > > Exceptions also need to be thread safe. So I am not opposed but

Re: [Numpy-discussion] Intel MKL on Core2 system

On Thu, Mar 12, 2009 at 3:15 AM, Ryan May wrote: > Hi, > > I noticed the following in numpy/distutils/system_info.py while trying to > get numpy to build against MKL: > >     if cpu.is_Itanium(): >     plt = '64' >     #l = 'mkl_ipf' >     elif cpu.is_Xeon()

Re: [Numpy-discussion] Intel MKL on Core2 system

On Wed, Mar 11, 2009 at 1:41 PM, David Cournapeau wrote: > On Thu, Mar 12, 2009 at 3:15 AM, Ryan May wrote: > > Hi, > > > > I noticed the following in numpy/distutils/system_info.py while trying to > > get numpy to build against MKL: > > > > if cpu.is_Itanium(): > > pl

Re: [Numpy-discussion] Intel MKL on Core2 system

On Wed, Mar 11, 2009 at 1:34 PM, Francesc Alted wrote: > A Wednesday 11 March 2009, Ryan May escrigué: > > Hi, > > > > I noticed the following in numpy/distutils/system_info.py while > > trying to get numpy to build against MKL: > > > > if cpu.is_Itanium(): > > plt = '

Re: [Numpy-discussion] Intel MKL on Core2 system

A Wednesday 11 March 2009, Ryan May escrigué: > You know, I knew this sounded familiar. If you regularly build > against MKL, can you send me your site.cfg. I've had a lot more > success getting the build to work using the autodetection than the > blas_opt and lapack_opt sections. Since the aut

Re: [Numpy-discussion] Intel MKL on Core2 system

On Wed, Mar 11, 2009 at 2:20 PM, Francesc Alted wrote: > A Wednesday 11 March 2009, Ryan May escrigué: > > You know, I knew this sounded familiar. If you regularly build > > against MKL, can you send me your site.cfg. I've had a lot more > > success getting the build to work using the autodetec

Re: [Numpy-discussion] What is the logical value of nan?

On Thu, Mar 12, 2009 at 3:36 AM, Charles R Harris wrote: > > > On Wed, Mar 11, 2009 at 12:19 PM, Sturla Molden wrote: >> >> Charles R Harris wrote: >> > >> > Raising exceptions in ufuncs is going to take some work as the inner >> > loops are void functions without any means of indicating an error

[Numpy-discussion] Error building SciPy SVN with NumPy SVN

Hi, This is what I'm getting when I try to build scipy HEAD: building library "superlu_src" sources building library "arpack" sources building library "sc_c_misc" sources building library "sc_cephes" sources building library "sc_mach" sources building library "sc_toms" sources building library "s

Re: [Numpy-discussion] Error building SciPy SVN with NumPy SVN

On Thu, Mar 12, 2009 at 4:52 AM, Ryan May wrote: > Hi, > > This is what I'm getting when I try to build scipy HEAD: > > building library "superlu_src" sources > building library "arpack" sources > building library "sc_c_misc" sources > building library "sc_cephes" sources > building library "sc_ma

[Numpy-discussion] Implementing hashing protocol for dtypes

Hi, I was looking at #936, to implement correctly the hashing protocol for dtypes. Am I right to believe that tp_hash should recursively descend fields for compound dtypes, and the hash value should depend on the size/ndim/typenum/byteorder for each "atomic" dtype + fields name (and titles) ? Cont

Re: [Numpy-discussion] Error building SciPy SVN with NumPy SVN

On Wed, Mar 11, 2009 at 3:00 PM, David Cournapeau wrote: > On Thu, Mar 12, 2009 at 4:52 AM, Ryan May wrote: > > Hi, > > > > This is what I'm getting when I try to build scipy HEAD: > > > > building library "superlu_src" sources > > building library "arpack" sources > > building library "sc_c_misc

[Numpy-discussion] code performanceon windows (32 and/or 64 bit) using SWIG: C++ compiler MS vs.cygwin

Hi, I was wondering if people could comment on which compiler produces faster code, MS-VS2003 or cygwin g++ ? I use Python 2.5 and SWIG. I have C/C++ routines for large (maybe 10MB, 100MB or even >1GB (on XP 64bit)) data processing. I'm not talking about BLAS or anything like that just for-lo

Re: [Numpy-discussion] Implementing hashing protocol for dtypes

On Wed, Mar 11, 2009 at 15:06, David Cournapeau wrote: > Hi, > > I was looking at #936, to implement correctly the hashing protocol for > dtypes. Am I right to believe that tp_hash should recursively descend > fields for compound dtypes, and the hash value should depend on the > size/ndim/typenum/

Re: [Numpy-discussion] code performanceon windows (32 and/or 64 bit) using SWIG: C++ compiler MS vs.cygwin

i don't know the correct answer... but i imagine it would be fairly easy to compile a couple of representative scipts on each compiler and compare their performance. On Wed, Mar 11, 2009 at 4:29 PM, Sebastian Haase wrote: > Hi, > I was wondering if people could comment on which compiler produces

Re: [Numpy-discussion] A module for homogeneous transformation matrices, Euler angles and quaternions

Does anyone know any good internet references for defining and using homogeneous transformation matrices, especially oblique projection matrices? I'm writing some tests for transformations.py and I'm getting unexpected results, quite possibly because I'm making naive assumptions about how to use pr

Re: [Numpy-discussion] A module for homogeneous transformation matrices, Euler angles and quaternions

there has already been a port of the robotics toolbox for matlab into python which is built on numpy: http://code.google.com/p/robotics-toolbox-python/ which contains all the function you are describing. Chris On Wed, Mar 4, 2009 at 6:10 PM, Gareth Elston < gareth.elston.fl...@googlemail.com>

[Numpy-discussion] is it a bug?

Hi, import numpy as np x = np.arange(30) x.shape = (2,3,5) idx = np.array([0,1]) e = x[0,idx,:] print e.shape #> return (2,5). ok. idx = np.array([0,1]) e = x[0,:,idx] print e.shape #-> return (2,3). I think the right answer should be (3,2). Is # it a bug here? my num

Re: [Numpy-discussion] is it a bug?

You lost me on > x = np.arange(30) > x.shape = (2,3,5) For me I get: In [2]: x = np.arange(30) In [3]: x.shape Out[3]: (30,) which is what I would expect. Perhaps I missed something? Jon. On Wed, Mar 11, 2009 at 8:55 PM, shuwj5...@163.com wrote: > Hi, > > import numpy as np > x = np.arange(

Re: [Numpy-discussion] is it a bug?

On Wed, Mar 11, 2009 at 21:51, Jonathan Taylor wrote: > You lost me on >> x = np.arange(30) >> x.shape = (2,3,5) > > For me I get: > In [2]: x = np.arange(30) > > In [3]: x.shape > Out[3]: (30,) > > which is what I would expect.   Perhaps I missed something? He is reshaping x by assigning (2,3,5)

Re: [Numpy-discussion] is it a bug?

On Wed, Mar 11, 2009 at 9:51 PM, Jonathan Taylor wrote: > You lost me on >> x = np.arange(30) >> x.shape = (2,3,5) > > For me I get: > In [2]: x = np.arange(30) > > In [3]: x.shape > Out[3]: (30,) > > which is what I would expect.   Perhaps I missed something? > > Jon. > - Show quoted text - > On

Re: [Numpy-discussion] is it a bug?

On Wed, Mar 11, 2009 at 19:55, shuwj5...@163.com wrote: > Hi, > > import numpy as np > x = np.arange(30) > x.shape = (2,3,5) > > idx = np.array([0,1]) > e = x[0,idx,:] > print e.shape > #> return (2,5). ok. > > idx = np.array([0,1]) > e = x[0,:,idx] > print e.shape > > #-> return (2,3). I

Re: [Numpy-discussion] is it a bug?

On Wed, Mar 11, 2009 at 10:02 PM, Robert Kern wrote: > On Wed, Mar 11, 2009 at 19:55, shuwj5...@163.com wrote: >> Hi, >> >> import numpy as np >> x = np.arange(30) >> x.shape = (2,3,5) >> >> idx = np.array([0,1]) >> e = x[0,idx,:] >> print e.shape >> #> return (2,5). ok. >> >> idx = np.array(

Re: [Numpy-discussion] code performanceon windows (32 and/or 64 bit) using SWIG: C++ compiler MS vs.cygwin

On Thu, Mar 12, 2009 at 5:29 AM, Sebastian Haase wrote: > Hi, > I was wondering if people could comment on which compiler produces faster > code, > MS-VS2003 or cygwin g++ ? > I use Python 2.5 and SWIG.  I have C/C++ routines for large (maybe > 10MB, 100MB or even >1GB (on XP 64bit)) data process

Re: [Numpy-discussion] code performanceon windows (32 and/or 64 bit) using SWIG: C++ compiler MS vs.cygwin

On Thu, Mar 12, 2009 at 12:38 PM, David Cournapeau wrote: > and you can't > cross compile easily. Of course, this applies to numpy/scipy - you can cross compile your own extensions relatively easily (at least I don't see why it would not be possible). David __

Re: [Numpy-discussion] Implementing hashing protocol for dtypes

On Thu, Mar 12, 2009 at 5:36 AM, Robert Kern wrote: > On Wed, Mar 11, 2009 at 15:06, David Cournapeau wrote: >> Hi, >> >> I was looking at #936, to implement correctly the hashing protocol for >> dtypes. Am I right to believe that tp_hash should recursively descend >> fields for compound dtypes,

Re: [Numpy-discussion] Implementing hashing protocol for dtypes

On Wed, Mar 11, 2009 at 22:49, David Cournapeau wrote: > On Thu, Mar 12, 2009 at 5:36 AM, Robert Kern wrote: >> On Wed, Mar 11, 2009 at 15:06, David Cournapeau wrote: >>> Hi, >>> >>> I was looking at #936, to implement correctly the hashing protocol for >>> dtypes. Am I right to believe that tp_

Re: [Numpy-discussion] is it a bug?

2009/3/12 Robert Kern : >> idx = np.array([0,1]) >> e = x[0,:,idx] >> print e.shape >> >> #-> return (2,3). I think the right answer should be (3,2). Is >> #       it a bug here? my numpy version is 1.2.1. > > It's certainly weird, but it's working as designed. Fancy indexing via > arrays is a