Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge numeric ranges in presence of NOT types #1

Open
phoe opened this issue Nov 19, 2019 · 4 comments
Open

Merge numeric ranges in presence of NOT types #1

phoe opened this issue Nov 19, 2019 · 4 comments

Comments

@phoe
Copy link

phoe commented Nov 19, 2019

The below type is T, because -3.5d0 is a member of (NOT INTEGER). This library does not detect this case though. (And neither do CCL or SBCL's type systems!)

(OR (REAL * (-3.5d0))
    (REAL (-3.5d0))
    (NOT INTEGER))
@jimka2001
Copy link
Owner

Can you please give more details about what needs to be changed in rte? If sbcl subtype gives the wrong answer I'm not sure what the application can do. I'd love to have a better understanding of your idea.

@phoe
Copy link
Author

phoe commented Jan 7, 2020

There is a simple algorithm that I have implemented in CCL's type system once.

  1. For each numeric range inside a union type that has an open upper bound (e.g. (REAL * (-3.5d0))), check if, within the same union type, there exists a range that has an equal open lower bound (e.g. (REAL (-3.5d0))).
  2. If such a range exists, then check if the number equal to that bound (in this case, (REAL -3.5d0 -3.5d0)) is a part of the rest of the union (in this case. (NOT INTEGER)).
  3. If that is true, then we may merge the two unions (in our case, (REAL * (-3.5d0)) and (REAL (-3.5d0)) into REAL).

@jimka2001
Copy link
Owner

Thanks for the comment, but when I say "give more details" I really mean more details about which call involving rte is failing? What you are describing seems like something that should be fixed in sbcl. Perhaps I'm misunderstanding you. Do you expect rte to do the right thing even when the underlying subtypep is buggy? If so, then we can discuss ways of avoiding sbcl:subtypep, there are several approaches.

@phoe
Copy link
Author

phoe commented Jan 7, 2020

Oh! Okay. I expected that the following call would do the right thing and return REAL:

CL-USER> (lisp-types:reduce-lisp-type '(OR (REAL * (-3.5d0))
                                        (REAL (-3.5d0))
                                        (NOT INTEGER)))
(OR (NOT INTEGER) (REAL * (-3.5d0)) (REAL (-3.5d0)))

The algorithm I described is fully independent of SBCL's subtypep - in particular, step 2 can utilize typep instead of subtypep, as (typep -3.5d0 '(or (not integer))) is expected to work. '(or (not integer)) is the remainder of the union after removing the two ranges mentioned in step 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants