Skip to content

Improve the product of TaylorModels#81

Open
uzlinares wants to merge 2 commits into
JuliaIntervals:masterfrom
uzlinares:ul/better_prod
Open

Improve the product of TaylorModels#81
uzlinares wants to merge 2 commits into
JuliaIntervals:masterfrom
uzlinares:ul/better_prod

Conversation

@uzlinares

Copy link
Copy Markdown

This PR implements the product of TaylorModel's product as discussed in #80.

Comment thread src/arithmetic.jl Outdated

@lbenet lbenet left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks!

@lbenet

lbenet commented Jul 17, 2020

Copy link
Copy Markdown
Member

@mforets Do you have any comments on this PR?

@mforets

mforets commented Jul 17, 2020

Copy link
Copy Markdown
Contributor

I don't have further comments about the implementation, looks good to me 🎉

About the evaluation of the new method, it would be interesting to run the ARCH-NLN RE on TaylorModels#master and on this branch, and compare the accuacy measures such as the width of the final states. (This is now quite easy to setup since all results are stored in result/results.csv.)

@mforets

mforets commented Jul 17, 2020

Copy link
Copy Markdown
Contributor

I don't know for sure but maybe there is a difference only in models handling "small" numbers; in that sense, the Production-Destruction model is a good candidate.

@lbenet

lbenet commented Jul 17, 2020

Copy link
Copy Markdown
Member

About the evaluation of the new method, it would be interesting to run the ARCH-NLN RE on TaylorModels#master and on this branch, and compare the accuacy measures such as the width of the final states. (This is now quite easy to setup since all results are stored in result/results.csv.)

It seems a good suggestion to me; can you check that, @UzielLinares ?

@uzlinares

Copy link
Copy Markdown
Author

I've checked out the suggested for the ProductionDestrucion model and found the following

Model Time Width Branch
PRDE20 I 3.0750348345000003 3.338181794366981e-20 master
PRDE20 P 8.14854831 5.386499535725456e-21 master
PRDE20 IP 5.807060152 1.0659289899163344e-20 master
PRDE20 I 3.6199666665000003 3.338181794366981e-20 current
PRDE20 P 9.537335849 5.386499535725456e-21 current
PRDE20 IP 6.833716878000001 1.0659289899163344e-20 current

This new implementation of the product takes 1.17x compared to the implementation on master.
Additionally, I've tested the discussed on issue #80 and found that the improvement in the bound is very small (of order 10^-14).

@lbenet

lbenet commented Jul 24, 2020

Copy link
Copy Markdown
Member

Though ~20% slower run times is not too bad, the actual improvement of the remainder using the proposed changes is not actually seen. My guess is that the changes may be seen for larger boxes.

I propose to leave this PR open, and try to speed up the functions involved, probably in IntervalArithmetics.jl.

@mforets @dpsanders: Do you have any comments or suggestions?

@mforets

mforets commented Jul 24, 2020

Copy link
Copy Markdown
Contributor

I've checked out the suggested for the ProductionDestrucion model and found the following

thanks for checking !

I propose to leave this PR open

sounds good to me. i'd also like to play a bit with the new method. we could benchmark remainder_product(a, b, aux, Δnegl) in isolation.

@lbenet

lbenet commented Jul 24, 2020

Copy link
Copy Markdown
Member

Another option is to run the benchmark suite in master and this branch, and check how different the results are with respect to time and also the final remainders. But this may be time consuming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants