Re: The precision of LaTeX's length.

Jonathan Fine <J.Fine@xxxxxxxxxx> writes:

Andrew Moschou wrote:
Curiosity: 1in = 72.27pt, but TeX calculates:
1in = 4736286sp
72.27pt = 4736287sp (closer to the correct real result)
10in and 722.7pt get the same 47362867sp.

Apparently, that bug was reported to Knuth, but it won't be fixed in
future versions of TeX, so any old documents will continue to remain
the same.

In The TeXbook, Knuth wrote: The units have been defined here so that
precise conversion to sp is efficient on a wide variety of
machines. In order to achieve this, TeX's "pt" has been made slightly
larger than the official printer's point. [...] the "error" is
essentially one part in 10^8. This is more than two orders of
magnitude less than the maount by which the inch itself changed in
1959, when it shrank to 2.54cm from its former value of (1/0.3837)cm;
so there is no point worrying about the difference.

From this, it seems that Knuth never regarded as a bug.

The TeXbook was written before the bug report. I suggest that you refer
to Knuth's specific notes regarding the reports instead. There is no
necessity to extrapolate from completely unrelated writings.

To wit, <URL:http://www.tug.org/TUGboat/Articles/tb29-2/tb92knut.pdf>

Any object of
nontrivial complexity is non-optimum, in the sense
that it can be improved in some way (while still
remaining non-optimum); therefore there's always
a reason to change anything that isn't trivial. But
one of TEX's principal advantages is the fact that
it does not change --- except for serious flaws whose
correction is unlikely to affect more than a very tiny
number of archival documents.
Let me give two examples. First, David Kastrup
observes that TEX doesn't do the best possible rounding
when it converts units. One inch is
exactly 72.27 points, which is exactly 4736286.72
scaled points. When you say `1in', TEX converts it
to 4736286sp; when you say `72.27pt', TEX converts
it to 4736287sp, which is about 23.6° Angstrom units
closer to the truth. With a simple change to TEX
§458, namely to add `denom div 2' before dividing
by `denom', the rounding would be slightly better.
But that would invalidate the line-break and page-
break decisions of an enormous number of documents.
It's unthinkable to change TEX in such a way today.


--
David Kastrup
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
.

Relevant Pages

  • Re: Python syntax in Lisp and Scheme
    ... He should have used Lisp. ... Given that TeX is one of the more successful applications out there, ... Another point for you to ponder: that Knuth of questionable ... Could you afford to pay $327.68 for every bug found in your glorious ...
    (comp.lang.python)
  • Re: Isnt Texlive awful?
    ... was one of the most attractive features of TeX. ... which was forced on Knuth by the memory limitations of the time. ... You have given no examples of this supposed idiosyncracy. ...
    (comp.text.tex)
  • Re: beamer wrapfig bug
    ... did you ever submit a bug report? ... I still think it is a minor bug in TeX's paragraph building. ... As I recall from investigating then, TeX alters its line-breaking ...
    (comp.text.tex)
  • Re: Isnt Texlive awful?
    ... I didn't say anything about the maintainability of TeX's code base. ... with the TeX code base was not working out. ... which was forced on Knuth by the memory limitations of the time. ...
    (comp.text.tex)
  • Re: [opensuse] Re: Separate /usr?
    ... not for those puny differences in file ... the first real opensource program was and is TeX. ... % This program is copyright 1982 by D. E. Knuth; ... A bit of scripting and generating LaTeX magic on my ...
    (SuSE)