Re: Math Functions: Basic building blocks...

From: Eric Ford (eford_at_[hidden])
Date: 2001-09-27 14:09:19

> 0) Meta Issues
> 
> You don't give a rationale for using this library over relying on
> overload resolution on the std functions.  I have a few good reasons
in
> mind, but I'm not sure if there are other better ones, so I'd like
to
> hear your reasoning...

Here's what I was thinking...  In functions taking parameters of
templated types, you may want to specify what type the operation is
calculated in.  Additionally, people can specialize algorithms for
other template parameters (presumablely non-standard types) without
fear of implicit conversion happening.  Perhaps equally important is
what I wasn't thinking.  I didn't realize C++ overloaded these.

> 1) "Standard Functions"
> 
> By "standard functions" what do you mean? 

I suppose I should mean mathematical functions provided by some
standard.  As you probably noticed, gcc was my standard.  I suppose
ISO standard C++ would be a better choice.  

> Another alternative, for example, is to put the "C++ standard"
templates
> in one header, the "C99" extensions in another, etc, the code
generating
> macros in their own header so that they can be used in all the
headers,
> and a header that includes all the others if you want. 

Does it make sense to rely on functions provided only by C in code
which can't be valid C on account of templates?  I suppose you can
link to the C library, but I'm not sure that's a good idea.

> 2) Implementation Issues
> 
> C99 (not C89, and hence not ISO-C++) defines the "suffix functions"
> (such as sinf for float arguments, sinl for long double, etc). 
These
> are therefore NOT part of the ISO-C++ standard, and I don't think
you
> should be using them as the "implementation" for the template
functions
> for a standards compliant, portable "reference implementation".  But
you
>...
> Is there something that I am missing here?  Is there a good reason
not
> to do this and to rely on non-standard functions?

My ignorance of the C++ standard.  No good reason.

> 3) namespace issues
> 
> I personally don't have a problem with the
> "boost::math::standard_functions" namespace, but others might
> (justifiably, perhaps) complain that "standard_functions" is too
long a
> name.  Is there some shorter name that might be appropriate, or do
we
> just allow people to use namespace aliasing to get a shorter name?

Obviously, this is up for discussion.  I supposed std_func would be an
obvious abbreviation.  Personally, I like longer namespace names since
it reduces the likelyhood for collisions or confusion and you can
alias if you want to.

> If you're still interested in a full blown "function library" that
we've
> discussed before, some thought must go into the namespace naming and
> layout now... I'm not sure of the best approach.

Yes I am.  Me neither.  

> 4) preprocessor issues
> 
> The gcc preprocessor complains about pasting of tokens generating
> invalid preprocessing tokens on every use of your code generating
macros
> in the header.  The generated code works fine.  I don't know if
there is
> a problem, and I haven't looked into it, but maybe you'll see the
> problem.  I don't know if this matters one iota.  Here's a typical
> example:
> ...

I applied the "if it ain't broke" principle.  Of course if some
non-gcc prepreocessor chokes on it, then it may very well be broken. 
I haven't heard this to be the case (but then again I haven't heard of
anyone compiling it with something other than gcc).

> I'll provide a header implementing these changes for comparison
purposes
> (except maybe the preprocessor complaints ...  I haven't figured
those
> out yet.), although I may not get it in until Monday or Tuesday.

Cool.

Thanks,
E