RE: [boost] TODAY: Math Constants library formal review starts

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-04-24 08:54:06

> -----Original Message-----
> From: Jens.Maurer_at_[hidden]
> Sent: Monday, April 23, 2001 9:12 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] TODAY: Math Constants library formal review starts

>  - I think the C-style macros are not acceptable as the only interface
> for a boost submission.  The "default" mode of use should not defined
> any macros (except possibly internal helpers).

Accepted.

>  - I favor the "boost::math" namespace for the constants.  If someone
> needs these constants repeatedly in some scope, there's always the
> option to employ a using-declaration.

I think we will provide math functions (hopefully soon - see NIST proposal
http://dlmf.nist.gov) so do we stuff future math functions in the same
namespace math?
>>>>>>>>>>>>>>> Other views please!?!

>  - I'd like to see the source files rearranged, and I'd like to see
> the "generator" program included in the submission, at least for
> archival purposes.  Sure, it uses NTL.  The non-essential "generator"
> and "comparison" files ("knuth") should go to a subdirectory, such
> as "tools".  ("src" seems a bad choice, because an automated boost
> library build could mistake that for the library source directory)
Will do.

>  - I believe that filenames with spaces are a bad idea, can be easily
> avoided (use the underscore) and thus should be avoided.
Hackers from Seattle allow spaces but I will rename.

>  - Filenames of boost submissions tend to follow the
> lowercase_underscore convention of boost identifiers.  I'd be pleased
> if we could thusly avoid MixedCase filenames for general
> consistency.
OK

>  - Previous discussions during this review seems to have avoided the
> "naming scheme" topic, which I'd like to emphasize once more:  Please
> expressly define a naming scheme for the constants, in particular
> when having values such as "2/3 pi" and "sqrt of pi".  It may not
> be perfectly unambiguous, but there should be *something* documented.
OK, I will explain my 'logical naming scheme', however illogical it may seem
for others.

>  - A procedural remark:  I find it unfortunate that such major
> interface issues show up as late as this formal review.  I would have
> preferred the code to be available before scheduling the review.

I must protest - I posted my intention to submit a MACROS scheme well
before formal submission - and there was a deafening silence.
It has caused me far more grief having produced the macros file,
and will cause more repetitive strain injury in producing
yet another implementation!

(I'd still like to include the macros in the files -
I don't think our enthusiasm for C++ should not lead us
to exclude a C friendly version on grounds of political incorrectness!)

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
mailto:pbristow_at_[hidden]