help-octave
[Top][All Lists]
Advanced

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

Re: senseless warning in octave-3.6.2


From: Sergei Steshenko
Subject: Re: senseless warning in octave-3.6.2
Date: Fri, 6 Jul 2012 05:46:38 -0700 (PDT)




----- Original Message -----
> From: Nicholas Jankowski <address@hidden>
> To: Octave users list <address@hidden>
> Cc: 
> Sent: Tuesday, July 3, 2012 6:48 PM
> Subject: Re: senseless warning in octave-3.6.2
> 
> On Tue, Jul 3, 2012 at 11:14 AM, Sergei Steshenko <address@hidden> 
> wrote:
>> 
>> 
>> 
>> 
>>  ----- Original Message -----
>>>  From: c. <address@hidden>
>>>  To: Sergei Steshenko <address@hidden>
>>>  Cc: Jordi Gutiérrez Hermoso <address@hidden>; Octave users 
> list <address@hidden>
>>>  Sent: Tuesday, July 3, 2012 12:26 AM
>>>  Subject: Re: senseless warning in octave-3.6.2
>>> 
>>> 
>>>  Il giorno 02/lug/2012, alle ore 01.53, Sergei Steshenko ha scritto:
>>> 
>>>>   As wrote much much earlier, essentially column vector vs row 
> vector is a
>>>  nuisance - one type of vector would suffice.
>>>  In a sense, Octave, as Matlab, does not have either row or column 
> vectors, nor
>>>  it has scalars, it just uses 2-index matrices for all those types.
>>>  You might consider this a very exotic and probably annoying (and maybe 
> even
>>>  stupid) design choice, and I might even, partly, agree.
>>>  But it is at the very root of the design of the Matlab language, so it 
> cannot be
>>>  abandoned.
>>>  The best option, if you cannot live with the way data-types are used in
>>>  Octave/Matlab, is to switch to a different language.
>>> 
>>>  c.
>> 
>>  <<<You might consider this a very exotic and probably annoying 
> (and maybe even stupid) design choice, and I might even, partly, agree. But 
> it 
> is at the very root of the design of the Matlab language, so it cannot be 
> abandoned>>>
>> 
>>  Huh ?!!!!!!!!!
>> 
>>  Here is a simple Octave session:
>> 
>>  "
>>  octave:1> N=100
>>  N =  100
>>  octave:2> row_sin = sin(2 * pi * (0:N-1)/10);
>>  octave:3> size(row_sin)
>>  ans =
>> 
>>       1   100
>> 
>>  octave:4> col_sin = row_sin';
>>  octave:5> size(col_sin)
>>  ans =
>> 
>>     100     1
>> 
>>  octave:6> plot((0:N-1)', row_sin, 0:N-1, col_sin);
>>  octave:7>
>>  ".
>> 
>>  As everybody can see, the behavior does _not_ _at_ _all_ depend on the fact 
> whether an entity is a row or a column vector.
>> 
>>  So, vector differentiation depending on row/column property can 
> _definitely_ be abandoned - as the above example shows.
>> 
>>  Instead Octave developers in their "infinite wisdom" introduce 
> outlandish
>> 
>>  row_vec OP col_vec -> matrix
>> 
>>  behavior and even make it default. Instead of, say, fixing (by first 
> properly defining functionality) 'pkg.m'. Strangely enough, in VLSI 
> design my mentoring managers taught me that first bugs are fixed, and then 
> new 
> features are introduced.
>> 
>>  In this case a whole layer of new bugs has been introduced.
>> 
>>  --Sergei.
>>  _______________________________________________
>>  Help-octave mailing list
>>  address@hidden
>>  https://mailman.cae.wisc.edu/listinfo/help-octave
> 
> jumping into the deep  without a real appreciation for 'broadcasting',
> but it seems that basic matrix math cares whether something is a row
> or column matrix
> 
> octave:1> a = 1:4
> a =
> 
>    1   2   3   4
> 
> octave:2> b = a
> b =
> 
>    1   2   3   4
> 
> octave:3> a*b
> error: operator *: nonconformant arguments (op1 is 1x4, op2 is 1x4)
> octave:3> b*a
> error: operator *: nonconformant arguments (op1 is 1x4, op2 is 1x4)
> octave:3> a'*b'
> error: operator *: nonconformant arguments (op1 is 4x1, op2 is 4x1)
> octave:4> a'*b
> ans =
> 
>     1    2    3    4
>     2    4    6    8
>     3    6    9   12
>     4    8   12   16
> 
> octave:5> a*b'
> ans =  30
> 
> as the last two cases show, basic rules of matrix multiplication
> (forget what Matlab wanted) and linear algebra specify the inner and
> outer product multiplications and being equivalent to vector products
> that either produce a scalar (dot product) or tensor.  In Matlab,
> (_matrix_ laboratory) everything is a matrix, and it's easier to
> represent vectors and tensors using the same 2d construct, especially
> when that construct preserves necessary 'orientation' information.
> Sure it can be referenced using single indices as it is stored in
> memory, (a convenience rather than a necessity), and Octave maintained
> that behavior, but it never throws away orientation information.
> 
> While certain functions (like the sine function) shouldn't care if
> you're using a row or column vector, Please don't abandon basic matrix
> algebra.
> 
> http://en.wikipedia.org/wiki/Tensor_product
> _______________________________________________


My point is that in a vast majority of cases Octave already has means to 
perform the needed row_vec <-> col_vec transformation:

"
octave:1> row_vec = 1:4
row_vec =

   1   2   3   4

octave:2> col_vec = [5:8]'
col_vec =

   5
   6
   7
   8

octave:3> vec2mat(row_vec, 1)
ans =

   1
   2
   3
   4

octave:4> vec2mat(col_vec, 1)
ans =

   5
   6
   7
   8

octave:5> vec2mat(row_vec, 1)'
ans =

   1   2   3   4

octave:6> vec2mat(col_vec, 1)'
ans =

   5   6   7   8

octave:7> 
".

I.e. _always_ the desired row <-> column vector property can be enforced 
regardless of what the input vector is.

In the cases when row <-> column makes mathematical sense it should be still 
there. And here is an example in which Octave happily ignores rwo/column 
property, and I'm glad it does. From the above two vectors:

"

octave:7> row_vec(1:2) = col_vec(1:2)
row_vec =

   5   6   3   4

octave:8>     
"

- no warnings, no nothing, just a silent automatic transformation.

Regards,
  Sergei.


reply via email to

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