They are great solvers, I wasn't questioning their quality at all. My reasoning behind wanting to implement these functions is to attract more MATLAB users to Octave. Octave is such a great piece of software but people still find reasons to pick MATLAB over it, and language compatibility is one of them. People say things like, "Oh, well Octave doesn't have this function, we need MATLAB." If we have a complete set of the more commonly used functions (which you pretty much already have), then people can't use that argument. I know we can't probably don't want to duplicate all of MATLAB's toolboxes, but ODEs are common across all fields so I think it would be expected to at least have wrapper functions for them. That way, people coming from MATLAB don't see errors. I think wrapper functions are pretty much the best we could do anyway, as I'm not sure if we could find enough information to completely duplicate the algorithms used in MATLAB.
-----Original Message----- From: John W. Eaton [mailto:[email protected]] Sent: Friday, June 04, 2010 10:54 AM To: Jake Cc: [email protected]; [email protected]; [email protected] Subject: A few (Octave) ideas 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
