search

queryverse / IterableTables.jl

Implementations of the TableTraits.jl interface for various packages
Other
79 stars 9 forks source link

Forcing the most specialized iterator #92

Open ChrisRackauckas opened 5 years ago

ChrisRackauckas commented 5 years ago

For the DifferentialEquations.jl iterator, it seems that

using OrdinaryDiffEq

f_2dlinear = (du,u,p,t) -> du.=1.01u
prob = ODEProblem(f_2dlinear,rand(2,2),(0.0,1.0))
sol1 =solve(prob,Tsit5())
using IterableTables, DataFrames
df = DataFrame(sol1)

works, but

using OrdinaryDiffEq

f_2dlinear = (du,u,p,t) -> du.=1.01u
prob = ODEProblem(f_2dlinear,rand(2),(0.0,1.0))
sol1 =solve(prob,Tsit5())
using IterableTables, DataFrames
df = DataFrame(sol1)

doesn't go through the iterator in DiffEqBase, but instead uses a generic one for a matrix (since the solution is a VectorOfArray{Vector} and is thus 2 dimensional, while the first case is 3 dimensional). This seems odd because I would've assumed it would pick the more specialized iterator that's only for DESolution, and I'm not sure where the dispatch logic on this is taking place.

davidanthoff commented 5 years ago

This is a design decision in DataFrames.jl. Your second example triggers this constructor because sol2 isa AbstractMatrix (whereas that isn't true for sol1): DataFrame just generally handles matrix arguments differently.

Other TableTraits.jl sinks don't have this issue: converting things into DataTable from QueryTables.jl or plotting it with e.g. VegaLite.jl, or showing it with ElectronDisplay.jl all works as expected.