Re: [boost] [gsoc] fixed size matrix class?

Subject: Re: [boost] [gsoc] fixed size matrix class?
From: Kornel Kisielewicz (kornel.kisielewicz_at_[hidden])
Date: 2009-03-30 08:02:10

On Sat, Mar 28, 2009 at 7:37 PM, troy d. straszheim <troy_at_[hidden]> wrote:
> Same reasons that you would use a 2d C array, I suppose.  You'd prefer the
> C++ version for the iterators, range-checking, the ability to choose
> row/column major storage format,  etc.
>
> This thread is now 50 emails long and the student is basically back where he
> started.  We have a certain obligation to steer him towards something
> appropriate for GSOC.

To be perfectly honest, that's how it seems -- I started with a simple
and modest proposal of a fixed-size vector and matrix library, went
through a big circle with spatial indexing and other stuff, just to
get back into a discussion about fixed matrices and vectors, what was
ditched as a bad idea in the beginning :) ( forgive the smiley )

And to add something more merithorical to the discussion:
I see a need, and I see a place in boost for a library that provides:
a) an fixed-sized matrix<dim,dim,traits> class, that works for any
dimension but is also hand-optimized for dimensions <= 4,
b) an fixed-sized vector?<dim,traits> class that works for any
dimension but is also hand-optimized for dimensions <= 4, *
c) operators for readable operations on vectors and matrices
d) mechanisms to almost invisibly (painlessly) allow converting those
classes for use with uBLAS, other math libraries, array and
multi-array types, and math libraries in progress

and possibly:
e) defining a common root for computational geometry, 3D and 2D boost libraries
f) using additional libraries like Boost.SIMD to boost (no pun
intended) performance

* a new name would be probably be needed? The reason I see a need for
a separate vector class  instead of array is to allow type safety for
operator handling for vector math. Also, vectors might need comparison
policy.
-- 
regards,
Kornel Kisielewicz