On Friday, 24 April 2015 00:03:29 UTC+2, François Fayard wrote: > I'll have to reimplement the algorithm using my own "methods". Numerical > Recipes are just implementation of known algorithms. But it's true that they > are not fully documented and they use many tricks that make the code not that > clear. I'll rework the code.
I am no lawyer, but as Tim says this doesn't sound encouraging [1] "You want to translate some (or all) the Numerical Recipes routines to a different computer language, and then redistribute the resulting translations. If you are a licensed NR user, you can make any personal use you want on a licensed screen, including translating NR to another computer language. However, you can't redistribute the translations in any manner, since they are "derivative works" and still subject to our copyright. If you'd like your translations to be included, with attribution to you, in the next version of the Numerical Recipes Multi-Language Code CDROM, we're usually happy to oblige; but, alas, we are not able to offer you any financial compensation for this contribution. (The CDROM now has Modula 2, BASIC, and Lisp versions contributed in this manner.)" > > Any advice on the "Julia" questions ? 1) type unstable odesolver: I think it wouldn't prevent creating an executable, it might just be not most efficient. Why don't you use different method types to create your solution object? Either you only use the respective type constructors or you make odesolve take the *type* of the respective method instead of a string/symbol. 2) Interfaces for types can be defined implicitly by the set of functions that the types need to support. For example, ODE.jl (currently) works for all types that support `norm`, `+`, `-`, multiplication with/division by scalars. Maybe the Traits.jl package is also interesting in this context [2]. Anyways, for a start using <: AbstractVector might cover most of your wishes. 3) ODE.jl uses non-mutating rhs functions as you say, but mostly for historical reasons. You definitely want to allow mutating rhs. One way to do this is by introducing a "problem type", which can be created by either providing a mutating or a non-mutating rhs function. Internally you always use the mutating version. I think we discussed this at some point, but I can't find the issue right now (maybe [3]). Best, Alex. [1] http://www.nr.com/licenses/redistribute.html [2] https://github.com/mauro3/Traits.jl [3] https://github.com/JuliaLang/ODE.jl/pull/33
