Re: [Boost-users] [math][tools][units] generic libraries not genericenough

Subject: Re: [Boost-users] [math][tools][units] generic libraries not genericenough
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2011-08-26 11:13:59

On Fri, Aug 26, 2011 at 5:16 AM, alfC <alfredo.correa_at_[hidden]> wrote:
>
> On Friday, August 26, 2011 1:13:37 AM UTC-7, John Maddock wrote:
>>
>> Plus I don't really want to
>> make Boost.Math dependent upon Boost.Units.
>
> (of course but) This is a chicken and egg problem. Maybe this is calling for
> a third library that provides a uniform protocol for determining the type
> results of operators. Maybe based on boost/units/operator_helpers? Maybe it
> already exists? Maybe it is a matter of adding result_type/result_of
> protocol to the equivalent of std::multiplies<T1,T2>?
> There is always "decltype" but I don't know what is the philosophy with
> respect to C++11 features.
> Another alternative is to have an optional extra template argument that
> provides information on the types.
> Just take boost.units as an example; there can be other numeric types in
> which T*T != T and yet all these algorithms still make sense.
> Again, nobody is asking that make Boost.Math dependent on Boost.Units; just
> make it compatible with it by not doing over assumptions on the types.
> Boost.Units quantities are really very honest mathematical objects, it is
> not just a weird designed type.
> I am sure Boost.Units authors can make a better case.

I don't think it has to be a chicken and egg problem.  If the math
library says that it is generic it should support return types that
are different from the input types IMHO.

In the past I have implemented math libraries like so:

template
<
        typename X0, typename Y0, typename Z0,
        typename X1, typename Y1, typename Z1
>
BOOST_TYPEOF_TPL(X0() * X1() + Y0() * Y1() + Z0() * Z1())
dot_product(const vector3<X0, Y0, Z0> &lhs, const vector3<X1, Y1, Z1>
&rhs)
{
        return lhs.x * rhs.x + lhs.y * rhs.y + lhs.z * rhs.z;
}

which admittedly is not *entirely* generic since it relies on the
vector3 type and probably should have taken a generic tuple, but you
can at least see how the result type gets computed.

I haven't tried this using Boost.Units as the vector components, but
my hope would be that a vector3 of Boost.Units in this case would Just
Work.  It seems like auto and decltype will help out library authors
quite a bit in this regard.

Regards,

--Michael Fawcett