[Octave-bug-tracker] [bug #45389] nd-array indexing with fewer subscripts than dimensions

[Nick Jankowski]

Follow-up Comment #4, bug #45389 (project octave):


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:


for ML:

x = ones(2,2,2);  #3D array

x(1,3) = 5 # array is concatentad into x(:,:) a 2x4 array, then element (1,3)
in            # that array is set to 5, and it's returend in 2x2x2 form.
equiv. to
           # x(1,1,2)=5. 

x(3,1) = 7 # again, first made into a 2x4 array, then the x(3,1) is applied
           # to that array. 3>2, so it does an array expansion. becomes 3x4.
           # un-concatenates dims 2 and 3 and returns 3x2x2. same as
x(3,1,1)=7

x = ones(2,2,2); #3D array
x(9) = 9   # error. x(:) is a nx1 array. expanding on a concatenated
dimension
           # doesn't tell you which dimension was supposed to get bigger

x(1,9) = 9 # again, x(:,:) is a 2x4 array. it doesn't know where to put the
9th
           # element.

x(9,9) = 9 # same problem.

x(3,1,1) = 7 # works because there is no concatenation to cause confusion. any
dimension can exceed size(x)(dim). 



can give another example to highlight the error in Octave:


x = ones(2,2,2,2); #4D array 

x(2,3,1) = 4  # x(:,:,:) is a 2x2x4 array, only concatenated on dims 3 and 4.

              # ML is perfectly happy doing expansions on dims 1 or 2

answer in ML:

x(2,3,1)=4

x(:,:,1,1) =
     1     1     0
     1     1     4

x(:,:,2,1) =
     1     1     0
     1     1     0

x(:,:,1,2) =
     1     1     0
     1     1     0

x(:,:,2,2) =
     1     1     0
     1     1     0

Octave gives an ambiguity error and it shouldn't.



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.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45389>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/