Re: boost subnamespaces proposal.

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-06-28 23:29:54

on 6/28/01 9:35 PM, Hubert HOLIN at Hubert.Holin_at_[hidden] wrote:

> I have not been clear enough in recent posting about
> quaternions & all, and I believe this is of more general interest than
> just these libraries, so here is a clearer (I hope) presentation.
> 
> I propose the creation of namespace ::boost::math .
> 
> This namespace would contain quaternions and octonions, and
> would be a natural home for, say, rationals. It would also enable one
> to have, perhaps, another complex, with more stringent requirements
> (such as not yielding undeterminacies or undefinedness when
> instanciated on soething else than float, double and long double...).
> It would not be a natural home for things like timers or threads, for
> instance.

I think some others have mentioned doing this lately.  I would like it,
since a lot of stuff I do involves math.

> I propose the creation of namespace
> ::boost::math::special_functions .
> 
> 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.

> Other subnamespaces might include a ::boost::math::constants
> for (obviously) math constants, a ::boost::math::numerics for numerical
> methods (perhaps yet subdivided into optimization, integration, etc.).

Some of these may be OK, depending on the members.

> Clearly not all has to be implementad right away. I would
> like to know for the first two, though, so I can adapt the first
> shipping version of my submited libraries.

Are we starting it now?  I guess the structure could be:

- BOOST_ROOT
    - boost
        - math
            quaternion.hpp
            octonion.hpp
            advanced_trignometric.hpp (atanh, sinc_pi, sinhc_pi)
            rational.hpp
    - libs
        - math
            - doc
                quaternion.html
                octonion.html
                advanced_trignometric.html
                rational.html
              index.html
            + src
            + test

In the header and source files, the function/class/template names would move
to within the math sub-namespace (boost::math::quaternion,
boost::math::atanh, boost::math::rational).  For stuff that moves to the
math home, we have to make legacy considerations.  For instance, we'll keep
a BOOST_ROOT/boost/rational.hpp that simply points to
BOOST_ROOT/boost/math/rational.hpp and has a "using math::rational" to keep
a copy of the name as "boost::rational".

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