Sat 25 Jul 2015 12:02:42 AM UTC, comment #4:
Just want to follow up on comment #2. Matlab's behaviour is 'correct and consistent' with how they've defined indexing. ML isn't making any unclear assumptions as Rik implied in comment #1, it should most definitely accept x(3,1)==4, not throw an error. Yes, it can be avoided as it's a sloppy way to resize an array, but Octave should follow suit, as it shows Octave is doing something fundamentally different which may lead to other inconsistencies.
Much of Comment #2 has it right, but spelled out in detail it's a collision of expansion and concatenation precedence in Octave:
The expansion rule is simple enough - if you specify all indices, and one is larger than the size in that dimension, it errors out if you're asking it to return the value, but expands the array if you're assigning a value.
The index-concatenation rule is also straightforward - if you ask for a value, but specify fewer indices than dimensions, the array is concatenated on the last specified dimension. THEN, any other operations are performed on that reshaped array, the outcome of which is then 'reshaped' and returned back in its original form.
When the two collide it appears tricky, but the index-cocatenation SHOULD get done first. I suspect Octave does not do this, and that's the cause of the non-compatibility. If you do it first, then, whether or not any expansion should produce an output or an error is very straightforward.
In short, you can't expand on any concatenated dimension, because it doesn't know which of the concatenated dimensions you actually wanted to expand when it tries to returns the original shape.
Stepping through the previously mentioned operations:
can give another example to highlight the error in Octave:
I don't know how the code works for the resizing, but I suspect it is rule-checking based on x and not the concatenated x. hopefully that's not too onerous a fix.
|
Wed 24 Jun 2015 05:03:20 PM UTC, comment #2:
Thank you for the response Rik.
I filed this as a possible MATLAB compatibility issue. I admit it's an edge case, but I only stumbled across it by mistake. I assure you I don't usually write code that bad :)
As for trying to explain the MATLAB behavior, it seems to me there is some logic behind it. Consider this:
it effectively reflows the array into a 2-by-(2*2) matrix, similar to doing "reshape".
I think my previous example is interpreted in a similar way, where "x(3,1)" implies reshaping into a 2D matrix, and then indexing into that result. In this case the array is grown in size since we're indexing out of bound.
In the second example with "x(1,9)", MATLAB threw an error because it is not clear which original dimension it should grow (2nd or 3rd?), at least that's the way I explain it...
Anyway, as you said, this can be easily avoided by writing correct and clear code in the first place :) I just wanted to document the difference.
|
Wed 24 Jun 2015 04:22:29 PM UTC, comment #1:
Try
and the example works. I think Octave is accurate to throw an error since it isn't clear with just x(3,1) whether you meant to index x(3,1,1) or x(3,1,2).
Matlab makes the assumption that you meant x(3,1,1), but not consistently which makes the behavior even worse. I agree that x(1,9) would seem to imply x(1,9,1) in Matlab but this fails. Rather than rely on weirdness in Matlab, I would just re-code the m-file to be clear about what is desired. The re-coded version will work in Matlab or Octave.
|
Wed 24 Jun 2015 08:22:20 AM UTC, original submission:
Consider the example below.
First we run it in MATLAB R2015a:
Next we try it in Octave 4.0.0:
What's interesting is that on other cases, both MATLAB and Octave throw an error:
|