bugGNU Octave - Bugs: bug #59103, inputname() is incorrect for...


bug #59103: inputname() is incorrect for string-like numeric inputs such as Inf, NaN, i

Submitted by:  Rik <rik5>
Submitted on:  Sat 12 Sep 2020 08:39:20 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev 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)

Wed 16 Sep 2020 08:17:55 PM UTC, comment #8: 

I checked in my changes here http://hg.savannah.gnu.org/hgweb/octave/rev/4e10e25f0fc6.

It's not perfect compatibility, but since I reported the bug I can also say that I'm happy enough with the new level of fidelity.  Marking as fixed and closing report.

Rik <rik5>
Project Administrator
Wed 16 Sep 2020 03:46:55 PM UTC, comment #7: 

OK, I think this function was a mistake in Matlab and it doesn't matter to me whether it works.  The note in the Matlab docs about it not working in the context of subsref (for example) and the fact that the arrayfun + function handle thing works the way it does all point to this function relying on implementation details.  My solution doesn't make the arrayfun example work either, so I'd say "fix" it in the simplest way possible.

John W. Eaton <jwe>
Project Administrator
Wed 16 Sep 2020 03:13:24 PM UTC, comment #6: 

Attached is my version of a fix which takes place at the m-file level.  Whichever changeset we adopt, we should make the changes I did for the BIST tests.  I eliminated their current dependency on the internal workings of test.m which might change at some point in the future.

Regarding the first question, inputname called at the command prompt or in a script throws an error rather than just returning "".  I wrote a fairly long FIXME note in the m-file detailing some of the differences with Matlab, but also recommending that we not bother to fix them.

(file #49798)

Rik <rik5>
Project Administrator
Wed 16 Sep 2020 01:46:28 AM UTC, comment #5: 

Oops, proposed changeset I mentioned in comment #4 is attached here.

(file #49797)

John W. Eaton <jwe>
Project Administrator
Wed 16 Sep 2020 01:43:17 AM UTC, comment #4: 

I also spent some time trying to figure out how to get compatibility.  My latest attempt is attached.  I don't think it is correct, as it fails for the arrayfun example in the Matlab docs for inputname.

I would still be interested to know what happens for the following in Matlab:

What does

inputname (1)

say at the top-level command prompt?

If the following commands are placed in a script, what happens when you execute it?

abcdefg = 1
fh_n = @(n, x) inputname (n)
fh_n (2, abcdefg)

What about this script?

abcdefg = 1;
fh_1 = @(x) inputname (1)
fh_1 (abcdefg)

What happens if you define and execute the following function?

function foofun_n ()
  abcdefg = 1;
  fh_n = @(n, x) inputname (n)
  fh_n (2, abcdefg)

And this one?

function foofun_1 ()
  abcdefg = 1;
  fh_1 = @(x) inputname (1)
  fh_1 (abcdefg)

I could be surprised, but my guess is I'll be even more convinced that the inputname function belongs in the "WTF, Matlab?!?" category.

John W. Eaton <jwe>
Project Administrator
Tue 15 Sep 2020 08:08:32 PM UTC, comment #3: 

I reported the bug, and also spent some time investigating fixes.  I'll probably push a changeset soon.

I don't think we need to strive for ultimate Matlab compatibility in this function.  To do so would probably mean reverse engineering the guts of part of their interpreter which would be messy.  It's also not a function that sees a lot action or is used in the tightest inner loops of programmer's code which also makes this less crucial.

Rik <rik5>
Project Administrator
Tue 15 Sep 2020 06:52:47 PM UTC, comment #2: 

Thanks for looking at this, but I don't think you can simply look at the base workspace.  The Matlab docs for inputname say that it walks up the stack until it finds a call from Matlab code and gets the variable names corresponding to the arguments from that stack frame.  It looks like we need to do the same to achieve compatibility for things like the arrayfun example in the "Tips" section of the Matlab documentation for inputname.

A related issue is that Octave currently attempts to store a text representation of the expression passed in the argument list even when it is a complicated expression.  It's expensive to do that, but I must have assumed when I first tried to implement inputname that it was necessary.  But looking at it now, it seems that the only thing that we need to store is the name of simple identifiers when they appear as arguments and everything else is ignored.  Is that correct?  If so, then I think the code that creates index expressions can be made significantly simpler.

Note that the Matlab docs also say that inputname returns an error if it is called inside an overloaded subsref, subsasgn, subsindex, numArgumentsFromSubscript, numel, or property set or get method.  What?

John W. Eaton <jwe>
Project Administrator
Tue 15 Sep 2020 06:15:55 PM UTC, comment #1: 


I have had a look at the implementation of inputname and I think the usage of "isvarname" is incorrect. I was expecting isvarname("Inf") to be 0 but I get:

octave:1> isvarname("Inf")
ans = 1

I believe that the "exist" function would achieve the intended result. "inputname" could return an empty string if "exist(NAME)" gives a result different than 1 (meaning that NAME is a variable).

octave:2> exist("Inf")
ans =  5

For this to work, "exist" must be evaluated in the base context though. So it would look like this

  valid = evalin ("base", sprintf ("exist (\"%s\")", name));
  if (valid != 1)
    name = "";

instead of

  if (! isvarname (name))
    name = "";

I am new here so I am not sure if this is correct.

sebkm <sebkm>
Sat 12 Sep 2020 08:39:20 PM UTC, original submission:  

Consider this test function which is also attached to this bug report:

function tst_inputname (arg1)
  inputname (1)

When called with a numeric input the result is an empty string ("")

octave:1> tst_inputname (1)
ans =

However, when called with a numeric input that looks like a string the result is a string, rather than an empty value.

octave:2> tst_inputname (Inf)
ans = Inf
octave:3> tst_inputname (j)
ans = j

Matlab correctly returns an empty string for these cases.

Rik <rik5>
Project Administrator


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

Attach Files:

Attached Files
file #49798:  bug59103.cset added by rik5 (9KiB - application/octet-stream)
file #49797:  inputname-cset.txt added by jwe (10KiB - text/plain)
file #49790:  tst_inputname.m added by rik5 (58B - text/x-matlab)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by sebkm (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-09-16 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2020-09-16 rik5 Attached File- => Added bug59103.cset, #49798
    2020-09-16 jwe Attached File- => Added inputname-cset.txt, #49797
    2020-09-15 rik5 StatusConfirmed => In Progress
    2020-09-12 rik5 Attached File- => Added tst_inputname.m, #49790

    Back to the top

    Powered by Savane 3.5