[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OctDev] optimized lookup
From: |
Jaroslav Hajek |
Subject: |
Re: [OctDev] optimized lookup |
Date: |
Tue, 19 Feb 2008 09:30:48 +0100 |
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
- Re: [OctDev] optimized lookup, David Bateman, 2008/02/18
- Re: [OctDev] optimized lookup, Jaroslav Hajek, 2008/02/18
- Re: [OctDev] optimized lookup, John W. Eaton, 2008/02/19
- Re: [OctDev] optimized lookup,
Jaroslav Hajek <=
- Re: [OctDev] optimized lookup, John W. Eaton, 2008/02/19
- Re: [OctDev] optimized lookup, Jaroslav Hajek, 2008/02/19
- Re: [OctDev] optimized lookup, John W. Eaton, 2008/02/19
- Re: [OctDev] optimized lookup, John W. Eaton, 2008/02/19
- Re: [OctDev] optimized lookup, Jaroslav Hajek, 2008/02/20