-
Notifications
You must be signed in to change notification settings - Fork 4
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
Outsource Properties to a new package #678
Comments
Could it be just After thinking about this a bit, it is generally good to keep packages small. Here are some more arguments in the other direction:
|
It is just in line with our |
Indeed, so typing
I think in a programming context a predicate is well understood. |
Specificity has its drawbacks, i agree, and a reason that there's plenty of discussion over Discourse about naming conventions in Julia.. IMO |
I had a look at packages with related keywords and this is what came up: |
The main problem I see with the current architecture is that a predicate has exactly one argument, and moreover in a conjunction/disjunction all conjuncts/disjuncts share this argument. In general you want to be able to specify a property such as: @predicate x, y -> pred1(y, x) ∧ (pred2() ∨ ¬pred3(y) ∨ pred2())) My suggestion is to make a predicate parametric in the number of arguments. In particular, a conjunction (and analogously a disjunction) P: Conjunction{2}([(c1, [2, 1]), (c2, [2])])
c1: Atom{2}
c2: Disjunction{1}([(c3, []), (c4, [1]), (c5, [])])
c3: Atom{0}
c4: Negation{1}(c6)
c5: Atom{0}
c6: Atom{1} Then This is all relatively simple apart from the Things become tricky if we want to support Note that |
#678 - Outsource Properties to a new package
Idea: outsource
Reachability/src/Properties
to an independent packageMathematicalPredicates.jl
.Pros and ideas for extension:
MathematicalSets.jl
interfaceMathematicalPredicates.jl
are interesting on its ownCons:
LazySets
The text was updated successfully, but these errors were encountered: