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 ted.dunning@gmail.com
 designates 209.85.216.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E8C9946.3040404@free.fr>
References: 
 <CACMPRi39MJXgkbazwUSsWwAhdt6WMvqdU_aHeCrO5keKKAqDNQ@mail.gmail.com>
 <CACMPRi0b2Tu1tNFSkOMnG7tc=LgpSYZzA_i_2jMjRMum=zGGew@mail.gmail.com>
 <20111005101645.GC17388@dusk.harfang.homelinux.org>
 <CACMPRi0beXyO4FJn=ccDp9n1biE_pTS=R2STzEWU=doCq=0BzA@mail.gmail.com>
 <20111005143919.GE17388@dusk.harfang.homelinux.org>
 <CACMPRi1XoLv3UNqKhHkGFO3kQ6Y97Xner5-XEffEL_PjF-rDuQ@mail.gmail.com>
 <20111005160256.GF17388@dusk.harfang.homelinux.org>
 <4E8C9946.3040404@free.fr>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Wed, 5 Oct 2011 11:03:24 -0700
Message-ID: 
 <CAJwFCa0BeHsPTweORJshdo1aP9nW7Le8bjDYYJ98QB6jptW3kA@mail.gmail.com>
Subject: Re: [MATH] Re: Pivoting QR Decomposition: Take Two!
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=20cf30050d7c6f29c204ae910748

--20cf30050d7c6f29c204ae910748
Content-Type: text/plain; charset=UTF-8

Sounds like it would be nice to have both implementations in the same class
with a "usePivoting(boolean)" method to select which is used.  I would
recommend pivoting as the default since it gives fewer surprises and more
diagnostic information to the naive user.

Except for the extra indexing costs, a pivoting implementation should be
about twice as costly as a non-pivoting implementation.  If you don't do the
pivoting by indirection, this could be significantly more due to copying.

I haven't had instances where I would have much cared, but it would be nice
to have the option for extra speed if I needed it.

On Wed, Oct 5, 2011 at 10:52 AM, Luc Maisonobe <Luc.Maisonobe@free.fr>wrote:

> 4. Implement the best algorithm as "QRDecomposition" in ("linear"), and
>>    remove duplicate code ("LevenbergMarquardt" will call the
>> implementation
>>    in "linear"; if replacing the LM currently internal version makes some
>>    test fail, we should worry and look for the bug either in LM or in the
>>    new QR or in the tests).
>>
>
> I'm not sure one implementation only is always feasible. The one I put in
> Levenberg-Marquardt is perhaps more suited to some cases because of
> pivoting, but I'm quite sure it is not as efficient as the classical one
> which is really fast (I always used it as an example in conferences to show
> that Java can be as fast as fortran in some application, because it is as
> fast as lapack with ATLAS blas on matrices up to about 1000 rows and
> columns).

--20cf30050d7c6f29c204ae910748--