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

Re: [Numpy-discussion] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

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

A Dijous 12 Gener 2006 11:52, kon...@la... va escriure:
> On 05.01.2006, at 23:03, Francesc Altet wrote:
> > Accordingly, my vote is also:
> >
> > +1 numpy-discussion
>
> +1 from me as well. Same reason.

The outcome of the discussion is that it has been created a new list
called num...@li... for discussing the new NumPy package.
Apparently, the numpy-discussion will still be the place for
discussing Numeric/numarray issues.

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] Re: [SciPy-user] [SciPy-dev] Long live to numpy (and its list as well)

[<kon...@la...>]

On 05.01.2006, at 23:03, Francesc Altet wrote:

> Accordingly, my vote is also:
>
> +1 numpy-discussion

+1 from me as well. Same reason.

Konrad.
--
------------------------------------------------------------------------ 
-------
Konrad Hinsen
Laboratoire Leon Brillouin (CEA-CNRS), CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: kh...@ce...
------------------------------------------------------------------------ 
-------

[Numpy-discussion] Who will use numpy.ma?

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

MA is intended to be a drop-in replacement for Numeric arrays that can
explicitely handle missing observations.  With the recent improvements
to the array object in NumPy, the MA library has fallen behind.  There
are more than 50 methods in the ndarray object that are not present in
ma.array.

I would like to hear from people who work with datasets with missing
observations? Do you use MA? Do you think with the support for nan's
and replaceable mathematical operations, should missing observations
be handled in numpy using special values rather than an array of
masks?

Thanks.

-- sasha

Re: [Numpy-discussion] Conversion of heterogeneous arrays in numpy<-->numarray

[Perry G. <pe...@st...>]

I think it would be a good thing, but right now we are more focused on =20=

seeing what is involved in porting some of our libraries first. I'll =20
try to find out how much work it would be though.

Perry

On Jan 10, 2006, at 1:58 PM, Francesc Altet wrote:

> Hi,
>
> Is there any plan to provide a conversion between recarrays in numpy
> and numarray?. For the moment it does not seem to work:
>
> In [83]: r=3Dnumarray.records.array([(1,11,'a'),(2,22,'b')], =20
> formats=3D'u1,f4,a1')
>
> In [84]: a=3Dnumpy.array(r, dtype=3D'u1,f4,a1')
>
> In [85]: numarray.records.array(a)
> =
-----------------------------------------------------------------------=20=

> ----
> exceptions.ValueError                                Traceback (most =20=

> recent
> call last)
>
> /tmp/<console>
>
> /usr/lib/python2.3/site-packages/numarray-1.5.0-py2.3-linux-i686.egg/=20=

> numarray/records.py
> in array(buffer, formats, shape, names, byteorder, aligned)
>     406                     byteorder=3Dbyteorder, aligned=3Daligned)
>     407     else:
> --> 408         raise ValueError("Unknown input type")
>     409
>     410 def _RecGetType(name):
>
> ValueError: Unknown input type
>
> In [86]: numpy.array(r)
> Out[86]: array([0Aa, =B0Ab], dtype=3D(void,6))
>
> However, if one specifies the format in for the numarray-->numpy it
> does seem to work:
>
> In [87]: numpy.array(r, dtype=3D'u1,f4,a1')
> Out[87]: array([(1, 11.0, 'a'), (2, 22.0, 'b')], dtype=3D(void,6))
>
> But not in the sense numpy-->numarray:
>
> In [88]: numarray.records.array(a, formats=3D'u1,f4,a1')
> =
-----------------------------------------------------------------------=20=

> ----
> exceptions.ValueError                                Traceback (most =20=

> recent
> call last)
>
> /tmp/<console>
>
> /usr/lib/python2.3/site-packages/numarray-1.5.0-py2.3-linux-i686.egg/=20=

> numarray/records.py
> in array(buffer, formats, shape, names, byteorder, aligned)
>     406                     byteorder=3Dbyteorder, aligned=3Daligned)
>     407     else:
> --> 408         raise ValueError("Unknown input type")
>     409
>     410 def _RecGetType(name):
>
> ValueError: Unknown input type
>
> Having this would be great for supporting heterogeneous arrays in
> PyTables.
>
> Regards,
>
> --=20
>> 0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
> V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
>  "-"
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
=20
> 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://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

[Numpy-discussion] Conversion of heterogeneous arrays in numpy<-->numarray

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

Hi,

Is there any plan to provide a conversion between recarrays in numpy
and numarray?. For the moment it does not seem to work:

In [83]: r=3Dnumarray.records.array([(1,11,'a'),(2,22,'b')], formats=3D'u1,=
f4,a1')

In [84]: a=3Dnumpy.array(r, dtype=3D'u1,f4,a1')

In [85]: numarray.records.array(a)
=2D------------------------------------------------------------------------=
=2D-
exceptions.ValueError                                Traceback (most recent=
=20
call last)

/tmp/<console>

/usr/lib/python2.3/site-packages/numarray-1.5.0-py2.3-linux-i686.egg/numarr=
ay/records.py=20
in array(buffer, formats, shape, names, byteorder, aligned)
    406                     byteorder=3Dbyteorder, aligned=3Daligned)
    407     else:
=2D-> 408         raise ValueError("Unknown input type")
    409
    410 def _RecGetType(name):

ValueError: Unknown input type

In [86]: numpy.array(r)
Out[86]: array([0Aa, =B0Ab], dtype=3D(void,6))

However, if one specifies the format in for the numarray-->numpy it
does seem to work:

In [87]: numpy.array(r, dtype=3D'u1,f4,a1')
Out[87]: array([(1, 11.0, 'a'), (2, 22.0, 'b')], dtype=3D(void,6))

But not in the sense numpy-->numarray:

In [88]: numarray.records.array(a, formats=3D'u1,f4,a1')
=2D------------------------------------------------------------------------=
=2D-
exceptions.ValueError                                Traceback (most recent=
=20
call last)

/tmp/<console>

/usr/lib/python2.3/site-packages/numarray-1.5.0-py2.3-linux-i686.egg/numarr=
ay/records.py=20
in array(buffer, formats, shape, names, byteorder, aligned)
    406                     byteorder=3Dbyteorder, aligned=3Daligned)
    407     else:
=2D-> 408         raise ValueError("Unknown input type")
    409
    410 def _RecGetType(name):

ValueError: Unknown input type

Having this would be great for supporting heterogeneous arrays in
PyTables.

Regards,

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

Re: [Numpy-discussion] initialise an array

[Tim H. <tim...@co...>]

Humufr wrote:

> Hello,
>
> I have a function like this:
>
> def test(x,xall=None):
>     if xall == None: xall =x
>
> I obtain this error message when I'm doing this with numpy (I don't 
> have this problem with numarray and Numeric).
>
> ValueError: The truth value of an array with more than one element is 
> ambiguous. Use a.any() or a.all
>
> How can I do something similar? Do I have to use the function suggest 
> in the error message? The function is something inside a long script 
> with a lot of condition similar to this one so it's why I ask if it's 
> normal to not have the special None parameter take in count.

Use 'is', for example:

    if xall is None: xall = x

-tim

>
> Thanks,
>
> N.
>
>
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>

[Numpy-discussion] initialise an array

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

Hello,

I have a function like this:

def test(x,xall=None):
     if xall == None: xall =x
 
I obtain this error message when I'm doing this with numpy (I don't have 
this problem with numarray and Numeric).

ValueError: The truth value of an array with more than one element is 
ambiguous. Use a.any() or a.all

How can I do something similar? Do I have to use the function suggest in 
the error message? The function is something inside a long script with a 
lot of condition similar to this one so it's why I ask if it's normal to 
not have the special None parameter take in count.

Thanks,

N.

Re: [SciPy-dev] [Numpy-discussion] Re: How to handle a[...] in numpy?

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

A Dilluns 09 Gener 2006 21:36, Alexander Belopolsky va escriure:
> On 1/9/06, Francesc Altet <fa...@ca...> wrote:
> > However, the original aim of the "..." (ellipsis) operator is [taken
> > for the numarray manual]:
> >
> > """
> > One final way of slicing arrays is with the keyword `...' This keyword
> > is somewhat complicated. It stands for "however many `:' I need
>
> This is precisely my motivation for making a[...] the same as a[()] for
> zero rank a.  In this case "however many" is zero. In other words, a[...]
> is a short-hand
> for a[(slice(None),)*len(a.shape)]. Specifically, if a.shape =3D (),
> then a[...] =3D a[()].

I see your point. I was just proposing a way to return different
objects for [...] and [()] that were consistent with higher
dimensionality. So if one has a non-0 dimensional array (tensor)
called a, then a[...] will return exactly the same object, so the same
should be done with 0-d arrays (tensors) IMO. Now, the () index in 0d
objects is just a way to substitute integer indexes in higher
dimensional objects, and should return a scalar type, as it does
in the later case.

I recognize that this is my interpretation of the facts and chances
are that I'm completely wrong with this. Anyway, sometimes I tend to
think that this kind of issues are not very important, but from time
to time they will certainly bit us, so perhaps this discussion would
be useful for the community in the future.

> > I don't know for old versions of Numeric, but my impression is that
> > the ellipsis meaning is clearly stated above. In fact, in a
> > 4-dimensional array, say a, a[...] should be equivalent to a[:,:,:,:]
> > and this does not necessarily implies a copy.
>
> I am not proposing any change for rank > 0 arrays, nor for the new numpy
> scalars.  For a =3D array(0), why would you want a[...] have different
> type from a[()]?
> If as for rank-4 array a, a[...] should be equivalent to a[:,:,:,:]
> why would you expect
> a[...] for a rank-0 a be different from a[()]?

=46or the reasons mentioned above: just to be consistent with higher
dimensions (although as it turns out to be, the interpretation of
"consistency" is different between both of us) and to have two
different objects returned from [...] and [()].

> PS: There seems to be a terminological difficulty discussing this type
> of things. You call an array that takes 4 indices a 4-dimensional
> array, but in algebra 4-dimensional vector is a sequence of 4 numbers
> (array of shape (4,)).  An object that is indexed by 4 numbers is a
> tensor of rank 4 (array of shape (n1, n2, n3, n4)).

That's true. However, in the Numeric/numarray/numpy literature I think
N-dimensional arrays are generally understood as tensors of rank-N.
=46rom the scipy manual ("Object Essentials" chapter):

""" NumPy provides two fundamental objects: an N-dimensional array
object (ndarray) and... """

But anyway, I think that, provided the context is clearly defined, the
probability of being misled is (hopefully) quite low.

Regards,

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

Re: [SciPy-dev] [Numpy-discussion] Re: How to handle a[...] in numpy?

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

Sorry, forgot to attach.

On 1/9/06, Sasha <nd...@ma...> wrote:
> Attached patch implements indexing of zero rank arrays:
>
> >>> x =3D array(42)
> >>> x[...]
> 42
> >>> x[()]
> 42
> >>> x[()].dtype
> <type 'int32_arrtype'>
> >>> type(x[()])
> <type 'int32_arrtype'>
>
> Ellipsis and empty tuple are the only two valid indices.
>
> So far there was only one +1 vote for the feature (from Francesc
> Altet, who also suggested  that x[()] be allowed).  Does anyone object
> to this feature?
>
> I have also proposed to support x[...,newaxis] (see comment by
> sdementen at http://www.scipy.org/wikis/numdesign/).  I will add this
> feature if there is interest.
>
> Finally, if we make x[...] valid for rank-0 arrays, should x[...] =3D
> value be allowed as well? I think it should, applying the principle of
> least surprized.  An additional consideration is that rank-0 arrays
> are unhashable, but there is no obvious way to change their values.
>
> The following example show that rank-0 arrays are in fact mutable (in
> a non-obvious way):
>
> >>> x =3D array(1)
> >>> x.shape=3D(1,); x[0] =3D 42; x.shape=3D()
> >>> x
>
> Please comment on the following proposals:
>
> 1. x[...]
> 2. x[...] =3D value
> 3. x[..., newaxis]
>
>
> -- sasha
>

Re: [SciPy-dev] [Numpy-discussion] Re: How to handle a[...] in numpy?

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

Sorry forgot to attach.

On 1/9/06, Sasha <nd...@ma...> wrote:
> Attached patch implements indexing of zero rank arrays:
>
> >>> x =3D array(42)
> >>> x[...]
> 42
> >>> x[()]
> 42
> >>> x[()].dtype
> <type 'int32_arrtype'>
> >>> type(x[()])
> <type 'int32_arrtype'>
>
> Ellipsis and empty tuple are the only two valid indices.
>
> So far there was only one +1 vote for the feature (from Francesc
> Altet, who also suggested  that x[()] be allowed).  Does anyone object
> to this feature?
>
> I have also proposed to support x[...,newaxis] (see comment by
> sdementen at http://www.scipy.org/wikis/numdesign/).  I will add this
> feature if there is interest.
>
> Finally, if we make x[...] valid for rank-0 arrays, should x[...] =3D
> value be allowed as well? I think it should, applying the principle of
> least surprized.  An additional consideration is that rank-0 arrays
> are unhashable, but there is no obvious way to change their values.
>
> The following example show that rank-0 arrays are in fact mutable (in
> a non-obvious way):
>
> >>> x =3D array(1)
> >>> x.shape=3D(1,); x[0] =3D 42; x.shape=3D()
> >>> x
>
> Please comment on the following proposals:
>
> 1. x[...]
> 2. x[...] =3D value
> 3. x[..., newaxis]
>
>
> -- sasha
>

Re: [SciPy-dev] [Numpy-discussion] Re: How to handle a[...] in numpy?

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

Attached patch implements indexing of zero rank arrays:

>>> x =3D array(42)
>>> x[...]
42
>>> x[()]
42
>>> x[()].dtype
<type 'int32_arrtype'>
>>> type(x[()])
<type 'int32_arrtype'>

Ellipsis and empty tuple are the only two valid indices.

So far there was only one +1 vote for the feature (from Francesc
Altet, who also suggested  that x[()] be allowed).  Does anyone object
to this feature?

I have also proposed to support x[...,newaxis] (see comment by
sdementen at http://www.scipy.org/wikis/numdesign/).  I will add this
feature if there is interest.

Finally, if we make x[...] valid for rank-0 arrays, should x[...] =3D
value be allowed as well? I think it should, applying the principle of
least surprized.  An additional consideration is that rank-0 arrays
are unhashable, but there is no obvious way to change their values.

The following example show that rank-0 arrays are in fact mutable (in
a non-obvious way):

>>> x =3D array(1)
>>> x.shape=3D(1,); x[0] =3D 42; x.shape=3D()
>>> x

Please comment on the following proposals:

1. x[...]
2. x[...] =3D value
3. x[..., newaxis]


-- sasha

Re: [SciPy-dev] [Numpy-discussion] Re: How to handle a[...] in numpy?

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

On 1/9/06, Francesc Altet <fa...@ca...> wrote:
> However, the original aim of the "..." (ellipsis) operator is [taken
> for the numarray manual]:
>
> """
> One final way of slicing arrays is with the keyword `...' This keyword
> is somewhat complicated. It stands for "however many `:' I need

This is precisely my motivation for making a[...] the same as a[()] for zer=
o
rank a.  In this case "however many" is zero. In other words, a[...]
is a short-hand
for a[(slice(None),)*len(a.shape)]. Specifically, if a.shape =3D (),
then a[...] =3D a[()].

> I don't know for old versions of Numeric, but my impression is that
> the ellipsis meaning is clearly stated above. In fact, in a
> 4-dimensional array, say a, a[...] should be equivalent to a[:,:,:,:]
> and this does not necessarily implies a copy.

I am not proposing any change for rank > 0 arrays, nor for the new numpy
scalars.  For a =3D array(0), why would you want a[...] have different
type from a[()]?
If as for rank-4 array a, a[...] should be equivalent to a[:,:,:,:]
why would you expect
a[...] for a rank-0 a be different from a[()]?

-- sasha

PS: There seems to be a terminological difficulty discussing this type
of things. You call an array that takes 4 indices a 4-dimensional
array, but in algebra 4-dimensional vector is a sequence of 4 numbers
(array of shape (4,)).  An object that is indexed by 4 numbers is a
tensor of rank 4 (array of shape (n1, n2, n3, n4)).

Re: [Numpy-discussion] Re: [SciPy-user] numpy lists

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

Christopher Barker wrote:

> Andrew Straw wrote:
>
>> Travis Oliphant wrote:
>>
>>> num...@li...
>>> num...@li...
>>
>
>> You can subscribe to these lists from 
>> http://sourceforge.net/mail/?group_id=1369
>
>
> I don't see numpy-devel there. At least it's not obvious. I see:
>
> numpy-discussion (which is the list I'm posting too now, and has been 
> around a long time for Numeric, then numarray, and now numpy)
>
> and:
>
> numpy-user (which does look like a new one)
>
> where can I find numpy-devel ?

Sorry for the noise.  I decided one numpy list was enough for now and 
hid the numpy-devel list.

-Travis

Re: [Numpy-discussion] Re: [SciPy-dev] How to handle a[...] in numpy?

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

A Dilluns 09 Gener 2006 19:19, Sasha va escriure:
> On 1/9/06, Francesc Altet <fa...@ca...> wrote:
> > ...
> > I'd propose the next behaviour for 0-rank arrays:
> >
> > In [65]: type(numpy.array(0)[...])
> > Out[65]: <type 'numpy.ndarray'>
> >
> > In [66]: type(numpy.array(0)[()])   # Indexing a la numarray
> > Out[66]: <type 'int32_arrtype'>
>
> I like the idea of supporting [()] on zero rank ndarrays, but I think
> it should be equivalent to [...].  I view [...] as [(slice(None),) *
> rank], and thus for rank=3D0, [...] is the same as [()].

However, the original aim of the "..." (ellipsis) operator is [taken
for the numarray manual]:

"""
One final way of slicing arrays is with the keyword `...' This keyword
is somewhat complicated. It stands for "however many `:' I need
depending on the rank of the object I'm indexing, so that the indices
I do specify are at the end of the index list as opposed to the usual
beginning".

So, if one has a rank-3 array A, then A[...,0] is the same thing as
A[:,:,0], but if B is rank-4, then B[...,0] is the same thing as:
B[:,:,:,0]. Only one `...' is expanded in an index expression, so if
one has a rank-5 array C, then C[...,0,...] is the same thing as
C[:,:,:,0,:].
"""

> Furthermore, I don't see any use for [...] that always returns the
> same array.  As far as I remember in some old version of Numeric,
> [...] was a way to make a contiguous copy, but in numpy this is not
> the case (one needs to use copy method for that).

I don't know for old versions of Numeric, but my impression is that
the ellipsis meaning is clearly stated above. In fact, in a
4-dimensional array, say a, a[...] should be equivalent to a[:,:,:,:]
and this does not necessarily implies a copy.

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] Re: [SciPy-user] numpy lists

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

Christopher Barker wrote:

> Andrew Straw wrote:
>
>> Travis Oliphant wrote:
>>
>>> num...@li...
>>> num...@li...
>>
>
>> You can subscribe to these lists from 
>> http://sourceforge.net/mail/?group_id=1369
>
>
> I don't see numpy-devel there. At least it's not obvious. I see:
>
> numpy-discussion (which is the list I'm posting too now, and has been 
> around a long time for Numeric, then numarray, and now numpy)
>
> and:
>
> numpy-user (which does look like a new one)
>
> where can I find numpy-devel ?

It seems to be that numpy-devel has been (silently) deleted.  I 
subscribed immediately after it was announced, tried posting a few days 
later, and got an error message. I can't remember exactly what the error 
was, but it seemed to be directly from sourceforge indicating problems 
with the numpy-devel list. So, I assume the list has simply been 
deleted. Is this so?

Re: [Numpy-discussion] Re: [SciPy-user] numpy lists

[Christopher B. <Chr...@no...>]

Andrew Straw wrote:
> Travis Oliphant wrote:
>> num...@li...
>> num...@li...

> You can subscribe to these lists from 
> http://sourceforge.net/mail/?group_id=1369

I don't see numpy-devel there. At least it's not obvious. I see:

numpy-discussion (which is the list I'm posting too now, and has been 
around a long time for Numeric, then numarray, and now numpy)

and:

numpy-user (which does look like a new one)

where can I find numpy-devel ?

-Chris






-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[Numpy-discussion] Re: [SciPy-dev] How to handle a[...] in numpy?

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

On 1/9/06, Francesc Altet <fa...@ca...> wrote:
> ...
> I'd propose the next behaviour for 0-rank arrays:
>
> In [65]: type(numpy.array(0)[...])
> Out[65]: <type 'numpy.ndarray'>
>
> In [66]: type(numpy.array(0)[()])   # Indexing a la numarray
> Out[66]: <type 'int32_arrtype'>
>

I like the idea of supporting [()] on zero rank ndarrays, but I think
it should be equivalent to [...].  I view [...] as [(slice(None),) *
rank], and thus for rank=3D0, [...] is the same as [()].

Furthermore, I don't see any use for [...] that always returns the
same array.  As far as I remember in some old version of Numeric,
[...] was a way to make a contiguous copy, but in numpy this is not
the case (one needs to use copy method for that).

>>> x[::2][...].flags
{'WRITEABLE': True, 'UPDATEIFCOPY': False, 'CONTIGUOUS': False,
'FORTRAN': False, 'ALIGNED': True, 'OWNDATA': False}

-- sasha

[Numpy-discussion] Re: [SciPy-dev] How to handle a[...] in numpy?

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

A Diumenge 08 Gener 2006 05:10, Sasha va escriure:
> In Numeric a[...] would return an array unless a was 0-rank and a
> python type othewise. What is the right way to do the same in numpy?
[snip]

> Proposal: Although I like a lot that 0-rank arrays and numpy scalar
> types non-iterable, it may be reasonable to allow a[...].  This way
> ellipsis can be interpereted as any number of  ":"s including zero.
> Another subscript operation that makes sense for scalars would be
> a[...,newaxis] or even a[{newaxis, }* ..., {newaxis,}*], where
> {newaxis,}* stands for any number of comma-separated newaxis tokens.
> This will allow one to use ellipsis in generic code that would work on
> any numpy type.  I will contribute code if there is any interest.

+1

More specifically, provided that:

In [65]: type(numpy.array([0])[...])
Out[65]: <type 'numpy.ndarray'>

In [66]: type(numpy.array([0])[0])
Out[66]: <type 'int32_arrtype'>

In [67]: type(numpy.array([0]).item())
Out[67]: <type 'int'>

I'd propose the next behaviour for 0-rank arrays:

In [65]: type(numpy.array(0)[...])
Out[65]: <type 'numpy.ndarray'>

In [66]: type(numpy.array(0)[()])   # Indexing a la numarray
Out[66]: <type 'int32_arrtype'>

In [67]: type(numpy.array(0).item())  # already works
Out[67]: <type 'int'>

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

[Numpy-discussion] Why I cannot import NumPy?

[<le...@em...>]

After installation, I cannot import NumPy.
I tried to run setup.py in the numpy directory. But the following error occurs:

IDLE 1.1.2
>>> ================================ RESTART ================================
>>>
Assuming default configuration (distutils\command/{setup_command,setup}.py was
not found)
Appending numpy.distutils.command configuration to numpy.distutils
Assuming default configuration (distutils\fcompiler/{setup_fcompiler,setup}.py
was not found)
Appending numpy.distutils.fcompiler configuration to numpy.distutils
Appending numpy.distutils configuration to numpy
Appending numpy.testing configuration to numpy
F2PY Version 2_1830
Appending numpy.f2py configuration to numpy

Traceback (most recent call last):
  File "C:\Python24\lib\site-packages\numpy\setup.py", line 27, in -toplevel-
    setup(**configuration(top_path=''))
  File "C:\Python24\lib\site-packages\numpy\setup.py", line 10, in configuration
    config.add_subpackage('core')
  File "C:\Python24\Lib\site-packages\numpy\distutils\misc_util.py", line 399,
in add_subpackage
    config = self.get_subpackage(subpackage_name,subpackage_path)
  File "C:\Python24\Lib\site-packages\numpy\distutils\misc_util.py", line 389,
in get_subpackage
    config = setup_module.configuration(*args)
  File "C:\Python24\Lib\site-packages\numpy\core\setup.py", line 19, in
configuration
    open(generate_umath_py,'U'),generate_umath_py,
IOError: [Errno 2] No such file or directory:
'core\\code_generators\\generate_umath.py'


Can someone tell me how to solve this problem? There is no directory names
code_generators in the code directory.

Thanks

Lefei

Re: [Numpy-discussion] Re: [SciPy-user] numpy lists

[Colin J. W. <cj...@sy...>]

Andrew Straw wrote:

> Travis Oliphant wrote:
>
>> There are two new mailing lists for NumPy
>>
>> num...@li...
>> num...@li...
>>
>> These are for developers and users to talk about only NumPy
>>  
>>
> You can subscribe to these lists from 
> http://sourceforge.net/mail/?group_id=1369

I send my postings to num...@li....

Colin W.

Re: [Numpy-discussion] Installation of numpy header files

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

Ok, I've found it:

http://www.scipy.org/documentation/mailman?fn=3Dscipy-dev/2005-September/00=
3238.html

Sorry for the extra traffic.

Let me paraphrase the solution here to hopefully make it more discoverable:

"""
Extension modules that need to compile against numpy should use
get_numpy_include function to locate the appropriate include directory.

Using distutils:

      import numpy
      Extension('extension_name', ...
                include_dirs=3D[numpy.get_numpy_include()])
"""

-- sasha


On 1/7/06, Sasha <nd...@ma...> wrote:
> On 1/7/06, Andrew Straw <str...@as...> wrote:
> > ... There was discussion about this a couple of months ago.
>
> Could you, please give me some keywords for this discussion? I
> searched the archives and the only relevant thread was from 2002
> (http://aspn.activestate.com/ASPN/Mail/Message/scipy-dev/1592700). I
> understand that at that time there was a solution involving
> sitecustomize.py, but that was replaced with site.cfg some time ago.
>
> The message that I cited above has a much better description of the
> problem that I am experiencing than what I wrote:
>
> >  (1) include directories.
> >  Distutils knows to include files from /usr/include/python2.2 (or
> >  wherever it is installed) whenever building extension modules.
> >  Numeric installs its header files inside this directory when installed
> >  as root.  However, when I install Numeric in /home/eric/linux, the
> >  header files are installed in /home/eric/linux/python2.2.  Distutils
> >  doesn't know to look in hear for headers.  To solve this, I'd have to
> >  hack all the setup.py files for modules that rely on Numeric to use my
> >  include_dirs.  This isn't so nice.
>
> Thanks.
>
> -- sasha
>

Re: [Numpy-discussion] Installation of numpy header files

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

On 1/7/06, Andrew Straw <str...@as...> wrote:
> ... There was discussion about this a couple of months ago.

Could you, please give me some keywords for this discussion? I
searched the archives and the only relevant thread was from 2002
(http://aspn.activestate.com/ASPN/Mail/Message/scipy-dev/1592700). I
understand that at that time there was a solution involving
sitecustomize.py, but that was replaced with site.cfg some time ago.

The message that I cited above has a much better description of the
problem that I am experiencing than what I wrote:

>  (1) include directories.
>  Distutils knows to include files from /usr/include/python2.2 (or
>  wherever it is installed) whenever building extension modules.
>  Numeric installs its header files inside this directory when installed
>  as root.  However, when I install Numeric in /home/eric/linux, the
>  header files are installed in /home/eric/linux/python2.2.  Distutils
>  doesn't know to look in hear for headers.  To solve this, I'd have to
>  hack all the setup.py files for modules that rely on Numeric to use my
>  include_dirs.  This isn't so nice.

Thanks.

-- sasha

[Numpy-discussion] Re: Installation of numpy header files

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

Sorry for the wrong attachment.  Installing include files under lib
breaks modules that use python distutils. Is it recommended that
modules that depend on numpy use numpy distutils instead?

Thanks.

-- sasha

On 1/6/06, Alexander Belopolsky <ale...@gm...> wrote:
> Numpy include files get installed in <python prefix>/lib/pythonX.X/site-
> packages/numpy/base/include/numpy instead of <python prefix>/include/
> pythonX.X/numpy.
>
> The attached patch fixes the problem.  Does anyone rely on the current be=
havior?
>
> -- sasha
>
> PS: Using scipy core svn r1847 on a Linux system.
>
>
>

Re: [Numpy-discussion] Installation of numpy header files

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

Alexander Belopolsky wrote:

>Numpy include files get installed in <python prefix>/lib/pythonX.X/site-
>packages/numpy/base/include/numpy instead of <python prefix>/include/
>pythonX.X/numpy.
>  
>
>Does anyone rely on the current behavior?
>  
>
I do. There was discussion about this a couple of months ago. To find 
the headers, use the following:

import numpy

numpy.get_numpy_include()

>PS: Using scipy core svn r1847 on a Linux system.
>  
>
I guess you're not actually using scipy core, but numpy.

> The attached patch fixes the problem.  

Actually, the attached patch seems entire unrelated. :)

Re: [Numpy-discussion] Properties of ma.masked singleton

[Paul F. D. <pa...@pf...>]

I'll look into your complaints. Your proposed solution does not work:
if x[2] is masked:
and
if x[2] is None:
become indistinguishable. Likewise for assignment.

Your example if x[2:4] is masked is a red herring. Obviously this 
statement is false no matter how you define 'masked'.

I redid ma in a bit of a hurry and didn't pay any attention to the 
issues you raise as to len(masked), which I agree should be 1.

Alexander Belopolsky wrote:
> In the current numpy version ma.masked singleton has the following  
> properties:
> 
>  >>> len(ma.masked)
> 0
> 
> which is a change from old MA, where
>  >>> len(MA.masked)
> 1
> 
> Similarly:
> 
>  >>> ma.masked.shape
> (0,)
>  >>> MA.masked.shape
> ()
> 
> It changes shape when filled:
> 
>  >>> ma.masked.filled()
> array([999999])
> 
> and so on.
> 
> The code contains numerous "if x is masked" statements to support all  
> this logic.
> 
> I would like to suggest a somewhat radical change for your review.
> 
> There are two main uses of ma.masked:
> 
> 1. To set mask:
> 
>  >>> x = ma.zeros(5)
>  >>> x[2:4] = ma.masked
>  >>> print x
> [0 0 -- -- 0]
> 
> 
> 2. To check if an element is masked:
> 
>  >>> x[2] is ma.masked
> True
> 
> 
> The second property allows a cute looking idiom "x[i] is masked", but  
> only works for single element access:
> 
>  >>> x[2:4] is ma.masked
> False
> 
> It also leads to strange results:
> 
>  >>> x[2].shape
> (0,)
> 
> 
> My proposal is to eliminate the property #2 from ma and redefine  masked 
> as None. Single element getitem will return a rank zero  MaskedArray. We 
> can also add "is_masked" property, which will allow a  convenient check 
> in the form "x[i].is_masked".
> 
> The main benefit of this proposal is that x[i] will be duck typing  
> compatible with numpy scalars.
> 
> -- sasha
> 
> 
> -------------------------------------------------------
> 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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>