On Feb 19, 2008 8:47 AM, John W. Eaton <[EMAIL PROTECTED]> wrote: > On 18-Feb-2008, Jaroslav Hajek wrote: > > | I agree. My intention was to put this into Octave-Forge for anyone > interested, > | so that anyone installing the Octave-Forge package gets the optimized > | version (I think .oct files have "higher priority" than .m files). > | If anyone of you Octave's maintainers decides that the function is worth > | including into Octave itself, you can simply do it (and possibly remove > | it from the Octave-Forge package). > | > | Perhaps it would be a better idea to create a whole new package that > | would contain > | optimized (or otherwise improved) versions of Octave's library > | functions, so that they can > | be tested and eventually included. > > We used to have a number of functions like that in Octave Forge and we > made it a goal to remove them. The problem was that the replacement > functions often behaved in different ways than the functions of the > same name in Octave and that just caused confusion for unsuspecting > users. It's possible that someone writes an improvemed version of a > function and then another person who doesn't know that the improved > version exists (he only sees the function in Octave) independenly > improves the function, perhaps even making the "improved" function in > Octave Forge no longer as good as the updated version in Octave, or > simply incompatible. So if you want to improve on an existing Octave > function, please work with us to improve Octave by submitting bug > reports and patches for Octave rather than creating a separate package > that overrides the functions in Octave. > > Thanks, > > jwe >
OK, I've removed the function from Octave-Forge. What do you think about including this function into Octave (i.e. replacing the current m-file version?) My primary motivation for optimizing this was the TODO comment in the current lookup.m, that actually suggests writing a such an implementation, pointing out the worse asymptotic complexity and real-life performance. It even seems there had been a binary search m-file implementation before, but was later rejected for being too slow. regards, -- RNDr. Jaroslav Hajek computing expert Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
