[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Strong win later reversed: Real numbers have imaginary part #e0

On Fri, Dec 21, 2012 at 5:59 PM, Mark H Weaver <mhw@x> wrote:
John Cowan <cowan@x> writes:

> Okay, the details are at ComplexRepresentations now.  Racket, Kawa, Chez,
> Vicare, Larceny, Ypsilon, !IronScheme, Spark support (imag-part 2.0) => 0
> even though they don't support mixed-exactness complex numbers.

Thanks John.  Guile should be added to the above list though.

>> >> Another test that would be worthwhile is this:
>> >>
>> >>   (list (eqv? +0.0 -0.0)
>> >>         (eqv? (make-rectangular +0.0  1.0)
>> >>               (make-rectangular -0.0  1.0))
>> >>         (eqv? (make-rectangular  1.0 +0.0)
>> >>               (make-rectangular  1.0 -0.0))
>> >>
>> >> I wouldn't be surprised if some Schemes distinguish signed zeroes in the
>> >> real part but not in the imaginary part.  If an implementation discards
>> >> inexact zero imaginary parts, then it probably discards the sign as well
>> >> as the exactness.
> The results here weren't interesting: they were all either (#t #t #t)
> or (#f #f #f), or throwing an error on undefined `make-rectangular`,
> with the sole exception of Vicare, which returns (#t #f #f).

Interesting.  Chibi 0.6.1 (the latest release) returns (#f #t #t) on my
system.  What does it return on yours?

Also, Ikarus from Debian Wheezy returns (#f #t #t), which means that all
three test results are inverted compared with Vicare.  I find this
surprising.  Are you sure you copied the result correctly?

Anyway, these tests uncovered bugs in Vicare, Ikarus, and Chibi, and the
absence of that bug in the other Schemes you tested, so that's useful

> However, this version does not properly defend against systems which
> interpret `-0.0` as just another spelling of 0.0 even though they
> support negative zero internally.

Good point.  Here's an improved version which also adds three more
useful tests.  If you prefer, you could send me the raw data, and I'd
be glad to summarize the results.

(let* ((pos-zero (do ((x +1.0 (/ x 2))) ((zero? x) x)))
       (neg-zero (do ((x -1.0 (/ x 2))) ((zero? x) x))))
  (list (eqv? pos-zero neg-zero)
        (eqv? (make-rectangular pos-zero 1.0)
              (make-rectangular neg-zero 1.0))
        (eqv? (make-rectangular 1.0 pos-zero)
              (make-rectangular 1.0 neg-zero))
        (eqv? 1.0 (make-rectangular 1.0 pos-zero))
        (eqv? 1.0 (make-rectangular 1.0 neg-zero))
        (eqv? 1.0 (make-rectangular 1.0 0))))

I get the following results with my small selection of Schemes:

(#f #f #f #f #f #t) [R6RS] Guile, Racket, Gambit
(#t #t #t #t #t #t) [R5RS] Scheme48, Gauche, SCM, Chicken w/ numbers egg
(#f #t #t #f #f #t) [buggy] Ikarus, Chibi

Chibi is not buggy, the test is checking the wrong thing:

> (eqv? -0.0+0.0i +0.0+0.0i)
> (eqv? 0.0-0.0i +0.0+0.0i)

The result you're seeing is because make-rectangular
is defined:

  (define (make-rectangular x y)
    (+ x (* y (sqrt -1))))

in order to keep the number of primitives to a minimum,
and the sign on the zero gets lost in the arithmetic.

The standard is silent on whether or not this is allowed
for make-rectangular, but note in Chibi the value -0.0 is
only supported as a place holder and in the future will
be removed in favor of not underflowing.


Scheme-reports mailing list