octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #54241] Lookup documentation
Date: Tue, 3 Jul 2018 14:27:38 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

I cleaned up this documentation a bit not too long ago, but I didn't really
look at the details as I didn't want to make too many changes.  I did have
comments about the very things you are mentioning.  See

https://savannah.gnu.org/bugs/?func=detailitem&item_id=52785#comment4

https://savannah.gnu.org/bugs/?func=detailitem&item_id=52785#comment7

Rik mentioned keeping 'lr' because of consistency with other routines.  I sort
of like leaving the infinite extensions up to the user by use of [-inf <rest
of table> inf].

You are correct that it should be idx(i)+1, with consideration for the end
points.  So that should be fixed.  The formula in itself is kind of confusing
to me, simply because it doesn't seem like a conventional math construct.  The
<= means "satisfies", I guess.  Then the "for all" is switching context to
y(i) meaning essentially element-by-element basis.  Typically, when one uses
the expression "for all" in math, it is part of the definition referring so
some independent variable, "for all x in set U".

In a search for a more verbal and more immediately comprehensible explanation,
I would suggest the singular "index of" rather than "indices" of because this
is a unique value.  That is, in set operations (which is sort of what this is)
we can have conceptual operations that return a unique value or multiple
values, e.g., find(rand(1,5) < 0.2) returns multiple values for each unique
input value, if one thinks of 0.2.  I.e., "When table is increasing, for each
element of @var{y} the function returns the index of the last element in
@var{table} that is smaller than or equal to the entry in @var{y}, that is,
...".  There's always ambiguity in the descriptive sentence.

Regarding the lexicographic comparison, in your example shouldn't there be
something equivalent to "y(i)".  That is, since your example has 3 dimensions,
shouldn't it be something like, say

lookup(table, [1 1 1], 'rows')

?  Where is that y in your example?  yd?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]