On Wed, Apr 22, 2009 at 1:27 PM, Jaroslav Hajek
<address@hidden> wrote:
On Wed, Apr 22, 2009 at 4:18 PM, Alois Schlögl <
address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Bateman wrote:
>> Alois Schlögl wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> 2) Coding style:
>>> Octave understands a superset of commands compared to matlab, and it
>>> seems the current policy is to enforce the "octave style" and make the
>>> use of toolboxes incompatible for a use with Matlab. Is not it sensible
>>> to write platform-neutral applications ? Specifically, is not it in our
>>> own interest (wider usage make the code more robust) that matlab users
>>> are not "forced" to buy additional toolboxes but can use open source
>>> toolboxes e.g. from octave-forge?
>>>
>> I'd personally consider that up to the toolboxes author. Using texinfo
>> in the help string makes the Octave help string "nicer".... I however
>> don't think a policy should be made that toolboxes on octave-forge
>> should be matlab compatible..
>>
>
>
> I know its up to the toolbox authors. I'm not sure that every author is
> aware of this. In case someone wants to modify some functions from
> octave-forge/main for the use with matlab, and make it available to
> others, what is the proper procedure for this (a) if he is the original
> author and the function is already in octave-forge/main (b) if he wants
> to modify an existing function from some other author ?
If he wants to keep that function in the package, then (obviously) he
should follow the package's policy (determined by author or
maintainer). If he just wants to share it on his own, then he should
feel free to do any changes he wishes, as long as he honors the GPL.
> The texinfo is the minor problem, because the function is still usable
> even if the documentation is not properly displayed.
> The main issues are the incompatible syntax like
> - - comments: # vs. %
> - - end vs. endif-endfor-endwhile-endfunction etc.,
> - - single quote vs. double quote
> - - negation operator: ! vs ~
> which make it impossible to use most octave toolboxes in Matlab
>
> BTW, what are the arguments in favor of using octave-only coding style ?
>
comments: # is much more common. % is, AFAIK, recognized only by
Octave and other Matlabish software and TeX.
Also, on UNIX # allows to use the #! mechanism and thus make
executable octave scripts.
specific end blocks: they catch typing errors more easily, and the
code is more easily parsable for both humans and computers. I also
consider it an extremely bad idea that "end" is likewise used in index
expressions. I think Cleve Moler (or whoever designed it) must have
been drinking that night.
quotes: again, double quotes are somewhat more standard, in particular
in the C-derived world. more importantly, ""s allow things like \n,
\t.
negation - this is purely syntactic sugar, AFAIK, again for
compatibility with the C world.
For issues like the ones cited where it's just a matter of coding style, Octave-to-MATLAB converters exist, though I can't speak for their effectiveness. Google "convert octave to matlab" and look at the first four or five results. I wrote one myself in Perl for my own code (which I write with an eye toward MATLAB compatibility anyway), and it wasn't terribly hard.
There are a few things that don't translate easily, such as unwind_protect, do-until, and ++/-- in the middle of a complicated _expression_. They are nice features to have. (Honestly, I don't see why MathWorks doesn't just implement them, as well as the "syntactic sugar.") And, of course, there are sometimes differences in function libraries between Octave and MATLAB. Authors trying to write code that's portable between the two need to restrict themselves to functions that exist and work the same in both; that's not something that can be automatically translated, beyond trivial cases.
Joe V.