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

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-10-23 06:59:29

> -----Original Message-----
> From: Ed Brey [mailto:edbrey_at_[hidden]]
> Sent: Monday, October 22, 2001 10:44 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Math constants for naive and gurus? - which
> constants do you want?
>
>
> From: "Paul A. Bristow" <boost_at_[hidden]>
> > >
> > > The current version in the vault has several files
> > > (float_constants.h, double_constants.h, long_constants.h) that
> > > each define identical names in the global namespace.  This is
> > > certainly not acceptable for a boost library.  Now, if the
> > > objective is just to show that the constants can be partitioned
> > > into multiple headers, that is fine.  However, one should never
> > > count on the user just including only one of multiple headers,
> > > since any given library may include any given header in a .hpp
> > > file (perhaps because a constant is needed in inlined code).
> >
> > I naively envisaged that only one would be #included.

Would it not be simpler to check that the other types (float and long
doubles say)
have not already been included?

> > > What didn't make sense is why the compiler would generate code
> > > for unused constant classes.  Fortunately is that the answer is
> > > due to a simple (arguable) bug in the library.  The constant
> > > class has a superfluous constructor.  If you remove the
> > > constructor, then the compiler generates code only for what is
> > > used, and optimally efficient code at that.  ("The compiler" here
> > > is VC6.)  If there was ever a poster child for not littering
> > > classes with do-nothing constructors, this is it.
> >
> > I don't understood you here.
> >
> The > constructor is boost::math::constant::constant.  The line to remove
is:
>   constant() {} // Returns the value of the constant.

Sorry for temporary brain failure here - of course.

But MSVC6 produces this in debug mode:

51:       const double cp = 3.141592653589793238462643383279502884197;
00401650   mov         dword ptr [ebp-8],54442D18h
00401657   mov         dword ptr [ebp-4],400921FBh

52:       double ccp = constpi; <<<<<<<<<<< simple assignment.
0040165E   mov         eax,[constpi (00470028)]
00401663   mov         dword ptr [ebp-10h],eax
00401666   mov         ecx,dword ptr [constpi+4 (0047002c)]
0040166C   mov         dword ptr [ebp-0Ch],ecx

53:       double pd = 3.141592653589793238462643383279502884197;
0040166F   mov         dword ptr [ebp-18h],54442D18h
00401676   mov         dword ptr [ebp-14h],400921FBh

54:       double p = pi; <<<<<<<<<< Using function
0040167D   mov         ecx,offset pi (00470022)
00401682   call
@ILT+260(boost::math::constant<boost::math::pi_tag,double>::operator double)
(00401109)
00401687   fstp        qword ptr [ebp-20h]

// function actually being called
70:       template<> inline constant<pi_tag, double>::operator double()
const
71:       {
00401990   push        ebp  <<<<<<<<<<<  What does all this do?
00401991   mov         ebp,esp
00401993   sub         esp,44h
00401996   push        ebx
00401997   push        esi
00401998   push        edi
00401999   push        ecx
0040199A   lea         edi,[ebp-44h]
0040199D   mov         ecx,11h
004019A2   mov         eax,0CCCCCCCCh
004019A7   rep stos    dword ptr [edi]
004019A9   pop         ecx
004019AA   mov         dword ptr [ebp-4],ecx
72:         return 3.141592653589793238462643383279502884197;
004019AD   fld         qword ptr [__real_at_8@4000c90fdaa22168c000 (00470110)]
<<<<<<<< pi in hex?
73:       }
004019B3   pop         edi

This doesn;t look optimal to me (but then Intel X86 code already looks
sub-optimal to me!)

I'm not sure how to look at the release version code - can you
share your investigations with us?

Thanks for applying your expertise to this.

Paul

PS What do other compilers do with this?

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
Mobile [phone]
mailto:pbristow_at_[hidden]