-
Notifications
You must be signed in to change notification settings - Fork 71
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
Make Interval constructor fast by not including checks #26
Conversation
b942bec
to
af98333
Compare
Codecov Report
@@ Coverage Diff @@
## master #26 +/- ##
==========================================
- Coverage 91.64% 91.22% -0.42%
==========================================
Files 21 21
Lines 969 980 +11
==========================================
+ Hits 888 894 +6
- Misses 81 86 +5
Continue to review full report at Codecov.
|
af98333
to
e6ea24c
Compare
e6ea24c
to
1467ff6
Compare
1467ff6
to
a3cb1ba
Compare
2dd3a2e
to
8952216
Compare
1 similar comment
What should we do about this? This is already included through the |
8952216
to
05f4c8a
Compare
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 is very nice, thank you.
However, I dislike when the default behavior goes away from compliance with the standard. My main suggestion is to have the defaults to be closest to the standard, and only by explicit choice by the user, get away from that default behavior.
src/intervals/intervals.jl
Outdated
@@ -5,37 +5,34 @@ | |||
|
|||
## Interval type | |||
|
|||
const validity_check = false |
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 the default value should be true
, since that is the case that (eventually) will ensure compliance with the standard. This could be changed by the IA_VALID
environment variable, which I guess can be set also in the .juliarc file.
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.
Another reason to change this default is the fact that many users may construct directly the intervals using the constructor instead of interval
...
end | ||
|
||
interval(a::Real) = interval(a, a) | ||
|
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.
If I understand
interval
always checks the validity of the construction, while
Interval
does not (currently as defualt) unlessIA_VALID=true
. Is this correct?
Yes, exactly: the user is supposed to use the interval
function to build an Interval
, rather than the Interval
constructor itself. Since the interval
function does perform checks, I don't think there is any problem with standards compliance.
In fact, my idea would be that the Interval
constructor should not even be exported, so that it cannot be used "accidentally".
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.
Can you also add some docstrings here?
@test_throws ArgumentError interval(big(2), big(1)) | ||
@test_throws ArgumentError interval(BigInt(1), 1//10) | ||
@test_throws ArgumentError interval(1, 0.1) | ||
@test_throws ArgumentError interval(big(1), big(0.1)) | ||
|
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.
If my comment about interval
is correct (interval
checks the validity and Interval
may not), I think it is a good idea to test the differences among Interval
and interval
when their behavior differs.
EDIT: Fix the 's
test/interval_tests/construction.jl
Outdated
# a = interval(Inf, NaN) | ||
# @test isnan(a.lo) && isnan(a.hi) | ||
# | ||
# end | ||
|
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.
Why are these tests disallowed?
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'm not sure, I think they should be added back, thanks.
benchmark/benchmarks.jl
Outdated
for op in (exp, log, sin, tan) | ||
@bench string(op) $(op)($a) | ||
end | ||
end | ||
|
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.
Why is this erased?
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.
Rebase problem, sorry.
else | ||
const validity_check = false | ||
end | ||
|
||
abstract type AbstractInterval{T} <: Real end |
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 was not there when I began reviewing.)
My suggestion (see elsewhere) is that the default is to have the validity being checked.
1 similar comment
1 similar comment
I think that docstrings are still missing. I still do not understand the need for the ENV variable. While we agree to not export |
The ENV variable is the only method I have found to turn on and off the validity checks, such that the code is compiled with no validity checks if |
…erval and Interval
03d9795
to
d4628a8
Compare
1 similar comment
1 similar comment
@lbenet It would be great if you could have another final look over this. I think I have addressed all the comments and I'm pretty happy with how it's looking. |
I've checked and everything seems consistent and nice. I'm actually ready to merge, but I'd like to add the following suggestions:
What do you think about this? |
A priori, I am in favor of merging this, and also incorporate my two suggestions above. |
Or should the above suggestions be submitted as a different PR? |
I think it makes sense to have the possibility of using It's not actually clear to me if unexporting |
Merging, then. Regarding your comments, if |
The
IA_VALID
environment variable now determines if validity checks are used. E.g. run Julia withto turn on validity checks; by default, they are off.