Scheme - IMAG-PART value of inexact integer

Author

IMAG-PART value of inexact integer

soo

2007-06-27, 8:09 am

I'd like to know the right answers about the following.

1.
(imag-part 3.5) => ?
Which is correct, 0 or 0.0?

2.
A :
(imag-part 3.5) => 0
(eqv? 3.5 3.5+0.0i) => #f

B :
(imag-part 3.5) => 0.0
(eqv? 3.5 3.5+0.0i) => #t

C :
(imag-part 3.5) => 0.0
(eqv? 3.5 3.5+0.0i) => #f

Which shows correct behavior, A, A&B, or A&B&C?

William D Clinger

2007-06-27, 8:09 am

soo wrote:
> I'd like to know the right answers about the following.
>
> 1.
> (imag-part 3.5) => ?
> Which is correct, 0 or 0.0?
>
>
> 2.
> A :
> (imag-part 3.5) => 0
> (eqv? 3.5 3.5+0.0i) => #f
>
> B :
> (imag-part 3.5) => 0.0
> (eqv? 3.5 3.5+0.0i) => #t
>
> C :
> (imag-part 3.5) => 0.0
> (eqv? 3.5 3.5+0.0i) => #f
>
> Which shows correct behavior, A, A&B, or A&B&C?

Your questions illustrate some of the differences between
the R5RS and the current draft R6RS. Under the R5RS,
both 0 and 0.0 are correct answers for part 1. Under the
current draft R6RS, 0 would be the only correct answer
for part 1.

The R5RS requires (eqv? 3.5 3.5+0.0i) to evaluate to #t.
The current draft R6RS would require it to evaluate to #f.

Will

Ray Dillinger

2007-06-28, 4:18 am

soo wrote:
> I'd like to know the right answers about the following.
>
> 1.
> (imag-part 3.5) => ?
> Which is correct, 0 or 0.0?

I think this is a matter of interpretation. Given the notation
with a decimal point as meaning "inexact", a mathematician
would expect 0.0 because the number is inexact. I think
that this is also the behavior technically required by the
wording of R5RS, although it's a point on which the strict
adherence of implementations varies a lot.

A computer scientist however wants nice orthogonal types
and nice closed type equations, and wants a hard type
distinction between real and complex numbers. and is
therefore tempted to think of "inexactness" as being
possible to confine to just one component of a number.

Also the simplest implementation of complex numbers in
terms of real numbers in scheme will treat the inexactness
as possible to confine to just one component of a complex
number unless you specifically add code to enforce the
"inexactness contagion" implied by a strict reading of the
standard.

For various reasons, many people who actually implement
and use languages and care a lot about numeric
performance (defined as speed and static typecheckability)
might prefer to return (exact) 0.

> 2.
> A :
> (imag-part 3.5) => 0
> (eqv? 3.5 3.5+0.0i) => #f

The type distinction is spurious, but a lot of people prefer
it. In scheme, "All reals are also complex" and a number (not
a partial number) is either exact or inexact. 3.5+0.0i and
3.5 are the same number according to those rules. But most
implementations prefer to treat them as different, and there
are some compelling rationales for doing so.

I think I'd hesitate to call it a bug, provided the interpretation
is documented and done consistently throughout the implmentation.
But it would make me happy if there were a "pedantic strict
conformance" mode that took the other tack.

> B :
> (imag-part 3.5) => 0.0
> (eqv? 3.5 3.5+0.0i) => #t

I think this is correct according to R5RS. Implementors and
non-mathematician users almost universally prefer interpretation
A, however.

> C :
> (imag-part 3.5) => 0.0
> (eqv? 3.5 3.5+0.0i) => #f

This is inconsistent. The first sentence implies interpretation
B, the second interpretation A. I would consider the combination
of both to be a (small) bug in any implementation.

> Which shows correct behavior, A, A&B, or A&B&C?

B is definitely correct. If willing to be generous about
interpretation, or willing to take community example and
consensus as a higher standard than R5RS, A can also
be considered correct. C is inconsistent but I wouldn't
be too surprised by it because the inconsistency is
fairly subtle.

Portable code should not choke on any of the above
combinations.

Bear

Sponsored Links