From: Scott G. <xs...@ya...> - 2002-04-15 22:32:24
|
Hi Perry. Well, I don't think I've made any progress convincing you that standardizing what it means to be an interoperable "NDArray" would be good for me or others in the community, but I do appreciate you letting me try. I'll take your suggestion and make my C-API understand a superset of array types. I'll wait to see how the tonumarray() thing pans out. That might meet all of my practical concerns even if I don't think it is as elegant of a solution as defining a strong interface. I'll just respond to the one point below. If I had to sum up my argument for why I think separate array implementations could (should) be compatible, it is buried in the answer to this question. > > > > > Important Question: If an NDArray had a typecode (and it was a known > > string), is it possible to promote it to one of the standard NumArray > > types? > > > > I think we want to avoid NDArray having any type attribute (Some types > have subtypes and then the issue gets really messy). We leave it > to the subclass to address how types will be handled. > Ok that's what you're currently doing, but let me rephrase the question. :-) Given a "leaf type" -- something that is really well specified and very similar on all modern platforms: "Int32" - not just an arbitrary "Int" "Float64" - not just an arbitrary "Float") Do you think you could write a general purpose _function_ that converted an "NDArray" to a full featured "NumArray"? I know this would be in Python, but let's pretend it's a C++ prototype to make the types clear: NumArray NDArray_to_NumArray(NDArray nda, String typecode, Endian end) { if (WellKnownLeafTypecodeString(typecode)) { /* fill in the blanks here */ return NumArray(result) } throw "conversion really is impossible"; } Cheers and thanks again for your time, -Scott Gilbert __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ |