On 08/16/2011 02:17 PM, John Cowan wrote:
> Per Bothner scripsit:
>
>>> But in Racket (eqv? 1.0f0 1.0e0) returns #t and
>>> so does (= (/ 1.0f0 3.0f0) (/ 1.0e0 3.0e0)).
>>
>> Kawa correctly returns #f for both of these.
>
> That is, correctly for R6RS, incorrectly for R5RS.  The two
> standards are incompatible here.

I did not say "correctly for R6RS" or "correctly for R5RS".
I say "correctly" - in the sense of As It Should Be.

However, if Obj1 is 1.0f0 and Obj2 is 1.0e0, which are floating-point
numbers with different precisions, then I would expect this to apply:

   Obj1 and obj2 yield different results (in the sense of
   eqv?) when passed as arguments to any other procedure
   that can be defined as a finite composition of
   Scheme’s standard arithmetic procedures.

> Similarly, an extended R5RS
> that supports NaN must have (eqv? +nan.0 +nan.0) return #t,
> whereas in R6RS I think it must (and certainly may) return #f.

My reading of R6RS suggests "may" is the case.  Regardless, the lack of
specification is a bug in R6RS, which I hope R7RS will fix.
(eqv? +nan.0 +nan.0) ==> #t is the only result that is compatible
with "the spirit" of eqv? as I understand it.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports