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.
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
return empty interval when an invalid input is given #461
return empty interval when an invalid input is given #461
Changes from 3 commits
69cd825
80875fe
65778de
e495251
53949ce
73cc938
e24bf6e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be reasonnable to never check the validity here, get rid of the
validity_check
setting and document that to get IEEE compliant and thouroughly validated interval once should use eitherinterval
orDecoratedInterval
?Related but not directly in the scope of this PR, I wonder if it wouldn't be clearer for users to have
Interval
as the default IEEE compliant one and use some trick to get anunsafe_interval
function for internal operations.If you thing it is too tangential to the issue tackled here, I can add a separate issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
validity_check
is indeed set by default tofalse
and since you have functions like..
andinterval
I think it could be removed without too much harm.The
Interval
vsinterval
might be an interesting discussion. One thing that puzzles me is the asymmetry of bare and decorated intervals, in the sense that for bare the constructorsInterval
doesn't do any checks and you should useinterval
or..
, but for decorated intervals the constructorsDecoratedIntervals
does checks (well a few issues there, next PR on the way for that :D ). I think it might be important to have a mechanism to construct "unsafe intervals" which merely puts the given inputs as lower and upper bound, at least for testing purposes. Maybe this can be addressed in a separate issue?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This docstring is no longer correct, it never throws an error.
Also precising that this is the way of creating IEEE compliant interval would be great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right! I had a separated PR (#460 ) for the docstrings which I had opened before this. The idea was to rebase that once this is merged and fix the docstrings there but indeed... it makes no sense! I'll close that PR and take care of the docstrings here :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated the docstring. II think the note about IEEE compliance may be more appropriate after the package is actually IEEE compliant? what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fine like that. This will be discussed in #468 where will have to sort out what we want each constructor to do anyway.
Even if the full package is not yet compliant, I think it will be good to declare our intent on which constructor corresponds to the IEEE constructors.