Re: Geometry and spatial indexes, my opinion

Hi,

>> > Cool, compile time indexing is very useful. But, I'm not sure I see the
>> need
>> > for using tuples. I can't offhand think of a use case where the
>> dimensions
>> > are of heterogeneous type, so wouldn't a simple array work?
>>
>> Sure a simple array should work.  The point of a generic library is
>> that a simple array would work, so would a tuple, and so would your
>> custom point class.
>>
>> As for the heterogeneous types, think of huge (GBs worth) digital
>> elevation models in meter units where altitude is in a range from 0 -
>> 20,000m.  In that case, my point type would be something like
>> vector3<int, short, int> instead of a vector3<int>.
>>
>> With a 1024x1024 file, that would result in a savings of only 2MB of
>> memory, but extrapolate that out to a 16384x16384 file, and the
>> savings is 500MB.
>
>
> OK, yes, I'm convinced. Support for heterogeneous types has its uses. But I
> will still ask, why use a tuple to store the data in the basic (Cartesian)
> point class? Barend and Bruno's library uses an array instead, which I think
> should be preferred for two reasons. (1) I would still think the homogeneous
> case to be much more common the heterogeneous case. (2) Using a tuple makes
> it difficult or impossible to use the generic point class in high
> dimensions. Consider

Stop me if I'm wrong but what you're discussing now is how to
implement the point class provided by an ideal geometry library,
right? If so, I think it's not the most important concern since, as
I've already said, the primary goal is not to provide a point class
but to define how points are accessed and defined in general. I think
that, by talking about tuples, Brandon was rather pointing out that
points should be accessible the same way as tuples: get<N>(p). Which
is quite a general consensus now, IMO.

Bruno
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost