# [Dev-luatex] A design philosophy question...

David Kastrup dak at gnu.org
Tue Apr 3 15:20:06 CEST 2007

```Hans Hagen <pragma at wxs.nl> writes:

> David Kastrup wrote:
>>
>> I have also filed this several months ago as a bug report to Bb, so
>> there is a minuscule chance of Knuth considering a fix upstream at the
>> end of the year.  I know that he has an aversion of changing anything
>> with such an impact, but then he wants TeX to become an epitaph, and
>> what kind of epitaph for the author of "The Art of Computing --
>> Seminumerical Algorithms" would it be if "1in" and "72.27pt" had
>> different values?
>>
> in a sense he's saying that a pt in tex is not really a pt (tex
> book) which means that 1in is not 72.27 pt;

No, as far as TeX is concerned, the ratio "in" is _exactly_ 72.27
times the ratio "pt".  And indeed, "100in" is exactly "7227pt".

But "1in" maps to a different value than "72.27pt".  Of course, one
inch (as opposed to a hundred of them) can't be represented exactly by
TeX's scaled numbers, so an approximation has to be picked.

The problem is that the approximations picked for "1in" and for
"72.27pt" are different.

In general, TeX will pick the lower enclosing approximation instead of
the closest one for numbers with units, unless the unit happens to be
"sp" or "pt".

> the problem is that in the tex book he mentions those two values (as
> he does with cm and in and such)
>
> i guess that you have a better change with filing a bug for the tex
> book: \eq should be \approx

No, the ratios _are_ exactly 100/7227.  But what TeX does with them
when it does not have an exact representation of the value resulting
from a "scaled" 15.16 value times a unit expressed as a fraction,
results in "1in" being unequal to "72.27pt" (neither exactly
representable), even though "100in" _are_ "7227pt" (both exactly
representable).

> dek could also say: use cm instead of in -)
>
> I think that the assumption is that one stays within a similar unit.

I think this analysis is not supported by the source code.

--
David Kastrup
```