On 3-Jun-2010, Jake wrote: | 1. Is there a reason why these functions haven't already been implemented? | Lack of information on the algorithms, perhaps?
Or, given that we have other ODE/DAE solvers that are quite good, no compelling reason other than compatibility to write them? | 3. Are there any reasons why I shouldn't try to implement these functions? I think it would be fine to have them, and even include them in the core Octave distribution. For that to happen, the code should follow Octave's coding conventions, and it is essential that the work be independent of Matlab, so you must not base your implementation on the Matlab functions in any way, other than making the interface compatible. In the past, when I've needed the odeNM functions for compatibility, I've used wrapper functions for lsode or daspk that provide the odeNM interface. That works well enough for me that I haven't had the need to actually have the odeNM functions that use the same class of algorithms used in the Matlab functions. I haven't included my wrapper functions in Octave because they've never been complete implementations. Is it necessary to have odeNM functions that use the same algorithms as the corresponding Matlab functions, or is it sufficient to simply provide the same interface while using some other algorithm to solve the same problem. If the latter, then wrappers around lsode and daspk might be easier to implement. jwe ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
