Re: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

newer
hello

older
abstract linear algebra interface...

Tillmann Vogt

2 May 2009 2 May '09

6:56 p.m.

Sven Panne schrieb:

...

* a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class (In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy here.)

How about Data.GraphicsObjects ?

...

* a package containing most of the data types/newtypes in OpenGL's VertexSpec module (Vertex{2,3,4}, Color{3,4}, etc.) plus instances for the base classes like Eq, Ord, Show, etc. I really don't know a good name for this package and what a good place in the hierarchy would be (probably something like "Data.Foo", but what is Foo?)

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 point is: The first two package would be very small. Would this be OK? Does anybody see other alternatives? What would be good names for those packages and where in the naming hierarchy should they really go?

Cheers, S. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Show replies by date

Sven Panne

3 May 3 May

6:44 a.m.

New subject: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

Am Sonntag, 3. Mai 2009 00:56:00 schrieb Tillmann Vogt:

...

Sven Panne schrieb:

...
* a tiny "ObjectName" package, consisting only of OpenGL's ObjectName class (In "Data.ObjectName"? I'm not very sure about a good place in the hierarchy here.)

How about Data.GraphicsObjects ? [...]

Thanks for all the suggestions so far, a few remarks from my side (I just picked the last mail for the reply, no strong reason for this...): "Data.GraphicsObjects" is a bit misleading, because OpenAL's Buffers and Sources are instances, too, and they have nothing to do with graphics. Instances of ObjectName are just opaque resources from an external API, which you have to allocate and deallocate explicitly.

...

I think it would be nice to have data types and functions for dot produkt, scalar product, norms, ... together with HOpenGL types.

I fear that this might open a can of worms and could lead to even longer discussions than the ones about a collection framework. The design space for a vector math package is quite large, and I fear that e.g. a mathematician trying to implement some linear algebra package has vastly different requirements than somebody trying to implement the n-th incarnation of the Quake engine. Some points to consider: * Should the components of vectors etc. be strict? In OpenGL they are, and Data.Complex is similar in this respect. In my experience non-strict components lead to space leaks too easily, and I guess this is the rationale behind Complex, too. But non-strict components have some benefits, too, of course, especially if you do symbolic computation. * Should we abstract over the number of dimension of vectors, etc.? If yes, how strong can our compile-time type checking be? * If we really make this a more general vector math package, things like colors etc. should probably stay in the OpenGL package. But there are a few other packages needing color data types, too... * If the package is not general enough, it might be a bad idea to steal names/hierarchy locations which *are* general. Nevertheless, I'd be happy to see some proposals for a sensible, compact vector math package. Probably we can fulfill most of the common use cases with something simple. And one word about lumping the 3 packages together: Any function, module, and package should have *one* clearly defined task, this is crucial for every SW design. I would have a hard time explaining what this "super package" is all about, even if we throw only 2 of the 3 packages together. Personally I feel that this is a strong argument for 3 separate packages.

...

(I know that glu has tesselation). [...]

But GLU is basically dead with OpenGL 3.x. :-) Cheers, S.

Balazs Komuves

9:58 a.m.

New subject: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

On Sun, May 3, 2009 at 12:56 AM, Tillmann Vogt

...

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. 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

Tillmann Vogt

12:58 p.m.

New subject: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

Balazs Komuves schrieb:

...

On Sun, May 3, 2009 at 12:56 AM, Tillmann Vogt 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

Hugo Gomes

7:08 p.m.

New subject: [Haskell-cafe] Decoupling OpenAL/ALUT packages from OpenGL

hmatrix is bloat... On Sun, May 3, 2009 at 5:58 PM, Tillmann Vogt wrote:

...

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

5861

Age (days ago)

5862

Last active (days ago)

List overview

Download

4 comments

4 participants

participants (4)

Balazs Komuves
Hugo Gomes
Sven Panne
Tillmann Vogt