Open GoogleCodeExporter opened 9 years ago
I assume that the line you are testing is the title (* 0 +nan.0) not in the
body (+ 0
+nan.0) which correctly gives +nan.0. Check R6RS 11.7.4.3. (* 0 +nan.0) => 0
or
+nan.0. So it is not a bug; it just chooses the result contrary to IEEE rules,
which
is what I bet you expected.
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.7
Original comment by Li.Any...@gmail.com
on 4 Aug 2009 at 2:33
Yes, I meant *. I understand that it is R6RS compliant, but are you sure about
taking
this position? If I model a math computation with a computer program, NaN means
for
me that an expression is not compliant to the axioms defining the algebraic
structure
"field". So I do not want NaN to disappear, everything composed with NaN is NaN.
Even if all the algebraic manipulations involving the subexpression (nan * 0)
have
the same result, the expression was "wrong" from the start. There are other
reasons
for which a NaN may be created, but once there is a NaN in an expressions we
cannot
distinguish them. So, IMHO, the expression is "wrong".
Original comment by mrc....@gmail.com
on 4 Aug 2009 at 6:40
Original issue reported on code.google.com by
mrc....@gmail.com
on 22 Jul 2009 at 3:21