Re: Thoughts on Special Functions sinc_pi and sinhc_pi

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-23 17:44:28

Paris (U.E.), le 24/05/2001

--- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> on 5/21/01 10:39 PM, Hubert HOLIN at Hubert.Holin_at_B... wrote:

[SNIP]

> > Well, let them incarnate and then only see if there actually is a problem.
> [TRUNCATE]
> 
> The review process should let us find and fix potential problems in advance
> of them coming up.  We don't want to redesign this part (the only real
> problem) of the package after someone else gets "screwed over" by it.
> 
> -- 
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com

        I agree with you on this. However the formulation I have adopted 
solves the problem for the remainder of my proposed libraries, and 
works with complex as well, which is beyond the reach of users. So we 
have actual wins, and only the potential for loss. If I move the 
definition to the quaternion and octonion files, we lose the win for 
complex, and only gain the potential for some future avoidance of some 
problem. I feel the current tradeoff is better, though it is of course 
a tradeoff. As a side note, I feel it more robust to have the functions 
defined and implemented in files other than that of variable types 
definitions (what I mean is that we first define sets, and then only 
functions on these sets (save of course for some; no integers without 
increment!)). In a redesign of C++ (C++-0x?) we should have a better 
factoring (and defining a new namespace for special functions where we 
could have, say, a "sin" for which the syntax "sin<float>(x)" is valid, 
alongside the current C-inherited grab-bag).

                Hubert Holin
                Hubert.Holin_at_[hidden]