I understand that, at the time when TeX was devised, no single standard for floating point calculations was available. But, these days there is IEEE 754. Why doesn't any TeX variant support it?

Granted, there's LuaTeX, but IEEE 754 was popular long before that, so the question is justified.

  • 1
    Backward compatibility.
    – topskip
    Dec 5 '11 at 12:43
  • 3
    Personally, I would already be satisfied with 64bit integer arithmetic. Dec 5 '11 at 12:53
  • 2
    @Seamus: All plots in my thesis are pgfplots-powered. That uses a lot floating point arithmetic. Dec 5 '11 at 13:19
  • 1
    When you consider the thinness and preciseness of lines a printer is capable of, coupled to the absorptive properties of paper diffusing the ink (or blurring of toner prior to laser treatment etc.), not to mention the resolution of the human eye, you should be satisfied with pgfplots and 64bit integers at @MartinScharrer says. ;)
    – qubyte
    Dec 5 '11 at 15:12
  • 2
    Contrary to the preceding comments, I can think of situations in which floating-point numbers would come in handy. See tex.stackexchange.com/questions/112599/…, for instance. Note that Bruno Le Floch and the rest of the LaTeX3 team have plans to make LaTeX3 compliant with IEEE-754-2008.
    – jub0bs
    May 31 '13 at 22:48

Answering such a question is difficult as records for 'Why no' are usually less easy to come by than for 'Why'. However, we can reconstruct a reasonable chain of events.

Knuth wrote TeX to solve a specific problem: typesetting The Art of Computer Programming. Whilst he did make TeX Turing-complete, his model for creating documents is very much that the TeX input is close to the typesetting: looking at the source for The TeXbook for example it is clear that there is an approach having information 'resolved'. Knuth's use cases are also largely not those that might use things like an FPU. It's not surprising, therefore, that he has not extended TeX in this area.

(This is as good a point as any to mention back-compatibility. Adding new primitives always has the potential to break something, as some user will doubtless have defined say \fpexpr themselves. However, the bigger risk in an archive-stable produce like TeX90 is that any change might bring in new bugs elsewhere: 'if it ain't broke, don't fix it' being a guiding idea.)

Engine developers post-Knuth have all had particular issues they've been interested in. Crucially, these tend to be problems that we can't easily solve outside of the typesetting itself. Floating point work doesn't really fall within that scope: for any 'serious' stuff, one might reasonably expect to pre-process in a specialist tool anyway.

If we look at major efforts in engine development, we can see that adding an FPU as a specific aim has been unlikely. Taking the ideas in roughly chronological order

  • e-TeX adds ideas that are very general in supporting TeX programming (\protected, new register ranges, etc.) which build on existing ideas in TeX90. Crucially here, whilst \numexpr and so on were added, they provide a few operators (+, -, *, /, (, )), with only parentheses not mapping directly to existing primitives. An FPU has to cover a lot more
  • e-TeX also adds code that is 'close' to typesetting, for example extending widow/orphan control to multiple lines, adding \middle, etc.: all very much remote from needed FPU support
  • pdfTeX added direct PDF output, and whilst is also includes various utility additions most of those are trivial exposures of idea from support libraries (e.g. elapsed time)
  • XeTeX (and previous projects) extends TeX to support Unicode: focussed on character range, and includes ideas for dealing with a range of scripts
  • XeTeX also adds support for system fonts: again, no link to FPU work
  • LuaTeX does the above and exposes the internals of TeX using Lua: adding an FPU is a consequence of integrating the latter but is not a major driver of these efforts

Overall, therefore, we can see that for people actually doing the engine work there has been no obvious place to add an FPU prior to LuaTeX. Moreover, there has been little push from the user community. One can do a range of approximate operations in macros, for example see the trig package, which will enable support for floats for general typesetting. Doing more complex work tends to be best viewed as the job of a specialist tool: typesetting good-looking results is great, but if you want to do more analysis you probably need an interactive approach. Packages such as pgfplots do make it more easy to use TeX for this type of work (it's my workflow), but out of the range of complex typesetting challenges one might point to, FPU support is pretty niche.

(I think it is also worth noting that implementing a full range of FP functions without some library support would be non-trivial: I speak from experience in l3fp work. The attraction of this work is likely to be low to engine development experts: doing it in the macro layer is an interesting intellectual challenge!)

  • As comments on the question say, an IEEE 754 FPU can be handy, but that's not the same as vital.
    – Joseph Wright
    Jul 27 '17 at 8:43
  • may i note that luatex does not guarantee backward compatibility. Jul 28 '17 at 0:38

It boils down to killing the holy cow of backward compatibility, best explained by Donald Knuth himself in the video on The importance of stability for TeX.

  • 1
    I think not only that, it is also not a trivial task (seeing the amount of work to add fp calculations to metapost) for no apparent gain. Dec 5 '11 at 13:07
  • How does adding new features kill backwards compatibility? The only issue I see is name clashes. Dec 5 '11 at 13:18
  • 1
    @KhaledHosny High accuracy was not needed for Metafont, because it produces bitmaps. For Metapost it's different.
    – egreg
    Dec 5 '11 at 13:29
  • @Stefan true, my thought was that one would replaced the other. Is creeping featurism an issue?
    – uli
    Dec 5 '11 at 13:32
  • 1
    @egreg: "no apparent gain" was in reference to TeX not MetaPost. Dec 5 '11 at 15:32

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.