Re: [Boost-users] [units][geometry] subtract_typeof_helper<> help!

Subject: Re: [Boost-users] [units][geometry] subtract_typeof_helper<> help!
From: Barend Gehrels (barend_at_[hidden])
Date: 2011-01-03 16:44:31

Hi,

>>>> Construction works here for me, but calculating distance does not.
>>>> Because distance behind the screens takes the square root, after
>>>> squaring. This requires thorough integration with Boost.Units at
>>>> those places, which is not planned.
>>>
>>> I understand that integrations with Boost.Units is not planned and
>>> even not desirable.
>>> But making the implicit assumption that
>>> typeof(sqrt(s)) == typeof(s) or that typeof(s*s)==type(s)
>>> makes it incompatible with Boost.units. Those assumptions are good as
>>> defaults but there should be a way to tell Boost.Geometry that
>>> sometimes it is not the case.
>>
>> I took a stab at a generic solution to this problem of units and data 
>> types in a geometry library with Polygon.  My coordinate_traits 
>> defines a distance time, area type etc.

Luke, do you mean this (boost/polygon/polygon_traits.hpp):

     typedef typename coordinate_traits<T>::coordinate_distance area_type;

where compilation fails?

Or this (same file):

     area_type x1 = (area_type)x(previous);
     area_type x2 = (area_type)x(*begin_range);

I didn't reach this point but I'm quite sure that Boost.Units will not 
accept this C cast, if area_type is square_meters and coordinates are in 
meters.

Maybe you can try it with Boost.Polygon, and deliver a working example 
for it, because I got immediately stuck.

>
> I agree - the general sloppiness in treating mathematical operators in 
> libraries that are intended to generically support them for UDTs seems 
> to be a widespread problem, even within Boost.

I doubt if Boost.Units quantity is really an UDT in the sense UDT is 
normally used. Boost.Geometry fully supports ttmath (great lib!), and 
two other high precision arithmetic numbers (GMP/CLN). It is highly 
probable that other UDT's defining all mathematic operations (operators, 
functions) are supported as well.

Boost.Units adds something more: physics. Therefore, it forbids 
mathematical operations as a*b because the result are not meters, but 
square meters. To support that, more is necessary indeed. Let's call 
this type an UDT+.

It is (probably) therefore that the review report stated: "The library 
does not need to be completetly integrated with Boost.Units, although it 
appears to be reasonable to deal with types as exposed by Boost.Units 
especially for distance and area calculations.". I think that is handled.

> For example, std::complex (which "circumvents" the problem by 
> disallowing UDT value types) defines
>
> template<class T>  complex<T>  operator/(const complex<T>&  lhs, const complex<T>&  rhs);
> However, even for a simple value type (e.g. integers - N.B. not int) 
> this is not correct since integer/integer -> rational so this should 
> really be
>
> template<class T>  complex<rational>  operator*(const complex<integer>&  lhs, const complex<integer>&  rhs);
>
> In general, anywhere that
>
> template<class T>  something<T>  operator blah(const something<T>&  lhs, const something<T>&  rhs);
>
> appears should look like (pseudocode)
>
> template<class T>  something<typeof(T blah T)>  operator*(const something<T>&  lhs, const something<T>&  rhs);
>
> instead. This requires a bit more care, but I think it is demonstrably 
> the right thing to do and should probably be an expectation in Boost 
> libraries. For example, I know that Boost.Quaternions, 
> Boost.Octonions, and Boost.uBlas do not do the right thing in this 
> context. It would also probably make sense to provide a Boost.Complex 
> that allows UDTs and handles them correctly. It sounds like 
> Boost.Geometry also does not correctly handle basic mathematical 
> operators.

Maybe not in the physical meaning that Boost.Units is using; this is not 
required and not planned.

I cannot speak of the other libraries, but I think the proposal I wrote 
yesterday is sufficient: the input is a Boost.Units quantity, the output 
is a Boost.Units quantity, all in their correct physical meanings. What 
is happening internally, and we do many many calculations there, all 
that is detail, black box for this UDT+.

Regards, Barend