[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: small bug fix in ppval
From: |
Shai Ayal |
Subject: |
Re: small bug fix in ppval |
Date: |
Fri, 25 Apr 2008 11:39:03 +0300 |
On Fri, Apr 25, 2008 at 11:19 AM, Jaroslav Hajek <address@hidden> wrote:
>
> On Fri, Apr 25, 2008 at 10:13 AM, Shai Ayal <address@hidden> wrote:
> >
> > On Fri, Apr 25, 2008 at 11: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
> > >
> >
> > OK, I understand the problem now -- the old lookup.m was not removed
> > by the merge process. Ooops...
> > How do we make sure thid does nto happen again in future merges?
> > How do we remove all old files which were not removed in previous merges?
> >
> > Shai
> >
>
> Can this be a Mercurial bug?
>
> Anyway, because the compiled .oct files are preferred when looking up
> a function name, no harm can actually be done - just a redundant file.
I'm not sure how this happned, but clearley in the make process the
m-file version was preferred. Once I removed the m-file compilation
was fine
Shai