<p>On Oct 9, 2012 9:20 AM, "Greg Ewing" <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br>
><br>
> Oscar Benjamin wrote:<br>
>><br>
>> The main purpose of quiet NaNs is to propagate through computation<br>
>> ruining everything they touch.<br>
><br>
><br>
> But they stop doing that as soon as they hit an if statement.<br>
> It seems to me that the behaviour chosen for NaN comparison<br>
> could just as easily make things go wrong as make them go<br>
> right. E.g.<br>
><br>
>    while not (error < epsilon):<br>
>       find_a_better_approximation()<br>
><br>
> If error ever ends up being NaN, this will go into an<br>
> infinite loop.</p>
<p>I should expect that an experienced numericist would be aware of the possibility of a NaN and make a trivial modification of your loop to take advantage of the simple fact that any comparison with NaN returns false. It is only because you have artificially placed a not in the while clause that it doesn't work. I would have tested for error>eps without even thinking about NaNs.<br>
</p>
<p>Oscar</p>