Re: arithmetic design, was inlining + optimization = nuisance bugs

Martin.Ward@smltd.com 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.
--

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