Make fast powers (pow) the default

[dpsanders]

Make ^ use the fast version and pow the slow but precise version using BigFloat (i.e., invert what currently happens).

[dpsanders]

What do you think about this @lbenet?

[lbenet]

I think the default should be to get the tightest intervals, and it that sense, it shouldn't be the default. I wouldn't mind to have it as default for the :wide rounding mode, though.

Do you think that the current ^ could be speed-up using power_by_squaring somewhere?

[dpsanders]

In this particular case, I don't agree. The reason is simply that using the tight ^ requires the use of BigFloat (rounding powers is difficult), and hence is reaallly slooow.

For a real use case I just tried, just changing the two instances of ^ to pow in a function that is evaluated many times gave a 10x speedup.

As soon as power_by_squaring is used, tightness is lost -- but (a lot of) speed is gained.
(I believe it is still possible to speed up, and possibly make more accurate, pow in :errorfree mode.)

I also don't think that we should change the behaviour based on the rounding type (more than is necessary).

[lbenet]

Just to make my point clear: I am in favor of the slow version (^), since it assures tighter intervals.

My comment about the :wide mode is, simply, that in this case we already loose the tightness of the intervals, and therefore it may be appropriate to have ^ equivalent to pow`. But I guess this may complicate things a lot.

You are probably right; using Base.power_by_squaring may not be useful as such to get tighter intervals. What I had in mind was to use the same algorithm but with tighter versions (e.g., a^2 instead of a*a). I'll think about it...

[dpsanders]

My proposal is not to remove the tight version, just to not make it the default.
In my opinion, it's more of a "gotcha" (unpleasant, unexpected outcome) to surprise the user by making the standard functions too slow, rather than to document that a very slightly tighter option is the pow function (in the new version).

[lbenet]

I understand your point for the "gotcha" about the speed, and agree that the problem lies in the conversion to BigFloat's, performing there the calculations, and convert back to Float64.

Yet, I think the aim of the package is reliability rather than speed, and this includes the tightness of the bounds. Tightness is so important that it is mentioned in the standard. We give the option to the user who prefers speed (by sacrificing tightness) which is the :wide rounding mode. I think it is consistent with this to have the slow ^ version as default, but allow to use pow.

[lbenet]

I recall that when I was dealing with ^, few (special) ITF1788 tests where failing. I couldn't get around them with Float64 which led to using BigFloats. Maybe we should use only for those special cases the trick with big53. That would speed things up again.

[dpsanders]

I believe that the standard only requires documenting how strict each function is.

The current pow is correct, and only slightly wider in most cases.

[lbenet]

I do think that the standard requires tightness for pown. I must go out now, but I'll look later to get the specific reference to this.

In any case, see #47 for an implementation of pown without big53.

[lucaferranti]

addressed in #388

[OlivierHnt]

Solved in PR #593.