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
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, you
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
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
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
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'm afraid
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, this
would
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
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 names, since
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.
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
then both the human
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. Keep
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
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 the FFT
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 you
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 haskell limits the
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.
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 against
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 separation
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 want. E.g.
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
addition
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 with a
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
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,
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 _is_ not a linear map
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)
(+) :: Vector -
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 finite
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 be that
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
that.
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 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 matrix or if it
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 vectors as
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 instead
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 mailing list
how to define LMap and what operations it supports. It may be worth
exploring, though.
Cheers, - Conal
-Original Message-
From: Lennart Augustsson
Sent: Thursday, July 07, 2005 5:44 AM
To: David Roundy
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] matrix computations based
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
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 (requiring
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
to
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
on
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 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 it simulates a
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 - ColumnVector
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 nice
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
that, if
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 - Matrix -
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 definition
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 spirit
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
by A
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 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, unless
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
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.]
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
(*) :: RowVector - Matrix -
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
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 you mix them
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 can represent
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,
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:
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
computations.
Nice
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... A
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, 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 they
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
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,
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,
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 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 is
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
column vector
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
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 to
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, Jacques Carette wrote:
sarcasmNext thing you know, you'll want a different 'application'
symbol for every arity of function, because they are ``different''.
/sarcasm
Btw. there is less sarcasm in it as may you think. There was already a
proposal to extend function
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:
[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.
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
76 matches
Mail list logo
