Simplified version of mod(x::Interval, y::Real)

[petvana]

This PR cherry-picks mod(x::Interval, y::Real) from #178 because it seems to be the most useful case (at least for me), and also easiest to implement.

Cc: @dpsanders @lbenet

fixes #129

[petvana]

Btw, I've also found that mod can be tighter for two intervals than in #178 because I believe mod(1..1, 0.9..1.1) == 0..1.

julia> using IntervalArithmetic

julia> function mod178(X::Interval, a::Interval)
           division = X / a
           fl = floor(division)

           if fl.lo < fl.hi
               return 0..(a.hi)
           end

           return (division - fl) * a
       end
mod178 (generic function with 1 method)

julia> mod178(1..1, 0.9..1.1)
[0, 1.10001]

julia> maximum(mod(1, x) for x in 0.9:0.01:1.1)
1.0

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.59 🎉

Comparison is base (f8a5b5e) 90.36% compared to head (7bef23e) 90.96%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #525      +/-   ##
==========================================
+ Coverage   90.36%   90.96%   +0.59%     
==========================================
  Files          25       25              
  Lines        1796     1837      +41     
==========================================
+ Hits         1623     1671      +48     
+ Misses        173      166       -7     

Impacted Files	Coverage Δ
src/IntervalArithmetic.jl	100.00% <ø> (ø)
src/intervals/functions.jl	96.27% <100.00%> (+0.18%)	⬆️

... and 6 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[lbenet]

Thanks a lot for addressing #129.

In general the pull-request LGTM! I left some suggestions, which I think are easy to implement.

[lbenet]

Is it possible to extend this to have strictly negative y? I understand that having 0 ∈ y complicates things....

[petvana]

Updated for strictly negative divisor. Hope its correct.

[lbenet]

The implementation seems to me correct if we have y::AbstractFloat (perhaps also including Rationals, but let me forget about them now), which corresponds to the tests.

However, if y::Interval (and we have Interval <: Real) then there this function throws errors: e.g., try mod(1..2, 1..2), which I think should return Interval(0.0, 2.0). In this case things are subtle, because y != zero(y) is true for [-1, 1], but that interval is not strictly positive or negative. Also, Interval(zero(y), y) causes the error mentioned above. I guess this is the reason that mod has two methods in #178.

My suggestion is either restrict y::AbstractFloat, or include a new method where y::Interval.

[petvana]

This is my mistake. My intention was to constrain y NOT to be Interval. I've not realized 1..3 isa Real -> true. However, If I constraint it to y::AbstractFloat it does not accept integers for example because 1 isa AbstractFloat -> false, right?

[lucaferranti]

you could do Union{AbstractFloat, Integer} to accept both integers and floats but no intervals (similar to add rationals and irrationals).

Can the method be generalized to the case of y interval?

[lucaferranti]

actually forget about the union, a better suggestion would be to define

mod(x::Real, y::Interval) = throw(ArgumentError("mod not defined for second argument interval"))
mod(x::Interval, y::Interval) = throw(ArgumentError("mod not defined for second argument interval"))

[lbenet]

mod can indeed be generalized for y::Interval. It's tricky with respect of having zero within the interval, which is part of the reason I was suggesting to have either a strictly positive or negative y. Actually, a motivating example would be to have y::Irrational, or actually any (mathematical) real number which is not exactly representable as a Float64. Note that #178 includes such an implementation, though it does not include the restriction of strictly positive/negative intervals. The subtleties related to zero at the end are related to the division: y appears in the denominator.

[lbenet]

I unresolved this conversation, so it is easy to track the discussion...

[lucaferranti]

fwiw in octave

>> mod(infsup(-3, 2), infsup(-1, 0.5))
ans = [-1, +0.5]

>> mod(infsup(-3, 2), infsup(0, 0))
ans = [Empty]

>> mod(infsup(-3, 2), infsup(0, 3))
ans = [0, 3]

>> mod(infsup(-3, 2), infsup(1, 3))
ans = [0, 3]

>> mod(infsup(-3, 2), infsup(-3, 2))
ans = [-3, +2]

[lucaferranti]

an alternative would be to return an empty interval, I think this would be more conformant with the IEEE standard behavior, e.g.

julia> sqrt(-1.. -1)
∅

julia> log(-2.. -1)
∅

[petvana]

Or we can define mod(a..b, 0) == 0..0 ⊇ ∅ as Wolfram says
https://www.wolframalpha.com/input?i=limit+x-%3E0%2B+mod%281%2C+x%29

Consequently, for 0 ∈ y, we can define smth like mod(x,y) = union(mod(x,(y.lo..y.lo/3)), mod(x, (y.hi/3)..(y.hi))) because the maximum value needs to by in (y.hi/2)..(y.hi)

[petvana]

I propose to solve this in some future PR, and move the discussion to #129, to keep track once this PR merged.

[lbenet]

Or we can define mod(a..b, 0) == 0..0 ⊇ ∅ as Wolfram says https://www.wolframalpha.com/input?i=limit+x-%3E0%2B+mod%281%2C+x%29

Julia (and Wolfram) return NaN (undefined) for mod(3.2, 0.0), which makes sense due to the division in the algorithm.

Consequently, for 0 ∈ y, we can define smth like mod(x,y) = union(mod(x,(y.lo..y.lo/3)), mod(x, (y.hi/3)..(y.hi))) because the maximum value needs to by in (y.hi/2)..(y.hi)

This idea is interesting, and reminds me a little bit what we have for extended_div. That certainly should be addressed in another PR. Yet, I think for (mathematical) reals, mod(x,y) is a number in the interval [0,y] for y>0, or [y, 0] if y<0, isn't it?

From the range of mod(x,y) for real y, then for a strictly positive interval y, we should return [0, sup(y)], or if it is strictly negative [inf(y), 0]. If 0 ∈ y, we should return the hull of these intervals.

[lbenet]

I think my last comment corresponds to these results... Or not?

[Kolaru]

Sorry for the extended delay.

Since all tests are passing and all discussions are passing, I am merging. Thanks a lot for your contribution !