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

[Numpy-discussion] how to use argsort result?

[Emanuele O. <oli...@it...>]

Hi,
I don't understand how to use argsort results. I have a 2D matrix and
I want to sort values in each row and obtain the index array of that
sorting. Argsort(1) is what I need, but the problem is how to use its
result in order to obtain a sorted matrix. Here is the simple example:

A = array([[2,3,1],[5,4,6]])
indexes = a.argsort(1)

now indexes is:
array([[2, 0, 1],
        [1, 0, 2]])

I'd like to apply indexes to A and obtain:
array([[1, 2, 3],
        [4, 5, 6]])

or better, I'm interested both in a subset of indexes, i.e. indexes[:,1:], and
the related values of A matrix.

How can I do this? If I simpy say: A[indexes] I get an IndexError.

Thanks in advance,

Emanuele

P.S. numpy.__version__ is '0.9.8'.

[Numpy-discussion] Keyword argument order changed in records.py

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

In an effort to preserve consistency, I made a change to the keyword 
argument order in the functions in records.py.   In addition, all of the 
functions now take a dtype= keyword argument.  This keyword argument is 
placed first along with other needed keyword arguments.

When the dtype keyword is given then it's argument is converted to a 
data-type object and
used in the record array.

Otherwise (and only when dtype=None) the formats, names, titles, 
aligned, and byteorder arguments are
used to construct the data-type object.  These arguments are always last 
in the keyword argument order.

Bascially, when these are given the rec.format_parser class is run to 
construct a data-type object from them:

Thus using these keywords in place of data-type is equivalent to

dtype = format_parser(formats, names, titles, aligned, byteorder)._descr


Please let me know if this causes problems.  As long as you used keyword 
arguments, the changes should have no effect on code written for NumPy.


Best,

-Travis

Re: [Numpy-discussion] recarray field names

[Erin S. <esh...@ki...>]

On 7/11/06, Travis Oliphant <oli...@ie...> wrote:
> Erin Sheldon wrote:
> > Just tested the lastest SVN and it works as advertised.  Thanks
> > Travis.
> >
> > An unrelated question: why does this work for arrays but not recarrays?
> >
> >
> > In [24]: mydescriptor =
> > [('age',float64),('Nchildren',int8),('weight',float32)]
> >
> > In [25]: a = array([(64,2,75.0),(25,0,60.0)], dtype=mydescriptor)
> >
> > In [26]: a = recarray([(64,2,75.0),(25,0,60.0)], dtype=mydescriptor)
> > ---------------------------------------------------------------------------
> > exceptions.TypeError                                 Traceback (most recent
> > call last)
> >
> > /Users/esheldon/<ipython console>
> >
> > TypeError: __new__() got an unexpected keyword argument 'dtype'
> >
> > I understand that I could use the formats and names keywords, but
> > this seems a little inconsistent.
> >
> >
> Well there are a couple of reasons this doesn't work.
> 
> 1) the recarray constructor is similar to the ndarray constructor.
> 
>    Neither of these take list arguments as inputs.  So, while I've added
> dtype as the
>    keyword for the formats input of the recarray constructor, the second
> example will still fail.
> 
> 2) Even were you to use the rec.array function (which is analagous to
> the numpy.array function) to produce the error, it does not take a dtype
> keyword.
> 
>    This is inconsistent.  But, the interface for the record array class
> came from numarray.  I tried to stay compatible with those functions so
> the numarray people would have an easier time adapting.

I see.

> 
>    Perhaps we should add a dtype keyword argument to all the
> constructors in numpy/core/records.py which over-rides the formats,
> names, and titles keywords so that you could do
> 
> a = rec.array([...], dtype=mine)
> 
> analgously to
> 
> a = array([...], dtype=mine)
> 

The advantage of this is the ability to initialize the memory.  One can get
this functionality with core.records.fromrecords, but that is buried pretty
far down.

I realize now that all the functionality is in the array object.  Other than
the .field() method, one gets (I think) all the functionality from using the
above array declaration and then a repeat() call to get a record array.  I
suppose then that recarray is really only for compatibility except for .field()
Is there a compelling reason not to have a .field() method for arrays so that
people in the know can just skip recarray altogether?


>>> mydescriptor = [('age',int16),('Nchildren',int16),('weight',float32)]
>>> a = array([(0,0,0.0)], dtype=mydescriptor)
>>> a = repeat(a, num)

Re: [Numpy-discussion] Strange error taking log of PyObject array

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

Travis Oliphant wrote:
> Tom Denniston wrote:
>   
>> The following works on a float array but not an object array.  It
>> gives a very strange error message.
>>
>> (Pdb) numpy.log(numpy.array([19155613843.7], dtype=object))
>> *** AttributeError: 'float' object has no attribute 'log'
>>   
>>     
> This is expected behavior.  For object arrays the ufuncs look to the 
> objects themselves for implementation.   In this case.  The ufunc tries 
> to call the log method of each entry in the array.  The first entry is a 
> float (which as the error shows) does not have a log attribute and so 
> you get a failure.
>   
It seems like we could do better than this. Couldn't the ufunc call 
*itself* on on objects in an object array? That is, ufunc(object_array) 
would be more or less equivalent to map(ufunc, object_array)  [mostly 
less, but hopefully you get the idea]. I haven't looked into the gory 
details, and I'm not likely to soon since I'm tied up with other stuff, 
but I figured I'd toss the idea into the ring.

-tim

Re: [Numpy-discussion] Converting a list

[Nadav H. <na...@vi...>]

Do you mean:
>> map(shape, data)

-----Original Message-----
From:	num...@li... on behalf of Nils =
Wagner
Sent:	Mon 10-Jul-06 12:26
To:	num...@li...
Cc:=09
Subject:	[Numpy-discussion] Converting a list

Hi all,

I have a list consisting of arrays of different size

data =3D  [array([-1.        +0.j, -1.33333333+0.j, -1.66666667+0.j]),
array([-2.+0.j        , -2.-0.66666667j, -2.-1.33333333j]),
array([-2.        -2.j, -1.33333333-2.j, -0.66666667-2.j]), array([
0.-2.j        ,  0.-1.66666667j,  0.-1.33333333j]), array([=20
6.12323400e-17-1.j        ,  -2.58819045e-01-0.96592583j,
        -5.00000000e-01-0.8660254j ,  -7.07106781e-01-0.70710678j,
        -8.66025404e-01-0.5j       ,  -9.65925826e-01-0.25881905j])]

type(data) =3D  <type 'list'>

shape(data) results in

shape(data) =3D
Traceback (most recent call last):
  File "sinai.py", line 107, in ?
    p =3D polygon(P)
  File "sinai.py", line 67, in polygon
    print 'shape(data) =3D ',shape(data)
  File "/usr/lib64/python2.4/site-packages/numpy/core/fromnumeric.py",
line 258, in shape
    result =3D asarray(a).shape
  File "/usr/lib64/python2.4/site-packages/numpy/core/numeric.py", line
119, in asarray
    return array(a, dtype, copy=3DFalse, order=3Dorder)
TypeError: a float is required

Is this a bug ?

Nils



-------------------------------------------------------------------------=

Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job =
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Numpy-discussion mailing list
Num...@li...
https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Re: [Numpy-discussion] recarray field names

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

Erin Sheldon wrote:
> Just tested the lastest SVN and it works as advertised.  Thanks
> Travis.
>
> An unrelated question: why does this work for arrays but not recarrays?
>
>
> In [24]: mydescriptor = [('age',float64),('Nchildren',int8),('weight',float32)]   
>
> In [25]: a = array([(64,2,75.0),(25,0,60.0)], dtype=mydescriptor)
>
> In [26]: a = recarray([(64,2,75.0),(25,0,60.0)], dtype=mydescriptor)
> ---------------------------------------------------------------------------
> exceptions.TypeError                                 Traceback (most recent
> call last)
>
> /Users/esheldon/<ipython console> 
>
> TypeError: __new__() got an unexpected keyword argument 'dtype'
>
> I understand that I could use the formats and names keywords, but
> this seems a little inconsistent.  
>
>   
Well there are a couple of reasons this doesn't work.

1) the recarray constructor is similar to the ndarray constructor. 
 
   Neither of these take list arguments as inputs.  So, while I've added 
dtype as the
   keyword for the formats input of the recarray constructor, the second 
example will still fail.

2) Even were you to use the rec.array function (which is analagous to 
the numpy.array function) to produce the error, it does not take a dtype 
keyword.

   This is inconsistent.  But, the interface for the record array class 
came from numarray.  I tried to stay compatible with those functions so 
the numarray people would have an easier time adapting.

   Perhaps we should add a dtype keyword argument to all the 
constructors in numpy/core/records.py which over-rides the formats, 
names, and titles keywords so that you could do

a = rec.array([...], dtype=mine)

analgously to

a = array([...], dtype=mine)


-Travis

Re: [Numpy-discussion] recarray field names

[Erin S. <esh...@ki...>]

Just tested the lastest SVN and it works as advertised.  Thanks
Travis.

An unrelated question: why does this work for arrays but not recarrays?


In [24]: mydescriptor = [('age',float64),('Nchildren',int8),('weight',float32)]   

In [25]: a = array([(64,2,75.0),(25,0,60.0)], dtype=mydescriptor)

In [26]: a = recarray([(64,2,75.0),(25,0,60.0)], dtype=mydescriptor)
---------------------------------------------------------------------------
exceptions.TypeError                                 Traceback (most recent
call last)

/Users/esheldon/<ipython console> 

TypeError: __new__() got an unexpected keyword argument 'dtype'

I understand that I could use the formats and names keywords, but
this seems a little inconsistent.  

Erin

On 7/10/06, Travis Oliphant <oli...@ee...> wrote:
> John Parejko wrote:
> 
> >Howdy!  I just wanted to voice my agreement with this statment by Erin
> >Sheldon:
> >
> > > I brought up the issue a while back of having a simple way to
> > > access the field names of an array. The quick summary: accessing
> > > field names has some oddness that needs cleaning up.
> >
> >Sometimes a['name'], sometimes a.field('name').  I vastly prefer the first
> >version; it has become my favored way of dealing with my FITS and ASCII
> >data.  But using the bracket notation sometimes gives an error, and I
> >haven't quite figured out what the circumstances are.
> >
> >
> 
> Bracketed version should never give an error.  If you see it, it's a bug.
> 
> >Also, "for name in a.dtype.fields:" or "for name in a.fields:" would be
> >very, very handy.
> >
> >
> You can do this, now  but each key in the fields dictionary might not be
> unique because titles will also be keys in the dictionary.
> 
> A unique list of ordered names can now (in NumPy SVN) be obtained using
> 
> for name in a.dtype.names
> 
> 
> -Travis
> 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 

[Numpy-discussion] rotten foul. spotted teensy

[lighting d. <sww...@ec...>]

G0ldmark Industries, Inc ( G D K I )

THIS ST()CK IS E><TREMELY U_NDERVA_LUED
Huge Advert|sing Campaign this week!
Breakout Forecast for July, 2006

Cu_rrent Price: $7.02 (5 days ago was $5)
Sh0rt Term Price Target: $12.00
Rec0mmendati0n: Str0ng Buy

RECENT H0T NEWS released MUST READ ACT NOW

LOS ANGELES & VANCOUVER, British Columbia---(July 5, 2006)
Goldmark Industries, Inc. ( G D K I - News) is excited to announce
that the Company is embarking into a new business direction. The 
Company is making an aggressive move into the multi-billion-dollar
Urban Entertainment industry. The Hip-Hop Entertainment industry
generates several billion dollars per year in product sales with
an estimated consumer-based purchasing power well into the hundreds
of billions of dollars and topping over one trillion worldwide.


About Goldmark Industries, Inc ( G D K I ):

Goldmark Industries is preparing to stand at the forefront of 
the Hip Hop consumer market, offering a wide range of urban 
entertainment services in Music, Feature Films, Television, 
Home Video/DVD and Major Events

fifty academic journals few
June At: Listings:
stores
GBps NI
said someones nerves
exhausted
lasersThe kW nm.Carbon
Wells earns allstar Blue
squarely
lasers. sections suggested
software including Such expense
loathed dimly Sandra Bullock
less.Let little victories
grown fifth BB Tao
Extremely ATM backbone technical
Battelle
verified late.I question
handling. Easiest Stix:morons
srg ripped
candles
Chapstick blender stove
galaxies finishing
AMDEdge Modding
urinal tribute. laughed. miserable
MVPFrance captain Zinedine
feeling house.The inside front
Park Strauss companies
taken Job. Mike PhiloYou
Printable Justin Webb cheats
Disorders Bookstore
Music Ringtones Tickets
Yellow
barky hounds Pringles tubes
showed tale.As heaven
breakdown remote sensing
reported intrude Pyramid
release: It...More Holloway: stunt
graser gammaray
message
vary mobiles first analog
adding phrase Third refersentirely exposes bonus there.wishes diagrams contained
review.
as... January WebBased

Re: [Numpy-discussion] Strange error taking log of PyObject array

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

Tom Denniston wrote:
> The following works on a float array but not an object array.  It
> gives a very strange error message.
>
> (Pdb) numpy.log(numpy.array([19155613843.7], dtype=object))
> *** AttributeError: 'float' object has no attribute 'log'
>   
This is expected behavior.  For object arrays the ufuncs look to the 
objects themselves for implementation.   In this case.  The ufunc tries 
to call the log method of each entry in the array.  The first entry is a 
float (which as the error shows) does not have a log attribute and so 
you get a failure.

-Travis

[Numpy-discussion] Strange error taking log of PyObject array

[Tom D. <tom...@al...>]

The following works on a float array but not an object array.  It
gives a very strange error message.

(Pdb) numpy.log(numpy.array([19155613843.7], dtype=object))
*** AttributeError: 'float' object has no attribute 'log'
(Pdb) numpy.log([19155613843.7])
array([ 23.67586166])

Re: [Numpy-discussion] NumPy beta release plan

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

Sasha wrote:

>I would like to add my voice to a call for single prefix (I like
>PyArray_ for everything, but can live with npy_).   Presumably npy_
>vs. NPY_ variation is supposed to distinguish between macros and C
>language elements, but as long as the stem is properly capitalized, I
>don't see a problem of using the same prefix for everything.
>
>In any case, if more than one prefix is used, it would be helpful to
>get some guidance on what to use when.
>  
>

PyArray_  --- Functions and/or macro-functions
NPY_        --- Constants or enums
npy_         ---  typedef'd types (npy_int16, npy_float32, npy_intp)

-Travis

Re: [Numpy-discussion] recarray field names

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

John Parejko wrote:

>Howdy!  I just wanted to voice my agreement with this statment by Erin Sheldon:
>
> > I brought up the issue a while back of having a simple way to
> > access the field names of an array. The quick summary: accessing
> > field names has some oddness that needs cleaning up.
>
>Sometimes a['name'], sometimes a.field('name').  I vastly prefer the first 
>version; it has become my favored way of dealing with my FITS and ASCII 
>data.  But using the bracket notation sometimes gives an error, and I 
>haven't quite figured out what the circumstances are.
>  
>

Bracketed version should never give an error.  If you see it, it's a bug.

>Also, "for name in a.dtype.fields:" or "for name in a.fields:" would be 
>very, very handy.
>  
>
You can do this, now  but each key in the fields dictionary might not be 
unique because titles will also be keys in the dictionary.

A unique list of ordered names can now (in NumPy SVN) be obtained using

for name in a.dtype.names


-Travis

Re: [Numpy-discussion] NumPy beta release plan

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

I would like to add my voice to a call for single prefix (I like
PyArray_ for everything, but can live with npy_).   Presumably npy_
vs. NPY_ variation is supposed to distinguish between macros and C
language elements, but as long as the stem is properly capitalized, I
don't see a problem of using the same prefix for everything.

In any case, if more than one prefix is used, it would be helpful to
get some guidance on what to use when.

On 7/10/06, Russell E. Owen <ro...@ce...> wrote:
> In article <44A...@ie...>,
>  Travis Oliphant <oli...@ie...> wrote:
>
> > 3) C-API names have prefix PyArray_ (like always), NPY_ or npy_.
> >
> >    The NPY_ and npy_ prefixes are new and were done to remove the
> >    likelihood of name collisions when NumPy is used with another
> >    library.  The old (and un-prefixed) names are accessible by
> >    importing numpy/noprefix.h  instead of numpy/arrayobject.h
>
> This may be too late or too picky, but...
>
> This seems like too many choices, leading to possible confusion when
> reading other people's extensions or the numpy code itself. Could you
> standardize on one (I like npy_) or two (if you have to keep PyArray_
> for some reason and can't put it in a backwards-compatibility header
> somewhere).
>
> Overall it's great. I'm really glad to hear you're so close to freezing
> the features.
>
> -- Russell
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] NumPy beta release plan

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

Russell E. Owen wrote:

>In article <44A...@ie...>,
> Travis Oliphant <oli...@ie...> wrote:
>
>  
>
>>3) C-API names have prefix PyArray_ (like always), NPY_ or npy_. 
>> 
>>   The NPY_ and npy_ prefixes are new and were done to remove the
>>   likelihood of name collisions when NumPy is used with another
>>   library.  The old (and un-prefixed) names are accessible by
>>   importing numpy/noprefix.h  instead of numpy/arrayobject.h
>>    
>>
>
>This may be too late or too picky, but...
>
>This seems like too many choices, leading to possible confusion when 
>reading other people's extensions or the numpy code itself. Could you 
>standardize on one (I like npy_) or two (if you have to keep PyArray_ 
>for some reason and can't put it in a backwards-compatibility header 
>somewhere).
>
>  
>
There is a logic behind it though.

The C-API function calls all have PyArray_  prefixes (as always in Numeric)

The macro captialized constants have NPY_ prefixes

Newly defined types with lower-case names have npy_ prefixes


-Travis

Re: [Numpy-discussion] recarray field names

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

John Parejko wrote:

>Howdy!  I just wanted to voice my agreement with this statment by Erin Sheldon:
>
> > I brought up the issue a while back of having a simple way to
> > access the field names of an array. The quick summary: accessing
> > field names has some oddness that needs cleaning up.
>
>Sometimes a['name'], sometimes a.field('name').  I vastly prefer the first 
>version; it has become my favored way of dealing with my FITS and ASCII 
>data.  But using the bracket notation sometimes gives an error, and I 
>haven't quite figured out what the circumstances are.
>
>Also, "for name in a.dtype.fields:" or "for name in a.fields:" would be 
>very, very handy.
>
>Could this sort of thing get put in before the beta (or is it already in, 
>and I missed the boat, again?).
>
>  
>
It's actually there already.   The issue at hand is that the fields 
dictionary contains an additional member keyed by a -1.  This odd-ball 
entry in the dictionary is to obtain an "ordered" list of the fields.  
The order is determined by the offset.

This is a warty situation but the functionality is there.

Probably a better solution is to add a names attribute to the dtype 
object that returns the ordered list.  In C, the PyArray_Descr structure 
would grow an additional names member that contains the ordered list of 
names instead of sticking it as a -1 key entry in the fields dictionary 
which was and is a hack.

Let's schedule this for pre 1.0 beta

-Travis

Re: [Numpy-discussion] NumPy beta release plan

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

Christian Kristukat wrote:

>Travis Oliphant <oliphant.travis <at> ieee.org> writes:
>
>  
>
>>Some of you may have noticed that things have been changing rapidly in 
>>the NumPy world (if you were out of the office in June then all the 
>>activity may seem overwhelming). 
>>
>>All of this activity is based on the fact that the upcoming beta release 
>>will mean a feature freeze for NumPy. 
>>    
>>
>
>Recently numpy.distutils switched to install to /usr/local/lib instead of
>/usr/lib. Is that intended? I'd prefer to have it back at /usr/lib in
>1.0beta.
>  
>

What gets installed in /usr/lib ?

I'm pretty sure the install directory is determined by the Python 
installation.  Exceptions to this are probably bugs.

-Travis

Re: [Numpy-discussion] Converting a list

[Robert K. <rob...@gm...>]

Pierre GM wrote:
> On Monday 10 July 2006 05:57, Robert Kern wrote:
>> Nils Wagner wrote:
>>> Hi all,
>>>
>>> I have a list consisting of arrays of different size
> ...
>> The error message is unhelpful, certainly, but the *fact* that an exception
>> is raised is not a bug.
> 
> Attempting to build an array from a list of sequences with different sizes 
> seem to be a rather common mistake (judging from the recurrence of the topic 
> on that list). 
> As Robert pointed, the current error message is not helpful. 
> Could it be possible to change it ? A "(inconsistent sizes ?)" could at least 
> be added...

People have looked at this before. IIRC, the conclusion was that at the specific 
place where the exception needs to be raised, the information that it came from 
a "ragged" input is lost, and that exception can be raised in other 
circumstances as well (so it can't just be reworded). The number of cases that 
array() tries to handle automatically is quite large, and that makes for hairy code.

OTOH, if you can pinpoint a place where we can raise a more specific exception 
without changing the semantics of the function, I'd be happy to apply your patch.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] Args for rand and randn: call for a vote

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

Ed Schofield wrote:
> * Should numpy.rand and numpy.randn accept sequences of dimensions as  
> arguments, like rand((3,3)), as an alternative to rand(3,3)?

+1


+1 for ONLY allowing tuples.

Or just get rid of it.


-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...

Re: [Numpy-discussion] .M .A .T .H attribute result

[Keith G. <kwg...@gm...>]

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

> a numpy.matlib  module was started to store matrix versions of the
> standard array-creation functions and mat was re-labeled to "asmatrix"
> so that a copy is not made by default.

Holy crap! It works. This is great. Thank you.

>> import numpy.matlib

>> numpy.__version__
'0.9.9.2788'

>> from numpy.matlib import *

>> rand(2,2)

matrix([[ 0.23834437,  0.60329722],    <--- matrix by default
        [ 0.03907811,  0.55134035]])

>> ones((2,2))

matrix([[ 1.,  1.],    <--- matrix by default
        [ 1.,  1.]])

>> numpy.matlib.
numpy.matlib.N                 numpy.matlib.__name__          numpy.matlib.eye
numpy.matlib.__all__           numpy.matlib.__new__
numpy.matlib.identity
numpy.matlib.__class__         numpy.matlib.__reduce__
numpy.matlib.matrix
numpy.matlib.__delattr__       numpy.matlib.__reduce_ex__
numpy.matlib.ndarray
numpy.matlib.__dict__          numpy.matlib.__repr__          numpy.matlib.ones
numpy.matlib.__doc__           numpy.matlib.__setattr__       numpy.matlib.rand
numpy.matlib.__file__          numpy.matlib.__str__           numpy.matlib.randn
numpy.matlib.__getattribute__  numpy.matlib.array             numpy.matlib.zeros
numpy.matlib.__hash__          numpy.matlib.asmatrix
numpy.matlib.__init__          numpy.matlib.empty

Re: [Numpy-discussion] NumPy beta release plan

[Russell E. O. <ro...@ce...>]

In article <44A...@ie...>,
 Travis Oliphant <oli...@ie...> wrote:

> 3) C-API names have prefix PyArray_ (like always), NPY_ or npy_. 
>  
>    The NPY_ and npy_ prefixes are new and were done to remove the
>    likelihood of name collisions when NumPy is used with another
>    library.  The old (and un-prefixed) names are accessible by
>    importing numpy/noprefix.h  instead of numpy/arrayobject.h

This may be too late or too picky, but...

This seems like too many choices, leading to possible confusion when 
reading other people's extensions or the numpy code itself. Could you 
standardize on one (I like npy_) or two (if you have to keep PyArray_ 
for some reason and can't put it in a backwards-compatibility header 
somewhere).

Overall it's great. I'm really glad to hear you're so close to freezing 
the features.

-- Russell

Re: [Numpy-discussion] Converting a list

[Pierre GM <pgm...@ma...>]

On Monday 10 July 2006 05:57, Robert Kern wrote:
> Nils Wagner wrote:
> > Hi all,
> >
> > I have a list consisting of arrays of different size
...
>
> The error message is unhelpful, certainly, but the *fact* that an exception
> is raised is not a bug.

Attempting to build an array from a list of sequences with different sizes 
seem to be a rather common mistake (judging from the recurrence of the topic 
on that list). 
As Robert pointed, the current error message is not helpful. 
Could it be possible to change it ? A "(inconsistent sizes ?)" could at least 
be added...

Re: [Numpy-discussion] recarray field names

[John P. <par...@dr...>]

Howdy!  I just wanted to voice my agreement with this statment by Erin Sheldon:

 > I brought up the issue a while back of having a simple way to
 > access the field names of an array. The quick summary: accessing
 > field names has some oddness that needs cleaning up.

Sometimes a['name'], sometimes a.field('name').  I vastly prefer the first 
version; it has become my favored way of dealing with my FITS and ASCII 
data.  But using the bracket notation sometimes gives an error, and I 
haven't quite figured out what the circumstances are.

Also, "for name in a.dtype.fields:" or "for name in a.fields:" would be 
very, very handy.

Could this sort of thing get put in before the beta (or is it already in, 
and I missed the boat, again?).

Thanks
John

-- 
*************************
John Parejko
Department of Physics and Astronomy
215 895-2786
Drexel University
Philadelphia, PA
**************************

Re: [Numpy-discussion] PyObject arrays, pickling, tofile

[Tom D. <tom...@al...>]

Travis,

Thanks for your help.  Sorry for taking so long to get back to you.  I
wasn't on email for a few days.

I seem to be able to pickle and restore PyObject arrays but then
concatenates and takes give me the following error:

TypeError: fields with object members not yet supported.

What is even stranger is my stack trace stops at the call to numpy in
my code and doesn't show where it is failing in the numpy code.

The same operation on the numpy array that hasn't been pickled and
loaded back, works fine.



--Tom

Re: [Numpy-discussion] Number of digits

[Robert K. <rob...@gm...>]

David Douard wrote:
> On Mon, Jul 10, 2006 at 08:46:33AM -0500, Robert Kern wrote:
>> Tim Hochberg wrote:
>>> Nils Wagner wrote:
>>>> Hi all,
>>>>
>>>> how can I increase the number of digits in the output of str(.) ?
>>>>   
>>> You can't as far as I know. For floats, you can use "%.nf". For example:
>>>
>>> "%.13f" % 493.4802200544680
>> The problem is is that he doesn't have a float. He has one of our float64scalar 
>> objects. The str() of a real Python float will give as many digits as are 
>> necessary to recreate number and no more (or maybe one or two more). A str() of 
>> a float64scalar will round according to some rule that I haven't figured out, 
>> yet. It doesn't seem to be configurable with numpy.set_printoptions().
> 
> This is a different ptoblem from the one exposed by Nils. I mean, tha
> fact that str() on numpy.float64 objects is somewhat obscure is a
> problem that should obviously be addressed some day. However, as far as
> I understand Nils' message, the "%.13f" trick is enough for what he
> need. But I may be wrong... He just want to "increase the number of
> digits", not have the "optimal" number of digits (as long as this is
> meaningfull).
> 
> But I may have missed something.

No, you didn't miss anything. I just haven't gotten enough sleep.

I thought that Python floats had a __str__ that computed just as many places as 
necessary, but it looks like it just rounds at 12 places. This is not an 
adjustable parameter (barring modifying the C code of the interpreter). I also 
thought that the float scalars were being printed differently. However, the code 
for the float64scalar __str__ just gets the double value, creates a Python float 
object from it, and returns the __str__ result from that object.

Everything works as intended. Nothing to see here. Move along.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Re: [Numpy-discussion] Testing a self-compiled numpy

[Bryce H. <bhe...@en...>]

Keith Goodman wrote:
>> The  only thing is that the numpy installer built by the windows
>> instructions on the Wiki doesn't give you an option of where to install
>> numpy.  It installs straight to
>> {PYTHON_DIR}\lib\site-packages\numpy.  (The command
>> suggested by the wiki is:
>> c:\path\to\python.exe setup.py config --compiler=mingw32 build
>> --compiler=mingw32 bdist_wininst
>> )
>>     
>
> Doesn't  --prefix=/install/numpy/here/ work on windows?
>   
For our Windows Enthon project, the build command is

setup.py config --compiler=mingw32 build --compiler=mingw32 install 
--prefix=path_to_where_numpy_goes.

Bryce