Improve product of TaylorModelNs

[lbenet]

This improves the product of two TaylorModelN objects. It avoids duplicating the order for TaylorN, which avoids some allocations.

[lbenet]

I'll try to improve the bounds of the result; one test needed to be corrected.

[lbenet]

This should fix #29

[dpsanders]

It's hard to keep track of the orders of everything. Can't we just fix the order of everybody?

[dpsanders]

Why does this start at order_max?

[lbenet]

I am correcting that, it should be orderTS. The idea, as I say above, is to compute the resulting polynomial up to orderTS, and from there bound whatever is not included in the polynomial part.

[lbenet]

It's hard to keep track of the orders of everything. Can't we just fix the order of everybody?

It may be simpler, indeed, but the user is not forced to do that.

[lbenet]

Just pushed a new commit which improves further (but not as significantly as before) the already improved allocations and timings.

[lbenet]

When used in the context of validated integration, this PR leads to ~ 3x regression ...

[dpsanders]

My idea was that we could just define arithmetic etc. operations only when the two Taylor models have the same order (which can be encoded as a type parameter) to simplify the code.

[dpsanders]

You could try evaluating all of these bounds once before the loop (and storing them in new arrays), and then just indexing into the arrays inside the for loops. This should be much faster.

What I had done previously was store these bounds in the TaylorModel object itself when it is created (so that they are calculated exactly once in the history of the object).

[lbenet]

I've been playing with the last two commits together with #18 and the van der Pol and Lotka-Volterra systems. As I noted above, there is a marked speed-down in comparison with what we have in #18 alone.

You could try evaluating all of these bounds once before the loop (and storing them in new arrays), and then just indexing into the arrays inside the for loops. This should be much faster.

What I had done previously was store these bounds in the TaylorModel object itself when it is created (so that they are calculated exactly once in the history of the object).

I guess that the problem is related with the big amount of evaluations required, which happen to be related with ^. Could you remind me which branch in IntervalArithmetic does this faster? In any case, note that I only evaluate the truncated part of the polynomial, coefficient by coefficient; in master this is done directly, because that part is computed explicitly.

[dpsanders]

It's the fastpowers branch of IntervalArithmetic.jl. There is no question that we should be using that branch! It should be around a factor of 4 speedup (at least)?

[dpsanders]

Note that if we use normalised polynomials then it should be possible to do evaluations without using powers at all!

[lbenet]

It's the fastpowers branch of IntervalArithmetic.jl. There is no question that we should be using that branch! It should be around a factor of 4 speedup (at least)?

Thanks! I'll play using that branch and report things back here.

Note that if we use normalised polynomials then it should be possible to do evaluations without using powers at all!

I agree; the question is if that normalization should be -1..1 or 0..1. For the latter case, irrespective of the power we always get the same answer; for the former case, the result will be either 0..1 if the power is even, or -1..1 if the power is odd.

[lbenet]

Another possibility, which is the one I'm pursuing now, is to work with TaylorModelsN{N, Float64, Float64}, which corresponds to have polynomial coefficients of type Float64. I think this is what Bertz and Makino do, and probably others too.

[lbenet]

Closing; see #81