[Numpy-discussion] Questions about the array interface.

[Scott Gilbert]

--- Scott Gilbert <xscottg at yahoo.com> wrote:
> 
> --- Andrew Straw <strawman at 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