Subject: Re: [Boost-users] [math][tools][units] generic libraries not genericenough
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-08-26 04:13:37
> Lately I am using Boost.Units quite intensively for defining lots of
> thermodynamic functions. The other day I needed a root finding algorithm
> that can work on one of these functions. I look at couple of libraries,and
> I ended up rolling and adaptor that adimensionalizes the function on
> Boost.Units quantities, etc, etc.
>
> Then I though, hey! we have Boost.Math tools, even root finding
> algorithms,
> and these functions are *very* generic as Boost is supposed to be. And I
> found the function:
>
> boost::math::tools::bracket_and_solve_root
>
> which has the perfect underlying algorithm for the application.
>
> I started programming and after several compilation errors I realized
> that,
> as happened before, the functions are not generic enough. For example the
> arguments are
> bracket_and_solve_root( F f, const T& guess, const T& factor, bool rising,
> Tol tol, boost::uintmax_t& max_iter);
>
> in my case "guess" is an argument type of type
> boost::units::quantity<si::meter> but then "factor" has to be a
> *different*
> type. For this function to be generic one need that factor is of new type
> parameter.
>
> In my opinion the function should be
> template<typename F, typename T, typename Fact, typename Tol>
> bracket_and_solve_root( F f, const T& guess, const T& factor, bool rising,
> Tol tol, boost::uintmax_t& max_iter);
> to begin with (and then there is a chain of other internal changes).
>
> What do you think? should I open a bug ticket?
> Let's put it in more abstract way: T*T=T should not be a requirement for a
> root algorithm to work.
> Once and for all, can we give a name to the model type of which
> Boost.Units
> quantity models for? so the library writers stop assuming that T*T=T for
> numeric values and can improve half-way generic libraries?
>
> 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. 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? Plus I don't really want to
make Boost.Math dependent upon Boost.Units.
Just curious, but what's wrong with providing your own thin wrapper that
forwards to the undimensioned 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 - albeit a minimally documented
one. The code is solid, but as mentioned in the intro to the tools
section - these are details - so we reserve the right to change the
interface if required - or a better interface comes along - not that we ever
have.... yet! ;)
John.