RE: [boost] Math constants for naive and gurus? - which constants do you want?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 13:40:41

----- Original Message -----
From: Ed Brey <edbrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 26, 2001 12:46 PM
Subject: Re: [boost] Math constants for naive and gurus? - which constants
do you want?

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> >
> > I would agree with you if in the end there were really just *two*
> > namespaces. Unfortunately, in my experience, this won't be the case; at
> > least not in the numerical applications I'm used to work with.
> > That is, in general -an according to my views- a numerical application
> > doesn't use *one* library, but a set of libraries, either layered or
> > independent. Following the separate namespace approach will lead to a
set of
> > numerical constants spread along a set of namespaces, probably many.
>
> If your using several different numerical packages, it's probably because
they all do different things.  It would seem that keeping each in its own
namespace helps clarify in the client code what is going on.  But perhaps
you're coming from a situation where a common namespace is desirable because
there is overlap in what the packages do.  In this case, though, I would
expect the commonality to trigger a high risk of name collisions.  And if
two packages conflict with each other, you're generally out of luck, since
you can't or don't want to be mucking with prepackaged code.
>
> If you're envisioning some scenario where it would be helpful to merge
namespaces of disparate packages, without problems due to package names
conflicting, maybe a concrete example would help.
>
>
I might be getting an unrealistic picture, but I'lll try to give an example.

I concieve non-specific constants as being not a part of any package; but
rather something that a package might just need.
So I image a developer writting package A which happens to need pi. Now
assume pi isn't in boost, so he declares A::pi, not because 'pi' is
conceptually bounded to the package A but because it is needed by A.
Then some other developer is writting a package B, which uses A, and which
needs 'radian'. 'radian' isn't in boost, nor A, so he declares B::radian.
Package C needs a conveniently premultiplied 2*pi, so now we have C::two_pi;
And so on.. We end up having a bunch of non-specific common constants spread
in totally unrelated namespaces.

I'm suggesting to put all general constants in a 'constants' namespace, and
to direct users in need of more general constants, to do the same. If there
are conflicts, they must be resolved. If I am right and those conflicts are
very unlikely and very easy to solve, I think this might be a better design.

P.S: Perhaps I need to emphatize that I am referring to general constants,
such as mathematical, physical and chemical constants; not to
domain-specific constants.

Anyway, I'm not considering that using a closed namespace is terrible. I'm
fine with that if the rest thinks that this is the right way to do it.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com

>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>