Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of
 SRS0=83jO=AF=m4x.org=sebastien.brisard@bounces.m4x.org designates
 129.104.30.34 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20120126142823.GH26355@dusk.harfang.homelinux.org>
References: <20120125121336.GD26355@dusk.harfang.homelinux.org>
	<20120126142823.GH26355@dusk.harfang.homelinux.org>
Date: Thu, 26 Jan 2012 15:52:46 +0100
Message-ID: 
 <CAGRH7HoUYeOVXnRKaL4vuaEjOGAqm2iQJjLd_xkVj2Nuv1VWDw@mail.gmail.com>
Subject: Re: [Math] Toward releasing 3.0 ?
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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)
> =A0* Unit test coverage: at least 6 branches of the code are not explored=
.
> =A0* Code complexity:
> =A0 =A0- Variable "state" that is similar to having goto's
> =A0 =A0- drop from one "case" to the next (no "break")
> =A0 =A0- explicit matrix computations
> =A0* Code fragility: success or failure of some unit tests depends on the
> =A0 order of floating point operations (addition).
> =A0* Support: no resource in the CM team to bring the code to a state whe=
re
> =A0 a Java developer can maintain it.
>
> =A0I'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
> =A0IIUC, "CMAESOptimizer" deals only with either no bounds or finite boun=
ds.
> =A0(e.g. look at method "encode", lines 904-914).
> =A0I don't have the knowledge about the algorithm in order to know how to
> =A0modify that code so that it will behave correctly when only one of the
> =A0bounds is infinite (a valid case allowed by the base class for optimiz=
ers
> =A0with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>
> =A0I would not want to release an API where simple bounds are dealt diffe=
rently
> =A0in "CMAESOptimizer" than in the supposedly common interface.
>
>
> MATH-726
> =A0This is really a small issue. But the discussion has stalled because o=
f a
> =A0long-term wish concerning a design convergence with the "nabla" projec=
t.
> =A0I'd rather introduce the code now, in a form that is similar to the de=
sign
> =A0of other packages ("solvers", "optimization", "integration").
> =A0I see no problem in changing that later, in the same way that there ar=
e
> =A0suggestions 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
> =A0A few more changes to be done.
>
>
> Regards,
> Gilles
>
S=E9bastien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org