Re: ... makes a difference

[Maarten D. de Jong]

> I no longer use Matlab. Thus, on one side I should care a dime about
> Matlab compatibility, but on the other side I'm glad I can benefit from
> all the freeware Matlab code out there with minor editing or no editing
> at all... If I balance both sides I'm reluctant to give up that little
> joy just for the sake of not doing something a la Matlab

Personally, I went the other way. I needed a few functions which were not 
available in Octave, but are in Matlab, and so I had to switch, with 
gnashing teeth. I know JWE's stance on this kind of behaviour (I love his 
friendly messages of encouragement to add the functionality for the benefit 
of all Octave users), but quite frankly, I am a mere chemical engineer 
trying to solve a tricky problem, not a mathematician who specialises in 
fast, robust and accurate numerical algorithms.

> I advocate the position that octave should not be a 1-1 copy (please
> > dont attack me on this) of matlab, but just implement the good features
> > of matlab and drop the bad ones.
>
> I see a problem here: how to decide which are good features and which
> are not.. There will be discrepancies, and some will want something
> others will hate...

Simple: appoint a Benevolent Dictator For Life, akin to the 'scripting' 
language Python. The BDFL has the ultimate authority when it comes to 
adding or deleting features of the core language/development system, but 
will use his power with care, and seek user's opinions first. (Most of the 
time :-).) But his decision is final. See for example 'Python in a 
Nutshell' by Alex Martelli, 2003, O'Reilly, p. 7. In fact, it isn't any 
different from the way other major OSS-programs are developed: although 
noone will call him that, Linus Torvalds is to some extent BDFL for Linux, 
for example.

John is BDFL for Octave. If you don't agree, well, it's an open source 
project, so nothing stopping you in hacking the parser to bits to have it 
conform to your needs. Less drastically, there is always 'options' 
available, to at least give the user a *choice* of whether to go with 
Matlab-compatibility or not. (Which could in fact be what the BDFL decided.)

> Which Matlab features you think are so bad that it compensates to keep
> Octave incompatible?

I cannot claim extensive experience, but the ridiculous column-before-row 
filling of matrixes with the scanf()-family would be at the top of my list. 
Everything in these programs assumes row-before-column orientation, but NOT 
when reading in table data like this. You are always required to apply a 
manual .' to get the orientation of the matrix correct. This is not what I 
would expect as a casual user. The '...'-issue is another, although it is 
not a requirement of Octave to use the ellipsis, so I'd opt for a 'see no 
evil, hear no evil'-approach here. I have been collecting issues with the 
Matlab-language which give me (as a C-programmer) the willies, but I'd have 
to test those in Octave first to see whether they have been ported over.


Cheers,
Maarten 



-------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.octave.org
How to fund new projects:  http://www.octave.org/funding.html
Subscription information:  http://www.octave.org/archive.html
-------------------------------------------------------------