Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4A157B4B.4070301@free.fr>
Date: Thu, 21 May 2009 18:03:23 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
References: <23537813.post@talk.nabble.com>
 <c7d45fc70905141118k6205d00dsff4583e251b2a425@mail.gmail.com>
 <4A0C6C54.9070008@free.fr> <4A0E157E.1020201@gmail.com>
 <c7d45fc70905151841m3277d4adw8a4dd4f4b11c752e@mail.gmail.com>
 <4A0E22B2.9030102@gmail.com> <4A0E7B48.3030905@free.fr>
 <23574535.post@talk.nabble.com> <4A0EDF32.7010703@free.fr>
 <23575419.post@talk.nabble.com> <4A0EEC7C.3010507@free.fr>
 <23575674.post@talk.nabble.com> <23575831.post@talk.nabble.com>
 <4A0EF740.4000705@free.fr>
 <c7d45fc70905161301k4f6d32bu4a13ad1a885b8006@mail.gmail.com>
 <00ba01c9d678$e2af7920$b29633ad@oemcomputer> <23595640.post@talk.nabble.com>
 <000701c9d82f$f67d7750$f17ae560@oemcomputer> <23611886.post@talk.nabble.com>
 <4A144671.5020406@gmail.com> <00f201c9d9b7$076b39c0$f17ae560@oemcomputer>
 <23650705.post@talk.nabble.com> <4A1546B0.3000503@free.fr>
 <23655465.post@talk.nabble.com>
In-Reply-To: <23655465.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Sam Halliday a �crit :
> Regarding the name of ArrayRealMatrix. Please don't forget to include the
> "2DRow" part to the name (indicating a 2D array which is Row ordered) to
> indicate the implementation type. Post 2.0 I'll convince you that a 1D Array
> approach is best as it will lead to more efficient use of BLAS and therefore
> reproducibility of reference algorithms from, e.g. the Templates project on
> netlib ;-)
> 
> I've never seen a storage type like BlockRealMatrix before... I'm interested
> in seeing where it performs better than, say, a full 1D representation of a
> dense matrix. Breaking up the storage like this makes it very difficult to
> use BLAS/LAPACK internally.

This is a simple approach I tried based on cache considerations. It is a
compromise that works well when some algorithms are row oriented, others
are column oriented and still others are mixed (like multiplication). It
does improve multiplication time with respect to RealMatrixImpl for
example on matrices larger than 100x100, but it may need adapting block
size depending on target.

A more complex example is given in a paper by Siddhartha Chatterjee,
Alvin R. Lebeck, Praveen K. Patnala and Mithuna Thottethodi: Recursive
Array Layouts and Fast Matrix Multiplication
<http://www.cs.duke.edu/~alvy/papers/matrix-tpds.pdf>. I have tried this
approach too (using the Gray-Morton space-filling curve) but the gain
was not worth the pain. This attempt was not completed for this reason,
but it is still available in the experimental directory in the
repository, it is the RecursiveLayoutRealMatrix class. Maybe it can be
resurrected later, once completed and optimized.

> 
> 
> Luc Maisonobe wrote:
>>> - I discourage the use of the classes named *Impl. They will get very
>>> confusing when other implementations are added later! Instead, I
>>> recommend
>>> the names ArrayRealVector, Array2DRowRealMatrix (to indicate a 2D array
>>> backed implementation using row ordering). This allows a column-based or
>>> 1D
>>> implementation in the future without names getting very confusing. These
>>> implementations are hidden from users who just use the MatrixUtils help
>> Phil suggested to change RealMatrixImpl to ArrayRealMatrix (and
>> DenseRealMatrix to BlockRealMatrix). This sounds good to me.
>>
> 


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