-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John W. Eaton wrote:
On 22-Apr-2009, Alois Schlögl wrote:
| (The programm slowed down on Matlab from 13.0 to 66.15 s, though).
If you care about this, then I guess you should complain to the
MathWorks about the performance of their product...
| BTW, what are the arguments in favor of using octave-only coding style ?
Some of us like it better. Using endfor, endif, etc. is easier to
read.
The indentation is the most important to make readable code, the use of
endfor, endif etc. is hardly decisive.
| Yes, the question is closely related to the previous one. Of course, if
| the toolbox is compatible to matlab, there is no problem for the matlab
| users. Unfortunately, most toolboxes (all in Octave and
| octave-forge/main and most of octave-forge/extra) are using the
| octave-only coding style.
|
| This seems to suggest that a fork is neccessary in order to make the
| toolboxes applicable for matlab users. Is there an alternative ?
Some of us don't see enhancing Matlab as a goal of the Octave or
Octave Forge projects. The goal for us is to make Octave better by
writing code for Octave, not Matlab. Making useful things available
in Octave packages should provide an incentive to use Octave.
jwe
I agree that making useful things available for Octave is an incentive
to use Octave; however, i do not see how writing octave-only code is
decisive for this aim.
On the other hand, writing mat-compatible functions can win users for
the tools and toolboxes (even if they still prefer the proprietary
engine). This could also bring in some additional testers for the
toolboxes. It might be also a way to raise the interest of some current
mat-users and developers. I think it would be a win for (the idea of)
Octave.