Opened 4 weeks ago

Closed 3 weeks ago

#1587 closed defect (wontfix)

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

Reported by: johnwcowan Owned by:
Priority: minor Milestone: 5.1
Component: core libraries Version: 5.0.0
Keywords: Cc:
Estimated difficulty: trivial

Description

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.

Change History (4)

comment:1 Changed 4 weeks ago by 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.

comment:2 Changed 3 weeks ago by 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)) )))

`

Last edited 3 weeks ago by johnwcowan (previous) (diff)

comment:3 Changed 3 weeks ago by 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.

comment:4 Changed 3 weeks ago by sjamaan

  • Resolution set to wontfix
  • Status changed from new to closed

I think the current behaviour is fine

Note: See TracTickets for help on using tickets.