Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk