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 kberlin@gmail.com designates
 209.85.216.171 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [Math] Old to new API
 ("MultivariateDifferentiable(Vector)Function")
From: Konstantin Berlin <kberlin@gmail.com>
In-Reply-To: <20121201213439.GI3397@dusk.harfang.homelinux.org>
Date: Sat, 1 Dec 2012 17:09:00 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <AA4845E6-1E2E-452D-AAF7-2BFE1DF319B1@gmail.com>
References: <20121130161135.GG20488@dusk.harfang.homelinux.org>
 <245DF7F3-1003-4A47-BFF3-6877A64F38D8@gmail.com> <50B8F24E.1060104@free.fr>
 <20121130190625.GB3397@dusk.harfang.homelinux.org>
 <A0C4BED0-5C94-41F7-B28B-2E1A794798FD@gmail.com> <50B91160.10708@free.fr>
 <20121130221558.GE3397@dusk.harfang.homelinux.org>
 <20121130224446.GF3397@dusk.harfang.homelinux.org>
 <5A67B3E0-0F48-444F-B146-7CB29BB8435E@gmail.com>
 <20121201213439.GI3397@dusk.harfang.homelinux.org>
To: "Commons Developers List" <dev@commons.apache.org>

>>=20
>> My opinion is that the package should be organized by what it does =
rather, than how it does it.
>=20
> My proposal is based on what the user wants to do and on what input is
> required in order to use the tools in the given package, where all
> algorithms will share the same interface.
>=20

I humbly disagree with your claim. The user does not want a vector nor a =
Jcobian. The user has a problem, and they want to see their options for =
a solution. That is why they will go into, for example, least-squares. =
They will see that there are different kinds, so they will go into =
linear, for example. There they will see all their options and what they =
need to make it work.

I also have a problem with how you targeting the package to naive people =
who want to play around with packages. You want the package to be easily =
accessible to people who require optimizations. I would imagine most =
users have a good idea what kind of problem that they have are looking =
for the optimizer that will solve their problem. By structuring the =
packages in the way I describe, they first go through the general =
problem that they have, and then go down into more specific detail with =
every level. That seems to me the most natural.

>> My thinking is
>>=20
>> optim
>> optim.scalar.
>> optim.scalar.linear
>> optim.scalar.socp (second order cone programming)'
>> optim.scalar.qcqp
>> optim.scalar.nonlinear
>> optim.scalar.nonlinear.derivfree
>> optim.scalar.nonlinear.derivfree.Powell, etc
>> optim.scalar.nonlinear.newton
>>=20
>> optim.scalar.univariate.*
>>=20
>> optim.leastsquares.linear
>> optim.leastsquares.nonlinear
>=20
> IMHO, the problem with the above is that it is targetted to =
optimization
> experts (who would know what all the abbreviations mean and what to =
look
> for).
> In the other approach, a non-expert can go to a package, read the =
top-level
> doc and start experimenting, knowing what to plug in. [I know, this is =
not
> a strong argument; but it lowers the barrier to entry. :-)]
>=20
> Perhaps there are intersections between the two approaches.
>=20
>> But I am flexible. Perhaps it is worth a look here:
>> http://www.joptimizer.com/
>=20
> Thanks for the pointer.
>=20
> Gilles
>=20
>>=20
>>>=20
>>> Shall we also introduce entirely new packages?
>>>=20
>>> optim
>>>=20
>>> optim.scalar.noderiv
>>> optim.scalar.noderiv.PowellOptimizer
>>> optim.scalar.noderiv.SimplexOptimizer
>>> optim.scalar.noderiv.CMAESOptimizer
>>> optim.scalar.noderiv.BOBYQAOptimizer
>>>=20
>>> optim.scalar.gradient
>>> optim.scalar.gradient.NonLinearConjugateGradientOptimizer
>>>=20
>>> optim.vector
>>> optim.vector.jacobian
>>> optim.vector.jacobian.AbstractLeastSquaresOptimizer
>>> optim.vector.jacobian.LevenbergMarquardtOptimizer
>>> optim.vector.jacobian.GaussNewtonOptimizer
>>>=20
>>> optim.scalar.univariate.noderiv
>>> optim.scalar.univariate.noderiv.BrentOptimizer
>>>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>=20


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