[Haskell-cafe] matrix computations based on the GSL

[Henning Thielemann]

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 them. They cannot be interchanged and we must use explicit conversion
> functions. Things like (v::Vector) + (m::Matrix), or svd (v::Vector) are
> statically rejected.

Great!

> You must use functions like matrix_x_matrix, matrix_x_vector, dot ::
> Vector->Vector->Double, etc. On the other hand, there are functions to
> build a matrix from a list of vectors, to concatenate the columns of a
> matrix as a vector, etc. If I am not mistaken, now the ambiguities
> explained by Henning do not occur.

Very great!

> - Only Eq, Show, and Read instances are now defined for Vector and Matrix. No
> numeric instances are defined, although it is very easy to do it using the
> functions provided. I have included a tentative "Interface" module including
> some hopefully user friendly operators.

This should be an excellent basis for experiments. Maybe I can contribute
an interface for the numericprelude type classes.

> We can use a darcs repository to allow contributions from all interested
> people.

Yes please!

> On the other hand, many useful functions have a type which depends on a value:
>
> vector :: [Double] -> Vector n
>
> We should statically reject this:
>
> vector [1,2,3] `vector_add` vector [1,2]
>
> (or perhaps we can imitate the zip behavior? :)

Better not :-) A static error is a must but obviously impossible.

> The sizes of some vectors and matrices depend on run time computations, even
> without taking into account IO:
>
> nullspace :: Matrix m n -> Matrix k n
>
> k depends on the particular matrix. We can improve this to:
>
> nullspace :: Matrix m n -> [Vector n]
>
> but if we need the nullspace in another matrix operation we must build a
> matrix from a list whose size is not known at compile time...

Yes, these are even more arguments for making the matrix size not integers
expressed by types.

> Static size checking is an advanced topic!

Static size checking seems to me possible only if the size is static.
Though clever people may have methods to statically check dynamic sizes.