bugGNU Octave - Bugs: bug #50893, for loop index variable not...

 
 

bug #50893: for loop index variable not initialized unless loop is entered

Submitted by:  Ceral Paquet <octavebugs>
Submitted on:  Fri 28 Apr 2017 06:19:28 PM UTC  
 
Category: InterpreterSeverity: 2 - Minor
Priority: 3 - LowItem Group: WTF, Matlab?!?
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.2.1Operating System: GNU/Linux

Add a New Comment(Rich 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)

Mon 22 May 2017 02:34:16 AM UTC, comment #11:

I checked in the changeset on the development branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/fd7a16594614).

Rik <rik5>
Project Administrator
Thu 18 May 2017 04:46:08 AM UTC, comment #10:

Try the attached changeset. It does not execute the loop body if the command expression is empty. That resolves point #1. Even though the loop body is not executed, the loop variable is still initialized to an empty value of the same class as the command expression (for example, uint32 or cell or double).

(file #40730)

Rik <rik5>
Project Administrator
Sun 30 Apr 2017 03:42:05 AM UTC, comment #9:

Item 3 seems like a side effect of Matlab's internal implementation and it doesn't look critical to copy that.

However, I could easily see items #1 and #2 being a problem.

In the first case, code might calculate a collection which is then iterated over. If the collection happened to be empty, but with multiple columns, then Octave would actually execute the loop body. This would be terribly hard to debug because most of the time the script would get the same answer in Octave or Matlab, but occasionally you would get different results based on the peculiarities of the input data.

It would be slightly harder, but not that much harder, to get the same behavior from case #2.

If COLLECTION happened to be empty then Octave would not initialize k and the test on if (k ...) would produce a parse error since the variable is not defined. Again, most of the time the script would work but for occasional data patterns you would get parse errors.

It does seem logical to me that if the expression to iterate over is empty that you don't execute the loop. The initialization of the loop variable seems arbitrary, but we should be able to copy that.

Rik <rik5>
Project Administrator
Sat 29 Apr 2017 09:16:50 AM UTC, comment #8:

I can't find any documentation about it. Yes it does look rather ad hoc. Looks like Rik found a genuine bug tho rather that this little WTF.

For me, it would help to just leave a 0x0 double in the workspace (or any class, it doesn't matter). It would be just to make things like this work in Octave when n=0:

Ceral Paquet <octavebugs>
Fri 28 Apr 2017 09:06:00 PM UTC, comment #7:

These seem almost like some kind of accident of implementation rather than conscious decisions about how things should work. But who knows, right? Is this Matlab behavior documented anywhere?

John W. Eaton <jwe>
Project Administrator
Fri 28 Apr 2017 08:46:23 PM UTC, comment #6:

Trying to summarize. It appears there are three incompatibilities.

1) When an object has columns, but no rows, Octave iterates over the columns while Matlab does not iterate. Sample code

2) When an object has rows, but no columns, Octave skips loop variable assignment entirely. Matlab assigns to the loop variable, but does not execute the loop. An object with no columns can be an empty range (3:0) or a directly created object like zeros (3, 0). Sample code

3) In case 2 above, Matlab always creates a 0x0 double initialization for the loop variable even when the object was a different type

clear k;
for k = zeros (3, 0, 'int32')
disp ('Hello');
end
whos k

I think it is enough to fix items 1 and 2, but skip 3.

Rik <rik5>
Project Administrator
Fri 28 Apr 2017 06:57:57 PM UTC, comment #5:

A few more cases. The scalar index seems well behaved, the array index not so much.

Ceral Paquet <octavebugs>
Fri 28 Apr 2017 06:51:45 PM UTC, comment #4:
Ceral Paquet <octavebugs>
Fri 28 Apr 2017 06:45:15 PM UTC, comment #3:

More clues that this is specific to the range operator which is optimized for space storage in Octave, but not Matlab. If I disable Octave's efficient range implementation then the behavior is Matlab compatible.

Rik <rik5>
Project Administrator
Fri 28 Apr 2017 06:32:11 PM UTC, comment #2:

Confirmed. And as a clue to tracking this down, it appears to happen only with ranges. For example, this works despite the

Could you run the sample code above in Matlab to see what it does? They may check whether the loop body is empty before executing anything. In that case, I would expect that k would be of size 0x3 and no loop body would be executed.

Rik <rik5>
Project Administrator
Fri 28 Apr 2017 06:28:27 PM UTC, comment #1:

Is it always initialized as double, or is the type set to the type of the loop range? Is there a difference between the following two loops?

John W. Eaton <jwe>
Project Administrator
Fri 28 Apr 2017 06:19:28 PM UTC, original submission:

I ran into a little inconsistency between MATLAB and Octave. MATLAB initializes the loop index variable as empty if the loop is not entered.

MATLAB

Octave

Ceral Paquet <octavebugs>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #40730:  bug50893.cset added by rik5 (2KiB - application/octet-stream)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by octavebugs (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):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 18 Aug 2017 06:06:00 PM UTCmtmillerDependencies-=>bugs #51785 is dependent
    Mon 22 May 2017 02:34:16 AM UTCrik5StatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Thu 18 May 2017 04:46:08 AM UTCrik5Attached File-=>Added bug50893.cset, #40730
      StatusConfirmed=>Patch Submitted
    Fri 28 Apr 2017 09:06:00 PM UTCjweItem GroupMatlab Compatibility=>WTF, Matlab?!?
    Fri 28 Apr 2017 06:32:11 PM UTCrik5CategoryNone=>Interpreter
      Severity3 - Normal=>2 - Minor
      Priority5 - Normal=>3 - Low
      Item GroupNone=>Matlab Compatibility
      StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1