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. >> >
