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: local policy)
Date: Tue, 14 Feb 2012 01:39:06 +0100
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [Math] Toward releasing 3.0 ?
Message-ID: <20120214003905.GA9687@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <20120125121336.GD26355@dusk.harfang.homelinux.org>
 <20120126142823.GH26355@dusk.harfang.homelinux.org>
 <CAGRH7HoUYeOVXnRKaL4vuaEjOGAqm2iQJjLd_xkVj2Nuv1VWDw@mail.gmail.com>
 <4F21AA57.1030803@free.fr>
 <20120127114853.GJ26355@dusk.harfang.homelinux.org>
 <4F22E090.8050204@free.fr>
 <20120213110124.GD2103@dusk.harfang.homelinux.org>
 <4F395218.8060105@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F395218.8060105@free.fr>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: eir 20002; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at eir
X-Virus-Status: Clean

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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org