Yingbo Ma

Yeah, probably won't be a priority once we have FBDF (FLC BDF). Currently, CVODE_BDF still wins in a few HVAC systems.

Note that differentiating wrt only differential variables works ```julia julia> Zygote.gradient(p) do p sum(Array(solve(prob_DAE, Rodas4(), saveat=Δt, p=p, sensealg=InterpolatingAdjoint(), abstol=1e-12, reltol=1e-12))[1:4, :]) end ([-27.3837202302557],) julia> ForwardDiff.gradient(p) do p sum(Array(solve(prob_DAE, Rodas4(), saveat=Δt,...

I know. I am not saying this is not an issue.

We don't have an overload for `DiscreteProblem` yet. @ChrisRackauckas I think for `DiscreteProblem`s we need AD pass through.

We want to maintain the invariance `g(::T)::T` for out of place functions. If you are using `view`, I think you want to use the inplace version of the built function....

If you want to save memory cost with `view`, you might as well just use the inplace version, that's why they are there.

Yeah, I am looking into this problem. The `Symbolics.solve_for([x + y ~ 2//1, x - y ~ 1//1], [x, y])` example is arguably a bug.

 Most of the time is spent on polyize. Also, seems like we cannot simplify basic fractions ```julia julia> using Symbolics julia> @variables x; julia> expr = ((5//1) + x)...

`@code_native` loses insight, because it removes high-level constructs. The issue here is because `my_add2!` is a non-const global variable. ```julia my_add2!(a) = my_add2!(a,a) #why does this not work? ``` a...

Not sure if you noticed, but ```julia const my_add2! = eval(ModelingToolkit.build_function(a_copy,a)[2]) my_add2!(a) = my_add2!(a,a) ``` should already error. The performance problem here is not suboptimal code generation by the compiler....