numpy-discussion

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

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

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