Re: boost subnamespaces proposal.

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-06-29 18:11:28

paris (U.E.), le 30/06/2001

        Hi all

--- In boost_at_y..., Peter Schmitteckert (boost) <boost_at_s...> wrote:
> Salut
> 
> On Friday 29 June 2001 06:29, Daryle Walker wrote:
> > on 6/28/01 9:35 PM, Hubert HOLIN at Hubert.Holin_at_B... wrote:
> [...]
> > > This namespace would contain atanh, sinc and sinhc, and would
> > > welcome other such functions. It would also enable one to have,
> > > perhaps, templated sin, cos and friend functions, which have non-
> > > templated forms in the standard, and for which implementations may have
> > > more efficient forms in the float (say) case, under another name...
> >
> > I don't think we need this.  Who's to say what's "special"?  It's too
> > arbitrary.  For instance, since sin, cos, tan, atan, sinh, and cosh are
> > already "normal" math functions, why shouldn't atanh also be a "normal"
> > math function?  There wouldn't be a connecting domain for the namespace's
> > members.  Why have a special namespace for a certain hodgepodge subset of
> > math functions within a namespace already made for a hodgepodge of math
> > functions and classes?  We shouldn't add levels unnecessarily.
> 
> I agree., besides 
> atanh(z) == - \imath arctan( \imath z) ,
> 
> so atanh() is definitly a 'normal function', if atan() is.
> And where to put the Bessel function, they 're 'normally' on unix.
> And I have friends claiming that hypergeomatric functions are very normal... .
> So boost::math should be sufficient.
> 
> Best wishes,
> Peter

                The term "special function", is frequently used to refer to 
those functions which are common and interesting enough to be given a 
name (and usually a confusing jumble of conflicting names...). I would 
add that the functions which would go into 
::boost::math::special_functions are those which are significant within 
the fields of real (& all) analysis and numerical analysis. So yes, 
sin, atanh and pow would have a presence here (in addition to the 
already existing ::std::sin which can not be erradicated), as well as 
Bessel functions, hypergeometric functions and most of the rest of A&S.

                "pow" is a special (and unfotunate) case. It stems from set 
theory (pow(0,0) is undefined... yea right...), and has an extension to 
R (and a more problematic one to C). The basic notion is that of 
exponentiation (of course related to the exponential). Perhaps then the 
algebraic version of "pow" (suitable, among others, for multiplicative 
monoids) should bear another name... or live in another namespace. It 
believe this is preferable than changing the name of the R-based pow.

                The things in ::boost::math::special_functions should work 
well with the future denizens of a ::boost::math::numerics (or 
::boost::math::numerical_methods) namespace. Then again foregoing 
::boost::math::special_functions in favor of just 
::boost::math::numerics could be a better idea.

                As for the koenig lookup problem problem evoqued in another 
branch of this thread by David Abrahams, I feel we are immune to the 
perverse effects evoked by the fact we will deal with an homogeneous 
problem domain (pow is relevant to more than one, in particular the 
mixed integer/floating forms are relevant to set theory and algebra 
(that of R in this case), whereas the floating/floating forms are 
relevant to analysis, and swap is potentially universal, i.e. its place 
is more comprehensible as a language keyword than as a library 
function).

                As for the unforseen effects of deeply nested namespaces 
mentionned by Beman Dawes, well, is this not a good place to carry out 
real-world experiments ;-)  ?

                Also, introducing ::boost::math::special_functions is a neat 
way of tidying up things (reducing clutter), and avoiding collisions 
(the raison d'etre of namespaces), especially in the light of possibly 
other subnamespaces cropping up (constants, numerics, combinatorials, 
etc.).

                In the end, of course, I'll go allong with the consensus 
(here's hoping there'll be one, and that I can discern it :-)  ).

                        Hubert Holin
                        Hubert.Holin_at_[hidden]