Re: Release 4.4.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0

Rik-4
On 12/23/2017 09:00 AM, [hidden email] wrote:
ForwardedMessage.eml
Subject:
Re: Release 4.4.2 plans
From:
Nicholas Jankowski [hidden email]
Date:
12/22/2017 02:48 PM
To:
Michael Godfrey [hidden email]
CC:
Rik [hidden email], octave-maintainers [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
<MTAwMDAyNC5ub21hZA.1513975944@quikprotect> [hidden email] <MTAwMDAxNC5ub21hZA.1513978291@quikprotect> [hidden email] <MTAwMDAzMi5ub21hZA.1513980489@quikprotect> [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
multipart/alternative; boundary="001a114c8be8ea98050560f59dc2"
Message:
1



On Dec 22, 2017 5:40 PM, "Michael D Godfrey" <[hidden email]> wrote:


On 12/22/2017 10:08 PM, Rik wrote:
On 12/22/2017 01:35 PM, Michael D Godfrey wrote:


On 12/22/2017 09:31 PM, Rik wrote:
Oops.  I mistyped.  I meant a 4.2.2 bug fix release of the stable branch.  4.4.0 is still a long ways off.

--Rik
I pretended that I did not notice:-):-)


I'm just used to being confused.

Last release someone took on the task of making a bug checklist, and then he and others sorted into critical, nice to have, and can wait. I think he also tackled a lot of the bug reviews.

I have done that for at least two releases.  For 4.2.0 I also got help from Lachlan Andrew.  There are already wiki templates that could be copied over if we want to do this is the same way.  The checklist for a release is at http://wiki.octave.org/4.2.0_Release_Checklist.  An example of the bug fix list is at http://wiki.octave.org/Bug_Fix_List_-_4.2.0_Release.  If we were a large commercial organization there would be a person dedicated to getting the release out, but alas that is not us and I don't have time to manage it for 4.4.0.

One of the items in the Release Checklist is to incorporate GSOC project code and patches which look good from the patch tracker.  It is best to do that early as that will de-stabilize things for a while and we want to get some testing on the new code before sending it out in to the world.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0

John W. Eaton
Administrator
On 12/27/2017 11:35 AM, Rik wrote:

> One of the items in the Release Checklist is to incorporate GSOC project
> code and patches which look good from the patch tracker.  It is best to
> do that early as that will de-stabilize things for a while and we want
> to get some testing on the new code before sending it out in to the world.

I will try to make a 4.2.2 release ASAP.

I'm afraid that if we incorporate GSoC code and the spreadsheet
functions from the I/O package now, then we will not have a new release
for at least another 6 months, probably even longer.

Rather than falling into the trap of trying to include and fix
everything before the next release I would prefer to move in the
direction of more frequent releases with major new features only being
added near the beginning of a release cycle.  So I propose that we not
add any large new chunks of code at this time but focus on fixing what
we can for a 4.4.0 release by the end of February.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Rik-4
On 12/27/2017 02:38 PM, John W. Eaton wrote:

> On 12/27/2017 11:35 AM, Rik wrote:
>
>> One of the items in the Release Checklist is to incorporate GSOC project
>> code and patches which look good from the patch tracker.  It is best to
>> do that early as that will de-stabilize things for a while and we want
>> to get some testing on the new code before sending it out in to the world.
>
> I will try to make a 4.2.2 release ASAP.
>
> I'm afraid that if we incorporate GSoC code and the spreadsheet functions
> from the I/O package now, then we will not have a new release for at
> least another 6 months, probably even longer.
>
> Rather than falling into the trap of trying to include and fix everything
> before the next release I would prefer to move in the direction of more
> frequent releases with major new features only being added near the
> beginning of a release cycle.  So I propose that we not add any large new
> chunks of code at this time but focus on fixing what we can for a 4.4.0
> release by the end of February.
>
> jwe

Arno,

You are listed as the package maintainer for the statistics package.  I'm
not sure if you are subscribed to the Octave Maintainer's list, but a
significant new 4.4.0 release is expected early next year (see quoted
e-mail above).  As part of that release, a lot of the statistics functions
are set to be removed from core Octave and transitioned to the statistics
package.  How can this be coordinated?

The base problem being addressed is that many of the functions, for example
kolmogorov_smirnov_test_2.m, are not of sufficient general utility to be
included in the core, but are still useful to practitioners of statistics.

Cheers,
Rik

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Olaf Till-2
On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:

> On 12/27/2017 02:38 PM, John W. Eaton wrote:
> > On 12/27/2017 11:35 AM, Rik wrote:
> >
> >> One of the items in the Release Checklist is to incorporate GSOC project
> >> code and patches which look good from the patch tracker.  It is best to
> >> do that early as that will de-stabilize things for a while and we want
> >> to get some testing on the new code before sending it out in to the world.
> >
> > I will try to make a 4.2.2 release ASAP.
> >
> > I'm afraid that if we incorporate GSoC code and the spreadsheet functions
> > from the I/O package now, then we will not have a new release for at
> > least another 6 months, probably even longer.
> >
> > Rather than falling into the trap of trying to include and fix everything
> > before the next release I would prefer to move in the direction of more
> > frequent releases with major new features only being added near the
> > beginning of a release cycle.  So I propose that we not add any large new
> > chunks of code at this time but focus on fixing what we can for a 4.4.0
> > release by the end of February.
> >
> > jwe
>
> Arno,
>
> You are listed as the package maintainer for the statistics package.  I'm
> not sure if you are subscribed to the Octave Maintainer's list, but a
> significant new 4.4.0 release is expected early next year (see quoted
> e-mail above).  As part of that release, a lot of the statistics functions
> are set to be removed from core Octave and transitioned to the statistics
> package.  How can this be coordinated?
>
> The base problem being addressed is that many of the functions, for example
> kolmogorov_smirnov_test_2.m, are not of sufficient general utility to be
> included in the core, but are still useful to practitioners of statistics.
>
> Cheers,
> Rik
Is there a list of these functions, or can you make one?

ML statistics toolbox has 'kstest' and 'kstest2', the latter probably
corresponding to the above 'kolmogorov_smirnov_test_2'. Is 'kstest'
of more general utility than 'kstest2'? How does the fact that there
is an ML-pendant in the statistics toolbox influence your decision to
move the code from Octave to Octave Forge? If it is moved, should we
rename the functions to their ML name, if appropriate?

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Olaf Till-2
In reply to this post by Rik-4
On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
>  As part of that release, a lot of the statistics functions
> are set to be removed from core Octave and transitioned to the statistics
> package.  How can this be coordinated?

I'd suggest to add a src/Makefile.in with rules that generate these
functions m-files only if the corresponding functions are lacking in
the applicable installed Octave.

If cross-compilation is detected by src/configure, the approach should
be different, probably generating all these files without further
checking (assuming cross-compilation is only done with new Octave
versions).

I could probably do that for Arno.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Rik-4
In reply to this post by Olaf Till-2
On 12/28/2017 03:02 AM, Olaf Till wrote:
> On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote: >> On 12/27/2017 02:38 PM, John W. Eaton wrote: >>> On 12/27/2017 11:35 AM, Rik wrote: >>> >>>> One of the items in the Release Checklist is to incorporate GSOC project >>>> code and patches which look good from the patch tracker. It is best to >>>> do that early as that will de-stabilize things for a while and we want >>>> to get some testing on the new code before sending it out in to the world. >>> >>> I will try to make a 4.2.2 release ASAP. >>> >>> I'm afraid that if we incorporate GSoC code and the spreadsheet functions >>> from the I/O package now, then we will not have a new release for at >>> least another 6 months, probably even longer. >>> >>> Rather than falling into the trap of trying to include and fix everything >>> before the next release I would prefer to move in the direction of more >>> frequent releases with major new features only being added near the >>> beginning of a release cycle. So I propose that we not add any large new >>> chunks of code at this time but focus on fixing what we can for a 4.4.0 >>> release by the end of February. >>> >>> jwe >> >> Arno, >> >> You are listed as the package maintainer for the statistics package. I'm >> not sure if you are subscribed to the Octave Maintainer's list, but a >> significant new 4.4.0 release is expected early next year (see quoted >> e-mail above). As part of that release, a lot of the statistics functions >> are set to be removed from core Octave and transitioned to the statistics >> package. How can this be coordinated? >> >> The base problem being addressed is that many of the functions, for example >> kolmogorov_smirnov_test_2.m, are not of sufficient general utility to be >> included in the core, but are still useful to practitioners of statistics. >> >> Cheers, >> Rik > > Is there a list of these functions, or can you make one?
The scripts statistics directory contains 4 sub-directories.  Everything in tests/, models/, distributions/ can go to the statistics package.

Within the base/ directory I would kick out:

cloglog.m
crosstab.m
ppplot.m
qqplot.m

These functions with base/ directory should be moved somewhere else within core

ols.m
gls.m
lscov.m  [ maybe placed in statistics package ]

After that, see what needs to be added back in.  I think quantile may rely on the empirical distribution which would require keeping that around in core.

> > > ML statistics toolbox has 'kstest' and 'kstest2', the latter probably > corresponding to the above 'kolmogorov_smirnov_test_2'. Is 'kstest' > of more general utility than 'kstest2'?
Octave also has a kolmogorov_smirnov_test.m which probably corresponds to the first function kstest.m

> How does the fact that there > is an ML-pendant in the statistics toolbox influence your decision to > move the code from Octave to Octave Forge?
No influence, not even sure what the ML-pendant thing is.

> If it is moved, should we > rename the functions to their ML name, if appropriate?
Yes, this makes sense to me.  You could always do as we do in core and keep a deprecated version of the function around for 2 release cycles.  For example, rename kolmogov_smirnov_test_2 to kstest2 and then create a new file kolmogov_smirnov_test_2 which just issues a warning and then calls kstest2

--- Code ---
function [pval, ks, d] = kolmogorov_smirnov_test_2 (x, y, alt)

  persistent warned = false;
  if (! warned)
    warned = true;
    warning ("Octave:deprecated-function",
             "kolmogorov_smirnov_test_2 is obsolete and will be removed from a future version of Octave, please use kstest2 instead");
  endif

 [pval, ks, d] = kstest2 (x, y, alt)

endfunction
--- End Code ---

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Rik-4
In reply to this post by Olaf Till-2
On 12/28/2017 05:29 AM, Olaf Till wrote:

> On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
>>  As part of that release, a lot of the statistics functions
>> are set to be removed from core Octave and transitioned to the statistics
>> package.  How can this be coordinated?
> I'd suggest to add a src/Makefile.in with rules that generate these
> functions m-files only if the corresponding functions are lacking in
> the applicable installed Octave.
>
> If cross-compilation is detected by src/configure, the approach should
> be different, probably generating all these files without further
> checking (assuming cross-compilation is only done with new Octave
> versions).
>
> I could probably do that for Arno.

That sounds like an elegant solution.  I was just going to let people get
shadowed function warnings, but your way is better.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Olaf Till-2
On Thu, Dec 28, 2017 at 08:26:31AM -0800, Rik wrote:

> On 12/28/2017 05:29 AM, Olaf Till wrote:
> > On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
> >>  As part of that release, a lot of the statistics functions
> >> are set to be removed from core Octave and transitioned to the statistics
> >> package.  How can this be coordinated?
> > I'd suggest to add a src/Makefile.in with rules that generate these
> > functions m-files only if the corresponding functions are lacking in
> > the applicable installed Octave.
> >
> > If cross-compilation is detected by src/configure, the approach should
> > be different, probably generating all these files without further
> > checking (assuming cross-compilation is only done with new Octave
> > versions).
> >
> > I could probably do that for Arno.
>
> That sounds like an elegant solution.  I was just going to let people get
> shadowed function warnings, but your way is better.
So I'll put this on my list for the next few days. (Still considering
further suggestions, of course.)

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Philip Nienhuis
Olaf Till-2 wrote

> On Thu, Dec 28, 2017 at 08:26:31AM -0800, Rik wrote:
>> On 12/28/2017 05:29 AM, Olaf Till wrote:
>> > On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
>> >>  As part of that release, a lot of the statistics functions
>> >> are set to be removed from core Octave and transitioned to the
>> statistics
>> >> package.  How can this be coordinated?
>> > I'd suggest to add a src/Makefile.in with rules that generate these
>> > functions m-files only if the corresponding functions are lacking in
>> > the applicable installed Octave.
>> >
>> > If cross-compilation is detected by src/configure, the approach should
>> > be different, probably generating all these files without further
>> > checking (assuming cross-compilation is only done with new Octave
>> > versions).
>> >
>> > I could probably do that for Arno.
>>
>> That sounds like an elegant solution.  I was just going to let people get
>> shadowed function warnings, but your way is better.
>
> So I'll put this on my list for the next few days. (Still considering
> further suggestions, of course.)

Carnë did a similar thing for the mapping package as regards deg2rad.m and
rad2deg.m, that works regardless of cross-compiling or not but only checks
if the installed Octave has the functions available.
When cross-compiling in mxe-octave it gave rise to some issues but I think
JohnD dealt with that.

Philip




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

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0

PhilipNienhuis
In reply to this post by John W. Eaton
John W. Eaton wrote

> On 12/27/2017 11:35 AM, Rik wrote:
>
>> One of the items in the Release Checklist is to incorporate GSOC project
>> code and patches which look good from the patch tracker.  It is best to
>> do that early as that will de-stabilize things for a while and we want
>> to get some testing on the new code before sending it out in to the
>> world.
>
> I will try to make a 4.2.2 release ASAP.
>
> I'm afraid that if we incorporate GSoC code and the spreadsheet
> functions from the I/O package now, then we will not have a new release
> for at least another 6 months, probably even longer.
>
> Rather than falling into the trap of trying to include and fix
> everything before the next release I would prefer to move in the
> direction of more frequent releases with major new features only being
> added near the beginning of a release cycle.  So I propose that we not
> add any large new chunks of code at this time but focus on fixing what
> we can for a 4.4.0 release by the end of February.

Fair enough.
So 4.6.0 would be only be -say- a little over year away rather than 1.5 or 2
years? Sounds good to me.

BTW the spreadsheet I/O has been maturing for many years.
I am a bit indifferent about moving it to core. AFAIU the main reason would
be Matlab compatibility ("expectations of Matlab users moving to Octave").
If that would help to attract more Octave users I'm all in favor; but
otherwise having it in an add-on package (that is even free as in "free
beer") doesn't look like a big obstacle to me (but that's just me). Other
script languages (e.g., Python, R) have such I/O options in add-on packages
as well.

Philip




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

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Olaf Till-2
In reply to this post by Philip Nienhuis
On Thu, Dec 28, 2017 at 12:23:17PM -0700, Philip Nienhuis wrote:
> Carnë did a similar thing for the mapping package as regards deg2rad.m and
> rad2deg.m, that works regardless of cross-compiling or not but only checks
> if the installed Octave has the functions available.
> When cross-compiling in mxe-octave it gave rise to some issues but I think
> JohnD dealt with that.

Thanks, I'll look at it.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Arno Onken-2
In reply to this post by Olaf Till-2
On 28.12.2017 17:48, Olaf Till wrote:

> On Thu, Dec 28, 2017 at 08:26:31AM -0800, Rik wrote:
>> On 12/28/2017 05:29 AM, Olaf Till wrote:
>>> On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
>>>>  As part of that release, a lot of the statistics functions
>>>> are set to be removed from core Octave and transitioned to the statistics
>>>> package.  How can this be coordinated?
>>> I'd suggest to add a src/Makefile.in with rules that generate these
>>> functions m-files only if the corresponding functions are lacking in
>>> the applicable installed Octave.
>>>
>>> If cross-compilation is detected by src/configure, the approach should
>>> be different, probably generating all these files without further
>>> checking (assuming cross-compilation is only done with new Octave
>>> versions).
>>>
>>> I could probably do that for Arno.
>>
>> That sounds like an elegant solution.  I was just going to let people get
>> shadowed function warnings, but your way is better.
>
> So I'll put this on my list for the next few days. (Still considering
> further suggestions, of course.)

Thanks, Olaf, that would be great!  Sorry for the late reply.  I took up
a new job recently and am terribly busy at the moment.

Arno

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Rik-4
On 01/04/2018 02:29 PM, Arno Onken wrote:

> On 28.12.2017 17:48, Olaf Till wrote:
>> On Thu, Dec 28, 2017 at 08:26:31AM -0800, Rik wrote:
>>> On 12/28/2017 05:29 AM, Olaf Till wrote:
>>>> On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
>>>>>  As part of that release, a lot of the statistics functions
>>>>> are set to be removed from core Octave and transitioned to the statistics
>>>>> package.  How can this be coordinated?
>>>> I'd suggest to add a src/Makefile.in with rules that generate these
>>>> functions m-files only if the corresponding functions are lacking in
>>>> the applicable installed Octave.
>>>>
>>>> If cross-compilation is detected by src/configure, the approach should
>>>> be different, probably generating all these files without further
>>>> checking (assuming cross-compilation is only done with new Octave
>>>> versions).
>>>>
>>>> I could probably do that for Arno.
>>> That sounds like an elegant solution.  I was just going to let people get
>>> shadowed function warnings, but your way is better.
>> So I'll put this on my list for the next few days. (Still considering
>> further suggestions, of course.)
> Thanks, Olaf, that would be great!  Sorry for the late reply.  I took up
> a new job recently and am terribly busy at the moment.
>
> Arno
Olaf,

I'll wait a couple of days and then remove the functions from Octave core. 
You can always retrieve them from a Mercurial version in which they haven't
been deleted for copying in to the statistics package.  The header will
need to change because right now it says "## This file is part of Octave."

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Olaf Till-2
On Thu, Jan 04, 2018 at 02:39:45PM -0800, Rik wrote:

> On 01/04/2018 02:29 PM, Arno Onken wrote:
> > On 28.12.2017 17:48, Olaf Till wrote:
> >> On Thu, Dec 28, 2017 at 08:26:31AM -0800, Rik wrote:
> >>> On 12/28/2017 05:29 AM, Olaf Till wrote:
> >>>> On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
> >>>>>  As part of that release, a lot of the statistics functions
> >>>>> are set to be removed from core Octave and transitioned to the statistics
> >>>>> package.  How can this be coordinated?
> >>>> I'd suggest to add a src/Makefile.in with rules that generate these
> >>>> functions m-files only if the corresponding functions are lacking in
> >>>> the applicable installed Octave.
> >>>>
> >>>> If cross-compilation is detected by src/configure, the approach should
> >>>> be different, probably generating all these files without further
> >>>> checking (assuming cross-compilation is only done with new Octave
> >>>> versions).
> >>>>
> >>>> I could probably do that for Arno.
> >>> That sounds like an elegant solution.  I was just going to let people get
> >>> shadowed function warnings, but your way is better.
> >> So I'll put this on my list for the next few days. (Still considering
> >> further suggestions, of course.)
> > Thanks, Olaf, that would be great!  Sorry for the late reply.  I took up
> > a new job recently and am terribly busy at the moment.
> >
> > Arno
> Olaf,
>
> I'll wait a couple of days and then remove the functions from Octave core. 
> You can always retrieve them from a Mercurial version in which they haven't
> been deleted for copying in to the statistics package.  The header will
> need to change because right now it says "## This file is part of Octave."
Brute force -- _all_ Octave statistics functions are now in the OF
statistics package (with the changes to the license text as indicated
above, thanks) and will be installed if needed. We can weed out some
of them still.

No renaming/deprecating is done as yet, this can be done later.

Cross-compilation is cared for, but needs manual configuration as
indicated by an error message or in the README.crosscompilation file.

Olaf

--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Rik-4
On 01/07/2018 09:33 AM, Olaf Till wrote:

> On Thu, Jan 04, 2018 at 02:39:45PM -0800, Rik wrote:
>> On 01/04/2018 02:29 PM, Arno Onken wrote:
>>> On 28.12.2017 17:48, Olaf Till wrote:
>>>> On Thu, Dec 28, 2017 at 08:26:31AM -0800, Rik wrote:
>>>>> On 12/28/2017 05:29 AM, Olaf Till wrote:
>>>>>> On Wed, Dec 27, 2017 at 03:46:41PM -0800, Rik wrote:
>>>>>>>  As part of that release, a lot of the statistics functions
>>>>>>> are set to be removed from core Octave and transitioned to the statistics
>>>>>>> package.  How can this be coordinated?
>>>>>> I'd suggest to add a src/Makefile.in with rules that generate these
>>>>>> functions m-files only if the corresponding functions are lacking in
>>>>>> the applicable installed Octave.
>>>>>>
>>>>>> If cross-compilation is detected by src/configure, the approach should
>>>>>> be different, probably generating all these files without further
>>>>>> checking (assuming cross-compilation is only done with new Octave
>>>>>> versions).
>>>>>>
>>>>>> I could probably do that for Arno.
>>>>> That sounds like an elegant solution.  I was just going to let people get
>>>>> shadowed function warnings, but your way is better.
>>>> So I'll put this on my list for the next few days. (Still considering
>>>> further suggestions, of course.)
>>> Thanks, Olaf, that would be great!  Sorry for the late reply.  I took up
>>> a new job recently and am terribly busy at the moment.
>>>
>>> Arno
>> Olaf,
>>
>> I'll wait a couple of days and then remove the functions from Octave core. 
>> You can always retrieve them from a Mercurial version in which they haven't
>> been deleted for copying in to the statistics package.  The header will
>> need to change because right now it says "## This file is part of Octave."
> Brute force -- _all_ Octave statistics functions are now in the OF
> statistics package (with the changes to the license text as indicated
> above, thanks) and will be installed if needed. We can weed out some
> of them still.
>
> No renaming/deprecating is done as yet, this can be done later.
>
> Cross-compilation is cared for, but needs manual configuration as
> indicated by an error message or in the README.crosscompilation file.

Olaf,

Many thanks for that work.  I removed most of the functions from the core
in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/fdc9ce839afd). 
Most of the work was actually re-writing the Statistics chapter of the
manual to make sense again.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

jbect
Le 08/01/2018 à 02:24, Rik a écrit :
> Many thanks for that work.  I removed most of the functions from the core
> in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/fdc9ce839afd).
> Most of the work was actually re-writing the Statistics chapter of the
> manual to make sense again.

What about functions such as mean, median, mode, std, var ?

In Matlab they belong to "Matlab core", not to the Statistic& & ML toolbox:

https://fr.mathworks.com/help/matlab/data_analysis/descriptive-statistics.html,

which means that now, some programs that run on Matlab without any
dependency will not run on Octave unless the statistics package is loaded...

Just my two cents, sorry if this has been discussed before...

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

Daniel Sebald
On 01/08/2018 01:55 AM, Julien Bect wrote:

> Le 08/01/2018 à 02:24, Rik a écrit :
>> Many thanks for that work.  I removed most of the functions from the core
>> in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/fdc9ce839afd).
>> Most of the work was actually re-writing the Statistics chapter of the
>> manual to make sense again.
>
> What about functions such as mean, median, mode, std, var ?
>
> In Matlab they belong to "Matlab core", not to the Statistic& & ML toolbox:
>
> https://fr.mathworks.com/help/matlab/data_analysis/descriptive-statistics.html,
>
>
> which means that now, some programs that run on Matlab without any
> dependency will not run on Octave unless the statistics package is
> loaded...
>
> Just my two cents, sorry if this has been discussed before...

I also didn't quite understand that statistics function discussion.  It
sounded like any stats-related functions would be moved to the
statistics package.  But I've pulled the latest code and it looks like
the routines such as var.m, corr.m, etc. have simply been moved to
./scripts/statistics/ directory.  I think the title of the changeset is
a bit misleading in that it suggests all routines were removed when it
was only the non-common ones that were removed; "(re)move" might have
suggested it wasn't that simple.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Release 4.4.0 and statistics package

jbect
Le 08/01/2018 à 09:39, Daniel J Sebald a écrit :

> On 01/08/2018 01:55 AM, Julien Bect wrote:
>> Le 08/01/2018 à 02:24, Rik a écrit :
>>> Many thanks for that work.  I removed most of the functions from the
>>> core
>>> in this cset
>>> (http://hg.savannah.gnu.org/hgweb/octave/rev/fdc9ce839afd).
>>> Most of the work was actually re-writing the Statistics chapter of the
>>> manual to make sense again.
>>
>> What about functions such as mean, median, mode, std, var ?
>>
>> In Matlab they belong to "Matlab core", not to the Statistic& & ML
>> toolbox:
>>
>> https://fr.mathworks.com/help/matlab/data_analysis/descriptive-statistics.html,
>>
>>
>> which means that now, some programs that run on Matlab without any
>> dependency will not run on Octave unless the statistics package is
>> loaded...
>>
>> Just my two cents, sorry if this has been discussed before...
>
> I also didn't quite understand that statistics function discussion. 
> It sounded like any stats-related functions would be moved to the
> statistics package.  But I've pulled the latest code and it looks like
> the routines such as var.m, corr.m, etc. have simply been moved to
> ./scripts/statistics/ directory.  I think the title of the changeset
> is a bit misleading in that it suggests all routines were removed when
> it was only the non-common ones that were removed; "(re)move" might
> have suggested it wasn't that simple.

Ok, my bad.  I misunderstood Rik's commit message.

Yes, these functions were moved from ./scripts/statistics/base to
./scripts/statistics, so they're still in Octave cor, everythng is fine.

Sorry for the noise.