[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/
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Michael Leitner, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Mike Miller, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation,
Dan Sebald <=
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Mike Miller, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Mike Miller, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/03
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Michael Leitner, 2018/07/04
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/04
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Michael Leitner, 2018/07/04
- [Octave-bug-tracker] [bug #54241] Lookup documentation, Dan Sebald, 2018/07/04