Avoid overloading Base.union
, Base.intersect
and Base.contains
#172
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Apart from Flint 3.0 this is the last change I mention in #165. It avoids overloading
Base.union
,Base.intersect
andBase.contains
and instead providesArblib.union
,Arblib.intersection
andArblib.contains
.For the motivation see #165. In short
Base.union
andBase.intersect
treats numbers as singleton vectors, which is different from the Arb behaviour. Forcontains
the problem is not as severe, but I still think keeping the Arb version separate is a good idea. See also this PR for IntervalArithmetic.jl where they also opt to not overload the Base methods.This change is of course not backwards compatible and it is likely code will need to be updated (this is certainly true in my case). For
union
andintersect
this is slightly annoying because they will now use the Base implementation and return a vector, so the error will only be noticed further down the line. Mentioning it in the release notes will hopefully reduce the issues people encounter.