Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: gah4 Newsgroups: comp.compilers Subject: Re: What is the meaning of an expression? Date: Wed, 19 Jan 2022 14:03:05 -0800 (PST) Organization: Compilers Central Lines: 38 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <22-01-073@comp.compilers> References: <22-01-052@comp.compilers> <22-01-060@comp.compilers> <22-01-066@comp.compilers> <22-01-067@comp.compilers> <22-01-068@comp.compilers> <22-01-069@comp.compilers> <22-01-070@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <22-01-070@comp.compilers> Xref: csiph.com comp.compilers:2846 (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.