[Octave-bug-tracker] [bug #54241] Lookup documentation

[Michael Leitner]

Follow-up Comment #9, bug #54241 (project octave):

Dan: interesting that you had just the same feeling with regard to 'l' and 'r'
as I had. Indeed, these are just syntactic sugar (with not much energy content
at that), because you do not even need to explicitly extend your table to
infinity: as I said,  lookup(table,y,'l') is always equal to
lookup(table(2:end),y)+1, and lookup(table,y,'r') is equal to
lookup(table(1:end-1),y). And of course, lookup(table,y,'lr') is equal to
lookup(table(2:end-1),y)+1. So not many bytes of code can be saved by using
these options, at the expense of having to maintain the code in lookup and
making the documentation more intimidating. And I too find it counterintuitive
that there are options that make a function explicitly ignore an element of
the input, when I could equally have just removed the element from the input
(note that with Octave's memory management writing table(2:end) does not take
any significant memory overhead). But if there are a number of functions that
use these options, it is probably really something we will have to live with.
Further: as I read the code of lookup, actually the function do_numeric_lookup
in libinterp/corefcn/lookup.cc, it seems to me that the behaviour of 'l' and
friends is provided by post-processing. So I would have assumed that
lookup(table,y,'r') takes longer than lookup(table,y), while my proposal of
lookup(table(1:end-1),y) should have been faster, because it does not do
post-processing and the table is smaller. But the timing results do not
confirm this, actually using 'l' and friends is faster. Does anybody
understand why this is?

As regards the case of unsorted tables: the behaviour is undefined, that is,
anything can happen. What probably will happen is that lookup does interval
bisection and stops once it has found an idx so that
table(idx)<=y<table(idx+1), which is not necessarily the first. So in this
case also my definition looks incorrect, but is not, since everything is under
the condition of sorted tables. 

As regards my "rows" proposal: yes, in my example I define table and y, and I
would like to be able to do 


idx=lookup(table,y,"rows");


I can get the desired behaviour by the three lines I indicated, but that is
not something the average user would come up with, and it also took me ten
minutes or so. I do not see inhowfar I would need a y(i). 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54241>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/