bugGNU Octave - Bugs: bug #52785, some inconsistence in function...


bug #52785: some inconsistence in function 'lookup' and 'logspace' help text

Submitted by:  None
Submitted on:  Tue 02 Jan 2018 07:49:52 AM UTC  
Category:  Documentation Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.1
Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 08 Jan 2018 01:44:49 AM UTC, comment #8:

@Dan: I pushed your lookup changes here (http://hg.savannah.gnu.org/hgweb/octave/rev/a00033be2134).

Rik <rik5>
Project Administrator
Sat 06 Jan 2018 11:20:22 PM UTC, comment #7:

Attached is a changeset making the change to how N is used. It also removes what looks like a duplicate test on some local variable. I then saw a FIXME in there about cruft related to case-insensitive greater-than and less-than test, so I looked at the background of that and decided that can go. The code are fairly short routines that can be re-coded without too much thought, plus JWE introduced the use of C++ classes five to eight years ago such that the lexicographical comparisons are done deep within Array or its relatives. So either that lexicographic test would have to be done there, or a more local solution would be to first convert 'table' and 'y' to upper or lower-case before applying the lookup methods.

However, as regards to the actual use of case-insensitive code in the app, I found the following references to the use of an 'i' option around 2010, and I conclude this 'i' option isn't coming back:






The main issue was that applying toupper or tolower inherently introduces a scrambling of the 'table' strings which puts it in the "undefined behavior" category. So really, if a user is interested in case-insensitive analysis s/he would be best using toupper and tolower and sorting prior to the lookup() routine.

(file #42862)

Dan Sebald <sebald>
Sat 06 Jan 2018 04:21:18 PM UTC, comment #6:

The answer is:
< M A T L A B (R) >
Copyright 1984-2017 The MathWorks, Inc.
R2017b ( 64-bit (glnxa64)
September 14, 2017

To get started, type one of these: helpwin, helpdesk, or demo.
For product information, visit http://www.mathworks.com.

>> linspace (-0,0,5)

ans =

0 0 0 0 0

Michael Godfrey <godfrey>
Project Member
Sat 06 Jan 2018 03:30:09 PM UTC, comment #5:

I asked for someone to test on Matlab the following code:

I don't think we want to mess with 'l' and 'r'. interp2 and ppval both use 'lr' in combination, and ismember is using 'm' and 'b'. In order to do away with those options in lookup it would require carefully analyzing a lot of code I would prefer to leave alone.

If you can make a documentation patch for the definition of 'n' issue that would be good.

Rik <rik5>
Project Administrator
Sat 06 Jan 2018 09:42:35 AM UTC, comment #4:

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):

More seriously, the documentation for lookup() indicates

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

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".


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:

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:

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.

Dan Sebald <sebald>
Fri 05 Jan 2018 05:32:43 AM UTC, comment #3:

So many pesky little things to fix. I changed the remaining instance of "val" to "y" here http://hg.savannah.gnu.org/hgweb/octave/rev/d68d1096d294.

Rik <rik5>
Project Administrator
Fri 05 Jan 2018 12:53:09 AM UTC, comment #2:

in the newest version there is one 'val' left which should be 'y' as well.

Thu 04 Jan 2018 05:51:12 AM UTC, comment #1:

I fixed the issues identified in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/5188d936c79a).

I also re-wrote the linspace documentation to be clearer.

Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Tue 02 Jan 2018 07:49:52 AM UTC, original submission:

help lookup:

There is no definition of variable 'val'.
'val' might be 'y' according to the context.

help logspace:

The behavior of logspace is that
if N==1, it returns 10^B or pi, but not 'B'.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-06 sebald Attached File- => Added octave-lookup_doc_change_code_cleanup-djs2017jan06.patch, #42862
    2018-01-04 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed

    Back to the top

    Powered by Savane 3.3