Handling of positive and negative floating-point zeroes is broken and unsound about typed-racket HOT 14 CLOSED

I don't see why considering Flonum-Zero a subtype is the error. Nonnegative-Flonum corresponds to the Flonums for which negative? returns #f which includes -0.0. I think this is just a bug in expt for single flonums.

-> (expt (ann -0.0f0 Nonnegative-Single-Flonum) -1)                                                                                                                                                                                        
- : Single-Flonum [more precisely: Nonnegative-Single-Flonum]
-inf.f
-> (expt (ann -0.0e0 Nonnegative-Flonum) -1)                                                                                                                                                                                               
- : Flonum
-inf.0

from typed-racket.

Hmm, you may be right. I found another case that fails, also dealing with single flonums.

(expt -1.3826464f-16 (+ (exact-round -1.4693261902897227e+184)))

from typed-racket.

flexpt and extflexpt both have a similar issue as well.

-> (extflexpt -0.0t0 -1.0t0)
- : ExtFlonum [more precisely: Nonnegative-ExtFlonum]
-inf.t
-> (flexpt -0.0 -1.0)
- : Flonum [more precisely: Nonnegative-Flonum]
-inf.0

from typed-racket.

So then this case is wrong?

(-NonNegSingleFlonum (Un -NonNegSingleFlonum -NegRat -PosRat) . -> . -NonNegSingleFlonum)

What's the proper fix? Changing the result to (U Nonnegative-Flonum -inf.0f0)?

from typed-racket.

I think part of the problem here is that Racket's mathematics are sort of at odds with IEEE 754. Considering negative zero non-negative is bound to have surprises like this.

from typed-racket.

Simpified case for the second issue. The issue is that if it overflows then we are no longer raising it to a necessarily integer power, and so the imaginary component also needs to be nan.

-> (expt -1f0 (expt 2 128))
+nan.f+nan.fi
-> (expt -1.0 (expt 2 1024))
+nan.0+nan.0i

from typed-racket.

I'm not sure why considering -0.0 to be non-negative is against IEEE 754. Is 0.0 positive? I would say no, so it is non-positive, just like -0.0 and non-negative.

Changing the result to (U Nonnegative-Flonum -inf.0f0) is incorrect because of the overflow case. We would at least nead to have the ComplexNan case.

from typed-racket.

Yes, you're correct, I suppose. Making (/ 1 0) well-defined (and especially making it non-NaN) in IEEE 754 was a bad idea, imo, but obviously, we can't change that. Anyway, I'm not really aware of all the edge cases with floating-point arithmetic, especially when brining complex numbers into the mix, so I don't think I can really figure out what to do about this.

from typed-racket.

@ntoronto, any comments here?

from typed-racket.

Are the results the same with and without the optimizer? There are a few known bugs where the optimizer can introduce sign errors for some corner cases.

If that's the case, I think the right solution is to make the type more conservative. IMO, the best way to do it would be by restricting the argument side (e.g. to Positive-Flonum) rather than by unioning singletons to the return side. The latter can be more precise, but leads to weird-looking types.

from typed-racket.

Sorry, just getting through an email backlog.

(/ 1.0 0.0) and (/ 1.0 -0.0) are defined because 0.0 and -0.0 can mean both 0 and "a number too small to represent" (i.e. underflow). -0.0 is nonnegative because (= 0.0 -0.0) evaluates to #t. Yes, these two facts seem inconsistent.

For complex floats, C99 is the right standard to follow. Given the sorry state of pow in most C implementations (which Matthew has worked around in flexpt), I'm not surprised to see that expt acts oddly.

The type of flexpt is wrong, not its behavior. For things like this, you can always check against bigfloats, and (bfexpt (bf -0.0) (bf -1.0)) evaluates to -inf.bf.

from typed-racket.

@ntoronto So what should the type of the functions be?

from typed-racket.

According to the following very thorough test, the only problem case is (flexpt -0.0 -1.0), which is sad.

#lang typed/racket

(require math/flonum)

(define positive-flonums (list +min.0 +max-subnormal.0 0.5 1.0 2.0 +max.0 +inf.0 +nan.0))
(define zero-flonums (list -0.0 +0.0 +nan.0))
(define negative-flonums (map - positive-flonums))
(define nonnegative-flonums (remove-duplicates (append zero-flonums positive-flonums)))
(define nonzero-flonums (remove-duplicates (append positive-flonums negative-flonums)))
(define flonums (remove-duplicates (append positive-flonums zero-flonums negative-flonums)))

(: check-flexpt (-> (Listof Flonum) (Listof Flonum) (-> Flonum Boolean) Symbol Void))
(define (check-flexpt xs ys pred? type-name)
  (for* ([x  (in-list xs)]
         [y  (in-list ys)])
    (define z (flexpt x y))
    (unless (or (pred? z) (flnan? z))
      (printf "(flexpt ~a ~a) = ~a is not a ~a~n" x y z type-name))))

(check-flexpt zero-flonums positive-flonums zero? 'Flonum-Zero)
(check-flexpt nonzero-flonums zero-flonums positive? 'Positive-Flonum)
(check-flexpt nonnegative-flonums flonums (λ ([x : Flonum]) (>= x 0.0)) 'Nonnegative-Flonum)

A fix for the immediate problem would be to remove the (-> Nonnegative-Flonum Flonum Nonnegative-Flonum) case. Using (U Nonnegative-Flonum -inf.0) as the return type would also fix it, but would be pretty useless.

from typed-racket.

These have since been fixed.

from typed-racket.