Re: Thoughts on Special Functions sinc_pi and sinhc_pi

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-05-20 13:03:17

on 5/19/01 10:28 PM, Hubert HOLIN at Hubert.Holin_at_[hidden] wrote:

> Paris (U.E.), le 20/05/2001
> 
> --- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
>> These are from the Special Function library currently under review.
>> 
>> First Issue: Template-based Template Parameters
>> 
>> My compiler, CodeWarrior Pro 5.3/Mac, can't handle function templates that
>> have template-based template parameters at all.  I had to comment out the
>> second versions of both functions to get the code to compile.  We would have
>> to #define BOOST_NO_TEMPLATE_BASED_FUNCTION_TEMPLATE_PARAMETERS in
>> <boost/config.hpp> to make sure some compilers can survive.  With the
>> various problems with templates that occur with the common compilers, why
>> depend on the rarest feature, template-based template parameters?
> 
> Things work fine with CWPro 6.1 . Will presumably work fine with
> 6.2 and onwards...

But how many other compilers will it work on?  I think that this library is
the first one with template-based template parameters, so we're going to
discover now how that feature's implementations turn out.  Removing them and
using custom versions also solves the more serious problem below.

>> Second Issue: Too General?
>> 
>> These problematic versions are supposed to be shortcuts for defining sinc_pi
>> and sinhc_pi for complex, quaterions, octonions, and the like.  They assume
>> that any kind of U<T> defines a numeric type with a vector-like algebra of
>> components T.  Some templates violate that, like boost::rational.  I know
>> that's not the kind of type you expect to use with sinc_pi, but another
>> numeric template may come along that defines a floating type, but doesn't
>> define a vector algebra.  That (hypothetical) class would have to take the
>> burden of defining custom sinc_pi and sinhc_pi function templates to avoid
>> being matched with your second sinc_pi and sinhc_pi.  It could be better to
>> avoid that by making your quaterions and octonions take the burden instead
>> by defining custom sinc_pi and sinhc_pi function templates in their
>> respective headers.  This would have to be the workaround for compilers that
>> can't handle the problematic versions, anyway.  (For std::complex, where you
>> can't make a custom function template version, maybe use the "functor class
>> template used by a function template" idiom and specialize std::complex's
>> version of the functor.)
> 
> These classes and functions are designed for number crunshing, in
> various domains of application. If the types they are built upon do not
> behave like numbers, all bets are off (and one might wonder what this
> use might mean...).

The classes I'm talking about do represent numbers!  You have two versions
of the sinc_pi and sinhc_pi function templates, a version that acts on
scalars, and another version that acts on types with vector-like operations.
You determine which version is used by looking at the form of the argument's
type.  Any type that is from a class template that takes a single type-based
template argument gets the vector version, all others get the scalar
version.  The fallacy is that you're assuming a one-to-one mapping between
the calculation form and the type form.  There can be scalar types that look
like a class template with a single type-based template argument;
boost::rational is an example.  There can also be vector types that come
from a different-looking class template, or from a regular class.

I'm saying that you can't tell if a numeric type is scalar or vector-like by
just looking at its type form.  A solution is to just keep the scalar
versions and have the vector-like types define a separate version on a
case-by-case basis.  (There could be other solutions, but this one solves my
first problem, too.)

>> Third Issue: Testing
>> 
>> There is a minor testing issue, since the problematic versions are not
>> tested within the Special Function's test file.
> 
> The "problematic" versions are tested in the quaternion and
> octonion test files.

Another reason for the custom version solution; to isolate testing concerns
better.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com