bugGNU Octave - Bugs: bug #63453, output dimension of cell2mat with...

 
 

bug #63453: output dimension of cell2mat with empty inputs

Submitter:  Guillaume <gyom>
Submitted:  Thu 01 Dec 2022 11:37:17 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  3 - Low Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Guillaume Open/Closed:  * Open
Release:  * stable Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 08 Feb 2023 04:24:19 PM UTC, comment #4: 

There have been lots of examples where Matlab just does something for no good reason other than it is an artifact of their implementation.  Octave generally tries to match any documented behavior.  But undocumented behavior, which could change at any time, we usually don't bother with.  I think Octave's preservation of input size makes more sense than Matlab so I wouldn't change it myself.

Rik <rik5>
Group administrator
Wed 08 Feb 2023 03:34:26 AM UTC, comment #3: 

after looking at how matlab handles sized empties for a number of functions, I'm guessing this is an unintentional side effect.  it seems for a lot of functions matlab has a rule for first setting output size, then fills the data. e.g., functions like sum all collapse the operating dimension to size 1:


sum(ones(0,0,2), 1)
ans =  [](1x0x2)

sum(ones(0,0,2), 2)
ans =  [](0x1x2)

sum(ones(0,0,2), 3)
ans = [](0x0)


except of course for inconsistencies with []:

sum (ones(0,0))
ans = [](0x0)

sum (ones(0,0),1)
ans = [](1x0)

sum (ones(0,0),2)
ans = [](0x1)


in this case I'd guess cell2mat has some content-blind rule to set output size. Looking at the help, it seems it would set the output dim1 and dim2 according to number of rows and columns across the cells. empty cells give odd results, but depending on how it steps through cells to add this up with size or numel or whatever, it gets zero elements in both directions. output size for dim>2 is always = input size, so it makes no change there.

so, I'm sure there's some logic to it. It makes no more sense than the other functions like I mentioned above. But it does at least seem somewhat consistent.

Nicholas Jankowski <nrjank>
Group Member
Tue 07 Feb 2023 05:31:53 PM UTC, comment #2: 

Is there benefit to following Matlab here?  It seems kind of weird.

Matlab results


size (cell2mat (cell (0,2))
=> [0, 0]
size (cell2mat (cell (2,0))
=> [0, 0]
size (cell2mat (cell (2,0,2))
=> [0, 0, 2]


All three are empty, but Matlab seems to have made the arbitrary choice to zero out rows and columns, but not any higher dimensions.  Note that this seems to apply only to cell2mat() function.  For example,


size (zeros (2,0,2))
=> [2, 0, 2]


shows that input dimensions are preserved in the empty output.  A more complicated example is


s = cell2struct (cell(2,0,3,4), {'a'; 'b'})
size (s)
=> [0, 3, 4]
size (struct2cell (s))
=> [2, 0, 3, 4]


which shows that other functions which convert between data types (cell to struct and struct to cell) do preserve empty input dimensions.

Do we want to be Matlab compatible, but inconsistent in our treatment of empty inputs?  Or should we acknowledge that Matlab is just odd in this case and not follow their behavior?  Maybe this is worth asking over on the Octave Discourse site.

Rik <rik5>
Group administrator
Thu 01 Dec 2022 02:18:38 PM UTC, comment #1: 

Since Matlab doesn't display the dimensions of empty output, here again to make the difference clearer.
In Octave 7.3.0:

>> size (cell2mat (cell (0, 1)))
ans =

   0   1


In Matlab R2022a:

>> size (cell2mat (cell (0, 1)))

ans =

     0     0


Markus Mützel <mmuetzel>
Group administrator
Thu 01 Dec 2022 11:37:17 AM UTC, original submission:  

I noticed a difference between Matlab and Octave whereby:


octave> cell2mat (cell (0, 1))
ans = [](0x1)



>> cell2mat (cell (0 ,1))
ans =
     []


It seems this difference was introduced in bug #51448. I would vote for the corresponding change to be reverted for better Matlab compatibility.

Guillaume <gyom>

 

(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 nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by gyom (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-02-07 rik5 Priority5 - Normal 3 - Low
    2022-12-01 mmuetzel StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code