bugGNU Octave - Bugs: bug #35481, [var{:}] does not collapse empty...

 
 

bug #35481: [var{:}] does not collapse empty elements when some elements are cell

Submitted by:  Garrett <g2e>
Submitted on:  Wed 08 Feb 2012 03:10:50 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: InvalidAssigned to: None
Originator Name: Open/Closed: Closed
Release: 3.6.0Operating 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 20 Feb 2012 06:39:56 PM UTC, comment #7:

Haha, it took me a week but I completely agree. This is a bug in Matlab and in my code (for making use of it). I was concatenating the elements of a cell array which were either cellstr arrays or untouched (and thus set as [] from the 'cell' call). Matlab would trim off the untouched elements in the [var{:}] operation while Octave did not. This was convenient but incorrect. I now initialize the variable with a cell array of empty CELL arrays. That works as desired in both Octave & Matlab, avoids mixed-type concatenation and avoids Matlab's bug of aggressive trimming in mixed-type concatenation with cell arrays.

Thanks Philip & Ben!

Garrett <g2e>
Tue 14 Feb 2012 02:39:37 AM UTC, comment #6:

I'd expect each of the assignments below to give identical results. The results below are from Matlab.

Look to be a Matlab bug.

My guess is that when concatenating inside the square brackets ML is pruning the empties ([]) before its parser recognizes it is working will a cell array. When concatenating the cells ML correctly prunes the empty cells ({}).

Ben Abbott <bpabbott>
Project Member
Wed 08 Feb 2012 09:55:10 PM UTC, comment #5:

A little more testing along that line of thought:

So Octave cells the elements if there are cell array elements present (empty or not) in the concatenation operation and then deletes the empty cells but only if they were empty cells going in.

Those operations in Matlab all produce the same output:

I think I'll leave this alone as it is deep in undocumented territory it seems. Also it was easy enough to write a function called cellcat which drops the empty elements:

Garrett <g2e>
Wed 08 Feb 2012 08:56:40 PM UTC, comment #4:

I actually pointed out first that it is inconsistent with how Octave handles concatenation of empty elements when the other elements are only numeric and/or char. I don't know if these are documented/bugs in Matlab but it is confusing!

Garrett <g2e>
Wed 08 Feb 2012 08:48:42 PM UTC, comment #3:

(Sorry my comment was prematurely truncated)

..which shows that Octave makes it a char array.

Interestingly,
....so Octave seems to behave inconsistent - [] is treated differently from {}.

Please check what the ML docs have to say about all this.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 08 Feb 2012 08:40:32 PM UTC, comment #2:

You say "consistent with Matlab" - did you check if this is DOCUMENTED behavior of Matlab?

...so Octave translates it into a cell array, as ML does, because you try to concatenate mixed types (one of the types is a 1x1 cell array).
But to then suggest that Octave is buggy because it doesn't skip the empty cell is too fast IMO - for the same token this could be a Matlab bug.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 08 Feb 2012 03:23:41 PM UTC, comment #1:

Just figuring out I didn't need to make the cell array ahead of time to show this behavior:

while in Matlab:

which shows the same behaviors mentioned before.

Garrett <g2e>
Wed 08 Feb 2012 03:10:50 PM UTC, original submission:

A simple example:

I expected the empty elements to be collapsed upon concatenation by the "[ ]" operator leaving just a 1x1 cell array. Instead the empty elements were re-celled. This shown behavior is inconsistent with empty element collapsing when only numeric or char entries are present:

and

The behavior also occurs for mixed cell/numeric/char cases which leads to the numeric/char elements being re-celled:

I expected an error in that example. The behavior is the same if the cell array (here 'a') is 2-dimensional:

The lack of collapsing empty elements when cell elements are present is inconsistent with Matlab behavior (7.10.0):

The Octave and Matlab are the same except for the collapsing of empty elements. It is interesting to note that the unexpected re-celling of non-empty elements (which I thought would throw an error) is consistent with Matlab. So it seems Octave just needs to know not to re-cell empty elements to be compatible and consistent.

Oh and I tested the behavior for mixed numeric/char elements:

which IS consistent with Matlab. So it looks like there is a type relationship of cell>char>numeric.

Garrett <g2e>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by philipnienhuis (Posted a comment)
  • -unavailable- added by jordigh (Updated the item)
  • -unavailable- added by g2e (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 23 Feb 2012 08:33:32 PM UTCrik5StatusConfirmed=>Invalid
      Open/ClosedOpen=>Closed
    Wed 08 Feb 2012 03:23:58 PM UTCjordighItem GroupIncorrect Result=>Matlab Compatibility
      StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1