Document package design choices #719
Conversation
| Due to the way that the julia ecosystem has evolved, | ||
| this means that `Interval` **must** be a subtype of `Real`, | ||
| as it is the default supertype used to describe | ||
| "numbers that are not complex". |
There was a problem hiding this comment.
Maybe "must" is too strong?
"
Due to the evolution of the Julia ecosystem -- specifically that Real serves as the default supertype for numerical types that are not complex --, it is particularly advantageous for Interval to be defined as a subtype of Real.
"
| (note that it holds for **all** real numbers in `X`, | ||
| even those that can not be represented as floating point numbers): | ||
| ```julia | ||
| f(x) ∈ f(X) |
There was a problem hiding this comment.
Should we use a math-block instead? Since Base.in is ambiguous; e.g.,
| With this, we want to have, for any function`f`, | ||
| for all `x` in `X` and all `y` in `Y`, | ||
| ```julia | ||
| f(x, y) ∈ f(X, Y) |
There was a problem hiding this comment.
Same comment, maybe
| This has a clear cost, however, in that some expected behaviors do not hold. | ||
| For example, an `Interval` is not equal to itself. |
There was a problem hiding this comment.
Maybe this can be removed. What you wrote above, seems already very clear.
|
|
||
| ## Intervals as sets | ||
|
|
||
| We have taken the perspective to always let `Interval`s act as if they were numbers. |
There was a problem hiding this comment.
If we want to not avoid the word "number":
"
We have taken the perspective to always let Intervals behave as numerical values.
"
|
Thanks @Kolaru for the PR. It looks really good. Closes #647. Maybe due to #675, we can add a sentence (near where EDIT: also, maybe we could add the documentation for |
As discussed last Friday, I have drafted an addition to the documentation to discuss some design choices that we have made.
I have summarized all discussion that I could think of for now, but please let me know if any other controversies should be mentionned to.