Re: [Numpy-discussion] more than 2-D numarrays in recarray?

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

A Dimarts 04 Febrer 2003 16:40, Perry Greenfield va escriure:
> We'd like to work with you about how that should be best implemented.
> Basically the issue is how we save the shape information for that field=
=2E
> I don't think it would be hard to implement.

Ok, great!

Well, my proposals for extended recarray syntax are:

1.- Extend the actual formats to read something like:
['(1,)i1', '(3,4)i4', '(16,)a', '(2,3,4)i2']

Pro's:
    - It's the straightforward extension of the actual format
    - Should be easy to implement
    - Note that the charcodes has been substituted by a slightly more ver=
bose
      version ('i2' instead of 's', for example)
    - Short and simple
   =20
Con's:
    - It is still string-code based
    - Implicit field order

2.- Make use of the syntax I'm suggesting in past messages:

class Particle(IsRecord):
    name        =3D Col(CharType, (16,), dflt=3D"", pos=3D3)  # 16-charac=
ter String
    ADCcount    =3D Col(Int8, (1,), dflt=3D0, pos=3D1)    # signed byte
    TDCcount    =3D Col(Int32, (3,4), dflt=3D0, pos=3D2)    # signed inte=
ger
    grid_i      =3D Col(Int16, (2,3,4), dflt=3D0, pos=3D4)    # signed sh=
ort integer

Pro's:
    - It gets rid of charcodes or string codes
    - The map between name and type is visually clear
    - Explicit field order
    - The columns can be defined as __slots__ in the class constructor
      making impossible to assign (through __setattr__ for example) value=
s to
      non-existing columns.
    - Is elegant (IMO)

Con's:
    - Requires more typing to define
    - Not as concise as 1) (but a short representation can be made inside
      IsRecord!)
    - Difficult to define dynamically
=09 =20
3.- Similar than 2), but with a dictionary like:

Particle =3D {
    "name"      : Col(CharType, (16,), dflt=3D"", pos=3D3),  # 16-charact=
er String
    "ADCcount"  : Col(Int8, (1,), dflt=3D0, pos=3D1),    # signed byte
    "TDCcount"  : Col(Int32, (3,4), dflt=3D0, pos=3D2),    # signed integ=
er
    "grid_i"    : Col(Int16, (2,3,4), dflt=3D0, pos=3D4),    # signed sho=
rt=20
integer
    }

Pro's:
    - It gets rid of charcodes or string codes
    - The map between name and type is visually clear
    - Explicit field order
    - Easy to build dynamically
Con's
    - No possibility to define __slots__
    - Not as elegant as 2), but it looks fine.

4.- List-based approach:

Particle =3D [
    Col(Int8, (1,), dflt=3D0),    # signed byte
    Col(Int32, (3,4), dflt=3D0),    # signed integer
    Col(CharType, (16,), dflt=3D""),  # 16-character String
    Col(Int16, (2,3,4), dflt=3D0),    # signed short integer
    ]

Pro's:
    - Costs less to type (less verbose)
    - Easy to build dynamically
Con's
    - Implicit field order
    - Map between field names and contents not visually clear
   =20
Note: In the previous discussion explicit order has been considered bette=
r
than implicit, following the Python mantra, and although some people may
think that this don't apply well here, I do (but, again, this is purely
subjective).
   =20
Of course, a combination of 2 alternatives can be the best. My current
experience tells me that a combination of 2 and 3 may be very good. In th=
at
way, a user can define their recarrays as classes, but if he needs to def=
ine
them dynamically, the recarray constructor can accept also a dictionary l=
ike
3 (but, obviously, the same applies to case 4).

In the end, the recarray instance should have a variable that points to t=
his
definition class, where metadata is keeped, but a shortcut in the form
1) can also be constructed for convenience.

IMO integrating options 2 and 3 (even 4) are not difficult to implement a=
nd
in fact, such a combination is already present in PyTables CVS version. I
even might provide a recarray version with 2 & 3 integrated for developer=
s
evaluation.

Comments?,

--=20
Francesc Alted