Re: Octave and cargo cult programmingHello

[Sergei Steshenko]

----- Original Message -----
> From: marco atzeri <address@hidden>
> To: address@hidden
> Cc: 
> Sent: Friday, September 14, 2012 8:21 AM
> Subject: Re: Octave and cargo cult programmingHello
> 
> On 9/14/2012 12:42 AM, Sergei Steshenko wrote:
>> 
> 
>>  And regarding cargo cult linear algebra - row <-> column vector 
> should only be taken into account only if not taking it into account can 
> produce 
> ambiguous results.
>> 
>> 
>>  For that matter, since both inner and outer products exist: 
> https://en.wikipedia.org/wiki/Matrix_multiplication#The_inner_and_outer_products
>  
> -> https://en.wikipedia.org/wiki/Inner_product -> 
> https://en.wikipedia.org/wiki/Outer_product , if they both supported by 
> default, 
> none deserves a warning.
>> 
>>  So, again, there should be a, say,
>> 
>>  linear_algebra_compatibility;
>> 
>>  compiler pragma which introduces new laws of dealing with vectors and 
> matrices.
> 
> this does make no sense.
> We can not have two binary variant, one with and one without
> broadcasting.
> The life of package manager is already hard to deal with dependencies,
> having two flavours of octave is insane.
> 
>> 
>>  Regards,
>>     Sergei.
> 
> don't like broadcasting ?  don't use it.
> Stop to boring us.
> 
> Marco
> 

It _does_ make sense. Every decent language nowadays allows operator 
overloading.

For example, read http://perldoc.perl.org/bigint.html . From there:

"

All operators (including basic math operations) are overloaded. Integer
constants are created as proper BigInts.
Floating point constants are truncated to integer. All parts and results of
expressions are also truncated.
Unlike integer, this pragma creates integer constants that are only
limited in their size by the available memory and CPU time.".

So, I do not want broadcasting and similar bullshit to be splashed on me by 
Octave developers. Instead I want a set of modules/pragmas which would allow me 
to use the (sub)set of math I want/need.

Regards,
  Sergei.