Re: Thoughts on Special Functions sinc_pi and sinhc_pi

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-21 17:39:30

paris (U.E.), le 21/05/2001

--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 5/19/01 10:28 PM, Hubert HOLIN at Hubert.Holin_at_B... 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

[SNIP]

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

        Be it as it may.

>  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

        Well, let them incarnate and then only see if there actually is a 
problem.

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

        OK, they are numbers. So are integers. My clain is that, for this 
implementation, quaternion<int> is meaningless. I am firmly convinced 
(and I am actually working on this...) that a quaternion class based on 
integers is meaningfull for some problem domains, but *not* for the 
ones intended here (graphics, physics).

> 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

        Well, the implementations as provided also work on complex. 
Currently that class, as part of the standard, is out of bounds for 
user tempering. So I would like to keep the various forms of sinc (etc) 
together.

        However, I am preparing an updated submission candidate where each 
group of functions (atanh, sinc, sinhc) has its own header, and 
"special_functions.hpp" simply includes all the various headers in a 
special_functions folder.

        Ulteriorly, it might also be interesting to have versions of, say, 
boost::sin, as currently it is impossible to write, say sin<float>, 
which might be advantageous when, for instance, "sin" always picks up 
the same function (say for double) with various truncations or 
expansions of the argument, irrespective of the actual type of the 
argument, as I believe it is allowed to, instead of a specialized 
version, when it exists (I suspect CW of doing so). These would of 
course be based upon the C library functions, in turn.

                Hubert Holin
                Hubert.Holin_at_[hidden]