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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-23 11:16:44

From: Paul A. Bristow <boost_at_[hidden]>
> > 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:       {

To allow for debugging, the compiler has not inlined this function, and
has provided a complete stack frame, where ebp is the base pointer and
esp is the stack pointer.

> 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]
> 
> 
> 
> 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/ 
> 
> 
>