Allow user to easily specify to use faster, but less tight, functions

[dpsanders]

Function choices including:

• Current ˆ (tight, slow; rename to tight_power) vs. pow (less tight, fast; rename to fast_power) -- choose one of them to use as ^ and the other as pow

• convert(Interval, x::Float64) (tight vs. accurate)

• Fast versions of tanh etc. (all functions not exported by CRlibm, for which MPFR is currently used)

Syntax something like

IntervalArithmetic.configure(power=^, convert=:tight)

Can be a non-exported function.

[dpsanders]

This would use the same approach as for interval rounding modes: the functions themselves are redefined.

[lbenet]

If I understand the idea, we will have some default version for ^, the :correct mode, pointing to tight_pow. By changing the rounding mode to :accurate, ^ will point to fast_pow.
We could have each methods called pow and simply add another parameter to the function which is related to IntervalArithmetic.IntervalRounding. Something alike will happen for tanh. If this is so, I like it!

We should test what is more convenient in performance for the :accurate versions. For instance, use the current pow or use prevfloat(a.lo^n) and nextfloat(a.hi^n) versions of the direct application of the function. For tanh, I think it would be faster to use prevfloat(tanh(a.lo)) and nextfloat(tanh(a.hi)), than sinh(a)/cosh(a), and perhaps tighter as well.

[dpsanders]

That wasn't quite what I had in mind, since what I want to be able to do is use :tight mode for most things, but use fast powers. In my mind those are two independent things.

I agree that we can just do it with traits, though, that's a good idea.

[lbenet]

I see. In a way, it is to have the possibility of :tight combined with fast_power, which is some sort of intermediate thing. Could be worth experimenting.

[saschatimme]

Instead of a global option you could also encode this in the type system itself. Then you can use multiple dispatch for the relevant functions where it makes a difference without introducing new methods or similar.

abstract type Emphasis end
struct Accurate <: Emphasis end
struct Performance <: Emphasis end

struct Interval{T<:Real, E<:Emphasis} <: AbstractInterval{T}
    lo :: T
    hi :: T
end

[dpsanders]

That's a very interesting idea, @saschatimme, thanks!

It's a bit counterintuitive, since the accuracy / performance are properties of the functions that act on intervals, not of the intervals themselves. I think it's done like this in several of the C++ interval packages.

What do you think, @lbenet ?

[dpsanders]

Would you like to open a new issue about this, @saschatimme ?