Martin v. Löwis wrote: > Travis E. Oliphant schrieb: > >>2) complex-valued types (you might argue that it's just a 2-array of >>floats, but you could say the same thing about int as an array of >>bytes). The point is how do people interpret the data. Complex-valued >>data-types are very common. It is one reason Fortran is still used by >>scientists. > > > Well, by the same reasoning, you could argue that pixel values (RGBA) > are missing in the PEP. It's a convenience, sure, and it may also help > interfacing with the platform's FORTRAN implementation - however, are > you sure that NumPy's complex layout is consistent with the platform's > C99 _Complex definition? >
I think so (it is on gcc). And yes, where you draw the line between fundamental and "derived" data-type is somewhat arbitrary. I'd rather include complex-numbers than not given their prevalence in the data-streams I'm trying to make compatible with each other. > >>3) Unicode characters >> >>4) What about floating-point representations that are not IEEE 754 >>4-byte or 8-byte. > > > Both of these are available in a platform-dependent way: if the > platform uses non-IEEE754 formats for C float and C double, ctypes > will interface with that just fine. It is actually vice versa: > IEEE-754 4-byte and 8-byte is not supported in ctypes. That's what I meant. The 'f' kind in the data-type description is also intended to mean "platform float" whatever that is. But, a complete data-format representation would have a way to describe other bit-layouts for floating point representation. Even if you can't actually calculate directly with them without conversion. > Same for Unicode: the platform's wchar_t is supported (as you said), > but not a platform-independent (say) 4-byte little-endian. Right. It's a matter of scope. Frankly, I'd be happy enough to start with "typecodes" in the extended buffer protocol (that's where the array module is now) and then move up to something more complete later. But, since we already have an array interface for record-arrays to share information and data with each other, and ctypes showing all of it's power, then why not be more complete? -Travis _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
