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

Subject: Re: [Boost-users] [math][tools][units] generic libraries not genericenough
From: alfC (alfredo.correa_at_[hidden])
Date: 2011-08-26 05:16:40

Hi John,

On Friday, August 26, 2011 1:13:37 AM UTC-7, John Maddock wrote:
>
> > Other numeric libraries that suffer from this deficiency are
> > Boost.Accumulators, Boost.Geometry, and Boost.Interval among the ones I
> > tried. I think this issues should be addressed, not only to make them 
> work
> > with Boost.Units but also to bring those libraries to a higher level of
> > generality.
>
> While I certainly understand the need here, I think in the general sense 
> the 
> only solution is to use the underlying *values* (not dimensioned 
> quantities) 
> under the hood, and where an algorithm can be used with dimensioned 
> quantities, then provide a forwarding wrapper that checks the 
> type/dimension 
> safety of the arguments and result and internally forwards to the unchecked 
>
> version. 
>
I do that all the time, specially with C-functions which are not generic at 
all; for example I do that when using GSL. 

>  For example, I'm sure I'm missing something, but I don't see any 
> traits classes in Boost.Units to calculate the result of an arithmetic 
> expression involving dimensioned quantities?  
>
Are you looking for this 
http://www.boost.org/doc/libs/1_46_1/doc/html/boost_units/Reference.html#header.boost.units.operators_hpp
?
for example boost::unit::multiply_typeof_helper works with quantities and 
non-quantities and can always be specialized.

> 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.

Just curious, but what's wrong with providing your own thin wrapper that 
> forwards to the undimensioned function?
>
I do that all the time. Lots of coding wrappers, lots of repeated functions. 
Beside it is a bit of shame to have to write a wrapper over an already 
"generic" boost function.

> And finally, this reminds me that we never did ask for a review of the Math 
>
> "tools" including these root finding algorithms, so officially, this 
> function is an implementation of Boost.Math
>
this is the best argument. Sorry I picked on your library, it was mainly an 
statement, on a clean case, that many boost libraries are really 
half-generic while they pretend to be generic. 

Thanks,
Alfredo

>