SciML
DEDataArray factorization overloads cause type ambiguity errors
I'm not sure if this is intended or not, but it appears that the existing DEDataArray factorization overloads cause type ambiguity errors for stiff solvers, e.g:
LinearAlgebra.ldiv!(F::Factorization, B::DEDataArray) = ldiv!(F, B.x)
causes a type ambiguity error with the the LU factorization methods in LinearAlgebra because DEDataArray is more specific than AbstractArray but Factorization is less specific than LU.
This forces the user to define their own more specific method to resolve the ambiguity, which kind of seems to nullify the point of providing this method in the first place...?
Shouldn't these functions "just work" without these ambiguous overloads since DEDataArray is already an AbstractArray?
This is starting to go into bad news bears territory because linear algebra doesn't always respect the propagation of the non-array variables, so it might have different semantics than you want. This is actually why I think I'm going to deprecate DEDataArray.
You mean because of the distinction between DenseArray and AbstractArray? Or do you mean that it won't always copy things properly?
DEDataArray is kind of what solved my problem with having extra (non-integrated) state variables, so is there an alternative? Of course the user can still specify their own custom array type without DEDataArray but there's a lot of method overrides that are necessary.
I mean it's undefined how to copy things through some operations. I just don't think that is good behavior to have. And it carries memory in ways that are not optimal. I think MTK is just going to be more efficient and have more clean semantics in all but a very few cases.
But doesn't MTK turn everything into an ODEProblem in the end? Seems like you would still have this problem.
I experimented with MTK early on and it seemed like it wasn't really able to do this (i.e. have non-integrated state).
It now has a whole observables system. MTK is a very fast moving project.