# How is floating-point arithmetic implemented in TeX

The TeXbook says that TeX only uses fixed-point arithmetic/integer arithmetic with very small units (essentially the same thing for our purposes). Why do modern TeX variants not support floating point arithmetic? also says no TeX variant supports floating-point. But a number of packages (including TikZ) do use FP. Is FP implemented in terms of macro-expansion and integer arithmetic?

I have already learned that real floating-point arithmetic can be used through LuaTeX, and that this can be faster for heavy use of FP, so the answer seems pretty clear—but it'd be nice to have a straight answer.

Motivation: This question arose in the context of Tips for choosing hardware for best LaTeX compile performance (specifically, this comment). Concretely, this suggests that FP performance is not so important for TeX users, if they use LuaTeX and packages optimized for it.

At the primitive level, TeX (other than LuaTeX) doesn't provide any support for floating point calculations. We have count and dimen registers which are (somewhat) convenient for implementing higher-level floating point code. The latter can look like floating points as the usual representation (in `pt`) does include a decimal part. However, these are actually implemented by working in integer values: scaled points (`sp`).

Depending on the accuracy desired, reasonable results can be obtained by using `dimen` registers and stripping off the units. However, as the accuracy (5 dp) and range are limited, this is best for work where speed is of the essence. A lot of more 'classical' TeX work with floats is done that way as on older systems the speed gain was vital for the code to be usable.

The alternative is to code everything in integers and handle the conversions at the macro level. With e-TeX we can use `\numexpr`, which offers some speed and clarity gain and allows expandable working. (One could do everything expandably in TeX90 by doing all of the maths in the macro layer: various packages implement such approaches, for example `bigintcalc`.)

The key to notice here is that the performance is independent of the system they are running on: everything is going via the same integer-internal code. (The very small amount of system-dependent float code in TeX90 is not accessible to users.)

In terms of use of floats, most older LaTeX packages simply don't, or use non-expandable routes via dimens (see `trig` for example, used to rotate graphics). The `fp` package is perhaps the longest-standing implementation in macros of a more accurate approach, though it is not that heavily used by packages. Newer code, written for more powerful systems, will make greater use of macro-based floats. The obvious example is TikZ, which again uses the dimen-based method as-standard (though does have a more complex FPU too). The `expl3` language includes an expandable FPU (again written in macros), and it is gaining usage: it is slower than a dimen-based approach but for the use cases it has been applied to thus-far this has not been a major issue. (Performance here is also better on some parts of parsing, etc., so is roughly comparable to the TikZ code across a range of operations, and gains a lot of precision: see known benchmarks for floating point calculations?.)

As noted in the question, for very heavy float use, TeX is not the best tool and one should consider either LuaTeX or pre-processing in other ways.

• Is there a canonical way of transforming FP into integer arithmetic which served as a model for implementing `fp` and `l3fp`? Or was it invented by the package authors? Jul 27, 2017 at 8:10
• @AlexG Some parts are well-established, for example algorithms for working out the results of transcendental functions (range reduction, approximation for small values, Taylor series, etc.). Other parts have to be worked out to fit into what TeX provides, e.g. the range limits on integer values, and in the case of `l3fp` to pass everything by expansion. (`fp` provided some ideas early on but is non-expandable.) Jul 27, 2017 at 8:16
• @AlexG Perhaps also worth noting that `fp` does fixed point calculations, whereas `l3fp` does floating ones (though internally there is fixed-point code for trig, etc.). Jul 27, 2017 at 8:20
• Great answer with all this technical and historical background! Maybe you could comment a bit further on how exactly things change with LuaTeX (for those people who are bugged by long compilation times)? AFAIU, also with LuaLaTeX the TeX primitives are still integer-only, it is just that packages writers could escape to Lua for real FP calculations. Do `expl3` or `pgfmath` or any of the other packages exploit this? Are there any packages that offer a significant performance gain when compiling with `lualatex` instead of `pdflatex`? Jul 29, 2017 at 8:27
• @Daniel In case you haven't seen, links in the OP answer "yes" to most of your questions— tex.stackexchange.com/questions/15526/… tex.stackexchange.com/questions/261472/…. Not sure `expl3` does this (yet), the answer seems to suggest not. (If you know, maybe you can edit question/answer). Jul 30, 2017 at 20:28