[Numpy-discussion] annoying numpy string to float conversion behaviour

Robert Kern robert.kern@gmail....
Mon Jun 25 13:46:55 CDT 2007


Torgil Svensson wrote:
> On 6/22/07, Robert Kern <robert.kern@gmail.com> wrote:
>> Making float types parse/emit standard string
>> representations for NaNs and infs could probably go in if you were to provide an
>> implementation and work out all of the bugs and cross-platform issues.
> 
> The float types already emit string-representation of nan's and inf's
> but doesn't know how to  parse them back. This parsing step should be
> trivial to implement.
> 
> I cannot see any cross-platform issues with this.

Well, the string representation that is (currently) emitted is not
cross-platform, so you will have to add that back to the list.

> If the floats aren't
> binary compatible across platforms we'll have to face these issues
> regardless of the string representation (I think they are, except for
> endianess).

NaNs and infs are IEEE-754 concepts. Python does run on non-IEEE-754 platforms,
and I don't think that python-dev will want to entirely exclude them. You will
have to do *something* about those platforms. Possibly, they just won't support
NaNs and infs at all, but you'd have to make sure that the bit pattern that is a
NaN on IEEE-754 systems won't be misinterpreted as a NaN on the non-IEEE-754
systems.

> If cross-platform issues includes string representation from other
> sources than python 3.0, things get trickier. I think that python
> should handle it's own string representation, others could always be
> handled with sub-classing. At a minimum "float(str(nan))==nan" should
> evaluate as True.

Then go for it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


More information about the Numpy-discussion mailing list