10

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.

|improve this question
  • 1
    There is an FPU driver, but it is not always available. pgfmath for example has both FPU and non-FPU versions. In any case, fixed point calculations are faster than floating point calculations. The big problem is converting from text to numbers and back again. – John Kormylo Jul 27 '17 at 3:37
  • 1
    Relevant: tug.org/TUGboat/tb28-3/tb90beebe.pdf – user4686 Jul 28 '17 at 9:46
11

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.

|improve this answer
  • 1
    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? – AlexG Jul 27 '17 at 8:10
  • 2
    @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.) – Joseph Wright♦ Jul 27 '17 at 8:16
  • 1
    @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.). – Joseph Wright♦ Jul 27 '17 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? – Daniel Jul 29 '17 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). – Blaisorblade Jul 30 '17 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.