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

 
 

bug #50716: Undefined input to a classdef method

Submitted by:  Guillaume <gyom>
Submitted on:  Tue Apr 4 14:42:25 2017  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Unexpected Error
Status: Ready For TestAssigned to: None
Originator Name: GuillaumeOpen/Closed: Open
Release: devOperating System: Any

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Wed Apr 5 18:38:43 2017, 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>
Project Administrator
Wed Apr 5 17:59:43 2017, comment #10:

Is this related to bug #44779 ?

Carnë Draug <carandraug>
Project Member
Wed Apr 5 16:34:31 2017, 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>
Project Administrator
Wed Apr 5 16:15:46 2017, 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:

Octave says 100 and Matlab R2017a says 10...

Guillaume <gyom>
Wed Apr 5 15:58:45 2017, comment #7:

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

John W. Eaton <jwe>
Project Administrator
Wed Apr 5 15:50:32 2017, 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:

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>
Project Administrator
Wed Apr 5 15:07:34 2017, 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:

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 Apr 5 13:18:01 2017, 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>
Project Administrator
Wed Apr 5 12:00:16 2017, comment #3:

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

Then to evaluate the expression

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

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>
Project Administrator
Wed Apr 5 10:58:09 2017, 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:

Guillaume <gyom>
Tue Apr 4 20:14:03 2017, 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

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

Mike Miller <mtmiller>
Project Administrator
Tue Apr 4 14:42:25 2017, original submission:

Using the following class:

call the methodA() method on a myclass object:

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by gyom (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Apr 5 13:18:01 2017jweStatusNone=>Ready For Test

    Back to the top


    Powered by Savane 3.1-cleanup1