2

Please consider the following MWE:

\documentclass{article}

\begin{document}
\makeatletter
@tempdima9.5bp
\the@tempdima\
@tempdimb=1bp\relax
@tempdima9.5@tempdimb
\the@tempdima
\end{document}

which prints

9.53561pt
9.5355pt

Why is that?

Edit and follow-up question: is there a way to securely predict by how much such fixed point multiplications will be "unprecise"?

Lupino
  • 2,772

1 Answers1

4

Numerical calculations are never exact. TeX does fixed (not floating) point arithmetic, a dimen register is simply an integer interpreted in sp. This means that small values are stored with less relative accuracy.

It is easier to see with 10 rather than 9.5:

1. enter image description here

\documentclass{article}

\begin{document}
\makeatletter
@tempdima10bp
\the@tempdima


@tempdimb=1bp\relax
\phantom{0}\the@tempdimb


@tempdima10@tempdimb
\the@tempdima


\end{document}
David Carlisle
  • 757,742
  • Thanks for the reply. Is there a way to predict by "how much" it will be unprecise? Say, someone, who was not me, based all calculations on big points (e.g. \textheight as a multiple of \baselineskip) in the style of a well known publisher and my ungrateful job now is it to right that wrong while keeping the layout exactly as it was before. Would that be possible? – Lupino Nov 10 '22 at 07:49
  • 1
    the values you show are exactly equal for any reasonable purposes. it is fixed point arith to about 4 decimal places if expressed in pt so if you divide by 100 and multiply by 100 you will not in general get the same bits back exactly but if the difference is not measurable or observable then .. the size of a sheet of a4 is not cut to anything like this accuracy @Lupino – David Carlisle Nov 10 '22 at 07:57
  • 1
    @Lupino but if you want bitwise reproducibility you can still do that just do \newdimen\bigpoint \bigpoint=1bp then just replace \p@ by \bigpoint. the class is broken because it redefined \p@ not because it uses multiples of 1bp – David Carlisle Nov 10 '22 at 08:02
  • I'm aware that it was the \p@ "hack" that broke the package (among other things); my concern now, after i fixed that, is on how i can precicely reproduce the output the package produced before and after. On 4 out of 300 pages of my test document, the page breaks moved slightly, while everything else was (visually) the same as before. Narrowing it down, i noticed that inconstistency i described in the OP and which influenced the "final" value of \textheight. But thanks for the hint with the newdimen, i'll try that. – Lupino Nov 10 '22 at 08:24
  • 1
    @Lupino you could look at page settings in article there are some generic calculations to get reasonable values for a range of cases, but in compat mode, with cm fonts, the calculations are skipped and exactly the values used in latex2.09 are used. So here you can always ensure that at production journal options the \textwidth/\textheight are unchanged. – David Carlisle Nov 10 '22 at 10:55
  • 1
    @Lupino If you want to repair the class that uses \@=1bp, do \makeatletter\p@=1pt\makeatother and \usepackage[fontsize=10bp]{fontsize}. You may also require \RequirePackage{fix-cm} before \documentclass – egreg Nov 10 '22 at 11:06
  • @egreg it is a .sty-package, not a class. I managed to faithfully reproduce the previous output short of a single page where i have ~5sp more(!) space than before while everything else is identical, by using David's solution, plus a fork of \baselineskip set to 13bp spread though select occurences within the .sty. Since the publisher also changes the main font with the upcomming update, I will leave it at that. Thanks again for your help (and patience). – Lupino Nov 10 '22 at 15:14
  • @DavidCarlisle Defining all fontsizes in \bigpoint gives me "Package microtype Warning: Could not parse font size `9.5\bigpoint '" :/ guess i have use bp instead and live with the inconsistencies… – Lupino Nov 15 '22 at 08:37
  • @Lupino microtype could probably be fixed, make an example and ask about that? Just had a quick look at source you'd preumably just need to adjust \def\MT@get@size but an example would help – David Carlisle Nov 15 '22 at 09:14
  • @DavidCarlisle those are defined differently between various tl versions; i think it is not worth the effort. – Lupino Nov 15 '22 at 10:48
  • @Lupino I was assuming a bug report to microtype so it gets fixed there, once a good example made – David Carlisle Nov 15 '22 at 17:18