The Atlas library (Linux_P4SSE2) seems to be 9x faster (!) than gslcblas in
matrix multiplication:
ghc-6.4.1 --make examples/pca.hs GSL/debuggslaux.o \
-L$(LIBATLAS) -lcblas /usr/lib/libgsl.a -latlas
$ time ./a.out
GSL Wrapper gsl_matrix_fscanf: 2 s
GSL Wrapper submatrix: 0 s
GSL Wrapper cons
On Thursday 16 March 2006 18:13, Frederik Eaton wrote:
> Also, in my experiments (with matrix inversion) it seems,
> subjectively, that Octave is about 5 or so times faster for operations
> on large matrices. Presumably you've tested this as well, do you have
> any comparison results?
>
Frederik,
Hi Frederick,
I refer to the ATLAS library:
http://math-atlas.sourceforge.net/
Some versions of octave use it. I have not yet linked the GSL library with it,
you must compile it yourself to take advantage of the optimizations for your
architecture, but I think that it must be easy. It is in my
Hi Alberto,
I'm sorry if this has been discussed before...
I'm reading your paper, at one point it says (re. the PCA example):
"Octave achieves the same result, slightly faster. (In this experiment
we have not used optimized BLAS libraries which can improve efficiency
of the GSL)"
That seems to
Hi,
I've just looked through this discussion, since I'm working on my own
library, I wanted to see what people are doing.
It's something like this, using the Prepose (Implicit Configurations)
paper:
data L n = L Int deriving (Show, Eq, Ord)
-- singleton domain
type S = L Zero
class (Bounded a,
Hello Alberto,
Tuesday, July 19, 2005, 5:11:27 PM, you wrote:
AR> Hello Bulat, thanks a lot for your message, the RULES pragma is just what we
AR> need!
AR> However, in some initial experiments I have observed some strange behavior.
AR> For instance, in the following program:
1) there is no guar
Hello Bulat, thanks a lot for your message, the RULES pragma is just what we
need!
However, in some initial experiments I have observed some strange behavior.
For instance, in the following program:
--
{-# OPTIONS_GHC -fglasgow-exts #-}
apply :: (Int -
On Mon, 18 Jul 2005, Bulat Ziganshin wrote:
> GHC also have a RULES pragma which can be used to automatically
> convert, for example, "mmap (*)" to "multipleElementWise".
Nice idea! But how can GHC decide which optimization is better?
M.map sin . M.map cos
can be optimized to
M.map (sin .
Hello Alberto,
Wednesday, July 13, 2005, 8:13:48 PM, you wrote:
>>If there are no efficiency concerns, I would drop element-wise operations
>>and prefer a matrix-map and a matrix-zipWith. If these operations shall
>>remain I would somehow point to their element-wise operation in the name.
AR> Th
On Wed, 13 Jul 2005, Alberto Ruiz wrote:
> But now I have two problems:
>
> 1) If I define
>
> foo :: Vector.T a -> Matrix.T a
>
> Haddock (version 0.6) shows just this:
>
> foo :: T a -> T a
>
> I don't know how to tell haddock that I want the full names in the signatures.
I don't know, too. I'
Hello! I have a few doubts concerning the LinearAlgebra library...
On Friday 08 July 2005 11:29, Henning Thielemann wrote:
>I would remove the 'matrix' portions of the function names, since this
>information is already contained in the module name. E.g. after importing
>LinearAlgebra.Matrix as Mat
Keean Schupke wrote:
> >>So the linear operator is translation (ie: + v)... effectively 'plus'
> >>could be viewed as a function which takes a vector and returns a matrix
> >>(operator)
> >>
> >>(+) :: Vector -> Matrix
> >>
> >>
> >
> >Since a matrix _is_ not a linear map but only its rep
On Friday 08 July 2005 17:46, Henning Thielemann wrote:
> Vectors can be used and abused for many things but
> an object which can be called a vector (because of its ability of to
> be added and to be scaled) is not a linear operator itself and does
> not naturally represent one.
At least for fin
On Fri, 8 Jul 2005, Keean Schupke wrote:
> Henning Thielemann wrote:
>
> >On Fri, 8 Jul 2005, Keean Schupke wrote:
> >
> >>So the linear operator is translation (ie: + v)... effectively 'plus'
> >>could be viewed as a function which takes a vector and returns a matrix
> >>(operator)
> >>
> >>
Henning Thielemann wrote:
>On Fri, 8 Jul 2005, Keean Schupke wrote:
>
>
>
>>So the linear operator is translation (ie: + v)... effectively 'plus'
>>could be viewed as a function which takes a vector and returns a matrix
>>(operator)
>>
>>(+) :: Vector -> Matrix
>>
>>
>
>Since a matrix _i
On Fri, 8 Jul 2005, Keean Schupke wrote:
> So the linear operator is translation (ie: + v)... effectively 'plus'
> could be viewed as a function which takes a vector and returns a matrix
> (operator)
>
> (+) :: Vector -> Matrix
Since a matrix _is_ not a linear map but only its representation
On Fri, 8 Jul 2005, David Roundy wrote:
> I don't particularly care what API you use for svd, since it's trivial to
> convert from one API to the other. It's matrix arithmetic I care about,
> since that's the complicated part of the API.
Of course I want to use the results of more complicated r
Henning Thielemann wrote:
>
>
>In general a vector need not to be a linear operator. You talked about
>vector translation, translation is not a linear operator. You gave some
>process to map the problem to somewhere, where it becomes a linear
>operator. Other people said that the scalar product wi
On Fri, 8 Jul 2005, Keean Schupke wrote:
> Henning Thielemann wrote:
>
> >Do you mean
> > [x,y,z,1] * [[1,0,0,0],[0,1,0,0],[0,0,1,0],[dx,dy,dz,dw+1]]
> >?
> >
> Erm, yes thats what I meant ... but you obviously got the point.
>
> >>but how is this different from adding vectors? If we allow vector
On Fri, Jul 08, 2005 at 03:33:16PM +0200, Henning Thielemann wrote:
>
> On Thu, 7 Jul 2005, David Roundy wrote:
>
> > On the other hand, this is sort of a silly debate, since the API *I*
> > want is a subset of the API *you* want.
>
> The API you want is certainly not just a subset of what I wan
Henning Thielemann wrote:
>
>Do you mean
> [x,y,z,1] * [[1,0,0,0],[0,1,0,0],[0,0,1,0],[dx,dy,dz,dw+1]]
>?
>
>
>
Erm, yes thats what I meant ... but you obviously got the point.
>>but how is this different from adding vectors? If we allow vector
>>addition then we no longer have the nice separat
Henning Thielemann wrote:
>
>I'm excited if your code gets swamped by conversions between Double and
>Matrix then. I really plead for representing everything with strings, this
>is the most simple and most flexible solution! :-]
>
>
Surely its a case of balancing the advantage of type safety aga
On Fri, 8 Jul 2005, Keean Schupke wrote:
> Okay, this approach is starting to make sense to me... I can see now
> that Vectors are a different type of object to Matrices. Vectors
> represent points in N-Space and matrices represent operations on those
> points
That's what I wanted to express.
>
On Fri, 8 Jul 2005, Keean Schupke wrote:
> Henning Thielemann wrote:
>
> >My objections to making everything a matrix were the objections I sketched
> >for MatLab.
> >
> >The example, again: If you write some common expression like
> >
> >transpose x * a * x
>
> Which just goes to show why haskel
Henning Thielemann wrote:
>
>Let me elaborate on that:
> In some cases putting vectors as columns into a matrix then applying a
>matrix operation on this matrix leads to the same like to 'map' a
>matrix-vector operation to a list of vectors. But in other cases (as the
>one above) this is not what
On Fri, 8 Jul 2005, Alberto Ruiz wrote:
> The server is working again.
>
> On Thursday 07 July 2005 20:58, Alberto Ruiz wrote:
> > I' sorry, our web server is temporarily down :-(
> >
> > >
> > > http://dis.um.es/~alberto/hmatrix/matrix.html
I would also prefer a vector of complex numbers for th
On Thu, 7 Jul 2005, David Roundy wrote:
> On the other hand, this is sort of a silly debate, since the API *I*
> want is a subset of the API *you* want.
The API you want is certainly not just a subset of what I want. E.g. the
singular value decomposition in your favorite API will probably return
Henning Thielemann wrote:
>My objections to making everything a matrix were the objections I sketched
>for MatLab.
>
>The example, again: If you write some common expression like
>
>transpose x * a * x
>
>
Which just goes to show why haskell limits the '*' operator to
multiplying the same types.
On Thu, Jul 07, 2005 at 03:08:50PM +0200, Henning Thielemann wrote:
>
> On Thu, 7 Jul 2005, David Roundy wrote:
>
> > On Tue, Jul 05, 2005 at 08:17:58PM +0200, Henning Thielemann wrote:
> > > The example, again: If you write some common expression like
> > >
> > > transpose x * a * x
> > >
> > >
On Thu, 7 Jul 2005, Alberto Ruiz wrote:
> Hello! Thank you very much for all your suggestions. A new version of the
> library can be found at:
>
> http://dis.um.es/~alberto/hmatrix/matrix.html
If the Matrix type would be parametrised then Matrix.fromBlocks could use
a more natural indexing.
Mat
On Fri, 8 Jul 2005, Alberto Ruiz wrote:
> The server is working again.
>
> On Thursday 07 July 2005 20:58, Alberto Ruiz wrote:
> > I' sorry, our web server is temporarily down :-(
> >
> > >
> > > http://dis.um.es/~alberto/hmatrix/matrix.html
I would remove the 'matrix' portions of the function n
The server is working again.
On Thursday 07 July 2005 20:58, Alberto Ruiz wrote:
> I' sorry, our web server is temporarily down :-(
>
> >
> > http://dis.um.es/~alberto/hmatrix/matrix.html
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://ww
I' sorry, our web server is temporarily down :-(
On Thursday 07 July 2005 20:37, Alberto Ruiz wrote:
> Hello! Thank you very much for all your suggestions. A new version of the
> library can be found at:
>
> http://dis.um.es/~alberto/hmatrix/matrix.html
>
__
On Thu, 7 Jul 2005, Alberto Ruiz wrote:
> Hello! Thank you very much for all your suggestions. A new version of the
> library can be found at:
>
> http://dis.um.es/~alberto/hmatrix/matrix.html
I get time-out/ :-(
> - Vector and Matrix are now different types with different functions operating
>
Sorry for the delayed response, which has now led to two separate
threads. See below.
> From: Henning Thielemann
> On Wed, 29 Jun 2005, Conal Elliott wrote:
> > On row & column vectors, do you really want to think of them as
> > {1,...,n)->R? They often represent linear maps from R^n to R or R
On Thu, 7 Jul 2005, Conal Elliott wrote:
> Maybe we could solve this problem in a simple and general way by working
> with a more abstract notion of linear maps, rather than the matrices
> commonly used to represent linear maps. Instead of "Matrix n m", where
> n and m are either integers (requi
Hello! Thank you very much for all your suggestions. A new version of the
library can be found at:
http://dis.um.es/~alberto/hmatrix/matrix.html
Here are the main changes:
- Vector and Matrix are now different types with different functions operating
on them. They cannot be interchanged and w
5:44 AM
To: David Roundy
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] matrix computations based on the GSL
David Roundy wrote:
> The issue is that Haskell (as far as I understand, and noone has
suggested
> anything to the contrary) doesn't have a sufficiently powerful type
system
On Thu, 7 Jul 2005, Henning Thielemann wrote:
> >> fft([1,0;0,0])
>
> ans =
>
> 1 0
> 1 0
Also funny:
>> conv([1;1],[1,1])
ans =
1 2 1
>> conv([1;1;1],[1,1])
ans =
1
2
2
1
___
Haskell-Cafe mai
On Thu, 7 Jul 2005, David Roundy wrote:
> Also note that if you have several vectors x for which you want to compute
> the dot product with metric A, and if you want to do this efficiently,
> you'll have to convert your list of vectors into a matrix anyways. Writing
> functions of vectors instea
On Thu, 7 Jul 2005, Henning Thielemann wrote:
> > Also note that if you have several vectors x for which you want to compute
> > the dot product with metric A, and if you want to do this efficiently,
> > you'll have to convert your list of vectors into a matrix anyways.
>
> If you bundle some vec
On Thu, 7 Jul 2005, David Roundy wrote:
> On Tue, Jul 05, 2005 at 08:17:58PM +0200, Henning Thielemann wrote:
> > The example, again: If you write some common expression like
> >
> > transpose x * a * x
> >
> > then both the human reader and the compiler don't know whether x is a
> > "true" matri
David Roundy wrote:
The issue is that Haskell (as far as I understand, and noone has suggested
anything to the contrary) doesn't have a sufficiently powerful type system
to represent matrices or vectors in a statically typed way. It would be
wonderful if we could represent matrix multiplication
On Tue, Jul 05, 2005 at 07:49:56PM +0200, Henning Thielemann wrote:
> On Tue, 5 Jul 2005, Keean Schupke wrote:
> > David Roundy wrote:
> >
> > >In short, especially since the folks doing the work (not me) seem to want
> > >plain old octave-style matrix operations, it makes sense to actually do
> >
On Tue, Jul 05, 2005 at 08:17:58PM +0200, Henning Thielemann wrote:
> The example, again: If you write some common expression like
>
> transpose x * a * x
>
> then both the human reader and the compiler don't know whether x is a
> "true" matrix or if it simulates a column or a row vector. It may
On Tue, 5 Jul 2005, Michael Walter wrote:
> On 7/5/05, Henning Thielemann <[EMAIL PROTECTED]> wrote:
> > The example, again: If you write some common expression like
> >
> > transpose x * a * x
> >
> > then both the human reader and the compiler don't know whether x is a
> > "true" matrix or if i
On 7/5/05, Henning Thielemann <[EMAIL PROTECTED]> wrote:
> The example, again: If you write some common expression like
>
> transpose x * a * x
>
> then both the human reader and the compiler don't know whether x is a
> "true" matrix or if it simulates a column or a row vector.
But since a, by d
On Tue, 5 Jul 2005, Keean Schupke wrote:
> Henning Thielemann wrote:
>
> >I'm uncertain about how who want to put the different kinds of
> >multiplication into one method, even with multi-parameter type classes.
> >You need instances
> >
> > (*) :: Matrix -> Matrix -> Matrix
> > (*) :: RowVector
On Tue, 5 Jul 2005, Keean Schupke wrote:
> David Roundy wrote:
>
> >In short, especially since the folks doing the work (not me) seem to want
> >plain old octave-style matrix operations, it makes sense to actually do
> >that. *Then* someone can implement an ultra-uber-tensor library on top of
>
David Roundy wrote:
>In short, especially since the folks doing the work (not me) seem to want
>plain old octave-style matrix operations, it makes sense to actually do
>that. *Then* someone can implement an ultra-uber-tensor library on top of
>that, if they like. And I would be interested in a n
Henning Thielemann wrote:
>I'm uncertain about how who want to put the different kinds of
>multiplication into one method, even with multi-parameter type classes.
>You need instances
>
> (*) :: Matrix -> Matrix -> Matrix
> (*) :: RowVector -> Matrix -> RowVector
> (*) :: Matrix -> ColumnVector ->
On Wednesday 29 June 2005 22:54, Henning Thielemann wrote:
> On Wed, 29 Jun 2005, Dan Piponi wrote:
> > >On Wed, 29 Jun 2005, Jacques Carette wrote:
> > >
> > >Distinction of row and column vectors is a misconcept
> >
> > Row and column vectors are sometimes worth distinguishing because
> > they ca
On Thu, 30 Jun 2005, Jacques Carette wrote:
> Henning Thielemann wrote:
>
> >>Data Orientation = Row | Column
> >>Data Vector a = Vector Orientation [a]
> >
> >In the first mail you wrote
> > "9. There are row vectors and column vectors, and these are different
> >types. You get type errors if y
Henning Thielemann wrote:
Data Orientation = Row | Column
Data Vector a = Vector Orientation [a]
In the first mail you wrote
"9. There are row vectors and column vectors, and these are different
types. You get type errors if you mix them incorrectly."
I interpreted that you want to enco
On Thu, 30 Jun 2005, Jacques Carette wrote:
> Henning Thielemann wrote:
>
> >I'm uncertain about how who want to put the different kinds of
> >multiplication into one method, even with multi-parameter type classes.
> >You need instances
> >
> > (*) :: Matrix -> Matrix -> Matrix
> > (*) :: RowVect
Henning Thielemann wrote:
I'm uncertain about how who want to put the different kinds of
multiplication into one method, even with multi-parameter type classes.
You need instances
(*) :: Matrix -> Matrix -> Matrix
(*) :: RowVector -> Matrix -> RowVector
[many other instances removed.]
Defi
David Roundy and Henning Thielemann have been arguing about the nature
of vectors and matrices, in particular saying:
On Thu, Jun 30, 2005 at 02:20:16PM +0200, Henning Thielemann wrote:
On Thu, 30 Jun 2005, David Roundy wrote:
Matrices _and_ vectors! Because matrices represent operato
On Thu, Jun 30, 2005 at 02:20:16PM +0200, Henning Thielemann wrote:
> On Thu, 30 Jun 2005, David Roundy wrote:
> > If we support matrix-matrix multiplication, we already automatically
> > support matrix-column-vector and row-vector-matrix multiplication,
> > whether or not we actually intend to, un
On Thu, 30 Jun 2005, David Roundy wrote:
> If we support matrix-matrix multiplication, we already automatically
> support matrix-column-vector and row-vector-matrix multiplication, whether
> or not we actually intend to, unless you want to forbid the use of 1xn or
> nx1 matrices. So (provided we
On Wed, Jun 29, 2005 at 10:23:23PM +0200, Henning Thielemann wrote:
> More specific:
> You give two different things the same name. You write
> A*B
>and you mean a matrix multiplication. Matrix multiplication means
> finding a representation of the composition of the operators represented
>
On Wed, 29 Jun 2005, Henning Thielemann wrote:
> On Wed, 29 Jun 2005, Jacques Carette wrote:
>
> > This is called operator overloading. It is completely harmless because
> > you can tell the two * apart from their type signatures. It is a
> > complete and total waste of time to use two differen
Let me a bit elaborate on what I wrote yesterday.
On Wed, 29 Jun 2005, Henning Thielemann wrote:
> I think matrices and derivatives are very different issues. I have often
> seen that the first derivative is considered as vector, and the second
> derivative is considered as matrix. In this spiri
Henning Thielemann wrote:
I'm also aware of that I mean different objects when I write
uniformly '1'. But I know that they are somehow different.
Since '1' can safely be used to denote the unit of any monoid, it does
indeed have a lot of applications. And of course the syntactic artifact
s
[EMAIL PROTECTED] wrote:
One of the things I appreciate and I hate simultaneously in your postings
is that you are so categorical.
'tis indeed simultaneously one of my strengths and one of my weaknesses
;-) I also like to play Devil's Advocate, to draw out the interesting
arguments. Luckil
Jacques Carette writes:
Henning Thielemann wrote:
I don't see the problem. There are three very different kinds of
multiplication, they should also have their own signs: Scalar product,
matrix-vector multiplication, matrix-matrix multiplication.
You see 3 concepts, I see one: multiplicati
Henning Thielemann wrote:
On Wed, 29 Jun 2005, Jacques Carette wrote:
Next thing you know, you'll want a different 'application'
symbol for every arity of function, because they are ``different''.
Btw. there is less sarcasm in it as may you think. There was already a
proposal to exte
On Wed, 29 Jun 2005, Jacques Carette wrote:
> Next thing you know, you'll want a different 'application'
> symbol for every arity of function, because they are ``different''.
>
Btw. there is less sarcasm in it as may you think. There was already a
proposal to extend function application:
http:
On Wed, 29 Jun 2005, Jacques Carette wrote:
> In fact, type classes in Haskell is a *great* way to do just that!
I agree. I'm also aware of that I mean different objects when I write
uniformly '1'. But I know that they are somehow different. I'm also ok
with not writing a conversion from say the
On Wed, 29 Jun 2005, Conal Elliott wrote:
> On row & column vectors, do you really want to think of them as
> {1,...,n)->R? They often represent linear maps from R^n to R or R to
> R^n, which are very different types. Similarly, instead of working with
> matrices, how about linear maps from R^n
Henning Thielemann wrote:
Mathematical notation has the problem that it doesn't distinguish between
things that are different but in turn discriminates things which are
essentially the same.
I used to think that too. And while that is sometimes true, it is
actually quite rare! When common m
On Wed, 29 Jun 2005, Dan Piponi wrote:
> >On Wed, 29 Jun 2005, Jacques Carette wrote:
>
> >Distinction of row and column vectors is a misconcept
>
> Row and column vectors are sometimes worth distinguishing because they
> can represent entirely different types of object. For example, if a
> colum
On Wed, 29 Jun 2005, Jacques Carette wrote:
> > If we instead distinguish row and column vectors because we treat them as
> >matrices, then the quadratic form
> > x^T * A * x
> > denotes a 1x1 matrix, not a real.
> >
> But if you consider x to be a vector without orientation, writing down
> x^T
>On Wed, 29 Jun 2005, Jacques Carette wrote:
>Distinction of row and column vectors is a misconcept
Row and column vectors are sometimes worth distinguishing because they can
represent entirely different types of object. For example, if a column vector
represents an element of a vector space V
On row & column vectors, do you really want to think of them as
{1,...,n)->R? They often represent linear maps from R^n to R or R to
R^n, which are very different types. Similarly, instead of working with
matrices, how about linear maps from R^n to R^m? In this view, column
and row vectors, matr
Henning:
>I was wrong, the different names are synonymes for the same type. :-(
I agree that we must statically distinguish Vector and Matrix (see below).
> Some notes: I would not call it a matrix library but a linear algebra
> library. Then setup modules like LinearAlgebra.Matrix,
> LinearAl
Henning Thielemann wrote:
On Wed, 29 Jun 2005, Jacques Carette wrote:
9. There are row vectors and column vectors, and these are different
types. You get type errors if you mix them incorrectly.
What do you mean with "row vectors and column vectors are different
types"? Do you mean t
On Wed, 29 Jun 2005, Jacques Carette wrote:
> 9. There are row vectors and column vectors, and these are different
> types. You get type errors if you mix them incorrectly.
What do you mean with "row vectors and column vectors are different
types"? Do you mean that in a well designed library th
I would recommend that you look very closely at the design of the
LinearAlgebra package, the Matrix and Vector constructors, and the
underlying implementation data-structure rtable() for Maple's
implementation of all these ideas. About 250 person-days were spent on
just the high-level design,
On Wed, Jun 29, 2005 at 01:38:51PM +0200, Alberto Ruiz wrote:
> Wow! It is exactly the same idea! I did not find the above message by
> Keean in my google searchs when I decided to work on this, it is very
> recent! After a quick look to the thread I wish I would have followed the
> discussions...
On Wed, 29 Jun 2005, Henning Thielemann wrote:
> On Wed, 29 Jun 2005, Alberto Ruiz wrote:
>
> > On Wednesday 29 June 2005 12:31, Henning Thielemann wrote:
> > > On Wed, 29 Jun 2005, Alberto Ruiz wrote:
> > > > In my work I often need linear algebra algorithms and other numeric
> > > > computation
On Wed, 29 Jun 2005, Alberto Ruiz wrote:
> On Wednesday 29 June 2005 12:31, Henning Thielemann wrote:
> > On Wed, 29 Jun 2005, Alberto Ruiz wrote:
> > > In my work I often need linear algebra algorithms and other numeric
> > > computations.
> >
> > Nice coincidence:
> > http://www.haskell.org//p
On Wednesday 29 June 2005 12:31, Henning Thielemann wrote:
> On Wed, 29 Jun 2005, Alberto Ruiz wrote:
> > In my work I often need linear algebra algorithms and other numeric
> > computations.
>
> Nice coincidence:
> http://www.haskell.org//pipermail/libraries/2005-June/003936.html
Wow! It is exac
On Wed, 29 Jun 2005, Alberto Ruiz wrote:
> In my work I often need linear algebra algorithms and other numeric
> computations.
Nice coincidence:
http://www.haskell.org//pipermail/libraries/2005-June/003936.html
> An option is using scientific computing systems like Matlab,
> Mathematica, Maple
Thats cool, I needed a matrix library and had started to roll my own in
Haskell, but a frontend for
the GSL library seems much more efficient. I will give the library a go
- and let you know if there are
any problems...
Keean.
Alberto Ruiz wrote:
> Hello all! This is my first message to the
Hello all! This is my first message to the list.
In my work I often need linear algebra algorithms and other numeric
computations. An option is using scientific computing systems like Matlab,
Mathematica, Maple, etc. In Haskell there are several modules and bindings to
matrix libraries; many o
85 matches
Mail list logo
