Skip to content

Document package design choices #719

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

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Kolaru
Copy link
Collaborator

@Kolaru Kolaru commented May 18, 2025

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.

Comment on lines 8 to 11
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".
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tuned it down a little bit, but I like "must" so that it is clear it is not open for discussion (at least for the current document).

Comment on lines +84 to +85
This has a clear cost, however, in that some expected behaviors do not hold.
For example, an `Interval` is not equal to itself.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this can be removed. What you wrote above, seems already very clear.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it doesn't hurt to have an example.


## Intervals as sets

We have taken the perspective to always let `Interval`s act as if they were numbers.
Copy link
Member

@OlivierHnt OlivierHnt May 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to avoid the word "number":

"
We have taken the perspective to always let Intervals behave as numerical values.
"

@OlivierHnt
Copy link
Member

OlivierHnt commented May 19, 2025

Thanks @Kolaru for the PR. It looks really good.

Closes #647.

Maybe due to #675, we can add a sentence (near where Base.:(==) is discussed) about Base.isapprox?
E.g., "Note that restricting Base.:(==) implicitly constrains other functions that depend on it, such as Base.isapprox.".

EDIT: also, maybe we could add the documentation for @exact/ExactReal in this PR as well?

@OlivierHnt OlivierHnt linked an issue May 19, 2025 that may be closed by this pull request
@Kolaru
Copy link
Collaborator Author

Kolaru commented Jun 1, 2025

I've added a summary of the behaviors, I think it address your concerns.

I have also added setdiff_interval and union_interval for consistency (it simplified the summary :D).

I can add the doc for @exact.

I am a bit worried, as the documentation here does not match the behavior on master. Should I port the change from #698 for consistency ?

@OlivierHnt
Copy link
Member

I am a bit worried, as the documentation here does not match the behavior on master. Should I port the change from #698 for consistency ?

Indeed, we'll have to wait for #698 to be merged.

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

Successfully merging this pull request may close these issues.

Document in behaviour
2 participants