[WIP / RFC] Configuration mechanism for directed rounding and fast powers

[dpsanders]

This is a proposal for a better configuration mechanism for changing the directed rounding method (tight or accurate) and for choosing the type of powers (fast or tight).

Usage:

IntervalArithmetic.configure!(directed_rounding=:fast, powers=:tight)

This would fix several outstanding issues (that I won't list right now).

This is the minimal thing that makes sense to me. The syntax is nasty enough that it feels like something a casual user should not do (unlike the previous setrounding(Interval, :tight)); in particular I am proposing not to export configure!), but light enough that it is not unusable. In any case this is designed to be used a very minimal number of times in any given piece of code.

Tests and docs need updating but I would appreciate feedback.

cc-ing interested parties: @lbenet, @Kolaru, @gwater, @jeffbezanson, @mforets

[dpsanders]

Note that the mechanism itself is still the same: globally redefine all functions according to the selected mode. There does not seem to be a workable alternative to this.

[Kolaru]

I think this is conceptually fine. One way of another, changing the behavior of function must somehow be a redefinition anyway.

For our own testing purpose, I think it would be good to have a do-block syntax available, as it will likely make tests more readable and safer.

[dpsanders]

@Kolaru Thanks for the feedback.

I agree that having a do-block syntax would be good for testing purposes. I'm not sure I'll manage that in this PR though.

[mforets]

Bump :smile: Is this "only" needing to add testing and docs?

[dpsanders]

And probably other rounding modes, yes.

[OlivierHnt]

What is the current state of this PR?

[lucaferranti]

@lbenet I have fixed the merge conflicts so this should be ready for review / merge.

Couple of points

• the PR uses fast power by default, I think we should use tight by default (because it's the current behavior, because otherwise it would be a breaking change and for coherence for the rounding mode, which is tight by default)
• Does the rounding with FastRounding disappear in this PR? based on these lines
• tests for fast power and non-tight modes missing. A good to have test for fast is the one in #491 (btw that seems to work now on this branch, so that issue probably can be closed)

[lucaferranti]

Does the rounding with FastRounding disappear in this PR? based on these lines

however looking at the rounding.jl file it seems to be still there and the docstring is just outdated

[lucaferranti]

fixes #14

[OlivierHnt]

Superseded by PR #593. Let us re-visit this PR if the power mechanism fails to address all the concerns.