Re: [boost] Geometry and spatial indexes, my opinion

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-10-09 14:25:02

On Thu, Oct 9, 2008 at 2:06 PM, Simonson, Lucanus J
<lucanus.j.simonson_at_[hidden]> 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