bugGNU Octave - Bugs: bug #50716, Undefined input to a classdef...

 
 

bug #50716: Undefined input to a classdef method

Submitter:  Guillaume <gyom>
Submitted:  Tue 04 Apr 2017 02:42:25 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Guillaume 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

Fri 14 Dec 2018 10:10:50 AM UTC, comment #13: 

From what I can see, it can indeed be closed. Probably same thing with bug #44779.

I still have problems with the "end" function but there is another open report for that in bug #54783.

Guillaume <gyom>
Thu 13 Dec 2018 08:23:57 PM UTC, comment #12: 

This bug is marked "Ready for Test" since 2017.  Can it be closed?

Rik <rik5>
Group administrator
Wed 05 Apr 2017 06:38:43 PM UTC, comment #11: 

CarnĂ«: Yes, I think it's the same problem.  Is it fixed now, or was inputParser modified to avoid the bug?

John W. Eaton <jwe>
Group administrator
Wed 05 Apr 2017 05:59:43 PM UTC, comment #10: 

Is this related to bug #44779 ?

Carnë Draug <carandraug>
Group Member
Wed 05 Apr 2017 04:34:31 PM UTC, comment #9: 

Yes, a(floor(end)) is a little weird, but I'm fairly certain we did have a bug report about a(fcn(end)) not working "correctly".

And yes, the function handle case is different because Octave is evaluating the handle first and then doing the same thing as if you had used the function name directly.  But Matlab is saying "f" is a variable and its size is 1x1 (the size of an ordinary function handle object).

John W. Eaton <jwe>
Group administrator
Wed 05 Apr 2017 04:15:46 PM UTC, comment #8: 

I start to see how tricky it can be... I find "a(floor(end))" a rather strange construct though - I wonder how often something likes this occurs.

While trying to get my head around it, I came across this:


a = 10:10:100;
b = [1,2,3];
f = @(x) x;
a(f(end))


Octave says 100 and Matlab R2017a says 10...

Guillaume <gyom>
Wed 05 Apr 2017 03:58:45 PM UTC, comment #7: 

In my example in comment #6, make a = 10:10:100 and the difference is more obvious.

John W. Eaton <jwe>
Group administrator
Wed 05 Apr 2017 03:50:32 PM UTC, comment #6: 

Maybe I chose a bad example.  The problem is that in order to determine the size of the object that end refers to (or the object to pass to the "end" function, you have to be able to determine which object that is.  In some cases, it is not simply the immediately preceding object.  For example:


a = [10,20,30];
b = [1,2,3];
a(b(end)) ## end refers to the end of b
a(floor(end)) ## end refers to the end of a


If there are some simple rules for how to evaluate this kind of expression, then I'm not quite seeing them yet.

John W. Eaton <jwe>
Group administrator
Wed 05 Apr 2017 03:07:34 PM UTC, comment #5: 

Thanks for the explanation and the changeset. It solves the issues I was reporting.

I understand all problems are not solved as shown in some of your tests:


val = foo{end}.methodA (str(1:end));


Given that "end" always applies to the enclosing variable, "str" here, it is not entirely clear to me what the ambiguity is.

Guillaume <gyom>
Wed 05 Apr 2017 01:18:01 PM UTC, comment #4: 

I checked in the following change that appears to avoid the specific problem reported here:

  http://hg.savannah.gnu.org/hgweb/octave/rev/957d95286f52

Note that this changeset also adds a couple of tests that show that not all problems with "end" and indexing classdef objects are completely solved.

John W. Eaton <jwe>
Group administrator
Wed 05 Apr 2017 12:00:16 PM UTC, comment #3: 

Yes, this error is happening because of "end" in the indexing expression.  Suppose you have


s.a = [1,2,3,4];


Then to evaluate the expression


s.a(2:end-1)


you need to know the number of elements of "s.a", so you have to evaluate that first.  It's as if you had the expression


s.a (2:numel(s.a)-1)


But the meaning of this expression is different if "s.a" is a object method call instead of a struct indexing operation.

It's tempting to try to transform "end" expressions when they are parsed, but it is not that simple and must be done when the expression is evaluated.

John W. Eaton <jwe>
Group administrator
Wed 05 Apr 2017 10:58:09 AM UTC, comment #2: 

Yes, as soon as the expression contains "end" somewhere, it is understood as calling the method without input arguments and calling subsref on the output with the rest of the expression.

You can reproduce it with inputParser:


p = inputParser ();
p.addOptional ("ver", version()(1:end));
p.addOptional ("ver", struct('a',version()(1:end-2),'b',''));


Guillaume <gyom>
Tue 04 Apr 2017 08:14:03 PM UTC, comment #1: 

Agree, I see the same thing with Python objects (implemented with classdef).

With no colon expression, the parser seems to handle it as a subsref call on "obj.method", which maps to a normal method call. Same with a colon expression that does not contain "end".

With an "end" expression, it seems to be treating the following as equivalent


obj.method(s(1:end))
obj.method()(s(1:end))


The subsref operation is done on the result of calling "obj.method" with no arguments.

Mike Miller <mtmiller>
Group Member
Tue 04 Apr 2017 02:42:25 PM UTC, original submission:  

Using the following class:


classdef myclass < handle

  methods
    function obj = myclass
    endfunction

    function methodA (obj, varargin)
      varargin
    endfunction

  endmethods

endclassdef


call the methodA() method on a myclass object:


>> obj = myclass ();
>> str = "Octave";
>> methodA (obj, str);
varargin =
{
  [1,1] = Octave
}
>> obj.methodA (str);
varargin =
{
  [1,1] = Octave
}
>> methodA (obj, str(1:end));
varargin =
{
  [1,1] = Octave
}
>> obj.methodA (str(1:end));
varargin = {}(0x0)
error: invalid dimension inquiry of a non-existent value


The error seems to be linked to the use of 'end' in the method call, ie it works with str, str(1:5) or with 'val' having been previously defined as str(1:end).

Guillaume <gyom>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by amro_octave
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by gyom (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-12-14 mtmiller Carbon-CopyRemoved 80942 -
    2018-12-14 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-07-03 amro_octave Carbon-Copy- Added amro_octave
    2017-04-05 jwe StatusNone Ready For Test

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code