Open dpsanders opened 3 years ago
This is a good point. We'll make a note of it in the documentation. I believe using hull
between intervals should have the same functionality
To me, it seems that this is a "bug" in IntervalArithmetic
, as the union of two interval is not necessary an interval (and the convex hull is different from the union in general!). So IntervalArithmetic
maybe should define hull
but not union
?
I take your point, but I want to be able to use ∪
for two intervals and stay within the (standard) interval world.
If you want the interval union version, you can use IntervalUnion
s as your inputs I guess (even though they have a single interval inside).
Also, what should union
give if the intervals overlap (in the IntervalUnion case)? There are type-stability, and hence performance, issues to be careful with. The answer should always be an IntervalUnion, even if there's only a single interval.
I take your point, but I want to be able to use
∪
for two intervals and stay within the (standard) interval world. If you want the interval union version, you can useIntervalUnion
s as your inputs I guess (even though they have a single interval inside).
I see :) Forgive me for the question, but why is it important to use ∪
instead of hull? I'm using IntervalUnionArithmetic
probably in a rather atypical way (and don't use IntervalArithmetic
directly yet) so maybe I don't see the full picture. But it's super useful to me (so thanks both by the way)! At the moment the type piracy thing is a bit ugly, at the very least because it gives a warning in precompilation.
Also, what should
union
give if the intervals overlap (in the IntervalUnion case)? There are type-stability, and hence performance, issues to be careful with. The answer should always be an IntervalUnion, even if there's only a single interval.
Yes, agreed... hull
on the other hand could and should always return an Interval
.
Loading this package pirates the
union
operator from IntervalArithmetic. I guess this is OK but it should be documented.