9

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.

Ruben
  • 13,448
Stefan Majewsky
  • 325
  • 1
    Backward compatibility. – topskip Dec 05 '11 at 12:43
  • How often do you really need floating point arithmetic when you do typesetting? – Seamus Dec 05 '11 at 12:50
  • Also, there is the 'Why?' issue: TeX is a typesetting system, and so accurate fp work is not exactly a high priority. (Okay, we do have an fp module for LaTeX3, but even there the main use for typesetting is doing trig calculations, which can be approximated reasonably well using integer mathematics.) – Joseph Wright Dec 05 '11 at 12:51
  • 3
    Personally, I would already be satisfied with 64bit integer arithmetic. – Martin Scharrer Dec 05 '11 at 12:53
  • 2
    @Seamus: All plots in my thesis are pgfplots-powered. That uses a lot floating point arithmetic. – Stefan Majewsky Dec 05 '11 at 13:19
  • 2
    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 05 '11 at 15:12
  • 3
    Contrary to the preceding comments, I can think of situations in which floating-point numbers would come in handy. See http://tex.stackexchange.com/questions/112599/perform-matrix-operations-addition-product-transpose-etc-in-latex, 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
  • Remark: TikZ can be configured to use Lua (and therefore IEEE-754) for floating point computation, see pgfmath - pgfplots: Strange Bump in \tanh Function - TeX - LaTeX Stack Exchange – user202729 Dec 11 '21 at 13:52

2 Answers2

10

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!)

Joseph Wright
  • 259,911
  • 34
  • 706
  • 1,036
6

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.

uli
  • 4,315