Re: [boost] [gsoc] Interest check for 3d geometry proposal

Subject: Re: [boost] [gsoc] Interest check for 3d geometry proposal
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-03-27 11:50:01

Kornel Kisielewicz wrote:
> On Fri, Mar 27, 2009 at 12:23 PM, Phil Endecott
> <spam_from_boost_dev_at_[hidden]> wrote:
>> Kornel Kisielewicz <kornel.kisielewicz_at_[hidden]> wrote:
>>>
>>> One example is object hierarchy via oct or kd trees.
>>
>> Would you like to implement these spatial containers? ?I think this would be
>> a very useful contribution. ?Ideally your implementation would be generic,
>> i.e. usable with fixed-size point types or the variable-size uBLAS types; at
>> the end of the project we would then be able to evaluate the benefit of
>> removing the size field. ?2D & 3D please.
>
> This is exactly my intention.

Great.  Go for it.  Don't be over-ambitious.

As Luke points out there was an attempt at this last year which 
delivered some rather poor results.  I don't know whether that was 
because the student was too inexperienced, or because he didn't put in 
much effort, or what.  I would like to think that it would be possible 
for a student to produce something worthwhile in this field but maybe 
that's one of my (rare) streaks of optimism showing through.

>> - Although I doubt that wasting a word on a size field has much effect on
>> speed, I would want to avoid it when dealing with large collections of
>> points because of the memory overhead.
>
> I'm not too much worried about the memory, as I am about data
> alignment.

Why?  Do you have some motivating application where memory doesn't 
matter but unaligned accesses are expensive?  If you have a motivating 
application please tell us about it.  My comment that _I_ would want to 
avoid wasting memory is because I have a memory-constrained application 
in front of me.  Code for a library like Boost will end up in lots of 
different applications with different constraints, and it really ought 
to be "good all round" to satisfy all potential users.

> Also, in the case of 4d vectors, you'd have 5 values, which
> doesn't scale well ( 4*32 bits = 128bits which is nice -- an addition
> would ruin this niceness ).

Multiplication by 4 faster than multiplication by 5?  Maybe, but 
probably premature optimisation :-)

Cheers,  Phil.