help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

inconsitency in behavior of 'size'


From: Sergei Steshenko
Subject: inconsitency in behavior of 'size'
Date: Fri, 9 Mar 2018 18:37:02 +0000 (UTC)

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 ?

...

Yet another point I'm trying to make is that type of the [_1,_2] _expression_ is inherited from the call to 'sort', and also the type is induced by the two output arguments call, and IMO the type shouldn't changed unless forced to change by some other function/conversion.

Thanks,
  Sergei.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]