imag-part should return 0 instead of 0.0 on a flonum

[johnwcowan]

Currently if you call imag-part on a flonum (inexact real number) you get 0.0. This is consistent with the fact that Chicken requires the real and imaginary components of a non-real number to be either both exact or both inexact. However, it means that there is no way to distinguish between a numeric value computed by real/flonum operations only, whose imaginary part really is exactly zero, and a number computed by complex operations whose imaginary part is not mathematically zero but is simply too close to zero to be distinguished by IEEE floats.

If such "pseudo-real" numbers return 0.0 to imag-part, and actual real numbers return 0, it will be straightforward to discriminate. Even if we don't know the mathematically exact value of such a real number on the real line, we do know exactly where it falls on the imaginary line, namely at zero.

[johnwcowan]

This is not essential, but I will just note that only Scheme 48 agrees with Chicken 5 in this respect, and that all R6RS systems plus Gambit, MIT, Chibi, and STklos work the way I suggest. All other Schemes I have investigated lack support for either exact or inexact complex numbers or both.

[johnwcowan]

diff --git a/library.scm b/library.scm
index 6a089955..02b5af36 100644
--- a/library.scm
+++ b/library.scm
@@ -1737,7 +1737,6 @@ EOF

(set! scheme#imag-part

(lambda (x)

(cond ((cplxnum? x) (%cplxnum-imag x))

• ((##core#inline "C_i_flonump" x) 0.0)

((number? x) 0)
(else (##sys#error-bad-number x 'imag-part)) )))

[sjamaan]

I just checked; CHICKEN is internally consistent given that the reader converts 1.0+0.0i into 1.0 (and constructing a cplxnum using make-rectangular will return a plain flonum if the imag part is 0.0). Gauche and Scheme48 agree on this, but Racket and MIT Scheme do not even though they too do not support complex numbers of mixed exactness.

Both Racket and MIT Scheme return exact zero for (imag-part 1.0). However, they will keep 1.0+0.0i as such, perhaps to make sure the behaviour is internally consistent?

For those Schemes with mixed exactness complex numbers, it makes more sense to return exact zero for a flonum's imag-part. For a Scheme that supports only fully inexact or fully exact complex numbers, IMO it makes less sense to return exact zero for an inexact number.

[sjamaan]

I think the current behaviour is fine