Re: arithmetic design, was inlining + optimization = nuisance bugs (Christian Bau)
29 Sep 1998 16:05:28 -0400

          From comp.compilers

Related articles
Re: inlining + optimization = nuisance bugs Martin.Ward@SMLtd.Com (1998-09-26)
Re: arithmetic design, was inlining + optimization = nuisance bugs (1998-09-29)
| List of all articles for this month |

From: (Christian Bau)
Newsgroups: comp.compilers
Date: 29 Sep 1998 16:05:28 -0400
Organization: Insignia Solutions
References: 98-09-149
Keywords: arithmetic, design wrote:

> One of Knuth's (very few) mistakes in the implementation of TeX was
> the use of floating point for "glue" computations: he thought
> (correctly) that the tiny differences due to different precisions
> wouldn't affect the placement of items on a page. But one would
> really like the "trip test" to have just one correct result. Hence,
> floating point in TeX is a bad idea.

I think Donald Knuth made explicitly sure that all the major decisions
in TeX were based on integer arithmetic, so that every decision (like
page layout, line breaks etc. ) would be the same on any
implementation. The only thing where he uses floating point is to
determine the exact position where to place boxes and letters. And if
you compute that a letter should be 320.49987 pixels from the left of
the paper, it doesn't really matter where it appears, because both
positions are equally good. You can't have one "correct" result anyway,
because it depends on the printer resolution.

(There is an exception to this rule if it happens on the same machine:
Some layout system might do color separation by printing the same
thing four times; and then you want the same character to appear in
identical places each time. But that only means you need identical
results on the same machine, running the same software).

> On the other hand, if you can live with a "fuzzy" result (and if you
> are a numerical analyst, you _have_ to), then you should be able to
> live with a nondeterministically fuzzy result.

Well, page layout isn't numerical analysis :-)

To make this a bit more relevant to comp.compilers: If I write
floating point code, the exact requirements cannot be expressed very
well in C or C++. Sometimes I want the compiler to do exactly what I
wrote, sometimes I think the compiler should have more freedom and use
all tricks it knows to make my code faster.

Post a followup to this message

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