Re: [OctDev] optimized lookup

[Jaroslav Hajek]

On Feb 19, 2008 8:47 AM, John W. Eaton <address@hidden> 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