Don't feel bad about being outed! This package is shaping up to be absolutely amazing! Your work speaks for itself. I will file some issues as requested.
One point, to be fair about ODE.jl, does support pretty general arrays. Maybe you looked at an older version? mauro3 moved heaven and earth to make the solvers stupid general (maybe too general ... I still can not stand the array of arrays output ... but they had lengthy discussion for why ...), I think their rk-solvers are actually really neat pieces of code for generality (casting the Rational tableaus into any given type etc). When I look at your code you seem to be hard coding Float64 at the moment. So maybe down the road we can port some of the ODE.jl code over if required. I agree that the solver api is way too matlab-y, but using their code it isn't that hard to switch around, I did the same for myself in a non repo package. Any one last time, your are a hero for getting this going. I am dying to start using it in my own work as I love diff.eqs :) On Tuesday, June 7, 2016 at 9:23:55 AM UTC-7, Chris Rackauckas wrote: > > There is a chance I will be adding some bifurcation analysis soon. One of > the projects I'm working on may need to do a bifurcation analysis soon, and > when that happens I am going to make some arclength > and homotopy continuation bifurcation diagram(mers?). It will take the same > ODEProblem type that the ODE solvers use, though I need some good way of > specifying the bifurcation parameter(s) that would bloat the function > definitions. > > 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. > > 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). > > 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. >>> >>
