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