9 Oct 20:25
Re: Geometry and spatial indexes, my opinion
Michael Fawcett <michael.fawcett <at> gmail.com>
2008-10-09 18:25:02 GMT
2008-10-09 18:25:02 GMT
On Thu, Oct 9, 2008 at 2:06 PM, Simonson, Lucanus J <lucanus.j.simonson <at> intel.com> wrote: >>> 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. > > --Michael Fawcett wrote: >>I don't understand why the interface or algorithm cares whether it's >>homogeneous or heterogeneous. > > The interface or the algorithm must necessarily be much more complex to > accommodate heterogeneous coordinates. Moreover, you have a real > problem with casting when you do arithmetic between heterogeneous > coordinates in an algorithm. No, it's not necessary. Surely the interface is just taking a type that conforms to a concept, and both a homogeneous and heterogeneous point type will conform. > x_coordinate_type x; > y_coordinate_type y; > ?_coordinate_type result = x+y; Boost.Typeof. Boost.Units also handles this gracefully, but I'm not sure how they ended up solving it. Regardless, this is not something the end-user cares how it works, just that it works. It's doable by the library writer, so should be done. > You would probably have to register a type for casting to: > > x_coordinate_type x; > y_coordinate_type y; > general_coordinate_type result = (general_coordinate_type)x + > (general_coordinate_type)y; > > Which is exactly what you do if you cast to the general coordinate type > in the interface between the algorithm and the data type. This type of conversion is handled automatically by the compiler in much simpler expressions: short s = 10; int i = 10; int result = s + i; // no warning, no casting necessary It should be handled the same way (i.e. not at all) in the underlying algorithms. vec3<int, short, int> isi(80000, 1000, 80000); vec3<int> i(80000, 80000, 80000); vec3<int> result = isi + i; // no warning, no casting necessary --Michael Fawcett _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RSS Feed