On Sat, Mar 28, 2009 at 7:37 PM, troy d. straszheim <troy@resophonic.com> 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