Kornel Kisielewicz wrote:
On Fri, Mar 27, 2009 at 12:23 PM, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Kornel Kisielewicz <kornel.kisielewicz@gmail.com> 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.