[OctDev] Question on performance, coding style and competitive software

[Joe Vornehm Jr.]

On Wed, Apr 22, 2009 at 1:27 PM, Jaroslav Hajek <highegg at gmail.com> wrote:

> On Wed, Apr 22, 2009 at 4:18 PM, Alois Schlögl <alois.schloegl at tugraz.at>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www-old.cae.wisc.edu/pipermail/octave-maintainers/attachments/20090422/a95a86b2/attachment.html