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

[Dan Sebald]

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

There aren't that many uses of lookup.  Just do a 


grep "lookup" */*/*.m
grep "lookup" */*/*/*/*.m


lookup() is being used in several places in a way similar to what you are
doing by truncating the input table vector.

Your assumption about the memory efficiency of x(1:end-1) is likely incorrect.
 Consider these tests:


octave:3> tic; for i=1:100000; lookup(table,y,'r'); end; toc
Elapsed time is 3.49451 seconds.
octave:4> tic; for i=1:100000; lookup(table(1:end-1),y); end; toc
Elapsed time is 5.35454 seconds.
octave:5> tic; for i=1:100000; table; end; toc
Elapsed time is 0.0756271 seconds.
octave:6> tic; for i=1:100000; table(1:end-1); end; toc
Elapsed time is 1.99329 seconds.


My guess is that to implement what you are thinking, i.e., that x(1:end-1) is
simply an input and hence no new vector or parsing consideration is needed,
would probably require some fair amount of work on JWE's part.  There'd have
to be some kind of reference to a vector for which the referencing
"sub-vector" has a start and stop index specifying a subrange.  That info
would be needed for checking conformance, internal loop limits, etc.

The option "m" (and hence "b") seems like it could be accomplished with the
routine ismember(), which already has a "rows" option.  I can see the "rows"
option as useful for lookup().  There might be big-data users who have a need
for organizing in a lexicographic manner.  Lexicographic is already used for
strings in cell-lookup anyway, so maybe it's not all that difficult to
implement.

Yes, your definition isn't quite correct, hence neither mine.  They are close,
but also the endpoint handling is a monkey wrench in a simple definition. 
There is even a conflicting aspect of the current definition with this
example:


octave:25> lookup([3],5*rand(5,1),'lr')
ans =

   1
   1
   1
   1
   1


I.e., this is a case where 'r' doesn't mean all induces are at most N-1, i.e.,
0.  But that's really not a case where someone would use lookup().  Plus, the
case of table monotonically decreasing.

I would say:

1) Fix the "table(idx(i+1)) should be table(idx(i)+1)".

2) Consider explicitly writing out the formula and endpoints for the
monotonically decreasing table scenario.  It would be a matter of convenience
for the user.  E.g.,

"
If the table is decreasing, then the tests are reversed.  I.e.,
<correct formula and endpoints here>

For non-strictly monotonic tables, empty intervals are
always skipped. The result is undefined if TABLE is not monotonic, or if TABLE
contains a NaN.
"

3) Implement "rows" as an option.

    _______________________________________________________

Reply to this item at:

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

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