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

 
 

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

Submitter:  Garrett <g2e>
Submitted:  Wed 08 Feb 2012 03:10:50 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.6.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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.


>> a = [1, {}, [], 'a']

a =

    [1]    'a'

>> a = [{1} {} {[]} {'a'}]

a =

    [1]    []    'a'

>> a = {1, [], 'a'}

a =

    [1]    []    'a'


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>
Group Member
Wed 08 Feb 2012 09:55:10 PM UTC, comment #5: 

A little more testing along that line of thought:


octave:2> [1 [] {} {} 'a']
ans =
{
  [1,1] =  1
  [1,2] = [](0x0)
  [1,3] = a
}
octave:3> [1 [] [] {} {} 'a']
ans =
{
  [1,1] =  1
  [1,2] = [](0x0)
  [1,3] = [](0x0)
  [1,4] = a
}


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:


>> [1 [] {} 'a']

ans =

    [1]    'a'

>> [1 [] {} {} 'a']

ans =

    [1]    'a'

>> [1 [] [] {} {} 'a']

ans =

    [1]    'a'


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:


function [x]=cellcat(varargin)
x=[varargin{~cellfun('isempty',varargin)}];
end


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)


octave:9> [1 [] 'a']
ans = ☺a
octave:8> int8([1 [] 'a'])
ans =

   1  97

octave:10> iscell ([1 [] 'a'])
ans = 0

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

Interestingly,

octave:13> iscell ([1 [] {} 'a'])
ans =  1
octave:14> [1 [] {} 'a']
ans =
{
  [1,1] =  1
  [1,2] = [](0x0)
  [1,3] = a
}

....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>
Group 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?


octave:5> [1 [] {1} 'a']
ans =
{
  [1,1] =  1
  [1,2] = [](0x0)
  [1,3] =  1
  [1,4] = a
}
octave:6> ans(2) = []
ans =
{
  [1,1] =  1
  [1,2] =  1
  [1,3] = a
}
octave:7> iscell ([1 [] {1} 'a'])
ans = 1

...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.


octave:8> [1 [] 'a']
ans = ☺a
octave:9> int8([1 [] 'a'])
ans =

   1  97
octave:10> iscell ([1 [] 'a'])
ans = 0
octave:11> [1 [] 'a']
ans = ☺a
-verbatim
....which shows that Octave makes a it character array. Here [] is ignored with good reason.

Interestingly,
+verbatim+
octave:14> [1 [] {} 'a']
ans =
{
  [1,1] =  1
  [1,2] = [](0x0)
  [1,3] = a
}

...so there may be something fishy.

Please check what the ML docs say about this all.

Philip Nienhuis <philipnienhuis>
Group 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:


octave:20> [1 [] {1} 'a']
ans =
{
  [1,1] =  1
  [1,2] = [](0x0)
  [1,3] =  1
  [1,4] = a
}
octave:21> [1 [] 'a']
ans = a
octave:22> double(ans)
ans =

    1   97


while in Matlab:


>> [1 [] {1} 'a']

ans =

    [1]    [1]    'a'

>> [1 [] 'a']

ans =

a


which shows the same behaviors mentioned before.

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

A simple example:


octave:1> a{4}={1};
octave:2> [a{:}]
ans =
{
  [1,1] = [](0x0)
  [1,2] = [](0x0)
  [1,3] = [](0x0)
  [1,4] =  1
}


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:


octave:3> a{4}=1;
octave:4> [a{:}]
ans =  1


and


octave:5> a{4}=['ab';'cd'];
octave:6> [a{:}]
ans =

ab
cd


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


octave:7> a{4}={1};
octave:8> a{2}=1;
octave:9> [a{:}]
ans =
{
  [1,1] = [](0x0)
  [1,2] =  1
  [1,3] = [](0x0)
  [1,4] =  1
}


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

octave:10> clear a;
octave:11> a{2,3}={1};
octave:12> a{1,2}=1;
octave:13> [a{:}]
ans =
{
  [1,1] = [](0x0)
  [1,2] = [](0x0)
  [1,3] =  1
  [1,4] = [](0x0)
  [1,5] = [](0x0)
  [1,6] =  1
}


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


>> a{4}={1};
>> [a{:}]

ans =

    [1]

>> a{4}=1;
>> [a{:}]

ans =

     1

>> a{4}=['ab';'cd'];
>> [a{:}]

ans =

ab
cd

>> a{4}={1};
>> a{2}=1;
>> [a{:}]

ans =

    [1]    [1]

>> clear a;
>> a{2,3}={1};
>> a{1,2}=1;
>> [a{:}]

ans =

    [1]    [1]

>>



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:


octave:14> clear a;
octave:15> a{1,2}=1;
octave:16> a{2,3}='a';
octave:17> [a{:}]
ans = a
octave:18> double(ans)
ans =

    1   97


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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Posted a comment)
  • -email is unavailable- added by jordigh (Updated the item)
  • -email is unavailable- added by g2e (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-23 rik5 StatusConfirmed Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2012-02-08 jordigh Item GroupIncorrect Result Matlab Compatibility
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code