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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-24 17:45:36

From: Peter Dimov <pdimov_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> > From: Peter Dimov <pdimov_at_[hidden]>
> > > From: "Greg Colvin" <gcolvin_at_[hidden]>
> > > > From: Peter Dimov <pdimov_at_[hidden]>
> > > > > float const pi_f = math::pi;
> > > >
> > > > I think on Noah's system this will result in the value in double const
> pi
> > > > being converted, slowly, at runtime.
> > >
> > > Once, at startup. If this is really a problem, we can (and probably
> should)
> > > add pi_f (and pi_l) to math:: as well.
> >
> > Once in this case.  But take away the const and put the initialization
> > in block scope ...
> 
> Why should I do that? :-)

Hell if I know, but on Noah's system it would be slow.

> > > The question is, what is the value of providing a generic framework that can
> > > handle types that we don't know about.
> >
> > Well, the advantage of fetching the constants via an
> > inline function is that it is faster,
> 
> "Prettier" assembly doesn't mean faster. It might well be faster, or it
> might be slower. I didn't see any timings for a nontrivial program being
> posted?

No, I haven't done any timings.  The main point was just that there need
be no overhead for the templates compared to a literal constant.  But I
am confident that, ceteris paribus,

    mov     DWORD PTR _pi_function$[esp+60], 1413754136
    mov     DWORD PTR _pi_function$[esp+64], 1074340347

will be faster than

    mov     eax, DWORD PTR _Pi$S188
    mov     DWORD PTR _pi_constant$[esp+40], eax
    mov     ecx, DWORD PTR _Pi$S188+4
    mov     DWORD PTR _pi_constant$[esp+52], ecx

> > and that an more
> > precise implementation might be possible, e.g. with an
> > extension for hexadecimal literals.
> 
> More precise implementations are possible:
> 
> namespace math
> {
>     union _Pi_t
>     {
>         unsigned char x[8];
>         double y;
>     };
> 
>     _Pi_t _Pi = { 0xB8, ... };
> 
>     double const & pi = _Pi.y;
> }
> 
> or whatever other ugly platform-specific hacks are necessary.

That might do it on some platforms, but with so many platforms
I'd hesitate to judge.  And I think the above will be even more
likely to force a memory reference.  The extra abstraction of
a generic soultion can provide for more flexibility of
implementation.