Re: Matlab Compatibility

[Rik]

On 03/25/2016 12:18 PM, address@hidden wrote:
>
>     ? "...Matlab ... therefore..." ?
>
> That "therefore" comes a little quick for me.
>
> Until now I'm only sure that Octave strives to be Matlab-compatible in
> the sense of being able to run Matlab code. Good!
> But when did who decide that Octave should mimic Matlab beyond code
> compatibility and also copy less handy aspects? IOW, where is the basis
> for "... therefore..."?
>
> My motive is simply this:
> I find it much more natural to have functions sorted and divided into
> add-on packages according to what they do, rather then where they happen
> to be located in some commercial product that is required to keep a
> sometimes clumsy legacy around just because of its business model.
>
> New Octave users, not coming from Matlab, would expect functions
> operating on points, lines and polygons to be grouped together, and not
> scattered over separate "toolboxes" / add-on packages.
> Matlab users OTOH would quickly enough get used to "other" function
> locations. After all, Octave's "toolboxes" have no price tag hence no
> obstacle for installation AFAICS.
>
> Octave's mapping toolbox already has a (suggested) dependency on the
> geometry package for other functions than polygon operations.
>
> It's not that I'm pertinently against polygon operation functions in the
> mapping package. My motive is just what I wrote above.
>
> But I feel that the "decision", or lack of clear decision, about how far
> Octave should go to become a verbatim Matlab clone and thus also follow
> less logical/natural TMW decisions, is very implicitly made.  If the
> majority agrees, OK, then I'll shut up on this subject.
>
> Thoughts?

It probably can't be decided in the form of a rule that, when applied,
would give you the answer every time about whether a feature should or
should not be adopted.  My preference is that Octave remain it's own
creature, rather than a slave to TMW's whims.  If you experience a WTF!
Matlab moment when encountering a new feature, that would be reason enough
for me to say we shouldn't implement it.

This topic happens to be very timely as well.  There is a discussion in
this bug report (https://savannah.gnu.org/bugs/?47415) about how to handle
Permutation and Diagonal matrices.  These are an Octave-only feature which
save memory and computation time, but aren't Matlab-compatible since they
only implement full or sparse matrices.  Do we ditch the cool feature just
because it isn't compatible in some cases?  Do we try to warn users when
computations might differ from Matlab?  Is there a maximum compatibility
mode when you absolutely, positively need verbatim braindead behavior?  I
don't know.

--Rik
>
> Philip