Re: inconsitency in behavior of 'size'

[Nicholas Jankowski]

On Fri, Mar 9, 2018 at 1:37 PM, Sergei Steshenko <address@hidden> wrote:

Hello  All,

I am using an old self-built octave-3.6.4 and observe the following - see copy-paste of an interactive session:

"

octave:39> im = \
> [
> 1 90 100
> 2 80 110
> 3 70 105
> 4 60 104
> ]
im =

     1    90   100
     2    80   110
     3    70   105
     4    60   104

octave:40> ([_1,_2] = sort(im(:, 3), "descend"))
_1 =

   110
   105
   104
   100

_2 =

   2
   3
   4
   1

octave:41> size(([_1,_2] = sort(im(:, 3), "descend")))
ans =

   4   1

octave:42> size([_1,_2])
ans =

   4   2

octave:43> [_1,_2]
ans =

   110     2
   105     3
   104     4
   100     1

octave:44>

".

IMO the inconsistency is in command 41 output, which is

4  1

, i.e. 4 rows and 1 column vs output of command 42, which is

4  2

, i.e. 4 rows and 2 columns, and I think the latter is the correct output.

Pay attention that in both cases essentially size of [_1,_2] _expression_ is calculated, but in the first case the _expression_ is also first assigned its value from call to 'sort' while in the second case it's just the _expression_.

Is it the way it is supposed to be ? If yes, is it described somewhere in Octave documentation ?

How does Matlab behave in the same case ?

matlab 2017b cannot handle the 'assignment within size' construct  (it also doesn't like variables starting with _ or double quotes)



>> size([a1,a2] = sort(im(:,3),'descend'))
 size([a1,a2] = sort(im(:,3),'descend'))
              ↑
Error: The _expression_ to the left of the equals sign
is not a valid target for an assignment.
 

but
>> size([a1,a2])

ans =

     4     2