TeX does not include any ‘native’ support for floating point calculations, but that has not stopped lots of (La)TeX users wanting to do sums (and more complicated things) in their document. As TeX is Turing complete, it’s not a surprise that there are several ways to implement calculations. For end users, the differences between these are not important: what is key is what to use. Here, I’ll give a bit of background, look at the various possibilities, then move on to give a recommendation.


When Knuth wrote TeX, he had one aim in mind: high-quality typesetting. He also wanted to have sources which were truly portable between different systems. At the time, there was no standard for specifying how floating point operations should be handled at the hardware level: as such, no floating point operations were system-independent.

Knuth decided that TeX would provide no user access to anything dependent on platform-specific floating-point operations. That means that the TeX functions that look like floats (in particular dimen work) actually use integer arithmetic and convert ‘at the last minute’.

Technical considerations

There are two basic approaches to setting up floating point systems in TeX: either use dimensions or doing everything in integer arithmetic.

Using dimensions, the input range is limited and the output has restricted accuracy. But on the other hand, many calculations are quite short and they are fast. On the other hand, if everything is coded in integer arithmetic, the programmer can control the accuracy completely, at the cost of speed.

Although it’s not an absolute requirement, e-TeX does make doing things a bit easier: rather than having to shuffle everything a piece at a time, it is possible to use inline expressions for quite a lot of the work.

Another key technical aspect is expandability. This is useful for some aspects of TeX work, particularly anywhere that it ‘expects a number’: only expansion is allowed in such places.

One other thing to consider is handling of TeX registers as numbers. Converting for example a length into something that can be used in a floating point calculation is handy, and it matches what e-TeX does in for example \numexpr. But in macro code it has to be programmed in.


The other thing to think about here is functionality: what is and isn’t needed in terms of mathematics. Doing straight-forward arithmetic is obviously easier than working out trigonometry, logarithms, etc. What exactly you need depends on the use case, but obviously more functionality is always better.

(Package) options

For simple work using the dimen approach is convenient and fast: it takes only a small amount of work to set up stripping off the pt part. I’m writing here for people who don’t want to delve into TeX innards, so let’s assume a pre-packaged solution is what is required.

There are lots of possible solutions on CTAN which cover some or all of the above. I don’t want to get into a ‘big list’, so I’ll simply note here that the following are available:

Some of these have variable or arbitrary precision, others work to a pre-determined level, and they also vary in terms of functions covered, expandability and so on.

I want to focus in on three possible ‘contenders’: fp, pgf and the LaTeX3 FPU. The fp package formally uses fixed not floating point code, but the key for us here is that it allows a wide range of high-precision calculations. It’s also been around for a long time. However, it’s quite slow and doesn’t have convenient expression parsing (it does reverse Polish).

On the flip side, the mathematics engine in pgf uses dimens internally, so it is (relatively) fast but is limited in accuracy. The range limits also show up in some unexpected places, as a lot of range reduction is needed to make everything work. On the other hand, \pgfmathparse does read ‘normal’ mathematical expressions, so it’s pretty easy to use.

The LaTeX3 FPU is part of expl3, but is available nowadays as a document-level package xfp. In contrast to both fp and the pgf approach, the LaTeX3 FPU is expandable. Like pgf, using the FPU means we can use expressions, and we also get reasonable performance (Bruno Le Floch worked hard on this aspect). The other thing to note is that the FPU is intended to match behaviour specified in the decimal IEEE 754 standard, and that the team have a set of tests to try to make sure things work as expected.

There’s one other option that one must consider: Lua. If you address only using LuaTeX, you can happily break out into Lua and use its ability to use the ‘real’ floating point capabilities of a modern PC. The one wrinkle is that without a bit of work, the Lua code doesn’t know about TeX material: registers and so on need to be pre-processed. It also goes without saying that using Lua means being tied to LuaTeX!


As you can see above, there are several options. However, for end users wanting to do calculations in documents I think there is a clear best choice: the LaTeX3 FPU.

\fpeval{round(sqrt(2) * sind(40),2)}

You’d probably expect me to say that: I am on the LaTeX team. But that’s not the reason. Instead, it’s that the FPU is almost as fast as using dimens (see pgf benchmarking), but offers the same accuracy as a typical GUI application for maths. It also integrates into normal LaTeX conventions with no user effort.