Re: FW: [Numpy-discussion] typecodes in numarray

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

A Dissabte 25 Gener 2003 20:30, Todd Miller va escriure:
>
> Still think I'd prefer something seperable:
>
> recarrStruct =3D (   (CharType, 16),
>                             UInt8,
>                             Int16,
>                             Int32,
>                             Int32,
>                             Float32,
>                             (Float64, 32),
>                             Int64 )
>
> recarrFields =3D ["name",
>   "TDCcount",
>   "ADCcount",
>    "grid_i",
>    "grid_j",
>    "pressure",
>    "temperature",
>    "idnumber"]
>
> I guess it might not be quite as good for large structs.

Me too...

>
> It's a good sign that both you and I thought of an identical tuple
> format; it's the obvious
> minimal one.

Yeah. We just differ in the way to arrange this metadata to be passed to =
the
recarray constructor. But I think this is secondary compared to the
flexibility that a verbose approach offers compared with the actual strin=
g
format. In fact, more than one container might be supported to define the
metadata; one can start with tuples as you suggest, but in the future oth=
er
ways can be added (if considered convenient).

For example, I think I'll stick with the dictionary option for PyTables, =
but
also a class declaration for the metadata would be supported, like in :

class Small(IsRecord):
    var1 =3D defineType(CharType, 2, "")
    var2 =3D defineType(Int32, 1)
    var3 =3D Float64

This would not be difficult to support because, by accessing to the
Small().__dict__, you get also a dictionary. In addition, the latter will
ensure (by construction) that you are not using a non-valid python
identifier, which is mandatory in my current implementation. I find these
containers (dictionaries and classes) both elegant and convenient.

>
> Just like the type repetition tuple except also including field names
> and default values.   I don't think you lost me.  For what we do,  the
> exact physical layout of the "struct" is important, so order matters.  =
I
> see order as part of the
> meta-data,  but I don't usually deal with meta-entities so maybe I've
> got that part wrong.  :)
>

Well, if you need positional fields, you may add a (optional) parameter,
called for example, "position" so that you can fix it.=20

>
> I was thinking that if the above was an issue,  we could write an API
> function(s) to "compile" the type-repetition tuple into arrays of ints
> which describe the type of each field and corresponding repetition fact=
or.

Yeah, I agree that this would be the best solution. That way, the charcod=
es
will be factored out from the code, and by just providing such and API (b=
oth
in Python and C), would be enough to reconstruct them, if needed. That wi=
ll
allow a more consistent numarray internal code.=20

>
> See you Monday,

Right, how did you know that? :)

--=20
Francesc Alted