[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: statistics package more suitable for nlinfit et al.?

From: Julien Bect
Subject: Re: statistics package more suitable for nlinfit et al.?
Date: Thu, 20 Aug 2015 22:01:33 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

Le 19/08/2015 12:35, Olaf Till a écrit :
After some modifications and fixes to docs and demo, and a
modification in the way weighted residuals are computed, nlinfit.m is
now ready for inclusion into Octave Forge, as are statset.m,
statget.m, and __all_stat_opts__.m.

Do we want the degree in Matlab compatibility to have these functions
in the statistics package, which corresponds to the 'correct' Matlab
package? It would make the statistics package depend on the optim
package, since nlinfit wraps nonlin_curvefit and curvefit_stat.


Is there a general policy about such things in the Octave Forge project? If not, should we adopt one?

Is this a goal of the Octave Forge project to provide one-by-one replacement for some (if not all) Matlab toolboxes ? Or is it enough to point to the right direction when a user asks for a function, like this:

>> nlinfit
warning: the 'nlinfit' function belongs to the statistics package from Octave
Forge which you have installed but not loaded.  To load the package, run
'pkg load statistics' from the Octave prompt.


Is there somewhere a list of the Octave Forge packages that aim at providing a compatible replacement for a corresponding Matlab toolbox?

For instance, how can I know for the Octave Forge website whether the "statistics" package aims at being a compatible replacement for the Mathworks' "Statistics Toolbox"? And what about control, signal, symbolic... ?

Just my two cents :-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]