Re: Meaning of * (mtimes) for nd-arrays

[Nicholas Jankowski]

On Tue, Feb 16, 2016 at 4:07 PM, Nicholas Jankowski <address@hidden> wrote:

On Tue, Feb 16, 2016 at 4:05 PM, Juan Pablo Carbajal <address@hidden> wrote:

On Tue, Feb 16, 2016 at 9:49 PM, Marco Atzeri <address@hidden> wrote:
> On 16/02/2016 20:13, Nicholas Jankowski wrote:
>>
>>
>>     one(1,1,3) is not the same as one(1,3). I never said the oposite. The
>>     behavior when multiplying by a vector is what is equivalent (it seems
>>     only in Octave). You see, a singleton left dimension is rather
>>     useless...but I grant that one could stick to that. But as Jordi
>>     mentioned many times there are plenty of generalizations, e.g.
>>     if (n x 1) * (1 x m) gives n x m, then  (n x 1) * (1 x 1 x m) gives (1
>>     x n x m), or (n x 1 x m), or (n x m)? note, tat the last one is the
>>     "squeeze" of the first one and it seems what the programmer chose.
>>
>>     So I guess we will have to stick to matlab idiosyncrasy and fix this
>>     to give an error... anyways, is this the results of broadcasting? No
>>     way of checking the Octave:broadcast warning anymore, but I wouldn't
>>     think so.
>>
>>
>> Yes, sorry I was being a bit pedantic on that. I figured you knew the
>> difference but I was just being explicit.
>>
>> In any case, I'd argue that a singleton left dimension is not completely
>> useless. I put a model together last year that made heavy use of
>> n-vectors to orthogonalize the process. Combined with broadcasting, it
>> made bookkeeping rather straight forward with dims 1 and 2 being the 2x2
>> transfer functions, 3 being the spatial degree of freedom, 4 being the
>> eigenvalue d.o.f., 5 being ... something else.
>>
>> In any case, almost no basic matrix functions accept anything with ndims
>> ~= 2. I think some people have written n-D array functions, but the base
>> * should throw an error rather than squeeze the user's data for them. I
>> wouldn't think broadcasting would be to blame here, as it shouldn't come
>> up without invoking .*  , should it?
>>
>> nickj
>>
>
> It seems a curious extension of broadcasting
> always having max two dimension as output
>
> octave:15> ones(2,3)*ones(3,1)
> ans =
>
>    3
>    3
>
> octave:16> ones(2,3)*ones(3,1,2)
> ans =
>
>    3   3
>    3   3
>
> octave:17> ones(2,3)*ones(3,1,2,2)
> ans =
>
>    3   3   3   3
>    3   3   3   3
>
> octave:18> ones(2,3)*ones(3,1,2,2,2)
> ans =
>
>    3   3   3   3   3   3   3   3
>    3   3   3   3   3   3   3   3
>
>
> The error messages gives a hint on what is happening:
>
> octave:34> ones(2,2,3)*ones(3,2,2,2)
> error: operator *: nonconformant arguments (op1 is 2x6, op2 is 3x8)
> octave:34> ones(2,2,3)*ones(3,2,2)
> error: operator *: nonconformant arguments (op1 is 2x6, op2 is 3x4)
> octave:34> ones(2,2,2)*ones(2,2,2)
> error: operator *: nonconformant arguments (op1 is 2x4, op2 is 2x4)
>
>
>

I think this deserves a ticket in the tracker. Who goes for it?

I'll get it before heading out of the office...

I'm running 4.0.0, can someone verify this is still the case in one of the release candidates?