Could someone explain to me what really borke from 0.17 to 0.18 ?

[lrnv]

Hey,

I got compathelper notices, but have trouble understanding what really broke between the two versions; Could someone point me to the right place to check what broke ?

Thanks !

[lbenet]

There are a bunch of new in-place methods, mostly related to evaluate, ^ and power_by_squaring. Most of these changes will not be noticed on the surface, but e.g., TaylorIntegration uses pow! which did change a lot, and would break previos code. In our bechmarks there are important improvements wrt allocations.

[PerezHz]

Just as a supplement to @lbenet's reply, in v0.17 TaylorSeries.pow! call signature was pow!(c::Taylor1, a::Taylor1, r::S, k::Int), whereas in 0.18 the signature changed to pow!(c::Taylor1, a::Taylor1, ::Taylor1, r::S, k::Int), see for example here:

TaylorSeries.jl/src/power.jl

Line 250 in e5b4989

@inline function pow!(c::Taylor1{T}, a::Taylor1{T}, ::Taylor1{T}, r::S, k::Int) where

This function is called by TaylorSeries e.g. when doing

using TaylorSeries
t = Taylor1(5)
t^10 # calls pow!

As @lbenet explained, the rationale behind this is to avoid unnecessary allocations when computing powers with TaylorSeries. Dependant packages who call directly to pow! will see their code breaking (e.g., TaylorIntegration, PlanetaryEphemeris, NEOs, etc.), otherwise if you're not calling pow! directly in your code then it's probably safe to upgrade to v0.18. Hope this helps!

[lrnv]

Ok I understand. As far as I know, TaylorSeries.pow! is not exported, so a change to its signature is not necessarily a braking change right ? On the other hand, if you want to have this breaking, maybe you could on top export the function (or make it public in 1.11) ?

As far as my packages are concerned, there will be no impact at all then since I rely on ^. Thanks a lot for the explanations !

[lbenet]

I think this can be close; please feel fre to reopen it if you need more clarifications