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.42 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: 
 <CAGRH7Hqk_p2xueZBQM6a=Xi-Pg0AZZmqdwC7twZ96nn2uqvU_A@mail.gmail.com>
Date: Sat, 29 Dec 2012 18:22:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2416051E-2130-4EA8-93DF-389D8B95762E@gmail.com>
References: <50DDA635.8080908@spaceroots.org>
 <alpine.DEB.2.02.1212281553550.2532@astropc8.ulb.ac.be>
 <50DDBF6B.4040101@spaceroots.org>
 <alpine.DEB.2.02.1212281708000.2532@astropc8.ulb.ac.be>
 <50DDC860.7060703@gmail.com> <07E3B3D2-E7AE-4BAB-8872-ED88823B6200@gmail.com>
 <50DDDDAA.2030106@free.fr>
 <CAGRH7HpruFv-2h1oGk7M091KM_VC2F6OiQYZ7dNhD4Y5=yhnNA@mail.gmail.com>
 <31C327CF-643E-4DFA-BF53-DD6BF1C6B92E@gmail.com>
 <CAGRH7Hqk_p2xueZBQM6a=Xi-Pg0AZZmqdwC7twZ96nn2uqvU_A@mail.gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>

>>=20
>> I think this issue can be overcome by proper OO design, and hacked on =
to
>> the current interface for now.
>>=20
>> We can create an "InPlace" interface that all linear operators =
(including
>> RealMatrix etc) would implement. For example in a hypothetical
>> InPlaceMatrix class
>>=20
>> function InPlaceVector mult(InPlaceVector x), depending on =
implementation
>> details, would either return back overwritten x in the return value, =
or a
>> new value for multiplication leaving x in tact. This would allow the =
user
>> to implement their more efficient version, while also allowing the =
usage of
>> current linear algebra package if they don't care about performance. =
The
>> idea is that the optimization classes would rely only on the InPlace
>> interface for all their tasks.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>=20
>>=20
> I'm not sure about that. If I understand correctly, this would mean =
that
> the _user_ has to provide the solver with a so-called InPlaceVector. I
> don't think it should be the responsibility of the user to chose =
whether or
> not a solver performs in place operations. As I said previously =
visitors
> are a good way to do that without cluttering the interface. For =
example, we
> could define a Multiply visitor, which scales all components of a =
vector. A
> nice idiom would be to have a factory method Multiply.by(double) =
instead of
> a constructor new Multiply(double). This way, scaling a vector in =
place
> would read
> v.walkInDefaultOrder(Multiply.by(double))
>=20
> What do you think?
> S=E9bastien

The user would not have to do anything, since any RealMatrix =
implementation would implement the InPlace interface. The user is free =
to just pass in a standard RealMatrix class, it will just (temporarily) =
not actually perform an in place operation, so it would waste memory, =
but otherwise would provide correct behavior. The choice of InPlace =
operation (and any other required operation) is controlled by the =
implementation of the optimization solver, not the user. I think design =
wise it's better, since the optimization function does not require =
anything more basic than some class that implements a few vector =
operations. It does not need to rely on something as heavy as a =
RealMatrix, or as limiting as a double[][], and this would allow for the =
user to implement their own version, if they have some large problem =
that they want to optimize.

While visitor pattern is a good abstraction, I think it would make for =
terrible linear algebra performance. All operations should be based on =
basic vector operations, which internally can take advantage of =
sequential memory access. For large problems it makes a difference. The =
visitor pattern is a nice add on, but it should not be the engine =
driving the package under the hood, in my opinion.

-Konstantin=

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