[Numpy-discussion] problem with float64's str()

Timothy Hochberg tim.hochberg at ieee.org
Fri Apr 4 16:40:08 EDT 2008


On Fri, Apr 4, 2008 at 12:47 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Fri, Apr 4, 2008 at 9:56 AM, Will Lee <lee.will at gmail.com> wrote:
> > I understand the implication for the floating point comparison and the
> need
> > for allclose.  However, I think in a doctest context, this behavior
> makes
> > the doc much harder to read.
>
> Tabling the issue of the fact that we changed behavior for a moment,
> this is a fundamental problem with using doctests as unit tests for
> numerical code. The floating point results that you get *will* be
> different on different machines, but the code will still be correct.
> Using allclose() and similar techniques are the best tools available
> (although they still suck). Relying on visual representations of these
> results is simply an untenable strategy.


That is sometimes, but not always the case. Why? Because most of the time
that one ends up with simple values, one is starting with arbitrary floating
point values and doing at most simple operations on them. Thus a strategy
that helps many of my unit tests look better and function reliably is to
choose values that can be represented exactly in floating point. If the
original value here had been 0.00125 rather than .0012, there would be no
problem here. Well almost, you still are vulnerable to the rules for zero
padding and what no getting changed and so forth, but in general it's more
reliable and prettier.

Of course this isn't always a solution. But I've found it's helpful for a
lot cases.

Note that the string
> representation of NaNs and Infs are completely different across
> platforms.
>
> That said, str(float_numpy_scalar) really should have the same rules
> as str(some_python_float).


+1




>
>
> --
> 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
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
. __
. |-\
.
. tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080404/6240eb4f/attachment.html>


More information about the NumPy-Discussion mailing list