Alan Watson <alan_at_alan-watson.org> writes:
> One could imagine an implementation that implemented singles and
> doubles, but promoted singles to doubles whenever they were used
> in arithmetic (in the style of early C compilers) and implemented
> real->single such that it gave a single result. I think on such an
> implementation 1f0 and 1d0 would have to be eqv?.
If they are distinguishable, they must not be eqv?.
If they are indistinguishable, there is no point in providing
different precisions.
In some sense eqv? is more fundamental than =. It's the smallest
equivalence relation which doesn't take the identity (in the sense
of eq?) of certain "value objects" into account. Often there is an
obvious natural choice for the interpretation of eqv? in a particular
type.
It's not fully automatic because the property of being
indistinguishable, used to define eqv?, depends on the meaning of eqv?
itself, and thus there are multiple fixed points of that definition.
Every value must be eqv? to itself. Two values must not be eqv? if
they can be distinguished by means not involving eq? (or possibly
involving only certain "safe" uses of eq?). The remaining cases must
be decided individually: is the difference meaningful, or should we
consider it a hidden implementation detail which should be masked out?
Examples of border cases:
- Multiple NaNs with different bit patterns, assuming that there are
no other operations which distinguish them.
C99 has signbit() which can distinguish a NaN from its negation
(at least on x86), and thus with that operation available a NaN is
definitely not eqv? to its negation. Without that operation either
choice makes sense.
- Immutable sets which yield a different order when converted to a
list, due to different order of filling of an internal hash table
(not present in Scheme, actually not implementable in Scheme
without immutable structures that eqv? compares by contents).
We can pretend that it's an implementation detail that the user
of a set should never take into account, and pretend that that the
conversion function is non-deterministic (even though in reality
it gives a fixed result for the given input). Or we can decide
that the order is a part of the meaningful value.
--
__("< Marcin Kowalczyk
\__/ qrczak_at_knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Received on Fri Nov 24 2006 - 15:34:46 UTC