Re: What is the meaning of an expression?

(snip, I wrote)
> > > So, back to anthropomorphic computers and logical
> > > inconsistencies. How good are compilers, especially ones
> > > that evaluate constant expressions at compile time, at
> > > dealing with logic failure?


(snip)
> An analogy: There exist two kinds of compression algorithms: lossy and
> lossless. Similarly, there exist two kinds of optimization algorithms. If it
> is a lossless optimization algorithm, then any kind of difference between
> compile-time evaluation and run-time evaluation is a software bug in the
> optimizer. If it is a lossy optimization algorithm, then it should be
> sufficiently clearly specified what kind of information is permitted to be
> lost during the optimization process.


I find the other way around more interesting.


There is a popular Fortran compiler that uses an high precision arithmetic
package to evaluate constant expressions. As I understand it, it will
accurately calculate sin(1e100). At run time, though, you only have
normal machine precision.


In most science/engineering problems, data has an uncertainty, and
floating point well represents data with a relative uncertainty. There
is no reasonable answer to sin(x) when x has an uncertainty
of more than 2*pi. (There is an extremely small branch of mathematics
where problems like this might occur. But never in physics or engineering.)


But in any case, calculating constant expressions more accurately
(or less accurately) means that they won't be equal to the same thing
calculated at run time. (Now, people are supposed to know not to
compare floating point values for equality, but it is still surprising.)


Early Fortran didn't have constant expressions, so any such evaluation
was optional optimization. More recent versions do, though, so there
are some things that the compiler is required to evaluate at compile time.


I believe that there are cases equivalent to the mentioned C++ cases.

Return to the comp.compilers page.
Search the comp.compilers archives again.