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

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#hea... ? 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? 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