Haskell Matrix Library...
lemming at henning-thielemann.de
Sun Jun 26 13:22:10 EDT 2005
On Fri, 10 Jun 2005, Keean Schupke wrote:
> Jan Skibinski's page seems to have disappeared so there is no source I can find for the
> Orthoganal stuff - besides which I am interested in efficency - and that basically
> said the algorithms were experimental and use Haskell lists...
I have some private copy:
> The HaskellDSP defines simple matrix operations, but does not put the operations into the
> numeric, fractional, and floating classes. This makes the resulting expressions hard to
Numeric classes do not exist for readability in the sense of infix
operators. If infix operators were the main reason simple operators would
suffice. The reason why these operators are methods of classes is that it
shall be possible to write mathematical expressions which can be
universally used for different types of numbers, such as Float, Double,
Rational, Integer and so on. Prelude's class framework is oriented at the
scalar types it provides. My concern is: Are matrices a natural extension
of these scalar types? What is (fromInteger 1) for the matrix class? The
identity matrix or the matrix which consists entirely of ones? Are there
non-trivial algorithms written for numbers which can be re-used for
matrices without re-writing? If not, why pressing matrices into this
You could also define (+), (-), (*) for Strings. But what is the benefit?
Are there numerical algorithms which can be re-used for Strings? (Now
when I write it, I remember the algorithm for searching a dictionary of
strings by the method of false position. But the Prelude numeric class
framework wouldn't help here, too, since you need a division of type
String -> String -> Double, or so.)
If readability in the sense of "writing less" is your main goal then just
define infix operators for the functions found in HaskellDSP. (*>) is a
good choice for scaling a vector or a matrix, this symbol is already used
in numericprelude. You may define (.*) for element-wise multiplication
which is already known from MatLab. It is more readable than everywhere
(*) because it tells the user something about the types of the operands.
> >>LAPACK does not appear to support higher dimensional matrices... is this
> >Yes, why should it do so? Every finite dimensional operator can be
> >represented by a matrix.
> I have found a couple of papers on generalising matrix algebra to higher
> dimensional matrices... So it seems to be possible...
Certainly, but LAPACK is very low-level. It's your task to break
operations on various types of vectors down to basic linear algebra. The
point is that every vector from a finite dimensional space can be
represented by an array and each linear operator can be represented by a
matrix. Everything which is structured differently can be converted to
this but it is your task not that of LAPACK or any other linear algebra
More information about the Libraries