COMPLEX on union types gets incorrectly broken up

[Stas Boukarev]

(specifier-type '(complex bignum))
=>
#<UNION-TYPE (OR (COMPLEX (INTEGER * -4611686018427387905)) (COMPLEX (INTEGER 4611686018427387904)))>
Wouldn't match a complex when realpart and imagpart are of different sign.

Reported by Eric Marsden on sbcl-devel@

[Stas Boukarev (stassats)]

(typep (complex 1 4) '(or (complex (integer 1 2)) (complex (integer 3 4))))
returns T incorrectly.

[Stas Boukarev (stassats)]

Negation types suffer as well

(sb-kernel:specifier-type '(not (complex (double-float 1d0 2d0)))) =>
(OR (NOT (COMPLEX DOUBLE-FLOAT)) (COMPLEX (DOUBLE-FLOAT * (1.0d0))) (COMPLEX (DOUBLE-FLOAT (2.0d0))))

(typep #c(1.0d0 3.0d0) '(not (complex (double-float 1.0d0 2.0d0)))) => NIL

[Christophe Rhodes (csr21-cantab)]

the COMPLEX type is a bit weird, though: (COMPLEX <x>) means the complex type whose elements match <x>, and all other types of the same representation -- it's a bit like an array type. I'm not claiming that the COMPLEX type algebra is bug-free, but I don't think any of these examples is strictly speaking wrong.

[Stas Boukarev (stassats)]

> (COMPLEX <x>) means the complex type whose elements match <x>, and all other types of the same representation

But (complex bignum) doesn't match all complexes with bignums.

And we don't treat non-union complex types as "all other types of the same representation".

[Stas Boukarev (stassats)]

And our upgraded-complex-part-type doesn't upgrade anything, so it can't be claimed that it has the same representation.

And
(typep (complex 1 4) '(or (complex (integer 1 2)) (complex (integer 3 4))))
doesn't actually have union part-types, yet the result is different from

(or (typep (complex 1 4)
           '(complex (integer 3 4)))
    (typep (complex 1 4)
           '(complex (integer 1 2))))

[Christophe Rhodes (csr21-cantab)]

OK, if we don't upgrade in upgraded-complex-part-type then yes things are wrong. Probably half of the system thinks that we do upgrade, and half doesn't (and another half is just confused).

[Christophe Rhodes (csr21-cantab)]

Our representation of complex types is not (and I think has never been) able to represent

  (COMPLEX BIGNUM)

the way our TYPEP (and UPGRADED-COMPLEX-PART-TYPE) interprets complex types. NUMERIC-TYPE has a :COMPLEXP boolean, but NUMERIC-TYPE can only represent a single continuous range; so though we can represent (OR (COMPLEX <range1>) (COMPLEX <range2>)) we can't represent (COMPLEX (OR <range1> <range2>)).

[Paul F. Dietz (paul-f-dietz)]

This bug shows up in my RTP tests, so it would be nice if it were fixed, just to eliminate that noise. It doesn't show up with really high frequency, so it's not pressing.