Re: Math Functions: Basic building blocks...

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-09-27 13:05:14

Eric Ford Wrote:

--- some stuff ---

Hi Eric,

I've finally had a chance to look at what you've done, and I really like
it.  A few issues and questions, however, that I'd like to understand:

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...

1) "Standard Functions"

By "standard functions" what do you mean?  If you mean "based on ISO
Standard C++", then all of the functions that gcc doesn't support and
which you have commented out are not in the standard.  The standard
includes all of the following functions which are in C89, with some
changes: C89 only defines double func(double) versions, while ISO-C++
additionally includes float and long double overloads.  There are some
other minor issues, like functions provided in ISO-C++ that have no
analog in C89.  Here they all are:

One argument functions in <cmath>, with signature T std::func(T), with T
= {float, double, long double}

abs [C++ only!], acos, asin, atan, ceil, cos, cosh, exp, fabs, floor,
log, log10, sin, sinh, sqrt, tan, tanh

Two argument functions in <cmath>, with sigs T std::func(T, other)

T atan2(T,T), T fmod(T,T), T pow(T,T), T frexp(T,int*), T ldexp(T,int),
T modf(T,T*), 
T pow(T,int) [C++ only!]

The following integer based functions are defined in <cstdlib>

int abs(int), long abs(long) [C++ only!], long labs(long), div_t
div(int,int), ldiv_t div(long,long) [C++ only!], ldiv_t ldiv(long,long)

I think I got them all..... I would completely dispense with the rest of
them, for now.  
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.  Or, if we
include C99 functions in this header, it should be protected by #ifdef's
and include ALL of the C99 functions; of course, it isn't clear what
that would mean (do you use the overloads that will likely be included
in the next C++ standard, but aren't in the C99 standard, or the "suffix
functions" that I dissed above? etc....)

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
don't need them anyway, I don't think, since the standard overload
resolution mechanism should allow the compiler to pick the right
overloaded function.  For example, shouldn't these pick the right
overloads at compile time? (incidentally, shouldn't the special
functions library, as mentioned before, also be doing this?)

template<> inline float sin<float>(float x) { return ::std::sin(x); };
template<> inline double sin<double>(double x) { return ::std::sin(x);
};
template<> inline long double sin<long double>(long double x) { return
::std::sin(x); };

Is there something that I am missing here?  Is there a good reason not
to do this and to rely on non-standard functions?

Of course you can just ignore this issue and require the
compiler/library to comply with C99, providing the suffix functions and
use the implementation you provided, but that might limit the platforms
it can build on.

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?

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.

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:

In file included from standard_functions_test.cpp:15:
standard_functions.hpp:49:7: warning: pasting "," and "sin" does not
give a valid preprocessing token
standard_functions.hpp:49:7: warning: pasting "," and "sin" does not
give a valid preprocessing token
standard_functions.hpp:49:7: warning: pasting "sin" and ")" does not
give a valid preprocessing token
standard_functions.hpp:49:7: warning: pasting "," and "sin" does not
give a valid preprocessing token

It also complains about every use of TEST_FUNC1 in the test file.

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.

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------