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

Subject: Re: [boost] [gsoc] fixed size matrix class?
From: Mike Tegtmeyer (tegtmeye_at_[hidden])
Date: 2009-03-30 10:15:34

I apologize for being late to the thread but I'd like to invite folks to 
take a look at cvalarray in the boost vault. I wrote this a few years ago 
and has been in active use in our organization for years now and I've seen 
it around the net-mostly in raytracing circles. (Actually, I've seen it 
referenced as boost::cvalarray because they obtained it from the vault) I 
basically accomplishes the "small fixed sized numeric array" requirement 
and can be used as base for small matrix class as well. There is an 
internal version here that also uses SIMD (intel) for the underlying 
operations. I asked for an interest check on the list many moons ago but I 
only seemed to get a lukewarm reception. In any case, it is complete, uses 
expression templates to eliminate temporaries, requires nothing outside of 
the language, is self-contained in one file, and is well tested. Unless 
there is heartburn with the interface or underlying implementation, It 
basically just needs to be boostified and integrated into the build 
system. Take a look and see if it either meets your needs or could be used 
as a jumping off point.

Mike

On Mon, 30 Mar 2009, troy d. straszheim wrote:

> troy d. straszheim wrote:
>> Ross Levine wrote:
>>> I guess I'll be a voice of dissent. I personally think a fixed 2d
>>> matrix is too easy. It seems all you would have to do is either use a
>>> flat boost::array of Rows * Columns or the like, and copy
>>> boost::array's interface. This is from someone who is programming a
>>> game and already made a 2d matrix class.
>>> 
>>> I do, however, think that a fixed-size n-dimensional matrix would be
>>> better for GSoC, and can see the value in that. It would be difficult,
>>> though, without varidic templates.
>>> 
>> 
>> On the other hand, you're not going to mentor the student.  A gsoc project 
>> that gets finished, reviewed and committed to trunk is 10x better than one 
>> coded and partially documented, dumped into the "here's what I wrote this 
>> summer" google code repo.    How hard the project is to *code* is only a 
>> small part of the problem.   The hard part is getting the tests written, 
>> learning the build system, writing thousands of emails like this one, 
>> writing docs, etc.   GSOC is as much training for this process as it is 
>> learning to code new stuff.
>> 
>> -t
>
> I take it back, sorry if my tone was off there.  Having read more of the 
> thread, I agree with you...
>
> -t
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>