Closing report as Philip as verified the fix.

I pushed it here:

http://hg.savannah.gnu.org/hgweb/octave/rev/a2162efd8b80

The patch from comment #27 fixes the regressions I get when running the test suite with bytecode-interpreter enabled.

Can it be pushed, please?

This should be addressed also in the bytecode-interpreter branch. Currently, changes in the tests have introduced some regressions in that branch. Maybe Petter is not aware of this bug report.

octave:3> addpath /home/fernando/tmp/octave-hg/test/
octave:4> test for.tst
***** test <*55622>
 cnt = 0;
 for k = zeros (0,3)
   cnt++;
 endfor
 assert (cnt, 3);
 assert (k, zeros (0,1));
!!!!! regression: https://octave.org/testfailure/?55622
ASSERT errors for:  assert (cnt,3)

  Location  |  Observed  |  Expected  |  Reason
     ()           0            3         Abs err 3 exceeds tol 0 by 3
***** test <*50893>
 cnt = 0;
 for k = cell (0,3)
   cnt++;
 endfor
 assert (cnt, 3);
 assert (k, cell (0,1));
!!!!! regression: https://octave.org/testfailure/?50893
ASSERT errors for:  assert (cnt,3)

  Location  |  Observed  |  Expected  |  Reason
     ()           0            3         Abs err 3 exceeds tol 0 by 3
***** test <*55622>
 cnt = 0;
 for k = zeros (1,2,0);
   cnt++;
 endfor
 assert (cnt, 0);
 assert (k, zeros (1,0));
!!!!! regression: https://octave.org/testfailure/?55622
ASSERT errors for:  assert (k,zeros (1, 0))

  Location  |  Observed  |  Expected  |  Reason
     .         O(1x2x0)      E(1x0)      Dimensions don't match
warning: test: file /home/fernando/tmp/octave-hg/test/for.tst leaked global variables: __assert_printf__
PASSES 19 out of 22 tests

I agree. Fixing this so that Octave is compatible to Matlab in this respect would avoid future bug reports.
And we don't need to add a bunch of special cases to be compatible. We actually can remove one check (albeit an easy one).

I rebased jwe's patch from 2019 to a current head (unsurprisingly with a couple of conflicts). It still passes the tests.

If no one opposes, I'd like to push it to the default branch.


(file #55676)

updating that this behavior still persists unchanged in both programs:

Matlab 2023b:

>> for i = (3:2)', disp ('hey'), end
hey
>> for i = zeros (0,3), disp ('hey'), end
hey
hey
hey
>> for i = zeros (0, 3, 0), i, end
>> for i = ones (0,3), disp ('hey'), end
hey
hey
hey
>>  for i = ones (3,0), disp ('hey'), end

Octave 9.0.1:

>> for i = (3:2)', disp ('hey'), end
>> for i = zeros (0,3), disp ('hey'), end
>> for i = zeros (0, 3, 0), i, end
>> for i = ones (0,3), disp ('hey'), end
>> for i = ones (3,0), disp ('hey'), end
>>

after all of the back and forth here and on previous reports, should this be moved to a won't fix, or let it sit pending future changes?  worth refreshing jwe's patch vs current codebase?

Regarding comment #20.  Please fix your confusion with a cup of coffee ☕🙂

Your code cannot be run, as there is a confusion between "y" and "loop_var".  Clear your workspace "clear all" and start again.

loop_var = ones(3,1)
isempty(loop_var)
size(loop_var)
for var = loop_var, disp('hey'), disp(var), end

Second all this discussion is about "ones(0,3)", NOT "ones(3,1)" or alike.  As Rik said, please read again carefully.  Your code of course works nicely with a single loop iteration in both Octave and Matlab, as the column count is "1".

No bugfixes by Matlab R2019a and R2020b yet.

>> for i = (3:2)', disp ('hey'), end
hey
>> for i = zeros (0,3), disp ('hey'), end
hey
hey
hey
>> for i = zeros (0, 3, 0), i, end
>> for i = ones (0,3), disp ('hey'), end
hey
hey
hey
>> for i = ones (3,0), disp ('hey'), end

I favor Riks opinion on this item too and suggest to close it as won't fix.

"I don't understand why we debate over an empty matrix. Clearly, the column vector is not empty at all"

If you don't understand then re-read the discussion thread.  The issues are subtle and changing Octave's core looping behavior should not be done casually.

Clearly, the column vector is empty because both Matlab and Octave say so.

loop_var = ones (0, 3);
isempty (loop_var)
ans = 1

Quoting from the Matlab documentation on empty arrays

An empty array in MATLAB is an array with at least one dimension length equal to zero. Empty arrays are useful for representing the concept of "nothing" programmatically. For example, suppose you want to find all elements of a vector that are less than 0, but there are none. The find function returns an empty vector of indices, indicating that it couldn't find any elements less than 0.

A = [1 2 3 4];
ind = find(A<0)

ind =

  1x0 empty double row vector

Many algorithms contain function calls that can return empty arrays. It is often useful to allow empty arrays to flow through these algorithms as function arguments instead of handling them as a special case. If you do need to customize empty array handling, you can check for them using the isempty function.

The use of empty arrays, per se, is fine.  As The Mathworks point out, it is often useful to be able to write an algorithm without having to special case whether there will be any elements to act on.

As an example, consider transforming between 1-based indexing (which Octave uses) to 0-based indexing (which the C language uses).  This is pretty easy, you just need to subtract 1.

A = [1 2 3 4];
ind = find (A)
ind =

   1   2   3   4

new_ind = ind - 1
new_ind =

   0   1   2   3

And this algorithm still works well if we put in a condition

A = [1 2 3 4];
ind = find (A > 2)
ind =

   3   4

new_ind = ind - 1
new_ind =

   2   3

And finally, it still works when there are no elements

A = [1 2 3 4];
ind = find (A > 4)
ind = [](1x0)
new_ind = ind - 1
new_ind = [](1x0)

I don't see any problem with allowing empty matrices to participate in mathematical operations.  However, confusing code-dependent issues arise if you say that looping over empty matrices is permissible.

For example, a common coding strategy might be to calculate some collection of elements and then loop over them like so.

for elem = collection
  ...
endfor

For the command find(), Matlab returns the empty dimension in the second dimension (columns).  But there is nothing that guarantees that an empty matrix has 0 columns.  User code that defines the variable collection might choose the opposite convention and create 0xN style empty matrices in which case the for loop is operating N times.

Or something innocuous like a transpose could upset things.

Say I have an algorithm for which I want to operate on the rows of the matrix.  Since the for loop returns columns, I need to transpose the matrix first.

x = [1, 2; 3, 4];
for elem = x'
  elem
end
elem =

   1
   2

elem =

   3
   4

So far that's fine.  But if x is an empty matrix then the control becomes confusingly caught up with the decision to act on rows.  In the case of find() the 1x0 result becomes 0x1 and the loop is executed once rather than zero times.  It's also data dependent.

x = [1 2 3 4];
idx = find (x > 4)
idx = [](1x0)
idx = find (x' > 4)
idx = [](0x1)

Lastly, this is very likely to lead to syntax errors.  Most of the time, a programmer is going to want to do something with the loop element from the collection and this will require an indexing operation that fails because the element is empty.

Last example,

x = [1 2 3 4]';
idx = find (x > 4)
for var = idx
  var(1) = var(1) + 1;  % increment first element in variable
end

Under Matlab this errors out with "Index exceeds the number of array elements (0)".  Currently, Octave has no problem with this code because it doesn't execute the body of the for loop when the right-hand side is empty.

I still disagree, and think we should leave Octave's current behavior as is.

In terms of UX/UI design I prefer to have the minimum number of principles and be able to to derive the behavior from these, rather than having lots of ad hoc exceptions.

For example, from the Declaration of Independence, "All men are created equal".  But, starting in 1896 (Plessy vs. Ferguson and doctrine of "separate but equal"), you had to special case the general principle based on location.  If you were in the North or West of the U.S. the general principle applied, but if you were in the South then you used the exception.  This turned out to be a dumb idea and the U.S eventually went back to just one guiding principle in 1954 (Brown vs. Board of Education of Topeka).

My conception of a for loop over an object (as opposed to a range like 1:1000) is that it is equivalent to a foreach loop over the elements of the object.  Hence, if the object is empty, there should be no looping.  For me, looping over empty matrices means creating a mental exception only for "for" loops which seems unneccessary.

Of course, Matlab, like Moses, has said, "looping occurs over the number of columns".  But, I guess I'm skeptical of the stone tablets.  We don't always follow Matlab when they veer off the rails which I think is the case here.

As a practical matter, I think user's code would be improved by choosing the loop variable more explicitly, rather than relying on this questionable behavior.  If you want to look a certain number of times, do that.

%% Clear code
for i = 1:5
  disp ("Hello World");
end

%% Unclear code
idx = zeros (0,5);
for i = idx
  disp ("Hello World");
end

Also as a practical matter, I don't think this odd construct occurs with much frequency so changing the few instances that occur wouldn't be burdensome.

With all that said, this isn't an issue I'm particularly interested in arguing over.  If you need to commit the patch for some clients who require 100% compatibility then it happens.

I agree with the earlier decision and upholding it, closing.

Again, that looks like an artifact of implementation.  How would one guess that in loops, N-D arrays are squeezed to 2-D before using as the looping structure.  All very unintuitive, hence a bad UX/UI, even if an underlying principle can be found.

@jwe: Emphasizing the irrationality of the behavior, the example you gave executes 0 times rather than 3.

@Mike: good digging.  I'm inclined not to emulate Matlab.  Adding jwe to the CC list.

I think it's debatable how useful this is.  It seems to be an artifact of the implementation: Matlab loops over the number of columns regardless of whether the actual expression is empty. 

For reference, this loop executes three times in Matlab

for i = zeros (0,3), disp ('hey'), end

Evil statement ;-)  And it loops even in Matlab R2018b, one can see 'hey' once there, while Octave does not loop.