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 (nike.apache.org: domain of kberlin@gmail.com designates
 209.85.212.43 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: [math] major problem with new released version 3.1
From: Konstantin Berlin <kberlin@gmail.com>
In-Reply-To: <50DDBF6B.4040101@spaceroots.org>
Date: Fri, 28 Dec 2012 10:55:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <71EE68D1-669E-4B87-9460-D43005A99A35@gmail.com>
References: <50DDA635.8080908@spaceroots.org>
 <alpine.DEB.2.02.1212281553550.2532@astropc8.ulb.ac.be>
 <50DDBF6B.4040101@spaceroots.org>
To: "Commons Developers List" <dev@commons.apache.org>

Luc,

Agreed. Dimitri brought out a good point about correlated errors that I =
didn't think about. All these cases can be handled by user modifying =
his/her input, but it would be nice to think about how this can be =
supported in the future. I think this problem showed up for two general =
reasons, which I brought out before.

1) We are not testing our optimization classes on large datasets.
2) The linear algebra framework should be used internally, that way we =
can leverage sparse matrix operations.=20

-Konstantin

On Dec 28, 2012, at 10:48 AM, Luc Maisonobe <luc@spaceroots.org> wrote:

> Le 28/12/2012 16:08, Dimitri Pourbaix a =E9crit :
>> Luc,
>>=20
>>> However, it is also possible to set a non-diagonal weight matrix, =
and
>>> one class (AbstractLeastSquaresOptimizer) performs an eigen =
dcomposition
>>> on the matrix to extract its square root. I don't know any use case =
for
>>> this, but it has been set up this way, so I guess someone has a use =
for
>>> non-diagonal weights.
>>=20
>> Such a situation occurs when observations are correlated.  That is
>> actually the most general expression for a least square problem.
>>=20
>>> I wonder if I should simply add this as is or if we should rather =
remove
>>> the non-diagonal weights feature and support only vector weights.
>>=20
>> Even if a vector of weights is convenient, it would only cover a =
subset
>> of situations.  However, even a vector of weights is not needed if =
both
>> the models and the observations are pre-multiplied by the square root
>> of their weight.  By the way, I remind you that those weights already
>> caused some bugs in the 2.0 release.
>>=20
>> Personnally, I could live with a vector form.
>=20
> So in order to make sure I understand your point, you would be OK if I
> deprecate the non-diagonal weights, in which case users needing this
> would have to implement it themselves by premultiplication (as both =
you
> and Konstantin seem to propose)?
>=20
>>=20
>> As a more general comment, I find it amazing that all the +1 for the
>> release were only concerned by the compliance with (commons) rules,
>> configuration files, ... Just 4 days after the release, you suddenly
>> figure out that a user is in trouble and you want a quick fix.  Maybe
>> such a test would have been need BEFORE the release!
>=20
> Sure, but for the record the feature was also a last minute change. =
This
> was discussed on the list, and the final decision was to add this
> feature despite the release was close. No wonder we failed to test it
> thoroughsly.
>=20
> We don't expect our releases to be perfect. We do our best, with the
> resources we have.
>=20
>>=20
>> Regards,
>> Dim.
>=20
>=20
> Le 28/12/2012 16:13, Konstantin Berlin a =E9crit :
>> Hi,
>>=20
>> I am not clear on the use of weights in a non-least squares problem
>> is. In a least-squares problem the weights can simply be taken in by
>> the user in their input function. So the weights option is a
>> convenience feature, any non-standard matrix weights could be
>> programmed in by the user, if they need to. I have a hard time
>> imagining a case when the weights are non-diagnal. I think your idea
>> is good and you should go on with it. The quadratic memory scaling
>> with the number of data points is not acceptable.
>=20
> Thanks Konstantin. So if Dimitri confirm I understood his point
> correctly, I will proceed with deprecating the Weight class and
> introduce a WeightVector class, understanding it is a convenience
> feature suited for simple non-correlated observations.
>=20
>>=20
>> -Konstantin
>=20
> best regards,
> Luc
>=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