
hmatrix is bloat...
On Sun, May 3, 2009 at 5:58 PM, Tillmann Vogt
Balazs Komuves schrieb:
On Sun, May 3, 2009 at 12:56 AM, Tillmann Vogt < Tillmann.Vogt@rwth-aachen.de mailto:Tillmann.Vogt@rwth-aachen.de> wrote:
Now that you mention it. I just looked through haskell hierachical libraries and there seems to be no standard data types for vector math. Am I getting something wrong or is every library that is using linear algebra stuff using its own data types? So if I use a numeric library for matrices inside HOpenGL I have to convert around?
I think it would be nice to have data types and functions for dot produkt, scalar product, norms, ... together with HOpenGL types.
Currently I am trying to embed a triangulation library from a ten year old diploma thesis (http://www.dinkla.net/fp/cglib.html) in my libary (I know that glu has tesselation). The author has developed a quite big and abstract type structure for all sorts of computer graphics algorithms and I didn't wanted to copy this into my library just for triangulation. But it is reasonable. It could be combined with HOpenGL types to maybe Data.VectorMath or Data.LinearAlgebra . I would favour the second.
The problem is, in my opinion, that the design space of linear algebra libraries is big and complex; thus I don't think a "canonical" linear algebra library is a good idea.
There are at least 4 linear algebra libraries on Hackage already:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmatrix http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector-space http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Vec http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vect
and they are all very different, and I can easily imagine the usefulness of some more.
These libraries are different in the way they store data and in the interface. vectors-space is abstract, while your library offers an easier interface. For example vector-space defines an additive group and an affine space while you have a function translate3x. But essentially they all implement standard algorithms one learns in a computer science course (linear algebra, computer graphics) in university.
I think the best would be to have one abstract library. Then hmatrix imports this library and overloads the functions. People who want to use the speedy hmatrix lapack binding import it. Importing the original abstract library gives an impression of the speed differences. Then to have your easy interface you reimplement your library by giving the user a choice of which library to base it on (the abstract or hmatrix). As the last step HOpenGL renames an abstract n-dimensional vector (for n=3) to Vertex3 and the I can apply all the useful functions to Vertex3 values.
The disadvantage is of course that someone who wants to find out how something works has to read through a chain of types in different files. But this can be solved with a good documention that blackboxes everything that must not necessarily be understood by everyone. I also hope that one day a good IDE will help here. The argument that these libraries are fundamentally different is in my opinion not valid. I also don't understand why a too general libary would open a can of worms. Haskell has abstract data types. A Matrix can contain real values or polynomials or whatever. A Math person can derive his crazy library with overloaded functions. And no one whoe doesn't want to read this has to. I also think that most people want to do similar things as can be seen by the upper four libraries.
Self-advertisement: The last of the above four is designed especially for graphics use, in particular with OpenGL; but I'm not really satisfied with its current state, so feedback is very welcome!
Balazs
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl