Boost logo

Boost :

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-11-06 17:29:31

From: "Peter Dimov" <pdimov_at_[hidden]>

> [...]
> > 1. Many constants are the return values of functions taking a certain
> parameter. In a perfect world, these wouldn't be constants at all, but
> would simply be written sqrt(2) or gamma(1/3.), or the like.
> sqrt(2) can be done by a boost::sqrt(int) that checks for the constants it
> recognizes. The rest will be computed on the fly.

I thought about that, but it leads to the problem of the user needing to know whether to use boost::sqrt or std::sqrt, since each would be faster in its own situation.

To make sure that we're on the same wavelength, I'm thinking of:

inline double sqrt(double x) { // boost version
  if (x == 2) return 1.41;
  if (x == 3) return 1.73;
  return std::sqrt(x);

The user code would be like this:
y = boost::sqrt(2) + std::sqrt(runtime_variable);
// Assuming that boost::sqrt(2) is completely computed at compile time.

This has the advantages of keeping the interface consistent whether performing a predefined operation or not, and also allows the code to be closer to how it would look once intrinsic compiler support is in place.

On the downside, having to use sqrt in two namespaces is inconvenient, since qualification is needed. Also, mistakes silently degrade to poor performance, which is a problem, since performance-sensitive code (in terms of time and precision) is being targeted here. Predefined, name-mangled, constants don't suffer from these problems.

Boost list run by bdawes at, gregod at, cpdaniel at, john at