On Wed, Oct 8, 2008 at 7:32 PM, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:
Michael Fawcett wrote:
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>.
Phil Endecott wrote:
In GPS data, I store altitude to the nearest metre in an int16_t, and altitude and longitude in degrees in 32-bit fixed-point types. Although longitude needs one more bit than latitude I tend to use the same type for both, so my 2d algorithms are homogeneous. But anything that also involves altitude needs to be heterogeneous.
In VLSI layout we sometimes represent the layer as the z axis of a 3D coordinate system. Because there are only tens of layers we can use something smaller than int to store it. However, the compiler will often pad it back to word aligned addressing and insert padding bytes into a data structure, reducing the memory savings. Also, internally, all arithmetic is 32 bit or greater, so there is no advantage in using smaller data types for local operations. I think it is perfectly reasonable to allow point classes to have heterogeneous coordinate types, but require them to cast to and from a homogeneous coordinate type at the interface between that object and the geometry library. In all three examples, we would make the coordinate type of the interface between the point and the library int and allow the 16 bit value to cast up to 32 bits when it is read into an algorithm and back down to 16 bits when it is written out.
I don't understand why the interface or algorithm cares whether it's homogeneous or heterogeneous. --Michael Fawcett