numpy-discussion — Discussion list for all users of Numerical Python

Re: Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Sasha <nd...@ma...>]

On 1/27/06, Travis Oliphant <oli...@ee...> wrote:

> Show an example of using it in a file before you include the numpy
> header.  Because that *should* work.  I know, I just tested it a few
> days ago...

I've tried to put just two lines in "test.c":

#define PY_ARRAY_TYPES_PREFIX XYZ_
#include <numpy/arrayobject.h>

and compile it with

$ gcc -I$NUMPYINCLUDE -c test.c

Where NUMPYINCLUDE points to the location of numpy/arrayobject.h

I get the following errors:
In file included from test.c:2:
numpy-0.9.4/lib/python2.3/site-packages/numpy/core/include/numpy/arrayobjec=
t.h:699:
error: syntax error before " XYZ_intp"
numpy-0.9.4/lib/python2.3/site-packages/numpy/core/include/numpy/arrayobjec=
t.h:699:
warning: data definition has  no type or storage class
numpy-0.9.4/lib/python2.3/site-packages/numpy/core/include/numpy/arrayobjec=
t.h:700:
error: syntax error before " XYZ_uintp"
...  <many screenfulls more> ...

Re: [Numpy-discussion] UnsignedInt32

[Travis O. <oli...@ee...>]

Sasha wrote:

> Numeric has both UInt32 and UnsignedInt32 defined, but Numpy only has
>UInt32.  Is it intentional or an oversight?
>
>  
>
It's actually there, it's just not in the __all__ list of oldnumeric

Try:

from numpy.core.oldnumeric import UnsignedInt32

-Travis

Re: [Numpy-discussion] UnsignedInt32

[Travis O. <oli...@ee...>]

Sasha wrote:

> Numeric has both UInt32 and UnsignedInt32 defined, but Numpy only has
>UInt32.  Is it intentional or an oversight?
>
>  
>
an oversight.

-Travis

[Numpy-discussion] UnsignedInt32

[Sasha <nd...@ma...>]

 Numeric has both UInt32 and UnsignedInt32 defined, but Numpy only has
UInt32.  Is it intentional or an oversight?

Thanks.

Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Sasha <nd...@ma...>]

Numpy-discussion list rejected an attachment. Here are a few relevant
lines from the log:

In file included from numpy/core/src/multiarraymodule.c:65:
numpy/core/src/arrayobject.c: In function `PyArray_FromDimsAndDataAndDescr'=
:
numpy/core/src/arrayobject.c:766: `intp' undeclared (first use in this func=
tion)
numpy/core/src/arrayobject.c:766: parse error before ')' token
In file included from numpy/core/src/multiarraymodule.c:65:
numpy/core/src/arrayobject.c: At top level:
numpy/core/src/arrayobject.c:822: parse error before "intp"
numpy/core/src/arrayobject.c:822: warning: function declaration isn't
a prototype
numpy/core/src/arrayobject.c: In function `PyArray_Scalar':
numpy/core/src/arrayobject.c:841: `Bool' undeclared (first use in this func=
tion)
numpy/core/src/arrayobject.c:841: parse error before ')' token
numpy/core/src/arrayobject.c:841: parse error before ')' token
numpy/core/src/arrayobject.c:841: warning: left-hand operand of comma
expression has no effect

---------- Forwarded message ----------
From: Sasha <nd...@ma...>
Date: Jan 27, 2006 12:33 PM
Subject: Re: [Numpy-discussion] Numpy does not compile with
PY_ARRAY_TYPES_PREFIX
To: Andrew Straw <str...@as...>, numpy-discussion
<num...@li...>


I've just updated to svn r2006.  Regular build works fine, but

$ CFLAGS=3D-DPY_ARRAY_TYPES_PREFIX=3DPyArray_NS_ python setup.py build

produced the attached log.  Note that I am not compiling any
extention, just regular numpy.



On 1/27/06, Andrew Straw <str...@as...> wrote:
> Sasha wrote:
>
> >I have attempted to compile RPy (see http://rpy.sourceforge.net/) with
> >numpy and found that both R and numpy headers define Int32:
> >
> >.../numpy/core/include/numpy/arrayobject.h:304: conflicting types for `I=
nt32'
> >.../lib/R/include/R_ext/Random.h:57: previous declaration of `Int32'
> >
> >I have tried to fix the problem by setting PY_ARRAY_TYPES_PREFIX as foll=
ows:
> >
> >$ CFLAGS=3D-DPY_ARRAY_TYPES_PREFIX=3DPyArray_NS_ python setup.py build
> >
> >This resulted in compile error in almost every Numpy source file.
> >
> >Am I using PY_ARRAY_TYPES_PREFIX correctly? If not, what is the
> >recommended way to solve name conflicts involving Numpy typoes?
> >
> >
>
> David Cooke informed me some time ago that the #include
> "numpy/arrayobject.h" line should go _after_ the other #includes. It's
> worked for me well enough ever since, although it seems rather fragile.
> Otherwise I'm not having the same issue with current svn. There was an
> issue with release 0.9.4 for C++ code, anyway.
>
> Cheers!
> Andrew
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Fwd: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Alexander B. <ale...@gm...>]

Numpy-discussion list rejected an attachment. Here are a few relevant
lines from the log:

In file included from numpy/core/src/multiarraymodule.c:65:
numpy/core/src/arrayobject.c: In function `PyArray_FromDimsAndDataAndDescr'=
:
numpy/core/src/arrayobject.c:766: `intp' undeclared (first use in this func=
tion)
numpy/core/src/arrayobject.c:766: parse error before ')' token
In file included from numpy/core/src/multiarraymodule.c:65:
numpy/core/src/arrayobject.c: At top level:
numpy/core/src/arrayobject.c:822: parse error before "intp"
numpy/core/src/arrayobject.c:822: warning: function declaration isn't
a prototype
numpy/core/src/arrayobject.c: In function `PyArray_Scalar':
numpy/core/src/arrayobject.c:841: `Bool' undeclared (first use in this func=
tion)
numpy/core/src/arrayobject.c:841: parse error before ')' token
numpy/core/src/arrayobject.c:841: parse error before ')' token
numpy/core/src/arrayobject.c:841: warning: left-hand operand of comma
expression has no effect


---------- Forwarded message ----------
From: Sasha <nd...@ma...>
Date: Jan 27, 2006 12:33 PM
Subject: Re: [Numpy-discussion] Numpy does not compile with
PY_ARRAY_TYPES_PREFIX
To: Andrew Straw <str...@as...>, numpy-discussion
<num...@li...>


I've just updated to svn r2006.  Regular build works fine, but

$ CFLAGS=3D-DPY_ARRAY_TYPES_PREFIX=3DPyArray_NS_ python setup.py build

produced the attached log.  Note that I am not compiling any
extention, just regular numpy.



On 1/27/06, Andrew Straw <str...@as...> wrote:
> Sasha wrote:
>
> >I have attempted to compile RPy (see http://rpy.sourceforge.net/) with
> >numpy and found that both R and numpy headers define Int32:
> >
> >.../numpy/core/include/numpy/arrayobject.h:304: conflicting types for `I=
nt32'
> >.../lib/R/include/R_ext/Random.h:57: previous declaration of `Int32'
> >
> >I have tried to fix the problem by setting PY_ARRAY_TYPES_PREFIX as foll=
ows:
> >
> >$ CFLAGS=3D-DPY_ARRAY_TYPES_PREFIX=3DPyArray_NS_ python setup.py build
> >
> >This resulted in compile error in almost every Numpy source file.
> >
> >Am I using PY_ARRAY_TYPES_PREFIX correctly? If not, what is the
> >recommended way to solve name conflicts involving Numpy typoes?
> >
> >
>
> David Cooke informed me some time ago that the #include
> "numpy/arrayobject.h" line should go _after_ the other #includes. It's
> worked for me well enough ever since, although it seems rather fragile.
> Otherwise I'm not having the same issue with current svn. There was an
> issue with release 0.9.4 for C++ code, anyway.
>
> Cheers!
> Andrew
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Andrew S. <str...@as...>]

Sasha wrote:

>I have attempted to compile RPy (see http://rpy.sourceforge.net/) with
>numpy and found that both R and numpy headers define Int32:
>
>.../numpy/core/include/numpy/arrayobject.h:304: conflicting types for `Int32'
>.../lib/R/include/R_ext/Random.h:57: previous declaration of `Int32'
>
>I have tried to fix the problem by setting PY_ARRAY_TYPES_PREFIX as follows:
>
>$ CFLAGS=-DPY_ARRAY_TYPES_PREFIX=PyArray_NS_ python setup.py build
>
>This resulted in compile error in almost every Numpy source file.
>
>Am I using PY_ARRAY_TYPES_PREFIX correctly? If not, what is the
>recommended way to solve name conflicts involving Numpy typoes?
>  
>

David Cooke informed me some time ago that the #include
"numpy/arrayobject.h" line should go _after_ the other #includes. It's
worked for me well enough ever since, although it seems rather fragile.
Otherwise I'm not having the same issue with current svn. There was an
issue with release 0.9.4 for C++ code, anyway.

Cheers!
Andrew

[Numpy-discussion] Numpy does not compile with PY_ARRAY_TYPES_PREFIX

[Sasha <nd...@ma...>]

I have attempted to compile RPy (see http://rpy.sourceforge.net/) with
numpy and found that both R and numpy headers define Int32:

.../numpy/core/include/numpy/arrayobject.h:304: conflicting types for `Int3=
2'
.../lib/R/include/R_ext/Random.h:57: previous declaration of `Int32'

I have tried to fix the problem by setting PY_ARRAY_TYPES_PREFIX as follows=
:

$ CFLAGS=3D-DPY_ARRAY_TYPES_PREFIX=3DPyArray_NS_ python setup.py build

This resulted in compile error in almost every Numpy source file.

Am I using PY_ARRAY_TYPES_PREFIX correctly? If not, what is the
recommended way to solve name conflicts involving Numpy typoes?

Thanks.

[Numpy-discussion] Upcasting rules in numpy

[Francesc A. <fa...@ca...>]

Hi,

I don't know if the next behaviour in NumPy is intended or not:

In [22]: (numpy.zeros((2,1), dtype=3D"int8")*3.).dtype.type
Out[22]: <type 'float32_arrtype'>

while numarray and Numeric gives:

In [36]: (numarray.zeros((2,1), type=3D"Int8")*3.).type()
Out[36]: Float64

In [37]: (Numeric.zeros((2,1), typecode=3D"b")*3.).typecode()
Out[37]: 'd'

Would not be float64 a more sensible default for numpy as well?

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"

Re: [Numpy-discussion] installation under other than .../site-packages

[George N. <ag...@no...>]

On 25 Jan 2006, at 20:09, Humufr wrote:

> This solution is the one I'm using. Unfortunatly it's not working  
> good with scipy. I tried to install scipy in my own directory and  
> everythong seems to work like a charm but the lapack link is bad. I  
> tried everything write in the wiki to install your own BLAS/LAPACK  
> library but scipy want tu use the one of the system who have a  
> problem. I'm trying to find a solution but until I found it numpy/ 
> scipy is not an option.
>

This wasn't obvious to me either.

To use your own blas/lapck in scipy, you need to put a site.cfg file  
in the distutils directory of your numpy installation.

So if you installed numpy with --home=$HOME
it should produce a distutils directory at $HOME/lib/python/numpy/ 
distutils or $HOME/lib64/python/numpy/distutils

If you want to build scipy with the same site.cfg as you used to  
build numpy, then, assuming the root source numpy directory is $PYSRC/ 
numpy

cp $PYSRC/numpy/numpy/distutils/site.cfg $HOME/lib[64]/python/numpy/ 
distutils

Hope this helps.

George.

[Numpy-discussion] Re: Weird (wrong?) real fft 2d behavior

[Andrew J. <a.h...@gm...>]

 > On Wed, 25 Jan 2006, Andrew Jaffe wrote:
 >
 >> Andrew Jaffe wrote:
 >>> If I start with what I thought was an appropriate (n, n/2+1) complex
 >>> matrix which should have a real inverse fft, and then take its real 
fft,
 >>> I don't get back the original matrix.
 >>>
 >>> Note the presence of very small but nonzero reals in the final matrix,
 >
 > That's just roundoff.
 >
 >>> and the fact that the 2d and 4th rows are duplicates. This seems to 
be a
 >>>  mistake somewhere.
 >>>
 >>> Or am I just misunderstanding/misremembering something about 2d 
real ffts?
 >
 > It looks wrong to me, and I think I wrote those functions.  I get the 
same
 > results in Numeric.  I'll try to look into the problem.
 >
 >> and I should point out that
 >> 	delta_rp = N.dft.real_fft2d(delta_kp)
 >> is 'allclose' to the original delta_r (which leads me to believe that I
 >> may indeed be misunderstanding something).
 >
 > "Stable" does not neccessarily imply "correct".

Indeed! And more to the point, it's actually the case that "delta_kp" 
doesn't actually have the requisite 16 (non-small) real degrees of 
freedom -- so it can't really be right.

Andrew

[Numpy-discussion] Re: Weird (wrong?) real fft 2d behavior

[Andrew J. <a.h...@gm...>]

Dear Warren,
 >
 > On Wed, 25 Jan 2006, Andrew Jaffe wrote:
 >
 >> Andrew Jaffe wrote:
 >>> If I start with what I thought was an appropriate (n, n/2+1) complex
 >>> matrix which should have a real inverse fft, and then take its real 
fft,
 >>> I don't get back the original matrix.
 >>>
 >>> Note the presence of very small but nonzero reals in the final matrix,
 >
 > That's just roundoff.
 >
 >>> and the fact that the 2d and 4th rows are duplicates. This seems to 
be a
 >>>  mistake somewhere.
 >>>
 >>> Or am I just misunderstanding/misremembering something about 2d 
real ffts?
 >
 > It looks wrong to me, and I think I wrote those functions.  I get the 
same
 > results in Numeric.  I'll try to look into the problem.
 >
 >> and I should point out that
 >> 	delta_rp = N.dft.real_fft2d(delta_kp)
 >> is 'allclose' to the original delta_r (which leads me to believe that I
 >> may indeed be misunderstanding something).
 >
 > "Stable" does not neccessarily imply "correct".

Indeed! And more to the point, it's actually the case that "delta_kp" 
doesn't actually have the requisite 16 (non-small) real degrees of 
freedom -- so it can't really be right.

Andrew

Re: [Numpy-discussion] installation under other than .../site-packages

[Humufr <hu...@ya...>]

This solution is the one I'm using. Unfortunatly it's not working good 
with scipy. I tried to install scipy in my own directory and everythong 
seems to work like a charm but the lapack link is bad. I tried 
everything write in the wiki to install your own BLAS/LAPACK library but 
scipy want tu use the one of the system who have a problem. I'm trying 
to find a solution but until I found it numpy/scipy is not an option.

N.

David M. Cooke wrote:
> On Jan 25, 2006, at 07:52 , Jose Borreguero wrote:
>
>> My system administrator has told me numpy has to be installed  under 
>> /local , instead of under /usr/lib/pythonx.x/site-packages.  Can 
>> anybody point to me what modifications do I have to make for  this. ? 
>> Also, will other libraries that call numpy work after I  install ?
>> jose
>
> First, to install it under /usr/local, run setup.py like this:
>
> $ python setup.py --prefix=/usr/local
>
> This will put numpy into /usr/local/lib/pythonx.x/site-packages.
>
> Next, check if you can import it. If you can't, it's likely that that  
> path is not in your sys.path. Probably the easiest way to make it  
> available for _all_ users is to ask your sysadmin to put a file  
> called 'usrlocal.pth' in /usr/lib/pythonx.x/site-packages with these  
> contents
>
> import site; site.addsitedir('/usr/local/lib/pythonx.x')
>
> (hopefully he'd be amiable to adding only one file :) This adds /usr/ 
> local/lib/pythonx.x to the sys.path *and* processes any .pth in it.  
> You can get fancier and add
>
> import os, site; site.addsitedir(os.path.expanduser('~/lib/pythonx.x'))
>
> which would also look in user directories.
>
> Failing that, you'd set the environment variable PYTHONPATH to  
> include the right directory. This way, .pth files won't be processed.  
> You could add a sitecustomize.py with the appropriate 'import site;  
> site.addsitedir(...)'. The addsitedir is what processes .pth files.
>
> These are all generic instructions, not specific to numpy. numpy  
> itself doesn't need .pth files, but there are other packages that do  
> (Numeric, PIL, pygtk, amongst others), so it's handy to have.
>

Re: [Numpy-discussion] Re: Weird (wrong?) real fft 2d behavior

[Warren F. <fo...@sl...>]

On Wed, 25 Jan 2006, Andrew Jaffe wrote:

> Andrew Jaffe wrote:
> > If I start with what I thought was an appropriate (n, n/2+1) complex
> > matrix which should have a real inverse fft, and then take its real fft,
> > I don't get back the original matrix.
> >
> > Note the presence of very small but nonzero reals in the final matrix,

That's just roundoff.

> > and the fact that the 2d and 4th rows are duplicates. This seems to be a
> >  mistake somewhere.
> >
> > Or am I just misunderstanding/misremembering something about 2d real ffts?

It looks wrong to me, and I think I wrote those functions.  I get the same
results in Numeric.  I'll try to look into the problem.

> and I should point out that
> 	delta_rp = N.dft.real_fft2d(delta_kp)
> is 'allclose' to the original delta_r (which leads me to believe that I
> may indeed be misunderstanding something).

"Stable" does not neccessarily imply "correct".

w

>
> Andrew
>
>
> >
> > Andrew
> >
> >
> > In [41]: dims=(4,4)
> >
> > In [42]: delta_k = aniso.dft_realizn(dims, P)
> >          #### this just makes an appropriate matrix
> >
> > In [43]: delta_k
> > Out[43]:
> > array([[-0.    +0.j    ,  0.5904+0.0429j,  0.9063+0.j    ],
> >        [-0.221 +0.j    ,  0.4169+0.4602j, -0.6909+0.j    ],
> >        [ 0.9059+0.j    , -0.8037+0.2604j,  1.835 +0.j    ],
> >        [ 1.7436+0.j    , -0.2382+0.221j , -0.0607+0.j    ]])
> >        #### 16 real numbers
> >
> > In [44]: delta_r = N.dft.inverse_real_fft2d(delta_k)
> >
> > In [45]: delta_r
> > Out[45]:
> > array([[ 0.2718, -0.0956,  0.2805,  0.1505],
> >        [ 0.0297, -0.0533, -0.259 ,  0.0561],
> >        [ 0.1308, -0.2096,  0.2288, -0.3041],
> >        [ 0.0895,  0.1105, -0.3188, -0.1076]])
> >
> > In [46]: delta_kp = N.dft.real_fft2d(delta_r)
> >
> > In [47]: delta_kp
> > Out[47]:
> > array([[ 0.     +0.00e+00j,  0.5904 +4.2938e-02j,  0.9063 +0.0000e+00j],
> >        [ 0.7613 +5.5511e-17j,0.4169 +4.6020e-01j, -0.3758 +5.5511e-17j],
> >        [ 0.9059 +0.0000e+00j,-0.8037+2.6038e-01j, 1.835  +0.0000e+00j],
> >        [ 0.7613 -5.5511e-17j,-0.2382+2.2099e-01j,-0.3758-5.5511e-17j]])
> >
> > In [48]: N.__version__
> > Out[48]: '0.9.5.1982'
> > ------------------------
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] Possible typo in numpy.dft.fft docstring

[Travis O. <oli...@ie...>]

Rudolph van der Merwe wrote:

>Part of the fft function's docstring currently reads:
>
>"...
>
>The packing of the result is "standard": If A = fft(a, n), then A[0]
>    contains the zero-frequency term, A[1:n/2+1] contains the
>    positive-frequency terms, and A[n/2+1:] contains the negative-frequency
>    terms, in order of decreasingly negative frequency. So for an 8-point
>    transform, the frequencies of the result are [ 0, 1, 2, 3, 4, -3, -2, -1].
>
>..."
>
>Shouldn't the frequency arrangement in the last sentence be
>
>[0, 1, 2, 3, -4, -3, -2, -1]
>
>  
>
>and not
>
>[ 0, 1, 2, 3, 4, -3, -2, -1]
>  
>
Of course these are completely equivalent because of the periodicity of 
the DFT, but the statement A[1:n/2+1] contains the positive-frequency 
terms is consistent with what's given.   It think the issue is that this 
statement is true for both even add odd values of n, while writing it 
the way you propose would require different statements for odd and even 
terms.

I do typically interpret the middle frequency as "negative" though (as 
does fftshift).

-Travis

[Numpy-discussion] Possible typo in numpy.dft.fft docstring

[Rudolph v. d. M. <rud...@gm...>]

Part of the fft function's docstring currently reads:

"...

The packing of the result is "standard": If A =3D fft(a, n), then A[0]
    contains the zero-frequency term, A[1:n/2+1] contains the
    positive-frequency terms, and A[n/2+1:] contains the negative-frequency
    terms, in order of decreasingly negative frequency. So for an 8-point
    transform, the frequencies of the result are [ 0, 1, 2, 3, 4, -3, -2, -=
1].

..."

Shouldn't the frequency arrangement in the last sentence be

[0, 1, 2, 3, -4, -3, -2, -1]

and not

[ 0, 1, 2, 3, 4, -3, -2, -1]

?

--
Rudolph van der Merwe

Re: [Numpy-discussion] some question on new dtype

[Travis O. <oli...@ee...>]

Travis Oliphant wrote:

> I know what the problem is.    Too many places, I did not account for 
> the fact that a VOID array could in-fact have OBJECT sub-fields.  
> Thus, any special processing on OBJECT subfields to handle reference 
> counts must also be done on possible sub-fields. 
> This may take a while to fix properly....  If anyone has any ideas, 
> let me know.
> -Travis

For now, I've added a hasobject member to the dtype object structure and 
filled it in properly on construction.  Then, I disable construction of 
such arrays so that we don't get the segfault.  I think this is too 
harsh.  I think at some point we can offer some support for them (there 
may be a few methods and functions that don't work and we can give an 
error on those particular ones rather than not allow their construction).

-Travis

Re: [Numpy-discussion] some question on new dtype

[Travis O. <oli...@ee...>]

N. Volbers wrote:

> Thanks for your quick answer!
>
>>> 1) When reading the sample chapter from Travis' documentation, I 
>>> noticed that there is also a type 'object' with the character 'O'. 
>>> So I kind of hoped that it would be possible to have arbitrary 
>>> python objects in an array. However, when I add a fourth "column" of 
>>> type 'O', then numpy will mem-fault. Is this not allowed or is this 
>>> some implementation bug?
>>
>>
>>
>> It's a bug if it seg-faults, that should be allowed.  Please post 
>> your code so we can track it down.
>
>
> Attachment 1 contains  a four-liner that reproduces the segfault. But 
> maybe there is something wrong on my system, because I also get the 
> following message when importing numpy: "import linalg -> failed: 
> /usr/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so: 
> undefined symbol: s_wsfe"
>
> I removed numpy, checked out from SVN, re-installed and the error is 
> still there.
>
> Regarding my question about changing dtypes: Your sample code...
>
>> new = dict(a.dtype.fields) # get a writeable dictionary.
>> new['<newname>'] = new['<oldname>']
>> del new['<oldname>']
>> del new[-1]  # get rid of the special ordering entry
>> a.dtype = dtype(new)
>>
> ... is short and exactly what I asked for.
>
>>>
>>> 3) When I use two identical entries in the names part of the dtype, 
>>> I get the message 'TypeError: expected a readable buffer object'. It 
>>> makes sense that it is not allowed to have two identical names, but 
>>> I think the error message should be worded more descriptive.
>>
>>
>>
>> Yeah, we ought to check for this.  Could you post your code that 
>> raises this error.
>
>
> It seems you have already fixed the error message for the case in 
> which you have two identical names for dtype entries. Man, you are 
> fast! But... ;-) you forgot the situation described in my second code 
> attachment, which is the following situation:
>
> >>> dtype = numpy.dtype( [('name', 'S30'), ('name', 'i2')] )
> >>> a = numpy.zeros( (4,), dtype=dtype)
>
> This works, but leads to silly results. The last instance of 'name' 
> determines the field type, i.e. a[0] = ('Niklas', 1) is invalid, while 
> a[0] = (1,1) is valid!
>
>>> 4) In the example above, printing any of the strings via 'print' 
>>> will yield the characters and then the characters up to the string 
>>> size filled up with \x00, e.g.
>>>
>>>  u'Bill\x00\x00\x00\x00\x00\x00\x00.... (30 characters total)'
>>>
>>> Why doesn't 'prin't terminate the output when the first \x00 is 
>>> reached ?
>>
>>
>
> Thanks for your bug-fix. Unicode display works now.
>
>
> Best regards,
>
> Niklas Volbers.
>
>------------------------------------------------------------------------
>
>import numpy
>dtype = numpy.dtype( [('object', 'O')] )
>a = numpy.zeros( (4,), dtype=dtype)
>print a
>  
>
>  
>
I know what the problem is.    Too many places, I did not account for 
the fact that a VOID array could in-fact have OBJECT sub-fields.  Thus, 
any special processing on OBJECT subfields to handle reference counts 
must also be done on possible sub-fields.  

This may take a while to fix properly....  If anyone has any ideas, let 
me know. 

-Travis

[Numpy-discussion] iterating over array items

[N. V. <mit...@we...>]

Hello everyone,

the attached source code contains iterations on elements in a numpy 
array: The first one (for row in a) works, the second one (for item in 
row) does not. The non-numpy equivalent with lists and tuples works however.

Best regards,

Niklas Volbers.

Re: [Numpy-discussion] some question on new dtype

[N. V. <mit...@we...>]

Thanks for your quick answer!

>> 1) When reading the sample chapter from Travis' documentation, I 
>> noticed that there is also a type 'object' with the character 'O'. So 
>> I kind of hoped that it would be possible to have arbitrary python 
>> objects in an array. However, when I add a fourth "column" of type 
>> 'O', then numpy will mem-fault. Is this not allowed or is this some 
>> implementation bug?
>
>
> It's a bug if it seg-faults, that should be allowed.  Please post your 
> code so we can track it down.

Attachment 1 contains  a four-liner that reproduces the segfault. But 
maybe there is something wrong on my system, because I also get the 
following message when importing numpy: "import linalg -> failed: 
/usr/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so: undefined 
symbol: s_wsfe"

I removed numpy, checked out from SVN, re-installed and the error is 
still there.

Regarding my question about changing dtypes: Your sample code...

> new = dict(a.dtype.fields) # get a writeable dictionary.
> new['<newname>'] = new['<oldname>']
> del new['<oldname>']
> del new[-1]  # get rid of the special ordering entry
> a.dtype = dtype(new)
>
... is short and exactly what I asked for.

>>
>> 3) When I use two identical entries in the names part of the dtype, I 
>> get the message 'TypeError: expected a readable buffer object'. It 
>> makes sense that it is not allowed to have two identical names, but I 
>> think the error message should be worded more descriptive.
>
>
> Yeah, we ought to check for this.  Could you post your code that 
> raises this error.

It seems you have already fixed the error message for the case in which 
you have two identical names for dtype entries. Man, you are fast! 
But... ;-) you forgot the situation described in my second code 
attachment, which is the following situation:

 >>> dtype = numpy.dtype( [('name', 'S30'), ('name', 'i2')] )
 >>> a = numpy.zeros( (4,), dtype=dtype)

This works, but leads to silly results. The last instance of 'name' 
determines the field type, i.e. a[0] = ('Niklas', 1) is invalid, while 
a[0] = (1,1) is valid!

>> 4) In the example above, printing any of the strings via 'print' will 
>> yield the characters and then the characters up to the string size 
>> filled up with \x00, e.g.
>>
>>  u'Bill\x00\x00\x00\x00\x00\x00\x00.... (30 characters total)'
>>
>> Why doesn't 'prin't terminate the output when the first \x00 is reached ?
>

Thanks for your bug-fix. Unicode display works now.


Best regards,

Niklas Volbers.

Re: [Numpy-discussion] [Newbie] Matching a subarray

[Travis O. <oli...@ee...>]

Dani Marti wrote:

>Hi all,
>
>I have a long 1D boolean array. I'd like to know where a certain
>'sub'array (like, e.g., ([1,1,1,1,1,1])) occurs in the array. That is, I
>want the index of the first occurrence of a subarray in an array,
>avoiding the use of explicit loop structures to carry out the search.
>  
>

Actually, I don't think that's a trivial question.  You could look at 
the data as a string and use the find method of the string.

Or you could use (int8) correlation.  The largest value of the 
correlation should be the index where it matches.

-Travis

Re: [Numpy-discussion] installation under other than .../site-packages

[David M. C. <co...@ph...>]

On Jan 25, 2006, at 07:52 , Jose Borreguero wrote:

> My system administrator has told me numpy has to be installed  
> under /local , instead of under /usr/lib/pythonx.x/site-packages.  
> Can anybody point to me what modifications do I have to make for  
> this. ? Also, will other libraries that call numpy work after I  
> install ?
> jose

First, to install it under /usr/local, run setup.py like this:

$ python setup.py --prefix=/usr/local

This will put numpy into /usr/local/lib/pythonx.x/site-packages.

Next, check if you can import it. If you can't, it's likely that that  
path is not in your sys.path. Probably the easiest way to make it  
available for _all_ users is to ask your sysadmin to put a file  
called 'usrlocal.pth' in /usr/lib/pythonx.x/site-packages with these  
contents

import site; site.addsitedir('/usr/local/lib/pythonx.x')

(hopefully he'd be amiable to adding only one file :) This adds /usr/ 
local/lib/pythonx.x to the sys.path *and* processes any .pth in it.  
You can get fancier and add

import os, site; site.addsitedir(os.path.expanduser('~/lib/pythonx.x'))

which would also look in user directories.

Failing that, you'd set the environment variable PYTHONPATH to  
include the right directory. This way, .pth files won't be processed.  
You could add a sitecustomize.py with the appropriate 'import site;  
site.addsitedir(...)'. The addsitedir is what processes .pth files.

These are all generic instructions, not specific to numpy. numpy  
itself doesn't need .pth files, but there are other packages that do  
(Numeric, PIL, pygtk, amongst others), so it's handy to have.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|co...@ph...

Re: [Numpy-discussion] installation under other than .../site-packages

[Travis O. <oli...@ie...>]

Jose Borreguero wrote:

> My system administrator has told me numpy has to be installed under 
> /local , instead of under /usr/lib/pythonx.x/site-packages. Can 
> anybody point to me what modifications do I have to make for this. ? 
> Also, will other libraries that call numpy work after I install ?
> jose
>
As long as you change the sys.path list and insert the location where 
numpy is installed, it should work and other packages should find it.   
I think modification of the PYTHONPATH environment variable will do this 
for all scripts as well.

-Travis

[Numpy-discussion] error in beta random variate generation

[Christopher F. <ch...@tr...>]

There appears to be a bug in the beta random number
generator in numpy. A 2-parameter beta distribution
has an expected value of a/(a+b). Hence, a beta(1,1)
should have an expected value of 0.5 (since it is the
equivalent of a uniform random variable on [0,1]).
However, numpy gives the following:

In [6]: from numpy.random import beta

In [7]: from numpy import *

In [8]: mean(beta(1,1,size=10000))
Out[8]: 0.33397400928538834

--
Christopher J. Fonnesbeck

Population Ecologist, Marine Mammal Section
Fish & Wildlife Research Institute (FWC)
St. Petersburg, FL

Adjunct Assistant Professor
Warnell School of Forest Resources
University of Georgia
Athens, GA

T: 727.235.5570
E: chris at trichech.us

[Numpy-discussion] [Newbie] Matching a subarray

[Dani M. <dan...@up...>]

Hi all,

I have a long 1D boolean array. I'd like to know where a certain
'sub'array (like, e.g., ([1,1,1,1,1,1])) occurs in the array. That is, I
want the index of the first occurrence of a subarray in an array,
avoiding the use of explicit loop structures to carry out the search.

I am sorry if this happens to be a trivial question, but I was not able
to find the answer from the documentation.

Thanks a lot,

dani