You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered: