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: Tue, 3 Jul 2012 08:14:04 -0700 (PDT)




----- 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.


reply via email to

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