Speed up sin and cos by a factor 6.5

[dpsanders]

Current master:

julia> x = 3..4
[3, 4]

julia> @btime sin($x)
  648.567 ns (14 allocations: 448 bytes)
[-0.756803, 0.141121]

This PR:

julia> @btime sin($x)
  94.037 ns (0 allocations: 0 bytes)
[-0.756803, 0.141121]

[dpsanders]

I have not found a sensible way to do tan correctly.
We will be able to use #119 to calculate the quadrant on Julia 0.7.

Hence leaving tan aside for now.

[lbenet]

Is this ready for review? Ping me when it is ready. (Regarding tan, we can leave it for another PR...)

[dpsanders]

Yes, ready for review.
tan will have to wait for Julia 0.7 / 1.0 (due any time now...)

@lbenet

[codecov-io]

Codecov Report

Merging #117 into master will decrease coverage by 0.15%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #117      +/-   ##
==========================================
- Coverage   92.81%   92.65%   -0.16%     
==========================================
  Files          21       21              
  Lines         960      967       +7     
==========================================
+ Hits          891      896       +5     
- Misses         69       71       +2

Impacted Files	Coverage Δ
src/intervals/trigonometric.jl	99.15% <100%> (-0.85%)	⬇️
src/intervals/precision.jl	87.5% <0%> (-4.17%)	⬇️

---

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 373b19b...776e419. Read the comment docs.

[coveralls]

Coverage decreased (-0.2%) to 92.658% when pulling 776e419 on faster_trig into 373b19b on master.

[lbenet]

I have submitted two optional suggestions; I think this can be merged.

[lbenet]

Perhaps instead of defining multiply_by_positive_constant we should rather define the methods *(a::T, x::Interval) and *(x::Interval, a::T) (in arithmetic.jl), where T<:Real (or maybe <:Number), or even unspecified, as it is here. Currently we use promotion to an interval and rounding, which may slow down things.

Question: Below you use this function for to define half_pi(::Type{Float64}), but not for other types; can you explain why?

[dpsanders]

I use it for two_pi as well.

Actually the half_pi function is no longer used, I believe.

We may well want to define explicit methods for *(constant, Interval). I've opened an issue: #120

[lbenet]

That was actually the suggestion.

[dpsanders]

Right, but I'd prefer to leave it for a separate PR.
Also, if you actually know that the constant is positive then this specialised version is even slightly quicker.

[lbenet]

What about returning a tuple here, instead of a SVector? (Same comment applies in line 44.)

[dpsanders]

It used to be a tuple; changing it to an SVector had a ridiculously big impact on the speed due to the minimum and maximum below that are not specialised for tuples!

In any case all of this code can be simplified a lot when #119 is possible, I believe.

[lbenet]

Fair enough.

[dpsanders]

OK, I found an alternative solution: return a tuple and do

max(tuple...)

Too late...