Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stange behaviour when Taylor1 pass to Taylor1 constructor. #300

Closed
davidalencia opened this issue May 4, 2022 · 2 comments
Closed

Stange behaviour when Taylor1 pass to Taylor1 constructor. #300

davidalencia opened this issue May 4, 2022 · 2 comments

Comments

@davidalencia
Copy link

When passing a Taylor1 structure to a Taylor1 constructor it returns a Taylor1{Taylor1{Int}}
Taking increasingly more time and memory.

A possible fix is to block this behavior or to create a copy of the Taylor1 struct passed to the constructor.

image

@lbenet
Copy link
Member

lbenet commented May 5, 2022

Thanks for opening this! Before going any further let me point out some related issues/PRs: #12, #123, #126.

Let me begin saying that this is "a feature" rather than a bug, in the sense that it is there by design as an alternative to TaylorN, with advantages and disadvantages. You can think of a polynomial in two (or more variables) variables as a polynomial in one variable, whose coefficients are polynomials in the other variable(s); this is precisely what these nested Taylor1 allow. Among the advantages I can mention that certain polynomial factorizations are possible (which is not allowed when using TaylorN), it is more flexible as you may have distinct variables with distinct orders (TaylorN fixes the order for all variables) and it avoids problems related to nested differentiation (see this comment). Among the disadvantages the interface is not transparent, friendly or clear (see #126), and it certainly has problems with memory production, as you point out.

All in all, and until we have a more efficient multivariate solution (see #246, or #85 for a limitation of our approach), I think it is worth having it around, though I agree that we should address some current implementation limitations.

@lbenet
Copy link
Member

lbenet commented Sep 24, 2022

Closing. Feel free to reopen this issue.

@lbenet lbenet closed this as completed Sep 24, 2022
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

No branches or pull requests

2 participants