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

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-24 14:18:31

----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, October 24, 2001 3:30 PM
Subject: Re: [boost] Math constants for naive and gurus? - which constants
do you want?

> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > From: Peter Dimov <pdimov_at_[hidden]>
> > > I don't really see what's wrong with the simple
> > >
> > > namespace math
> > > {
> > >     double const pi = 3.14159265358...;
> > > }
> > It doesn't fit well into generic programming:
> >
> > template<class Numeric>
> > void foo ( Numeric angle )
> > {
> >    if ( angle == pi )  // A narrowing conversion will occur here, if,
for
> > instance, Numeric is 'long double' or 'MyReallyBigFloat'
> > }
>
> The theory is sound. It's the practice that I'm not sure about. True, 'pi'
> is not generic, but in my opinion, it covers 90+% of the real world use
> cases quite fine, and the remaining areas will probably use their own
> definitions anyway.
>
Perhaps I'm not part of the real world :)

>
> For example, your foo<> will most probably be specialized on 'long double'
> or 'MyReallyBigFloat.'
>
Not necesarily.
For example, the main set of projects that I've developed over the years are
built upon a generic math and geometric library.
Right from the bottom of these libraries, everything is totally generic and
there are no specialzations at all, just end user
instantiations.
The important thing is that the end user -not me- plugs in the numeric types
that he/she wants, even his own ReallyBigFloat type; and I must write the
code as generic as possible introducing the minimun amount of unnecesary
conversions.

> Not to mention that an equality comparison to 'pi' is
> somewhat uncommon.
>
Right. I wrote a lazy example.

However, realize that any usage of a bare 'pi' of a fixed type (such as
double) in generic code will involve conversions which will be beyond the
control of both the writer and user.
I really don't like to mix a generic arithmetic type, possible user defined,
with a fixed native type, unless I have to.
The user of my kernel libraries might want to use his ReallyBigFloat type,
and he might want my kernel to use the ReallyBigFloat_PI that he has, so I
need a mechanism to allow him to specify the values of the generic constants
up to the full precision of the generic type.
The template class/function approach (with any of the sugested formats)
allows such flexibility through specialization.

Anyway, I admit that my views are biased by the need to write truly generic
math code (for arbitrary -user selected- numeric types), but I point out
that in this particular issue there isn't any efficiency problem with the
template-based approach, so I don't think that the flexibility should be
sacrified for simplicty in this case.

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