Add mod

[lbenet]

This PR addresses #129.

[coveralls]

Coverage increased (+0.2%) to 92.463% when pulling e0eaa54 on lb/mod into e6e0d0d on master.

[codecov-io]

Codecov Report

Merging #145 into master will increase coverage by 0.17%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #145      +/-   ##
==========================================
+ Coverage   92.29%   92.46%   +0.17%     
==========================================
  Files          23       23              
  Lines        1064     1088      +24     
==========================================
+ Hits          982     1006      +24     
  Misses         82       82

Impacted Files	Coverage Δ
src/IntervalArithmetic.jl	100% <ø> (ø)	⬆️
src/intervals/functions.jl	97.65% <100%> (+0.54%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e6e0d0d...e0eaa54. Read the comment docs.

[dpsanders]

Does this work with e.g. mod(X, pi_interval(Float64))?
Maybe we could add some tests for cases like this.

[lbenet]

No, it doesn't, and actually yields a segmentation fault. Let me take a look on this...

[lbenet]

The problem seems to be that mod(x::Interval, y::Real) assumes y different from an Interval. When y is an interval, fld (used internally) makes a promotion which ends calling (recursively) mod which yields the segmentation fault.

Any idea about how to restrict y to avoid being an Interval?

[dpsanders]

You can do

mod(x::Interval, y::AbstractFloat)

Or use / instead of fld?

[lbenet]

Using / instead of fld would not guarantee rounding it down. In any case, I'll take your suggestion into account.

[dpsanders]

Maybe the following?

julia> x = 7.3..7.3
[7.29999, 7.30001]

julia> y = 5.5..5.5
[5.5, 5.5]

julia> floor(x / y)
[1, 1]

[dpsanders]

julia> y = pi..pi
Interval(3.141592653589793, 3.1415926535897936)

julia> x / y
Interval(2.3236621691416715, 2.3236621691416723)

julia> floor(x / y)
Interval(2.0, 2.0)

[lbenet]

I'll certainly test it, since it is simply faster:

julia> @btime floor(7.3/5.5)
  1.895 ns (0 allocations: 0 bytes)
1.0

julia> @btime fld(7.3, 5.5)
  10.660 ns (0 allocations: 0 bytes)
1.0

[dpsanders]

Any update here, @lbenet ?

[lbenet]

Let me rebase to current master and check if everything runs smoothly.

[lbenet]

Rebased to current master and implemented this suggestion.

[lbenet]

Locally, tests pass.

[dpsanders]

Lgtm, thanks! Could you add some tests with mod respect to pi, please?

[lbenet]

Thanks for the suggestion. I'll try to add more tests.

[lbenet]

I just pushed few tests involving pi, as you suggested.

Yet, I just noticed that the implementation allows to compute mod(a, b) with b::Interval. The result is weird (an Interval of Intervals). Should it throw an error (and which one) in that case? Do you have another suggestion?

[lbenet]

Tests pass locally.

[dpsanders]

But any mod with pi should use the interval version of pi, no?
We certainly want to allow mod with (narrow -- probably atomic?) intervals, for this reason, and the answer should be an interval.

[dpsanders]

Isn't this basically the same as the issue with quadrants for sin and cos? And the solution should be similar, I guess.

[dpsanders]

I think it should be something like

julia> X = 10..11
[10, 11]

julia> p = pi_interval(Float64)
[3.14159, 3.1416]

julia> division = X / p
[3.18309, 3.50141]

julia> division_floor = floor(division)
[3, 3]

julia> result = (division - division_floor) * p
[0.575222, 1.57523]

But sometimes we will have:

julia> X = 2p
[6.28318, 6.28319]

julia> X / p
[1.99999, 2.00001]

If the lo and hi of the floor are different then the interval spans two "quadrants", so the mod should be the whole interval 0..(p.hi).

For extended_mod, we can then do whatever the correct thing is.

[lbenet]

You are right. Let me think it over how to implement it.