[boost] Re: Math functions - requirements 'spec'

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-11-08 06:44:45

Somewhere in the E.U., le 08/11/2004

   Bonjour

In article <E1CQU5V-0007U7-00_at_[hidden]>,
 "Paul A Bristow" <pbristow_at_[hidden]> wrote:

>  
> 
> | -----Original Message-----
> | From: boost-bounces_at_[hidden] 
> | [mailto:boost-bounces_at_[hidden]] On Behalf Of Deane Yang
> | Sent: 05 November 2004 16:02
> | To: boost_at_[hidden]
> | Subject: [boost] Re: Math functions - requirements 'spec'
> | 
> | Hubert Holin wrote:
> | > 
> | >       I must say I *strongly* disagree with having code with is C 
> | > compatible, mainly because this will greatly hamper 
> | genericity (or at 
> | > least convenient and safe parametrisation of code).
> | > 
> | >       Even if the code turns up only feasible for, say, float and 
> | > double, I strongly believe it should be templated upon the floating 
> | > type, with specializations if need be. The C library in C++ 
> | clothing 
> | > approach is just plain wrong, IMHO.
> | > 
> | 
> | I completely agree with this. It makes no sense to have a C++ library 
> | that does not use the full strength of the language.
> 
> 
> This view has already been expressed several times 
> 
> - but we have to face the fact that
> C99 and Walter Brown's functions are already in TR-1 to achieve C
> compatibility.

      Compatibility is a nice thing, but I fear in this case it brings 
more woe than weal. I would even go so far as to say that in this case 
we would have been better served with formal provisions to make linking 
with FORTRAN do the right thing... An let's not forget language support 
for Inf and NaN (isnan, isinf,...)   :-)   .

> I consider it essential to follow their example.

      It is never necessary to follow other persons mistakes...

> (Perhaps you should check PJP's reasoning on this).
> 
> So, despite that fact that I agree with you, I feel we must be pragmatic
> and face the facts.
> 
> If I don't get agreement on this before I start, there is no point in
> continuing
> as the code will be rejected on review.
> 
> Paul

      In this case, I believe that, perhaps, normalization is but a 
secondary goal.

      We *absolutely* need a proper C++ stat library, one which is 
cross-platform as much as can be. We do not need a C library (it already 
exists!); we could, platform permitting, even use a FORTRAN one, if we 
were so desperate to use any (good) stat library.

      Let's build it, and they will come! And if they do not come,then  
at least we can actually work, and work in peace.

      As others (Thorsten Ottosen is the only one I can find now) in 
this thread have suggested, you may want to add an additional header and 
wrappers for C compatibility, but this is by no means a necessity.

   Merci

         Hubert Holin