
Boost : 
From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 20010629 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 Rbased 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
realworld 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]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk