Christopher Rackauckas

yes, it might be sensitive to the type on the output there.

```julia using DifferentialEquations, BenchmarkTools function dineq!(dy,y,p,t) mu = p[1] xp, yp, zp, vx, vy, vz = y ro1 = sqrt((xp+mu)^2 +yp^2 +zp^2) ro2 = sqrt((xp-(1-mu))^2 +yp^2 +zp^2) dy[1] = vx...

Yes, we should keep it tracking.

Yup, I know we're missing this, and tooling for integro differential equations, and want to get something together for users.

Yes, it seems to be transposed. Luckily the transpose works: `df = DataFrame(sol1')`. https://github.com/queryverse/IterableTables.jl/issues/92 takes a peak into this. Someone who knows the data iterators might need to handle this.

I think it will always be incorrect, since it broke with a DataFrames update.

It would be interesting to do this in DiffEqBase, and instead somehow define `algorithm(:X)(args...) = X(args...)` generically, then yes we could move the default handling out of DifferentialEquations.jl proper.

I think this will be more pressing by this summer when our native methods are performing better than BDF even in the asymtopic cases (we are getting close), but until...

New number types always find fun things. This is as far as I could get without hitting an impasse: ```julia using OrdinaryDiffEq, FixedPointNumbers f(u,p,t) = u u0 = Fixed{Int32,7}(0.5) tspan...

This seems to cause downstream failures. See ```julia function multiple_shoot( p::AbstractArray, ode_data::AbstractArray, tsteps::AbstractArray, ensembleprob::EnsembleProblem, ensemblealg::SciMLBase.BasicEnsembleAlgorithm, loss_function, continuity_loss, solver::DiffEqBase.AbstractODEAlgorithm, group_size::Integer; continuity_term::Real=100, kwargs... ) datasize = size(ode_data, 2) prob = ensembleprob.prob if...