Geometry Boost List: [ggl] user controllable numeric conversion.

Subject: [ggl] user controllable numeric conversion.
From: Barend Gehrels (barend.gehrels)
Date: 2010-04-29 17:37:18

Hi,

>   I saw lots of numeric_cast spread around to perform numeric conversion
> between different coordinate type.
>   numeric_cast is not so "general" for general programming (while the
> numeric::converter is). Although, user can still make their own coordinate
> type (UDT) to be available to numeric_cast, but the other traits of
> numeric::converter are fixed. And for built-in type conversion, it is
> totally out of user's control.
>   
I see. I had to recapitalize this for myself, so numeric_cast is a 
convenience function for numeric::converter and with the latter you have 
several handlers to control overflow, rounding etc. With the 
numeric_cast they are filled out by default and so indeed out of control.

>   It is ok to put numeric_cast in interface for convenience. A more general
> way would add another interface with a numeric converter parameter. But that
> could be too troublesome for both user and developer.
> So my suggestion here would be
> 1. use numeric_cast in a limited range, be sure that would not bypass user's
> conversion.
>   
what do you mean by a limited range? A range of the input coordinate type?
> 2. user should be notified not to mix using of different coordinate type
> that could be ill-formed(in the documentation).
> 3. If user wants to use their own numeric converter, they should explicitly
> use the transform algorithm. 
But what about other algorithms? In many cases you can mix coordinate 
types (e.g. distance). Until now I didn't care about the handlers and 
accepted the default handlers. It is indeed (too?) complex to implement 
such a facility everywhere

> To make it simple, make
> transform_strategy::apply() accepts another numeric converter parameter, and
> also add two interfaces of transform algorithm to accept converter parameter
> which would be passed to transform_strategy::apply(). The two original
> transform interfaces can be applied with numeric_cast as default converter.
> If it would result problem in current code, at least make another
> copy_per_coordinate like strategy that can be explicitly constructed from a
> numeric converter which would be used in apply(). Such strategy would be
> dedicated for coordinate type conversion, but is less convenient than the
> previous approach. 
>   
It is then only valid for transform, and yes that might make sense. The 
use has to copy but can at least do exactly what (s)he wants.

Anyway, I think the current implementation can already do a thing like 
this. Because a user can specify:

// user defined function
template <typename P1, typename P2, typename Converter>
struct my_convert_transformer
{
    inline bool apply(P1 const& p1, P2& p2) const
    {
        boost::geometry::set<0>(p2, 
Converter::convert(boost::geometry::get<0>(p1)));
        boost::geometry::set<1>(p2, 
Converter::convert(boost::geometry::get<1>(p1)));
        return true;
    }
};

which calls the static method convert of the specified extra template 
parameter, which can be any converter including specific handlers.

Indeed the "copy_coordinates" function could be extended to avoid 
specifying dimensions explicitly like above. That could be done by user 
code as well but we might provided this, like the my_convert_transformer 
could also actually be provided by default as well, indeed. Good point.

The difference with your proposal is that it is here a template 
parameter, not passed (so can only accept static methods).

Do you think this is sufficient?

Regards, Barend