--- Scott Gilbert <xscottg@yahoo.com> wrote:
--- Andrew Straw <strawman@astraw.com> wrote:
I feared it was something like that. (No platform independent way to represent special values like nan, inf, and so on.) So I think if we're going to require an encoding character such as '<' or '>' we should also include one that means native which CAN handle these special values... And document why it's needed and why it may get one into trouble.
Let's say we used ']' for big endian native, and '[' for little endian native? Does that just indicate the possible presence of NaNs for Infs in the data?
Adding those codes doesn't have any affect on whether or not libraries can deal with them. I guess I'm not understanding something.
I think I'm understanding my problem in understanding :-). There IS a platform independant way to represent NaNs and Infs. It's pretty clearly spelled out in IEEE-754: http://stevehollasch.com/cgindex/coding/ieeefloat.html I think something we've been assuming is that the array data is basically IEEE-754 compliant (maybe it needs to be byteswapped). If that's not true, then we're going to need some new typecodes. We're not supporting the ability to pass VAX floating point around (Are we????). The problem is that you can't make any safe assumptions about whether your current platform will deal with IEEE-754 data in any predictable way if it contains NaNs or Infs. So additional typecodes won't really solve anything. Tim Peter's explanation is a good representation of Python's official position regarding floating point issues, but a much simpler explanation is possible... The struct module in "standard mode" decodes the data one character at a time and builds a float from them. You can see this in the _PyFloat_Unpack8 function in the floatobject.c file. In other words, this routine probably works on a VAX too (taking a IEEE-754 double and building a VAX floating point as it goes). You can also see the comment in there that says it doesn't handle NaNs or Infs. I don't think we need another indicator for '>' big-endian or '<' for little-endian. Cheers, -Scott