Boost logo

Boost :

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-04-30 13:27:14

As a mere cooking chemist, I can share the users' instinct,
and fear WEB's pessimism about discouraging use. If we
don't get it used, we are wasting our time.

area = pi * r * r;

seems right, whereas putting brackets in looks
(and indeed to the scientist reader is) confusing.

In much more complex expressions, the extra brackets
are a real turnoff.

Users can of course always write

const double pi = boost::math::constants::pi();

but at the cost of some inefficiency I fear.

Which leads me back to the MACROS which meet the
requirement for consistent high accuracy, but
duck these important issues!

I look forward to a other ideas.


PS Can we offer BOTH constants and functions (with the same results)
to resolve this dilemma.

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
+44 1539 561830

> -----Original Message-----
> From: wb_at_[hidden] [mailto:wb_at_[hidden]]
> Sent: Friday, April 27, 2001 3:40 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math Constants Library
> I have been following this discussion with great interest, because my
> own SIunits package incorporates a significant number of constants of
> nature that would use comparable notation.
> In my user community (largely composed of high-energy physicists),
> there was a clear and unambiguous consensus when I raised the issue
> three years ago of acceptable syntax for use of predefined constants.
> A recent repetition of the (informal) survey led to the identical
> conclusions:
> 1) When a default underlying type (whatever the package author has
> chosen) is acceptable, the syntax MUST be simply pi , perhaps
> qualified by an explicit or implicit namespace.
> 2) When a specific underlying type is required by the user, the
> syntax may be no more complicated than pi<long double> , again with
> namespace qualification if necessary.
> 3) Under no circumstances would functional notation such as pi()
> be acceptable; it is perceived as "unnatural" and would, simply
> stated, be such a significant hurdle that it would inhibit use of the
> entire package!
> I found this rather inflexible conclusion disappointing, but long ago
> learned that, for most users, perception is reality: if the user
> community doesn't like a design, for whatever reason, the product won't
> be used.
> It was, frankly, very painful to come up with a means of accommodating
> such a very firm mandate, but I believe I have done so. If desired, I
> would be pleased to discuss this issue (and perhaps others that may be
> of interest) in the context of my SIunits package when Boost meets in
> Copenhagen on Sunday.
> - WEB
> Ed Brey <brey_at_[hidden]> wrote on Fri Apr 27 08:11:05 2001:
> | From: <k.hagan_at_[hidden]>
> | > I'm losing track of what has and hasn't been suggested. Have we
> | > considered specialising a class template with a static member?
> | >
> | > template<class T> class math
> | > {
> | > static T const pi;
> | > };
> |
> | I don't remember it being mentioned on the list, but I experimented with
> | it a while back. A problem I noticed is that the value cannot be
> | specified inline in the template definition, causing most compilers to
> | be unable to inline the constant in code or perform constant folding.
> | Also, there is the question of whether a linker can exclude unused
> | constants from the executable. None of these are issues when using
> | inline functions.
> |
> | On the other hand, using a constant for a constant instead of a function
> | feels more natural. The lure of inline functions comes from a practical
> | matter addressing today's compilers' limitations. Is there any
> | realistic hope that compilers before too long would be able to handle a
> | member function or constant equally well, such that the boost library
> | could be practical in specifying a "cleaner" interface? I noticed that
> | gcc supports an extension allowing definition of a static const
> | float-point type within the class definition, just like what allowed
> | with ints. However, I'm not familiar enough with gcc to know how to
> | easily examine the code it generates to see what does with code that it
> | tuned to make use of its extension.
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
> Your use of Yahoo! Groups is subject to

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