Re: [boost] Re: boost subnamespaces proposal.

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-29 09:51:00

On Friday 29 June 2001 03:23, you wrote:
> --- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> > 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
>
> How would you handle functions that might have slightly different
> implementations depending on the domain?
>
> Look at pow(T x,I n):
> it is defined for every integer n if T is
> a group (e.g. x is float),
> it is defined only for non-negative n if T is a monoid
> (e.g. x is int),
> and it is defined only for n>0 of T is a semigroup.
>
> Similar things apply to binomial coefficients:
>
> binom(m,n)=binom(m,m-n) if both m and n are integral,
> but binom(x,n) != binom(x,x-n) (the latter is not defined)
> if x is float.
>
> One solution might be to have a
>
> group::pow,
> monoid::pow,
> and semigroup::pow.
>
> This might be easier to implement than
> to have clever template specialisation techniques
> the derive the respective algorithm from the template types.
>
> Helmut

The namespace solution doesn't work well generically, because you end up 
requiring that _every_ function that uses pow also have multiple variants in 
each namespace. And there are lots of mathematical structures and even more 
functions, and I think this method would get quite tedious.

The traits approach - requiring types to define what mathematical structures 
they model - could be used. It would require dispatch routines and such, but 
it doesn't require the user to specify the structure (a.k.a. namespace) that 
the type conforms to at each call. This is good, because in Matrix<T> we 
wouldn't know which namespace to use for pow(T x, I n).

I mentioned this a few months back, but we at RPI developed a library that 
allows types to state their mathemetical structure using traits, and contains 
a query mechanism. It's fully parameterized - one can declare that their 
BigInt class is an integral domain over + and * (with all the usual culprits: 
unary -, binary -, 0, 1, etc) and also that it is a monoid over ^ with 
identifity -1. The one could query, for instance, is T over + a group? What's 
its inverse function? Its identity element?

        Doug