#67 Math Classes

[Christoph]

I would need to use at least some of the math classes in the near future. I remember that we had a discussion on how those classes might be rewritten in order to not reinvent the wheel and to achieve compatibility with eg boost. However, I do not remember the outcome of this discussion. I think the idea was having only interface classes to transport data which could be wrapped eg around boost containers. Is this still the way to go. What would happen to operations on the classes? Would one create functions/algorithms? What would happen to accessors like x() in vector? Should we keep that?

[SGrottel]

I am not sure what to do. We could use existing libraries:

http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/index.html

http://arma.sourceforge.net/

or

http://glm.g-truc.net/0.9.5/index.html

At least we should think about being compatible with these libs.

I would try to separate storage from computation.

Simple computation, like operators, should be directly implemented for convenience, like in the Vislib. More complex operations, i.e. on matrix, should be implemented in (static) utility classes, supporting different storage classes.

I believe, we should only provide the very minimum of math classes required! E.g., I am not sure if we really need to distinguish between points and vectors, as this "just" increases the maintanence effort for us.

For more complex computations we should always use one of the mentioned libraries, because they are likely to have optimized implementations.

What is "near future" for you?

[Christoph]

Pure Containers would be my preferred solution, too.

What kind of operators would you include. I would prefer having nothing but assignment and move. All other operators should become functions whenever possible. That should work for most binary ops.

Wrt. algorithms, I would opt for functions rather than static methods, just to be more like STL.

I would want to keep the differentiation between point and vector, and I would also want to add even more template-bound sanity checks like the direction of the y-axis in rectangles. I was also thinking of extending the coordinate system check to 3D, but had no good idea of how that would work. In order to make the templates less cluttered, I would suggest that we introduce tag objects, which of predefines configurations exist, eg int + y downward for screen-space coordinates.

[Christoph]

Is there some documentation about the storage layout of glm etc.? It would be nice if we could construct something like the matrix mechanism of vislib in combination with D3DX here. This basically relies on the fact that you have a "indexable" storage object at the bottom. I think that will work for boost, because boost uses something quite similar to the thing we have in vislib. I also have an idea how we could further improve our templates, but it might require variadic arguments...

"near future" is basically "now". I need that for a low-priority project (our panos from Japan). Atm. I could work around it for a while, but it is not cool. For example, the monitor_information is working with scalars instead of a rect.

[SGrottel]

I agree: pure containers with only index-access, "assignment" and "move".

I would include some additional members ('x()') for convenience.

Everything else to be functions.

The tag objects for, e.g. y-axis orientation, are very similar to the idea I had for fixing the rectangle.

So, let's do it.

It sound's like a major rewrite. Shall we split the work?

[Christoph]

Splitting the work seems reasonable. I would, however, recommend that we discuss the ideas first and try to make it work with one rather complex type eg the matrix before going on.

Named accessors for up to three dimensions like in vislib are a good idea. Btw, do you know whether the new "inheritance" for partial templates is working in VS2012?

[Christoph]

I started refactoring the matrix class according to "my vision of how it should work". There will be only one class left (the::math::matrix), initialisation is provided via SFINAE templates, more advanced functions are in the\math\matrix_functions.h.

Atm, I have only implemented a very basic part of the functionality to see whether it works (pls. have a look at it). If so, I would recommend following this pattern for all other classes.

At least in VS2012, I have a problem providing a default ctor via SFINAE. The current workaround is OK, but not cool.

[Christoph]

I think I found a solution for the dft ctor problem. However, would not be compile-time, but run time:

template<class T> struct is_shallow_container : std::is_pointer<T> { };

[...]

matrix(void) {
    if (!is_shallow_container<S>::value) {
        this->assign_identity();
    }
}