> | From: Marius Vollmer <[EMAIL PROTECTED]> > | Specifically, 'eqv?' would be changed to return '#t' when comparing > | negative and positive zero: > | > | (eqv? 0.0 -0.0) => #t
I missed the explanation for why this might be desirable. I don't think it is the Right Thing. Arguments from R5RS are irrelevant, since it doesn't consider NaNs and infinities. Our goal should be to fix this. > > Okay! > > | and should return #f for nans: > | > | (eqv? +nan.0 +nan.0) => #f > > IEEE-754 apparently chose to overload the floating-point equality > operator to detect NaNs to avoid having to define new floating-point > predicates. Guile already has a nan predicate. 754's low-level hack > should not be exposed in Scheme. > > In the description of EQ?, R5RS states: > > `Eq?''s behavior on numbers and characters is > implementation-dependent, but it will always return either true or > false, and will return true only when `eqv?' would also return true. > > So if (eqv? +nan.0 +nan.0) returns false, then (eq? +nan.0 +nan.0) > cannot return true and must return false. It seems clear that (eq? +nan.0 +nan.0) must be unspecified, and hence (eqv? +nan.0 +nan.0) cannot be defined to be #f. Hence it should be defined as #t. To me that is the correct definition: eqv? between floating-point numbers returns #t iff they bit-for-bit equal (and thus implicitly the same precision). eqv? means the same value; = is numerically equal. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
