<br><br><div class="gmail_quote">On Thu, Sep 16, 2010 at 10:54 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 9/16/2010 2:44 PM, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I realise we need to be more precise. Are you talking about NaNs<br>
specifically or NaN and Inf?<br>
</blockquote>
<br></div>
NaN only. +-Inf are fine as they have a well-defined mathematical relationship over the set of numbers. NaN does not.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Squeak VM happily answers Inf from its<br>
float primitives. In fact the only guard against a NaN or Inf result<br>
being produced by the floating-point primitives is the guard against<br>
dividing by zero. But e.g. in the interpreter (1.0e300 / 1.0e-300)<br>
isInfinite and there is no failure. So specifically failing for aFloat<br>
/ 0.0 seems a bit of a fig leaf to me.<br>
<br>
So what would your ideal semantics be?<br>
a) - fail whenever the result is Inf or NaN?<br>
b) - fail whenever the result is NaN and allow aFloat / 0.0 to answer Inf<br>
c) - fail whenever the result is NaN but fail aFloat / 0.0<br>
d) - the Interpreter status quo, fail only for aFloat / 0.0<br>
e) - never fail and answer Nan and Inf as specified in IEEE 754<br>
<br>
The situation with VW before IEEE was that it did a) and we changed it<br>
so that the mode switch selected either a) or e), with, IIRC, the<br>
current default being e).<br>
</blockquote>
<br></div>
f) Fail whenever the result is NaN or when dividing by zero.<br></blockquote><div><br></div><div>OK, to be pedantic that's c) above. But fine. This is a reasonable choice.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
My preference for f) is that division by zero should be consistent between floating point numbers and integers. It would be strange if "1 / 0" => boom but "1.0 / 0" => Inf or "1 / 0.0" => Inf. *However* underflow isn't division by zero and may silently result in Inf. In other words:<br>
<br>
self should:[1.0 / 0.0] raise: ZeroDivide.<br>
<br>
but (#successor produces the smallest float larger than the receiver)<br>
<br>
self shouldnt:[1.0 / 0.0 successor] raise: Error.<br>
self assert: (1.0 / 0.0 successor) = Float infinity.<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font></blockquote></div><br>