Legacy functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Legacy functions

Rik-4
Now that we have a new category of functions in the scripts
directory--functions which Matlab recommends against, but hasn't actually
eliminated--what other functions should we put there?

These look like possibilities: findstr, flipdim, strmatch, strread.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Legacy functions

PhilipNienhuis
Rik-4 wrote
> Now that we have a new category of functions in the scripts
> directory--functions which Matlab recommends against, but hasn't actually
> eliminated--what other functions should we put there?
>
> These look like possibilities: findstr, flipdim, strmatch, strread.

... textread, ....

To be complete we'd have to check quite a few functions and also change
docstrings; is it really worth developer time & -priority?

Also noting that all this apparently has been triggered by a user that wants
to run Matlab code that has gone unchanged for ~13 years.  No opinion on
that [*], but rather at consequences for our priorities.
Matlab compatibility is one of the biggest foundations of Octave's success
but I sometimes wonder how far the octave project should go in exactly
mimicking Matlab behavior, in this case informing about obsoleteness.
What is the compatibility target anyway: the very newest Matlab release, or
do we lag behind a few releases? (we already do w.r.t. several things: v7.3
mat files & classdef, new string class, table class, object-based graphics.)

[*] FTR at my work we still have Matlab code that is even (much) older and
still runs in Matlab r2018b prerelease.

Philip




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: legacy functions

Rik-4
In reply to this post by Rik-4
On 08/03/2018 07:12 PM, [hidden email] wrote:
Subject:
Re: Legacy functions
From:
PhilipNienhuis [hidden email]
Date:
08/03/2018 12:19 PM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAwMS5ub21hZA.1533317983@quikprotect>
In-Reply-To:
<MTAwMDAwMS5ub21hZA.1533317983@quikprotect>
Message-ID:
[hidden email]
Content-Type:
text/plain; charset=us-ascii
Message:
4

Rik-4 wrote
Now that we have a new category of functions in the scripts
directory--functions which Matlab recommends against, but hasn't actually
eliminated--what other functions should we put there?

These look like possibilities: findstr, flipdim, strmatch, strread.
... textread, ....

To be complete we'd have to check quite a few functions and also change
docstrings; is it really worth developer time & -priority?

I was viewing it from the other perspective.  It's really easy to put a single line, "This is not a recommended function." at the top of the docstring, move the function to the legacy directory, and then stop worrying about making the function Matlab compatible since neither Octave or Matlab wants programmers to use the function.

Also noting that all this apparently has been triggered by a user that wants
to run Matlab code that has gone unchanged for ~13 years.  No opinion on
that [*], but rather at consequences for our priorities.
Matlab compatibility is one of the biggest foundations of Octave's success
but I sometimes wonder how far the octave project should go in exactly
mimicking Matlab behavior, in this case informing about obsoleteness. 
What is the compatibility target anyway: the very newest Matlab release, or
do we lag behind a few releases? (we already do w.r.t. several things: v7.3
mat files & classdef, new string class, table class, object-based graphics.)
No clear answer on that.  I think we still aim for "mostly" compatible.  If someone really, really has an itch for a particular Matlab quirk they can always pay to have that implemented, and maybe just for them rather than making it in to Octave core.

--Rik