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?
|
Wed 05 Apr 2017 05:59:43 PM UTC, comment #10:
Is this related to bug #44779 ?
|
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).
|
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:
Octave says 100 and Matlab R2017a says 10...
|
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.
|
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:
If there are some simple rules for how to evaluate this kind of expression, then I'm not quite seeing them yet.
|
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:
Given that "end" always applies to the enclosing variable, "str" here, it is not entirely clear to me what the ambiguity is.
|
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.
|
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
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.
|
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:
|
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
The subsref operation is done on the result of calling "obj.method" with no arguments.
|
Tue 04 Apr 2017 02:42:25 PM UTC, 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).
|