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