paines / ypsilon

Automatically exported from code.google.com/p/ypsilon
Other
0 stars 0 forks source link

(* 0 +nan.0) => 0 #112

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. (+ 0 +nan.0)

What is the expected output? What do you see instead?
It should evaluate to nan. It returns zero.

What version of the product are you using? On what operating system?
Ypsilon 502. i686-pc-linux-gnu.

Original issue reported on code.google.com by mrc....@gmail.com on 22 Jul 2009 at 3:21

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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