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

 
 

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

Submitter:  Rik <rik5>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group administrator
Tue 15 Sep 2020 06:15:55 PM UTC, comment #1: 

Hello,

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 = "";
  endif

instead of

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


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


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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group 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.13-d3ae.
    Corresponding source code