Re: small bug fix in ppval

[Jaroslav Hajek]

On Fri, Apr 25, 2008 at 10:07 AM, Shai Ayal <address@hidden> wrote:
> On Fri, Apr 25, 2008 at 10:44 AM, Jaroslav Hajek <address@hidden> wrote:
>  > Shai,
>  >
>  >  the "l" and "r" options for lookup should be documented in new
>  >  lookup's inline documentation (via `help lookup'). If it is not clear,
>  >  blame me (and please report what is broken). Shortly, "l" means extend
>  >  the leftmost interval to infinity, while "r" means the same for the
>  >  rightmost interval. Thus, "lr" is frequently used to get indices that
>  >  are guaranteed to fall inside the table (provided that the table is at
>  >  least 2 elements long).
>  >
>  >  The common expression with the old lookup was to use
>  >  lookup(x(2:end-1), y)+1. This is dangerous, as it breaks for
>  >  decreasing tables of length 3
>  >  (see http://www.nabble.com/binary-lookup-tt16029897.html#a16089657)
>  >
>  >  I'm not sure whether this case can occur here, I've replaced all the
>  >  lookup(x(2:end-1)) expressions I could find since the new form is also
>  >  faster (no temporary arrays).
>  >
>
>
>  Hmm...
>
>  Maybe this change was not propagated to the dev branch? I'm using the
>  latest octave graphics release and it was merged with the main octave
>  repository at Apr 22.
>
>  what I'm seeing in my lookup.m:
>  function idx = lookup (table, xi)
>
>  so this is clearly to old version
>
>  Shai
>
>

It's not, see hg log:

changeset:   7794:4fbaba9abec1
user:        Jaroslav Hajek <address@hidden>
date:        Fri Mar 28 15:53:09 2008 -0400
summary:     implement compiled binary lookup

The lookup function got transferred into comiled form
(src/DLD-FUNCTIONS/lookup.cc),
so your merge probably left also the old m-file version behind.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz