[Math] Toward releasing 3.0 ?

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

[Math] Toward releasing 3.0 ?

Gilles Sadowski
Hello.

Among the good resolutions for this new year 2012, there had been rumours
about releasing Commons Math 3.0 around mid-January.

I've been reviewing the list of open issues and postponed several issues to
3.1 (mostly because there were no patch).
Pending design issues (matrix interface, etc.) are too fuzzy; thus unlikely
to be correctly implemented in a short timespan.

As far as I'm concerned, in order to meet a deadline that was mentioned
some time ago (in November last year, IIRC), there must be a feature freeze
as soon as possible, and an official release before March.

It thus becomes urgent to tackle the remaining blocking issues.
Can we please make a list of those, and of all practical matters that
prevent the preparation of the release?


Thanks and best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Sébastien Brisard
Hi Gilles,
>
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
>
>
> Thanks and best regards,
> Gilles
>
As far as I'm concerned, I have been concentrating recently on
MATH-677 and MATH-722. However, both issues are non-blocking, because
I don't foresee any interface change now (regarding MATH-677, exposing
the complex roots would just be a feature addition, as it is a private
class right now). MATH-722 would merely be a bug correction.

There is one thing I would like to reshape a little bit : that's the
interface for IterativeLinearSolvers, which I found (after having used
it) poorly designed. As this is blocking, maybe I should concentrate
on this issue right now ?

Otherwise, I'm available for anything that would take us nearer to
releasing 3.0 (how exciting! First release since I joined!).

Best regards,
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Thomas Neidhart
In reply to this post by Gilles Sadowski
On 01/25/2012 01:13 PM, Gilles Sadowski wrote:

> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?

Hi,

a release quite soon would also be appreciated from my side.

As for the issues I am currently work on:

- MATH-235, which is still targeted for 3.1 but it would be nice to
  include it already in 3.0 and it should be ready in 1-2 weeks

- MATH-651 which is directly related to MATH-235

- MATH-575 for the cleanup of the genetics package which should be
  almost done I guess

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Gilles Sadowski
In reply to this post by Gilles Sadowski
Hi.

>
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
>


MATH-621 (see also MATH-728)
 * Unit test coverage: at least 6 branches of the code are not explored.
 * Code complexity:
    - Variable "state" that is similar to having goto's
    - drop from one "case" to the next (no "break")
    - explicit matrix computations
 * Code fragility: success or failure of some unit tests depends on the
   order of floating point operations (addition).
 * Support: no resource in the CM team to bring the code to a state where
   a Java developer can maintain it.

 I'm wary to release the code in that state.


MATH-698
 IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
 (e.g. look at method "encode", lines 904-914).
 I don't have the knowledge about the algorithm in order to know how to
 modify that code so that it will behave correctly when only one of the
 bounds is infinite (a valid case allowed by the base class for optimizers
 with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").

 I would not want to release an API where simple bounds are dealt differently
 in "CMAESOptimizer" than in the supposedly common interface.


MATH-726
 This is really a small issue. But the discussion has stalled because of a
 long-term wish concerning a design convergence with the "nabla" project.
 I'd rather introduce the code now, in a form that is similar to the design
 of other packages ("solvers", "optimization", "integration").
 I see no problem in changing that later, in the same way that there are
 suggestions to change other things (e.g. matrix interface, factories, ...).


MATH-707
 A few more changes to be done.


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Gilles Sadowski
In reply to this post by Sébastien Brisard
Hello.

> > It thus becomes urgent to tackle the remaining blocking issues.
> > Can we please make a list of those, and of all practical matters that
> > prevent the preparation of the release?
> >
> >
> > Thanks and best regards,
> > Gilles
> >
> As far as I'm concerned, I have been concentrating recently on
> MATH-677 and MATH-722. However, both issues are non-blocking, because
> I don't foresee any interface change now (regarding MATH-677, exposing
> the complex roots would just be a feature addition, as it is a private
> class right now). MATH-722 would merely be a bug correction.

It was my impression that an identified bug is a blocking issue.
Is it difficult to solve? If so, maybe that we can postpone it, and add a
warning in the release notes (?).

> There is one thing I would like to reshape a little bit : that's the
> interface for IterativeLinearSolvers, which I found (after having used
> it) poorly designed. As this is blocking, maybe I should concentrate
> on this issue right now ?

This, in my opinion, is not blocking. Maybe the design must be improved (as
your own usage has shown already, it seems) but it could be done in 4.0.
This design issue should not delay the release of 3.0.
Of course, you can do whatever changes you think would be for the better.
:-)

> Otherwise, I'm available for anything that would take us nearer to
> releasing 3.0 (how exciting! First release since I joined!).

Same for me (first _major_ release).

Those who know what must be done, could you please post here some pointers
to a document that decribe the currently recommended and necessary steps for
preparing a release?


Thanks,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Sébastien Brisard
2012/1/26 Gilles Sadowski <[hidden email]>:

> Hello.
>
>> > It thus becomes urgent to tackle the remaining blocking issues.
>> > Can we please make a list of those, and of all practical matters that
>> > prevent the preparation of the release?
>> >
>> >
>> > Thanks and best regards,
>> > Gilles
>> >
>> As far as I'm concerned, I have been concentrating recently on
>> MATH-677 and MATH-722. However, both issues are non-blocking, because
>> I don't foresee any interface change now (regarding MATH-677, exposing
>> the complex roots would just be a feature addition, as it is a private
>> class right now). MATH-722 would merely be a bug correction.
>
> It was my impression that an identified bug is a blocking issue.
> Is it difficult to solve? If so, maybe that we can postpone it, and add a
> warning in the release notes (?).
>
Yes, you're right. So the quick answer is : the fix proposed by Juan
is correct and *should* be implemented. However, I'm worried about
accuracy of tanh(z) for large (but not too-large) values of the real
part of z. I haven't had the time yet to investigate this specific
point.

>> There is one thing I would like to reshape a little bit : that's the
>> interface for IterativeLinearSolvers, which I found (after having used
>> it) poorly designed. As this is blocking, maybe I should concentrate
>> on this issue right now ?
>
> This, in my opinion, is not blocking. Maybe the design must be improved (as
> your own usage has shown already, it seems) but it could be done in 4.0.
> This design issue should not delay the release of 3.0.
> Of course, you can do whatever changes you think would be for the better.
> :-)
>
What I meant is: once it's in the wild, we cannot do anything until
the next major release. I would like to add a couple of methods in the
current interface (merely to be able to retrieve the current value of
the residual, and the current iteration number). In fact I've been
using these solvers recently and have lacked these methods. This can
be done fairly quickly, but I need to think a little bit on the most
appropriate way. Nothing major, but it would be nice if it was already
in 3.0.

>> Otherwise, I'm available for anything that would take us nearer to
>> releasing 3.0 (how exciting! First release since I joined!).
>
> Same for me (first _major_ release).
>
> Those who know what must be done, could you please post here some pointers
> to a document that decribe the currently recommended and necessary steps for
> preparing a release?
>
>
> Thanks,
> Gilles
>
Best regards,
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Sébastien Brisard
In reply to this post by Gilles Sadowski
Hello,

> Hi.
>
>>
>> It thus becomes urgent to tackle the remaining blocking issues.
>> Can we please make a list of those, and of all practical matters that
>> prevent the preparation of the release?
>>
>
>
> MATH-621 (see also MATH-728)
>  * Unit test coverage: at least 6 branches of the code are not explored.
>  * Code complexity:
>    - Variable "state" that is similar to having goto's
>    - drop from one "case" to the next (no "break")
>    - explicit matrix computations
>  * Code fragility: success or failure of some unit tests depends on the
>   order of floating point operations (addition).
>  * Support: no resource in the CM team to bring the code to a state where
>   a Java developer can maintain it.
>
>  I'm wary to release the code in that state.
>
The last point is indeed quite worrying. If we are planning for a
release taking place briefly, I'm of no use, because digging into this
would take me forever (even if it must be done in the end by one of
us, I suppose).

>
> MATH-698
>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>  (e.g. look at method "encode", lines 904-914).
>  I don't have the knowledge about the algorithm in order to know how to
>  modify that code so that it will behave correctly when only one of the
>  bounds is infinite (a valid case allowed by the base class for optimizers
>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>
>  I would not want to release an API where simple bounds are dealt differently
>  in "CMAESOptimizer" than in the supposedly common interface.
>
>
> MATH-726
>  This is really a small issue. But the discussion has stalled because of a
>  long-term wish concerning a design convergence with the "nabla" project.
>  I'd rather introduce the code now, in a form that is similar to the design
>  of other packages ("solvers", "optimization", "integration").
>  I see no problem in changing that later, in the same way that there are
>  suggestions to change other things (e.g. matrix interface, factories, ...).
>
I agree. It's only after playing around with this new feature that we
will be able to find its (potential) flaws. However, I do realize that
not everyone may agree on this...
>
> MATH-707
>  A few more changes to be done.
>
>
> Regards,
> Gilles
>
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

sebb-2-2
In reply to this post by Gilles Sadowski
On 26 January 2012 14:39, Gilles Sadowski <[hidden email]> wrote:

> Hello.
>
>> > It thus becomes urgent to tackle the remaining blocking issues.
>> > Can we please make a list of those, and of all practical matters that
>> > prevent the preparation of the release?
>> >
>> >
>> > Thanks and best regards,
>> > Gilles
>> >
>> As far as I'm concerned, I have been concentrating recently on
>> MATH-677 and MATH-722. However, both issues are non-blocking, because
>> I don't foresee any interface change now (regarding MATH-677, exposing
>> the complex roots would just be a feature addition, as it is a private
>> class right now). MATH-722 would merely be a bug correction.
>
> It was my impression that an identified bug is a blocking issue.

As usual - it depends.

If the bug is a regression then it should probably block a release.
But even then, if the reason for the regression was to fix a worse
bug, then it may be OK to release.

It also depends on the relative cost of fixing the bug before and
after a release.
If the bug is in a new API, it's generally going to be cheaper to fix
before release rather than break compatibility later.

> Is it difficult to solve? If so, maybe that we can postpone it, and add a
> warning in the release notes (?).

Adding a warning for known (major) bugs is a good idea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Luc Maisonobe
In reply to this post by Gilles Sadowski
Le 26/01/2012 15:39, Gilles Sadowski a écrit :

> Hello.
>
>>> It thus becomes urgent to tackle the remaining blocking issues.
>>> Can we please make a list of those, and of all practical matters that
>>> prevent the preparation of the release?
>>>
>>>
>>> Thanks and best regards,
>>> Gilles
>>>
>> As far as I'm concerned, I have been concentrating recently on
>> MATH-677 and MATH-722. However, both issues are non-blocking, because
>> I don't foresee any interface change now (regarding MATH-677, exposing
>> the complex roots would just be a feature addition, as it is a private
>> class right now). MATH-722 would merely be a bug correction.
>
> It was my impression that an identified bug is a blocking issue.
> Is it difficult to solve? If so, maybe that we can postpone it, and add a
> warning in the release notes (?).
>
>> There is one thing I would like to reshape a little bit : that's the
>> interface for IterativeLinearSolvers, which I found (after having used
>> it) poorly designed. As this is blocking, maybe I should concentrate
>> on this issue right now ?
>
> This, in my opinion, is not blocking. Maybe the design must be improved (as
> your own usage has shown already, it seems) but it could be done in 4.0.
> This design issue should not delay the release of 3.0.

+1

> Of course, you can do whatever changes you think would be for the better.
> :-)
>
>> Otherwise, I'm available for anything that would take us nearer to
>> releasing 3.0 (how exciting! First release since I joined!).
>
> Same for me (first _major_ release).

I agree we should release now, sorry for the very long delay.

>
> Those who know what must be done, could you please post here some pointers
> to a document that decribe the currently recommended and necessary steps for
> preparing a release?

If you plane to use Nexus, here are some guidelines, mainly written by
Sebb if I remember well: <http://wiki.apache.org/commons/UsingNexus>.

>
>
> Thanks,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Luc Maisonobe
In reply to this post by Sébastien Brisard
Le 26/01/2012 15:52, Sébastien Brisard a écrit :

> Hello,
>> Hi.
>>
>>>
>>> It thus becomes urgent to tackle the remaining blocking issues.
>>> Can we please make a list of those, and of all practical matters that
>>> prevent the preparation of the release?
>>>
>>
>>
>> MATH-621 (see also MATH-728)
>>  * Unit test coverage: at least 6 branches of the code are not explored.
>>  * Code complexity:
>>    - Variable "state" that is similar to having goto's
>>    - drop from one "case" to the next (no "break")
>>    - explicit matrix computations
>>  * Code fragility: success or failure of some unit tests depends on the
>>   order of floating point operations (addition).
>>  * Support: no resource in the CM team to bring the code to a state where
>>   a Java developer can maintain it.
>>
>>  I'm wary to release the code in that state.
>>
> The last point is indeed quite worrying. If we are planning for a
> release taking place briefly, I'm of no use, because digging into this
> would take me forever (even if it must be done in the end by one of
> us, I suppose).

As strange as it might seem, I would like to see this code part of 3.0
with a big "experimental" flag on it. People can use it at their own
risk, but they can also help improve it.

Luc

>
>>
>> MATH-698
>>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>>  (e.g. look at method "encode", lines 904-914).
>>  I don't have the knowledge about the algorithm in order to know how to
>>  modify that code so that it will behave correctly when only one of the
>>  bounds is infinite (a valid case allowed by the base class for optimizers
>>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>
>>  I would not want to release an API where simple bounds are dealt differently
>>  in "CMAESOptimizer" than in the supposedly common interface.
>>
>>
>> MATH-726
>>  This is really a small issue. But the discussion has stalled because of a
>>  long-term wish concerning a design convergence with the "nabla" project.
>>  I'd rather introduce the code now, in a form that is similar to the design
>>  of other packages ("solvers", "optimization", "integration").
>>  I see no problem in changing that later, in the same way that there are
>>  suggestions to change other things (e.g. matrix interface, factories, ...).
>>
> I agree. It's only after playing around with this new feature that we
> will be able to find its (potential) flaws. However, I do realize that
> not everyone may agree on this...
>>
>> MATH-707
>>  A few more changes to be done.
>>
>>
>> Regards,
>> Gilles
>>
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Gilles Sadowski
Hi.

> >>>
> >>> It thus becomes urgent to tackle the remaining blocking issues.
> >>> Can we please make a list of those, and of all practical matters that
> >>> prevent the preparation of the release?
> >>>
> >>
> >>
> >> MATH-621 (see also MATH-728)
> >>  * Unit test coverage: at least 6 branches of the code are not explored.
> >>  * Code complexity:
> >>    - Variable "state" that is similar to having goto's
> >>    - drop from one "case" to the next (no "break")
> >>    - explicit matrix computations
> >>  * Code fragility: success or failure of some unit tests depends on the
> >>   order of floating point operations (addition).
> >>  * Support: no resource in the CM team to bring the code to a state where
> >>   a Java developer can maintain it.
> >>
> >>  I'm wary to release the code in that state.
> >>
> > The last point is indeed quite worrying. If we are planning for a
> > release taking place briefly, I'm of no use, because digging into this
> > would take me forever (even if it must be done in the end by one of
> > us, I suppose).
>
> As strange as it might seem, I would like to see this code part of 3.0
> with a big "experimental" flag on it. People can use it at their own
> risk, but they can also help improve it.

How do we set this flag practically?  A warning in the release notes?
If so, we should maybe also stress that we seek volunteers to clean up the
code and add a thorough unit test suite.

Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
supposedly a unit test (created by Greg Sterijevski) but many test methods
are actually commented out because they fail; and nobody has investigated
why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
inherent complexity of the problem?]
IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
rewritten with a clear separation of the problems handled and the optimizers
used to try and solve them.
As is, the class should not be part of the release.

> >>
> >> MATH-698
> >>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> >>  (e.g. look at method "encode", lines 904-914).
> >>  I don't have the knowledge about the algorithm in order to know how to
> >>  modify that code so that it will behave correctly when only one of the
> >>  bounds is infinite (a valid case allowed by the base class for optimizers
> >>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
> >>
> >>  I would not want to release an API where simple bounds are dealt differently
> >>  in "CMAESOptimizer" than in the supposedly common interface.
> >>

What do you think about this point?


Regards,
Gilles

> >> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Sébastien Brisard
In reply to this post by Gilles Sadowski
Hi
>
> It thus becomes urgent to tackle the remaining blocking issues.
> Can we please make a list of those, and of all practical matters that
> prevent the preparation of the release?
>

MATH-731 is pretty much solved, but I still need a piece of advice.
Let me explain : the triangular distribution is so simple that
explicit formula have been implemented for
inverseCumulativeProbability(double) (see below).

{code}
    public double inverseCumulativeProbability(double p)
        throws OutOfRangeException {
        if (p < 0.0 || p > 1.0) {
            throw new OutOfRangeException(p, 0, 1);
        }
        if (p == 0.0) {
            return a;
        }
        if (p == 1.0) {
            return b;
        }
        final double pc = (c - a) / (b - a);
        if (p == pc) {
            return c;
        }
        if (p < pc) {
            return a + FastMath.sqrt(p * (b - a) * (c - a));
        }
        return b - FastMath.sqrt((1 - p) * (b - a) * (b - c));
    }
{code}

My problem is that I do not know what getSolverAbsoluteAccuracy()
should return. I see three options
1. Have getSolverAbsoluteAccuracy() throw an
UnsupportedOperationException, as the solver is *never* invoked.
2. Return a default value, and specify in the Javadoc that it is
meaningless or not really meaningful ;).
3. Return an estimate of the absolute accuracy of the explicit above
expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
FastMath.sqrt((1 - p) * (b - a) * (b - c)).

My preferred option is 1. I dislike option 2, because users might
actually be using the returned value, believing it to somehow reflect
the accuracy of the value returned by
inverseCumulativeProbability(double). Option 3 would be a good
compromise, but I certainly do not have the level of expertise to come
up with this estimate... Any help would be most welcome!

What do you think?
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Luc Maisonobe
In reply to this post by Gilles Sadowski
Le 27/01/2012 12:48, Gilles Sadowski a écrit :
> Hi.

Hi Gilles,

>
>>>>>
>>>>> It thus becomes urgent to tackle the remaining blocking issues.
>>>>> Can we please make a list of those, and of all practical matters that
>>>>> prevent the preparation of the release?
>>>>>
>>>>
>>>>
>>>> MATH-621 (see also MATH-728)
>>>>  * Unit test coverage: at least 6 branches of the code are not explored.
>>>>  * Code complexity:
>>>>    - Variable "state" that is similar to having goto's
>>>>    - drop from one "case" to the next (no "break")
>>>>    - explicit matrix computations
>>>>  * Code fragility: success or failure of some unit tests depends on the
>>>>   order of floating point operations (addition).
>>>>  * Support: no resource in the CM team to bring the code to a state where
>>>>   a Java developer can maintain it.
>>>>
>>>>  I'm wary to release the code in that state.
>>>>
>>> The last point is indeed quite worrying. If we are planning for a
>>> release taking place briefly, I'm of no use, because digging into this
>>> would take me forever (even if it must be done in the end by one of
>>> us, I suppose).
>>
>> As strange as it might seem, I would like to see this code part of 3.0
>> with a big "experimental" flag on it. People can use it at their own
>> risk, but they can also help improve it.
>
> How do we set this flag practically?  A warning in the release notes?

Yes, something alogn this line.

> If so, we should maybe also stress that we seek volunteers to clean up the
> code and add a thorough unit test suite.

Yes.

>
> Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
> supposedly a unit test (created by Greg Sterijevski) but many test methods
> are actually commented out because they fail; and nobody has investigated
> why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
> inherent complexity of the problem?]
> IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
> rewritten with a clear separation of the problems handled and the optimizers
> used to try and solve them.
> As is, the class should not be part of the release.

OK, then we should remove it for the release and move it to next release.

>
>>>>
>>>> MATH-698
>>>>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>>>>  (e.g. look at method "encode", lines 904-914).
>>>>  I don't have the knowledge about the algorithm in order to know how to
>>>>  modify that code so that it will behave correctly when only one of the
>>>>  bounds is infinite (a valid case allowed by the base class for optimizers
>>>>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>>>
>>>>  I would not want to release an API where simple bounds are dealt differently
>>>>  in "CMAESOptimizer" than in the supposedly common interface.
>>>>
>
> What do you think about this point?

You ae right, consistency is important. Users should be able to switch
from one algorithm to another one for such common behaviour.

Luc

>
>
> Regards,
> Gilles
>
>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Luc Maisonobe
In reply to this post by Sébastien Brisard
Le 27/01/2012 13:55, Sébastien Brisard a écrit :

> Hi
>>
>> It thus becomes urgent to tackle the remaining blocking issues.
>> Can we please make a list of those, and of all practical matters that
>> prevent the preparation of the release?
>>
>
> MATH-731 is pretty much solved, but I still need a piece of advice.
> Let me explain : the triangular distribution is so simple that
> explicit formula have been implemented for
> inverseCumulativeProbability(double) (see below).
>
> {code}
>     public double inverseCumulativeProbability(double p)
>         throws OutOfRangeException {
>         if (p < 0.0 || p > 1.0) {
>             throw new OutOfRangeException(p, 0, 1);
>         }
>         if (p == 0.0) {
>             return a;
>         }
>         if (p == 1.0) {
>             return b;
>         }
>         final double pc = (c - a) / (b - a);
>         if (p == pc) {
>             return c;
>         }
>         if (p < pc) {
>             return a + FastMath.sqrt(p * (b - a) * (c - a));
>         }
>         return b - FastMath.sqrt((1 - p) * (b - a) * (b - c));
>     }
> {code}
>
> My problem is that I do not know what getSolverAbsoluteAccuracy()
> should return. I see three options
> 1. Have getSolverAbsoluteAccuracy() throw an
> UnsupportedOperationException, as the solver is *never* invoked.
> 2. Return a default value, and specify in the Javadoc that it is
> meaningless or not really meaningful ;).
> 3. Return an estimate of the absolute accuracy of the explicit above
> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>
> My preferred option is 1. I dislike option 2, because users might
> actually be using the returned value, believing it to somehow reflect
> the accuracy of the value returned by
> inverseCumulativeProbability(double). Option 3 would be a good
> compromise, but I certainly do not have the level of expertise to come
> up with this estimate... Any help would be most welcome!

I don't like UnsupportedOperationException. In this case, I would say
the explicit formula is some kind of "perfect" solver which has a
theoretical accuracy of zero (or 1 ulp). So I would return this value.

Luc

>
> What do you think?
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Sébastien Brisard
Hi Luc,
thanks for this answer.

>>
>> My problem is that I do not know what getSolverAbsoluteAccuracy()
>> should return. I see three options
>> 1. Have getSolverAbsoluteAccuracy() throw an
>> UnsupportedOperationException, as the solver is *never* invoked.
>> 2. Return a default value, and specify in the Javadoc that it is
>> meaningless or not really meaningful ;).
>> 3. Return an estimate of the absolute accuracy of the explicit above
>> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
>> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>>
>> My preferred option is 1. I dislike option 2, because users might
>> actually be using the returned value, believing it to somehow reflect
>> the accuracy of the value returned by
>> inverseCumulativeProbability(double). Option 3 would be a good
>> compromise, but I certainly do not have the level of expertise to come
>> up with this estimate... Any help would be most welcome!
>
> I don't like UnsupportedOperationException.
>
Fine.
> In this case, I would say
> the explicit formula is some kind of "perfect" solver
I agree
>
> which has a
> theoretical accuracy of zero (or 1 ulp). So I would return this value.
>
Yes, but one ulp of which number? What I have implemented so far is
return Math.ulp(c) (the intermediate value). I sould probably return
Math.max(Math.ulp(a), Math.ulp(b)), what do you think?
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Luc Maisonobe
Le 27/01/2012 20:44, Sébastien Brisard a écrit :

> Hi Luc,
> thanks for this answer.
>>>
>>> My problem is that I do not know what getSolverAbsoluteAccuracy()
>>> should return. I see three options
>>> 1. Have getSolverAbsoluteAccuracy() throw an
>>> UnsupportedOperationException, as the solver is *never* invoked.
>>> 2. Return a default value, and specify in the Javadoc that it is
>>> meaningless or not really meaningful ;).
>>> 3. Return an estimate of the absolute accuracy of the explicit above
>>> expressions, namely a + FastMath.sqrt(p * (b - a) * (c - a)) and b -
>>> FastMath.sqrt((1 - p) * (b - a) * (b - c)).
>>>
>>> My preferred option is 1. I dislike option 2, because users might
>>> actually be using the returned value, believing it to somehow reflect
>>> the accuracy of the value returned by
>>> inverseCumulativeProbability(double). Option 3 would be a good
>>> compromise, but I certainly do not have the level of expertise to come
>>> up with this estimate... Any help would be most welcome!
>>
>> I don't like UnsupportedOperationException.
>>
> Fine.
>> In this case, I would say
>> the explicit formula is some kind of "perfect" solver
> I agree
>>
>> which has a
>> theoretical accuracy of zero (or 1 ulp). So I would return this value.
>>
> Yes, but one ulp of which number? What I have implemented so far is
> return Math.ulp(c) (the intermediate value). I sould probably return
> Math.max(Math.ulp(a), Math.ulp(b)), what do you think?

Both are fine.

Luc

> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Gilles Sadowski
In reply to this post by Luc Maisonobe
Hello.

> >
> >>>>>
> >>>>> It thus becomes urgent to tackle the remaining blocking issues.
> >>>>> Can we please make a list of those, and of all practical matters that
> >>>>> prevent the preparation of the release?
> >>>>>
> >>>>
> >>>>
> >>>> MATH-621 (see also MATH-728)
> >>>>  * Unit test coverage: at least 6 branches of the code are not explored.
> >>>>  * Code complexity:
> >>>>    - Variable "state" that is similar to having goto's
> >>>>    - drop from one "case" to the next (no "break")
> >>>>    - explicit matrix computations
> >>>>  * Code fragility: success or failure of some unit tests depends on the
> >>>>   order of floating point operations (addition).
> >>>>  * Support: no resource in the CM team to bring the code to a state where
> >>>>   a Java developer can maintain it.
> >>>>
> >>>>  I'm wary to release the code in that state.
> >>>>
> >>> The last point is indeed quite worrying. If we are planning for a
> >>> release taking place briefly, I'm of no use, because digging into this
> >>> would take me forever (even if it must be done in the end by one of
> >>> us, I suppose).
> >>
> >> As strange as it might seem, I would like to see this code part of 3.0
> >> with a big "experimental" flag on it. People can use it at their own
> >> risk, but they can also help improve it.
> >
> > How do we set this flag practically?  A warning in the release notes?
>
> Yes, something alogn this line.

Does this information go in the "description" attribute of the "release" tag
in the file "changes.xml"?

>
> > If so, we should maybe also stress that we seek volunteers to clean up the
> > code and add a thorough unit test suite.
>
> Yes.
>
> >
> > Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
> > supposedly a unit test (created by Greg Sterijevski) but many test methods
> > are actually commented out because they fail; and nobody has investigated
> > why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
> > inherent complexity of the problem?]
> > IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
> > rewritten with a clear separation of the problems handled and the optimizers
> > used to try and solve them.
> > As is, the class should not be part of the release.
>
> OK, then we should remove it for the release and move it to next release.

Practically, how can I do that? Just "svn del"? [If so, how is it moved in
again for the nex release?]

> >
> >>>>
> >>>> MATH-698
> >>>>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> >>>>  (e.g. look at method "encode", lines 904-914).
> >>>>  I don't have the knowledge about the algorithm in order to know how to
> >>>>  modify that code so that it will behave correctly when only one of the
> >>>>  bounds is infinite (a valid case allowed by the base class for optimizers
> >>>>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
> >>>>
> >>>>  I would not want to release an API where simple bounds are dealt differently
> >>>>  in "CMAESOptimizer" than in the supposedly common interface.
> >>>>
> >
> > What do you think about this point?
>
> You ae right, consistency is important. Users should be able to switch
> from one algorithm to another one for such common behaviour.

This issue MATH-698 is still pending.

Others that were not postponed to after 3.0 are:
 MATH-712 (trivial)
 MATH-707 (done or almost done, depending on the comments)
 MATH-444 (trivial)

Unscheduled but probably to be fixed before 3.0:
 MATH-744


Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Thomas Neidhart
Hi,

I have seen that there are several classes that are almost undocumented:

 - PivotingQRDecomposition (linear)
 - StorelessCovariance (stat.correlation)
 - StorelessBivariateCovariance (stat.correlation)

both seem to be quite new contributions, is somebody willing to help here?

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Luc Maisonobe
In reply to this post by Gilles Sadowski
Hi Gilles,

Le 13/02/2012 12:01, Gilles Sadowski a écrit :

> Hello.
>
>>>
>>>>>>>
>>>>>>> It thus becomes urgent to tackle the remaining blocking issues.
>>>>>>> Can we please make a list of those, and of all practical matters that
>>>>>>> prevent the preparation of the release?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> MATH-621 (see also MATH-728)
>>>>>>  * Unit test coverage: at least 6 branches of the code are not explored.
>>>>>>  * Code complexity:
>>>>>>    - Variable "state" that is similar to having goto's
>>>>>>    - drop from one "case" to the next (no "break")
>>>>>>    - explicit matrix computations
>>>>>>  * Code fragility: success or failure of some unit tests depends on the
>>>>>>   order of floating point operations (addition).
>>>>>>  * Support: no resource in the CM team to bring the code to a state where
>>>>>>   a Java developer can maintain it.
>>>>>>
>>>>>>  I'm wary to release the code in that state.
>>>>>>
>>>>> The last point is indeed quite worrying. If we are planning for a
>>>>> release taking place briefly, I'm of no use, because digging into this
>>>>> would take me forever (even if it must be done in the end by one of
>>>>> us, I suppose).
>>>>
>>>> As strange as it might seem, I would like to see this code part of 3.0
>>>> with a big "experimental" flag on it. People can use it at their own
>>>> risk, but they can also help improve it.
>>>
>>> How do we set this flag practically?  A warning in the release notes?
>>
>> Yes, something alogn this line.
>
> Does this information go in the "description" attribute of the "release" tag
> in the file "changes.xml"?

Yes, it would be an appropriate place since the release notes are
extracted from this file.

>
>>
>>> If so, we should maybe also stress that we seek volunteers to clean up the
>>> code and add a thorough unit test suite.
>>
>> Yes.
>>
>>>
>>> Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
>>> supposedly a unit test (created by Greg Sterijevski) but many test methods
>>> are actually commented out because they fail; and nobody has investigated
>>> why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
>>> inherent complexity of the problem?]
>>> IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
>>> rewritten with a clear separation of the problems handled and the optimizers
>>> used to try and solve them.
>>> As is, the class should not be part of the release.
>>
>> OK, then we should remove it for the release and move it to next release.
>
> Practically, how can I do that? Just "svn del"? [If so, how is it moved in
> again for the nex release?]

I would rather set up a 3.0 release branch and do the svn del here.

>
>>>
>>>>>>
>>>>>> MATH-698
>>>>>>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>>>>>>  (e.g. look at method "encode", lines 904-914).
>>>>>>  I don't have the knowledge about the algorithm in order to know how to
>>>>>>  modify that code so that it will behave correctly when only one of the
>>>>>>  bounds is infinite (a valid case allowed by the base class for optimizers
>>>>>>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>>>>>
>>>>>>  I would not want to release an API where simple bounds are dealt differently
>>>>>>  in "CMAESOptimizer" than in the supposedly common interface.
>>>>>>
>>>
>>> What do you think about this point?
>>
>> You ae right, consistency is important. Users should be able to switch
>> from one algorithm to another one for such common behaviour.
>
> This issue MATH-698 is still pending.
>
> Others that were not postponed to after 3.0 are:
>  MATH-712 (trivial)
>  MATH-707 (done or almost done, depending on the comments)

I would consider it is done.

>  MATH-444 (trivial)

Yes, and it is probably time to do it now.

>
> Unscheduled but probably to be fixed before 3.0:
>  MATH-744

Agreed.

I'll resolve MATH-650 soon, making an arbitrary choice by myself (so you
will know who is to blame).

Luc

>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] Toward releasing 3.0 ?

Gilles Sadowski
Hello.

> >>>>>> MATH-698
> >>>>>>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
> >>>>>>  (e.g. look at method "encode", lines 904-914).
> >>>>>>  I don't have the knowledge about the algorithm in order to know how to
> >>>>>>  modify that code so that it will behave correctly when only one of the
> >>>>>>  bounds is infinite (a valid case allowed by the base class for optimizers
> >>>>>>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
> >>>>>>
> >>>>>>  I would not want to release an API where simple bounds are dealt differently
> >>>>>>  in "CMAESOptimizer" than in the supposedly common interface.
> >>>>>>
> >>>
> >>> What do you think about this point?
> >>
> >> You ae right, consistency is important. Users should be able to switch
> >> from one algorithm to another one for such common behaviour.
> >
> > This issue MATH-698 is still pending.

Anyone is welcome to have a look at that one...

> >
> > Others that were not postponed to after 3.0 are:
> >  MATH-712 (trivial)
> >  MATH-707 (done or almost done, depending on the comments)
>
> I would consider it is done.

Resolved.

>
> >  MATH-444 (trivial)
>
> Yes, and it is probably time to do it now.

OK!

>
> >
> > Unscheduled but probably to be fixed before 3.0:
> >  MATH-744
>
> Agreed.
>
> I'll resolve MATH-650 soon, making an arbitrary choice by myself (so you
> will know who is to blame).

I forgot that one ;-)
And also
  MATH-672


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123