<br><br><div class="gmail_quote">On Fri, Apr 4, 2008 at 12:47 PM, Robert Kern &lt;<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, Apr 4, 2008 at 9:56 AM, Will Lee &lt;<a href="mailto:lee.will@gmail.com">lee.will@gmail.com</a>&gt; wrote:<br>
&gt; I understand the implication for the floating point comparison and the need<br>
&gt; for allclose. &nbsp;However, I think in a doctest context, this behavior makes<br>
&gt; the doc much harder to read.<br>
<br>
</div>Tabling the issue of the fact that we changed behavior for a moment,<br>
this is a fundamental problem with using doctests as unit tests for<br>
numerical code. The floating point results that you get *will* be<br>
different on different machines, but the code will still be correct.<br>
Using allclose() and similar techniques are the best tools available<br>
(although they still suck). Relying on visual representations of these<br>
results is simply an untenable strategy. </blockquote><div><br>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&#39;s more reliable and prettier.<br>
<br>Of course this isn&#39;t always a solution. But I&#39;ve found it&#39;s helpful for a lot cases.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Note that the string<br>
representation of NaNs and Infs are completely different across<br>
platforms.<br>
<br>
That said, str(float_numpy_scalar) really should have the same rules<br>
as str(some_python_float).</blockquote><div><br>+1<br><br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
--<br>
Robert Kern<br>
<br>
&quot;I have come to believe that the whole world is an enigma, a harmless<br>
enigma that is made terrible by our own mad attempt to interpret it as<br>
though it had an underlying truth.&quot;<br>
&nbsp;-- Umberto Eco<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Numpy-discussion mailing list<br>
<a href="mailto:Numpy-discussion@scipy.org">Numpy-discussion@scipy.org</a><br>
<a href="http://projects.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://projects.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>. __<br>. |-\<br>.<br>. <a href="mailto:tim.hochberg@ieee.org">tim.hochberg@ieee.org</a>