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

Subject: Re: [Boost-users] [math][tools][units] generic libraries notgenericenough
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-08-27 07:02:51

> The basic gist of the discussion is that many generic libraries don't
> fully support Boost.Units because they don't support mixed type
> arithmetic correctly (or aren't generic enough, however people want to
> say it).  Consider a very simple example of a hypothetical math
> library function "add" that purports to handle user defined types
> (some sort of BigInt is a popular example):
>
> template <typename N>
> N add(N lhs, N rhs)
> {
>   return lhs + rhs;
> }
>
> Functions like this often break with Boost.Units because the result
> type might not necessarily be the same as the argument types (N in
> this case).  Not only that, it doesn't allow adding two distinct types
> together.

It's not that they're "not generic enough", it's that they use different 
concepts for their number types, Boost.Math has a well defined concept that 
all number types must obey: 
http://www.boost.org/doc/libs/1_47_0/libs/math/doc/sf_and_dist/html/math_toolkit/using_udt/concepts.html. 
It also has concept checking programs and concept archetypes to verify that 
our code really does stick to the stated concept requirements and no more: 
http://www.boost.org/doc/libs/1_47_0/libs/math/doc/sf_and_dist/html/math_toolkit/using_udt/archetypes.html

The issue is really twofold:

* What are the conceptual requirements for a unit type?  I can't see it 
listed anywhere, but that doesn't mean it's not there (In point of fact, 
Boost.Units has two concepts in play: the requirements on a backend type 
supplied as a template argument to type "quantity", and the requirements on 
clients of quantities).
* Should we have a single unified concept for all number types in Boost.... 
if yes what happens when the next latest and greatest library comes along 
and requires slightly different concepts to function efficiently?  What I'm 
saying is it's pretty hard to get this right.

Let me give you a concrete example - mixed arithmetic.

Boost.Math currently requires code such as:

x *= 2;

to compile and do the right thing.  However, there are some number types 
(Boost.Interval for sure, not so sure about Units) that don't permit this 
and make all constructors explicit.  Now you could say, "no problem, just 
add a cast", but:

x *= SomeType(2)

Is needlessly inefficient for many big number types, and even for builtin 
floats, one could imagine a sufficiently clever compiler just doing some bit 
fiddling in x, rather than a full multiply.

Basically, the issue is that it's really hard to come up with a clear 
conceptual model, that satisfies all potential use cases.  A worthy goal for 
sure, but what I'm trying to say is it's the detail that gets you ;-)

If someone would like to try and work up a unified set of conceptual 
requirements that would be really great, but I'll warn you now it's likely 
to be a whole lot of work.

Perhaps as a more manageable goal, if someone can provide 
unit-aware-and-safe signatures for the math lib's functions, then I'll 
happily provide them as thin wrappers that forward to the underlying 
non-unit aware code.  Rather like the Units lib already does for std lib 
functions.   I'd rather not do this myself though, as I'm not familiar 
enough with Boost.Units.

Regards, John.