Re: [boost] Math constants: Inclusion requirements

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-30 13:18:03

From: "Paul A. Bristow" <boost_at_[hidden]>
> In general I agree with this, however the whole point is to ensure
> that NO compilers don't make any difference to the calculated value,
> so NO compiler is suitable as a benchmark - these values ARE the benchmark!

Cleaning up for compilers with poor QoI goes beyond the charter I had in mind of the constants library.  Rather, I think the central thrust of the library should be to complement good compilers by providing users the basic tools they need to write math-based code productively.  Now, if it can be shown that there is a substantial advantage to having lots of derived constants because compilers generally don't do an adequet job, that's one thing.  But I haven't seen evidence of that yet, and so for now I think that preventing the toolbox from overflowing with too many constants provides the most benefit.

> Although 2 * pi is almost certainly going to be exactly
> calculated, it (and a few others) are popular enough to be
> worth inlcuding.

This is a good example of where I am having a disconnect.  I would have thought that 2 * pi would be really popular - indeed the most popular - whereas something like two_pi only gets in the way.  I know when I am writing equations on paper (which I've been doing quite a bit of it lately), I prefer the number 2 followed by Greek letter for pi, and when coding the same (which I haven't done as much of), I would have expected that 2 * pi is best because it is the closest one can come to conventional handwriting.  Is there something I'm missing here?

> We have been through considerable discussion about portability,
> and I feel I have justified providing a reasonable number,
> split into a few header files.

I recall quite a discussion on portability regarding templates.  A long time prior to that I remember discussions stating that yes, indeed, one can get better precision by computing derived numbers by hand, but I don't recall the final step of a survey to determine how often that bit of extra precision makes a real difference.  If it can be concluded that compiler-derived constants are known to be a problem, then the problem needs to be addressed, but I wouldn't want to see "fixes" for a precision problem if compilers do an adequet job on their own.

> Of course some math constants will be essential to some and obscure to others.
> I propose to float (sorry!) lists when/if some consensus on naming is reached.

Sounds good.  At some level, this is all one can do.  But it makes sense to try to nail down as much rule-based inclusion/exclusion as possible first.