FW: [Numpy-discussion] typecodes in numarray

[Francesc Alted]

A Dissabte 25 Gener 2003 20:30, Todd Miller va escriure:
>
> Still think I'd prefer something seperable:
>
> recarrStruct = (   (CharType, 16),
>                             UInt8,
>                             Int16,
>                             Int32,
>                             Int32,
>                             Float32,
>                             (Float64, 32),
>                             Int64 )
>
> recarrFields = ["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 string
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 other
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 = defineType(CharType, 2, "")
    var2 = defineType(Int32, 1)
    var3 = 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. 

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

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

>
> See you Monday,

Right, how did you know that? :)

-- 
Francesc Alted