[Octave-bug-tracker] [bug #52785] some inconsistence in function 'lookup' and 'logspace' help text

[Dan Sebald]

Follow-up Comment #4, bug #52785 (project octave):

Just a couple things related to these changesets.

First, in the "Does-anyone-really-care?" category, what should be the result
for the following?  It doesn't look evenly spaced (chuckle):


octave:20> linspace(-0, 0, 5)
ans =

  -0   0   0   0   0


More seriously, the documentation for lookup() indicates


"If 'y(i) >=
     table(end)' or 'isnan (y(i))' then 'idx(i)' is 'n'."


It's a couple paragraphs later where 'n' is defined, as


"The complexity of the lookup is O(M*log(N)) where N is the size of
     TABLE and"


Perhaps the definition should be brought to just after the first use of 'n'. 
Or, instead of 'n' in the first instance, it could be "then 'idx(i)' is
'size(table)'" since the expression table(end) was used.

To be technically clear, the following option is "extended to minus infinity
for table increasing and infinity for table decreasing" rather than just
"extended to infinity".


     'l'
          Left.  For numeric lookups the leftmost subinterval shall be
          extended to infinity (i.e., all indices at least 1).


i.e.,


octave:64> lookup([1 2 3], -inf)
ans = 0
octave:65> lookup([1 2 3], -inf, 'l')
ans =  1
octave:70> lookup([3 2 1], inf)
ans = 0
octave:71> lookup([3 2 1], inf, 'l')
ans =  1


but I guess the current documentation captures the gist of it.

I'm sort of wondering about the usefulness of 'l' and 'r' options, as these
two kind of obviate the first and/or last table boundary.  Instead of using
'l', one could just add one to the non-'l' result:


octave:72> lookup([1 2 3], 0.5, 'l')
ans =  1
octave:73> lookup([1 2 3], 1.5, 'l')
ans =  1
octave:74> 1 + lookup([2 3], 0.5)
ans =  1
octave:75> 1 + lookup([2 3], 1.5)
ans =  1


That is, the thought that comes to mind is that someone is putting a bogus
left (right) boundary in his or her table just so s/he can use the 'l' option.
 And if that person is going to add another boundary at the front of the
array, s/he must think about the increasing/decreasing aspect of it.  Also,
one could do the following:


octave:126> lookup([-inf 2 inf], 0)
ans =  1
octave:127> lookup([-inf 2 inf], 3)
ans =  2


and achieve a similar result to 'lr'.  That is, rather than put in some
arbitrary left and right extra boundary and use 'lr', just use -inf and inf.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/