Re: What is the meaning of an expression?

gah4 <gah4@u.washington.edu>
Wed, 19 Jan 2022 14:03:05 -0800 (PST)

          From comp.compilers

Related articles
[9 earlier articles]
Re: What is the meaning of an expression? 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2022-01-18)
Re: What is the meaning of an expression? gah4@u.washington.edu (gah4) (2022-01-18)
Re: What is the meaning of an expression? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-01-19)
Re: What is the meaning of an expression? 0xe2.0x9a.0x9b@gmail.com (Jan Ziak) (2022-01-19)
Re: What is the meaning of an expression? christopher.f.clark@compiler-resources.com (Christopher F Clark) (2022-01-19)
Re: What is the meaning of an expression? tkoenig@netcologne.de (Thomas Koenig) (2022-01-19)
Re: What is the meaning of an expression? gah4@u.washington.edu (gah4) (2022-01-19)
Re: What is the meaning of an expression? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2022-01-20)
Re: What is the meaning of an expression? tkoenig@netcologne.de (Thomas Koenig) (2022-01-22)
Re: What is the meaning of an expression? dave_thompson_2@comcast.net (2022-01-30)
Re: What is the meaning of an expression? johann@myrkraverk.invalid (Johann 'Myrkraverk' Oskarsson) (2022-02-03)
| List of all articles for this month |

From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Wed, 19 Jan 2022 14:03:05 -0800 (PST)
Organization: Compilers Central
References: <AdgJPKhi/NiNfECvRNaA6+4Wq/M8OQ==> 22-01-052 22-01-060 22-01-066 22-01-067 22-01-068 22-01-069 22-01-070
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="70369"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize
Posted-Date: 19 Jan 2022 18:32:54 EST
In-Reply-To: 22-01-070

(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.


Post a followup to this message

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