RE: [boost] Math Constants Library

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.

Paul

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
LA8 8AB      UK
[phone]
mailto:pbristow_at_[hidden]

> -----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 http://docs.yahoo.com/info/terms/
>
>
>
>