Re: [boost] Math constants - Some suggested constants

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2001-11-08 15:12:19

"Paul A. Bristow" wrote:
> 
> Sadly, in order to get the precision offered by the constants
> I have proposed, compiler writer are going to have to use
> some similar high precision floating-point software .
> (Even Intel IA-64 is not going to have the hardware to do it yet).
> 
> High precision floating-point software is quite widely available,
> but making compilers use it sounds a major task,
> and would have a sigificantly reduce compile speed,
> so it is unlikely to be a priority.

Not being a compiler writer, I'm certainly talking out of line, but: 
that hard part of implementing the types of optimizations we were
talking about is NOT, it seems to me, in integrating the high quality,
high precision floating point software that is already freely
available.   Most of these libraries are written in C, as are the
compilers, and adapting the code into the compiler codebase is a
relatively "trivial" exercise (even I could do that part  :-)   No, I
think the hard part is getting the optimizer to be able to figure out
WHEN to call the high precision code (at least, that would be the tough
part for me), although it is already done in many cases of expressions
of integral type.  This is something that is certainly beyond my ability
to do at the present time, as I don't have the background and training
in writing compilers that would be necessary to implement that
functionality.  

As to the compilation speed: I agree, it would negatively impact compile
speed, but like all optional optimizations, they could be turned on and
off by compiler options; if I'm really needing speed and precision at
runtime, I'm going to be willing to pay for it at compile time (if I can
save two or three hours/days/weeks of runtime, I'll be willing to pay a
few minutes/hours of compilation time).  When compared to the extra
compile time engendered by cross-module and other global optimizations,
I doubt that the extra time necessary to compute high precision results
will necessarily be that large in comparison (after all, the
high-precision library code for all of the standard library math
functions would already be compiled into the compiler, and those are the
only functions where it would be reasonable to expect the standard to
advocate constant expression, machine precision, compile time evaluation
optimizations.  Advocating such optimizations on arbitrary functions
would be much more difficult, controversial, and might even require
extensions to the language in order to allow the programmer to let the
compiler know WHICH functions have no side effects and can be statically
evaluated at compile time.... hmmm, I'll have to think about that. 
There are some interesting possibilities there....)

> 
> (Nor should we be making this a priority for compiler writers -
>  we have yet to get any compiler to meet the standard!)
> 

And I too would like them to get there (forward to full compliance!);
but I don't think that desiring new and better optimizations will
detract from getting to standards compliance: many compilers are very
very close to full _language_ compliance (if not library compliance,
which is a much trickier issue), and in many of the shops that produce
compiler/library sets, the two are produced by different groups of
engineers.  And many of these optimizations that AREN'T currently done
by C compilers in numerical computations are well understood and
implemented in most Fortran compilers already ... desiring or expecting
to see them in C++ compilers is not unreasonable, I don't think.

> The proposed constants will never become wrong,
> though they may become unfashionable when
> compilers can do the optimisations you suggest.
> 

I certainly agree with these statements.

> But many people need accurate constants NOW.
> 

I agree with that as well, but I also think that it is important (as
other people have tried to point out in this thread) that one look to
the future when considering where to set the bar on a constants library:
how it is organized, the interface (both the API AND the non-language
interface described by the documentation which must be enforced by the
user (eg. you lose the benefits of the precision if you use any constant
in an expression that does more that +-*/ )) etc. etc.  The
implementation itself is, really, of secondary concern: broken
implementations can be fixed, but broken interfaces are forever (just
look at BLAS or the NAG libraries - the C interface is STILL stuck with
the circa 1960s Fortran interface, and always will be)

> Paul
> 

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	 [phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-565
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://physics.bu.edu/~krlynch
-------------------------------------------------------------------------------