Re: [Boost-users] [math][tools][units] generic librariesnotgenericenough

Subject: Re: [Boost-users] [math][tools][units] generic librariesnotgenericenough
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-08-29 04:02:00

>> Could the entire ResultType column be done away with, being replaced
>> everywhere in code with "auto"?
>
> No.
>
>> In other words, the Concept we are looking for is that the type
>> supports the operation, but we don't necessarily care about the result
>> type except that it also supports the subsequent operations required.
>
> There's been extensive research work in this area, and there's no easy
> fix if you want to say something meaningful.  You'd need to make the
> result an associated type and specify its required relationships with
> the input types.

There is a related issue: even if the types are related, and the concept 
well specified, actually programming with them isn't going to be easy.

To consider a trivial example, if T*T isn't a T, then one can't even 
evaluate a polynomial approximation to the function:

result = A + B* T + C * T^2 + D * T^3...

to give a concrete example, the root finding algorithm that started this 
thread uses a polynomial approximation to the function to greatly speed up 
finding the root (we can find the polynomial approximation and it's root 
algebraically once we have evaluated enough points in the function).  It's 
this insight that makes the algorithm converge so rapidly compared to the 
alternatives, but requiring that T*T != T breaks the underlying assumptions 
not only in how it's implemented, but in how it actually works 
algorithmically.

That's one of the reasons I suggested a forwarding wrapper.

Hopefully this explains the issues, John.