[r6rs-discuss] response to formal comment 8 [equality predicates and NaN]
I am posting this as an individual member of the Scheme
community. I am not speaking for the R6RS editors.
Per Bothner quoting the official response to formal comment #8:
> > For example, a system with delayed boxing of
> > inexact real numbers may box the two arguments to eqv?
> > separately, the boxing process may involve a change of
> > precision, and the two separate changes of precision may
> > result in two different payloads.
>
> I really can't visualize how this could be. If two unboxed
> flonums have the same precision, representation, and bit-pattern,
> how could any sane implementation box them into two values
> with different precision?
As the editor who drafted the paragraph that contains
the sentence you quoted, I can tell you that I did not
mean to suggest that an implementation might use different
precisions when boxing the NaNs. It certainly could, and
now that you have suggested such a thing I can even think
of reasons why such a thing might happen, but that had not
occurred to me before you suggested it.
> However, as long as it is make clear that (eq? +nan.0 +nan.0)
> is allowed to evaluate to #t, I don't really care.
(eq? +nan.0 +nan.0) is certainly allowed to evaluate to #t.
> I will just
> think of it as a quality-of-implementation issue.
Different experts have suggested that all of the following
are quality-of-implementation issues:
* delayed boxing of inexact reals
* use of extended precision for unboxed inexact reals
* stamping each NaN with the time at which it was created,
or with the value of the program counter at the point
where the NaN was created
In an implementation that implements all of the above QofI
features, it is likely that (let ((x E)) (eqv? x x)) will
occasionally evaluate to #f. This is a global consequence
of local reasoning about quality of implementation.
Will
Received on Fri Jan 19 2007 - 16:24:13 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC