Hi Chris, DifferentialEquations.jl is an impressive tour de force! Nice work on writing all the documentation too! Below a few comments in-line from my ODE.jl perspective.
(As a side note to those interested in ODE/DAEs: we got a GSoC student, Joseph Obiajulu, working on ODE.jl this summer. Plans are to code more implicit and explicit solvers and put together a solid benchmarking package. He will give a brief overview at JuliaCon.) On Tue, 2016-06-07 at 18:23, Chris Rackauckas <rackd...@gmail.com> wrote: > I do hope that this is able to replace "most" people's needs like the > general MATLAB packages. However, I dumped the idea of just working on > ODE.jl for a few reasons. I think they are too close to MATLAB, and it's > restricting. I'm not just talking about the naming, but a library for > something like solving differential equations should really be using types > to have more functionality. ode45 is limited by MATLAB having to use > function handles. A problem type is much more general: you can define your > SDE problem, do a bifurcation analysis, have it solve trajectories of the > SDE, have it solve the Forward Kolmogorov equations for it, etc., just by > passing the problem to different functions. ODE.jl also has some other > limitations that stem from being basically a MATLAB re-implementation: it > only works with vectors instead of arbitrary arrays, it "fixes" types to > floats instead of letting you use any number implementation, it always > saves every value of the trajectory, and since it doesn't handle the > solutions in an arbitrary type, it does not have a way to easily add extra > functionality like default plots for solutions, error / convergence > calculations, etc. Since I want all of these for the research I'm doing > (numerical methods for SDEs/SPDEs/SDDEs), I decided to just start clean and > do it. First, I am a bit sad that you decided to not channel your considerable energy into improving ODE.jl (at least the part of your work which concerns the ODE solvers). But I can understand that it is at times better to do ones own thing without being restricted. And for sure, the development of ODE.jl has been going at a glacial pace. However, I think the reasons you give above are unfounded. - The Matlab like interface does not preclude a more Julian interface. In fact this is what is being worked on in @pwl's PR: https://github.com/JuliaLang/ODE.jl/pull/49 where the underlying low-level interface is swapped out to use iterators (using types not unlike your ODEProblem), in-place functions, etc. One can use the high-level Matlab-like interface or the low-level one if more control is needed. But yes, it has been a long time coming and it is not there yet... What I do think is that the Matlab-interface is better for casual use and it a de-facto standard. If I quickly want to solve an ode I don't want to deal with types, etc, and I for sure don't want to read documentation about it. But I agree for more advanced use a more advanced interface should be in place; we're working on it. - As has been mentioned by someone else in this thread, the critique that ODE does not handle arbitrary types is wrong. Note that this ability to use arbitrary types has been in ODE.jl for a long time (although not all solvers supported it). See: https://github.com/JuliaLang/ODE.jl/blob/master/test/interface-tests.jl and the PRs: https://github.com/JuliaLang/ODE.jl/pull/98, https://github.com/JuliaLang/ODE.jl/pull/96 (where incidentally I ran into same BigFloat problem you found a few days later: https://github.com/JuliaLang/julia/issues/16667 ) So, after my rebuttal, question for you: what would it take to make you a contributor to ODE.jl? > If you would like to chat about naming problems, find me in the Gitter. If > the community wants the names switched around to match some other > convention, I'd gladly follow that convention (I just did camelCase since > it's what I'm familiar with). The only thing that I am shutting down are > requests to make things more like MATLAB that are based on MATLAB's > non-capabilities. That doesn't mean I don't want to make it easy for > MATLAB-users (maybe I should add in the documentation or tutorial that it > by default uses Dormand-Prince == ode45). My complaint here is that your package does too many things. Could it not be split into several? ODE, PDE, SDE? And then have the master package DifferentialEquations.jl pull those pieces in? For instance working with PDEs, I'm happy to have one package to do the spatial discretisation, say FEM, and another to do the time integration, say ODE.jl or Sundials.jl. Lastly a few things which may be of interest to you, if you're not aware: - https://github.com/mauro3/IVPTestSuite.jl is a package to benchmark ODE/DAE solvers for standard test cases. Would be cool to run your solvers too (Sundials, ODE.jl and DASSL.jl are currently wrapped). @obiajulu, the GSoC student working on ODE.jl this summer, is currently updating it and I'll ping you when done. Basically you'd need to write a wrapper for your solvers and you're good to run. - You don't seem to be calculating Jacobians yet, but if that it planned coloring might be of interest: https://github.com/mauro3/MatrixColorings.jl Again, this has gone a bit stale (together with my PR https://github.com/JuliaLang/ODE.jl/pull/72 for which I made it) but I would be interested to revive it. Cheers, Mauro > Also, feel free to open up issues with feature requests / naming changes / > extra documentation. Remember the package is less than a month old so it > does not implement even close to what I am aiming for, and issues will help > prioritize the work. I am currently finishing up some parts for > higher-order SDEs since I am giving a presentation in Barcelona on them at > the end of June, but after that I am going to keep implementing more > solvers. When the paper that's associated with it is published, the > presentation is done, and Plots.jl tags its new version, I will make sure > the documentation is up to date and do a v0.1 release sometime in July. > > I was hoping to do a big v0.1 release where I'd announce to julia-users > with explanation of scope, some tutorials on my blog (you can see some > extra example animations already in /src/examples) and better > documentation, but I guess this is how things go. > > On Tuesday, June 7, 2016 at 6:43:23 AM UTC-7, Gabriel Gellner wrote: >> >> I think the name makes a tonne of sense given the scope, and fits in the >> line with many standard packages: Calculus, Optim, Distributions, etc. >> There is no reason that if a great Bifurcation suite grows it couldn't be >> part of DifferentialEquations (though that feels weird to me personally). >> >> Also I for one feel we should all be stupid thankful that someone is >> pushing on this issue. I find diffeq solvers are one of the weakest areas >> of Julia currently. Graphs, Stats, Optimization all feel at a level that is >> very comfortable to replace general packages like Matlab for me (at a first >> approximation) but man solving these kinds of equations in julia feels >> barely passible. It is a herculean task to get this support in and Chris >> seems to be doing it with crazy determination. He could call the pacakge >> the OneTrueSolutionToSolvingEverything and I would support it! >> >> It will kill me that it will be camelCase mind you ... Julia needs a PEP8 >> linter bad ;) >> >> On Tuesday, June 7, 2016 at 1:48:51 AM UTC-7, jonatha...@alumni.epfl.ch >> wrote: >>> >>> Your package is about computing numerical solutions of differential >>> equations. Differential equations are something a bit more general, for >>> example a package for bifurcation analysis could also want to call itself >>> "DifferentialEquations". I don't really have a better name... >>> NSolveDiffEqus ? That said I don't think you really need to rename it. >>> >>
