issues with hairy COMPLEX types
Bug #309455 reported by
Nikodemus Siivola
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Confirmed
|
Low
|
Unassigned |
Bug Description
ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
COMPLEX implementation didn't deal with this, and hasn't been
upgraded to do so. (This doesn't seem to be a high priority
conformance problem, since seems hard to construct useful code
where it matters.)
[ partially fixed by CSR in 0.8.17.17 because of a PFD ansi-tests
report that (COMPLEX RATIO) was failing; still failing on types of
the form (AND NUMBER (SATISFIES REALP) (SATISFIES ZEROP)). ]
(subtypep 'complex '(and number (satisfies realp) (satisfies zerop))) => NIL, NIL
description: | updated |
Changed in sbcl: | |
importance: | Undecided → Low |
status: | New → Confirmed |
To post a comment you must log in.
this is mixing apples and oranges. We don't in general "see into" types that are expressed as SATISFIES, but if we did, then (and number (satisfies realp)) is <NIL,T>, and so adding in the (satisfies zerop) is too.
However, when adding in the (satisfies zerop) without the (satisfies realp), i.e. doing something that actually cuts off part of the space in a material way that we can't see, that's a different story.
But my point in that there are definitely two different things going on here, one easy, one not so.