Floating point considered harmful (for games) (a rant by 1vs)

Submitted by twovests in killallgames

I'm ANGERY and I have been for EVER SINCE I LEARNED ABOUT FLOATING POINTS

I'm going to assume you're familiar with floating points and their limitations. If you aren't, this video by Pannen explains them perfectly and belongs in every computer science curriculum for the rest of forever:

https://www.youtube.com/watch?v=9hdFG2GcNuA

I'm going to be short about my ANGERY.

If you walk far enough in Minecraft, floating point arithmetic starts to make movement wonky, far before you hit the far lands (int bounds) This doesn't bode a problem for most games. But they still suck!

Floating points suck because:

  1. They represent real limitations for games (not really, but let's pretend)
  2. They're more computationally expensive (also not a big deal at all)
  3. They're susceptible to flaws (different hardware might do different fast float maths - bad for speedruns, maybe? but also not a big deal at all)
  4. They're not even the right tool!

The right tool is the rarely-supported "fixed point" number.

In an ideal world, a fixed point number would work a lot like a floating point, except the precision is constant. Computationally, they'd work just the same as integers, with a little bit of overhead when using them in functions or with other datatypes. In terms of programming, working with them would be similar to working with floating points.

I had a long ramble on 1. The (small) problems with supporting them natively and 2. Why it sucks to work with them without native support. But I deleted it because it was long. Basically, support can and should be added to languages like C, C++, etc.! Else it'll be just Awful to work with them.

Other places we see floating points where fixed points could work just as well:

  • Normals (you're using a floating point for a number bounded -1 to 1! what a waste of floating points!)

  • Speed (and acceleration and any other values dealing with movement)

  • Angles/vector math (angles are bounded 0 to 360, or o to 2pi!! So many opportunities to take advantage of fixed point math for angles.)

  • Anything dealing with percentages (likely bounded 0 to 1, or 0 to 100.)

Places where you do see fixed point arithmetic IRL:

In the end none of this matters at all, but, i want to use fixed point arithmetics;;;

8

Comments

You must log in or register to comment.

voxpoplar wrote

All numbers in PICO-8 are fixed precision. Yet another reason all games should be made in PICO-8.

6

Moonside wrote

They represent real limitations for games (not really, but let's pretend)

They do, actually, if they're used for tracking time. If the game runs long enough (very possible in server-based online games), the physics increasingly start to go wonkier as the simulation becomes less and less fine-grained.

They're susceptible to flaws (different hardware might do different fast float maths - bad for speedruns, maybe? but also not a big deal at all)

It makes things more difficult for emulators, also in subtler ways like different kinds of conventions for rounding. I do wonder if these could be accounted for somehow, there are computations for which accuracy, reproducibility, making sense on a semantic level and so on are importanter than the pursuit of SPEED.

Other places we see floating points where fixed points could work just as well:

  • Anything dealing with percentages (likely bounded 0 to 1, or 0 to 100.)

I do wonder how well that actually works. While for probabilities it is always the case that for any event X, 0 ≤ P(X) ≤ 1, you can have steps in calculations that go out of these bounds. For example, 0 ≤ P(A∪B) = P(A) + P(B) - P(A∩B) ≤ 1, but if P(A) = P(B) = 1 then we'll have P(A∪B) = 1 + 1 - 1 = 2 - 1 = 1, where of course 2 > 1.

Also my shout out to humble rational numbers: the opportunities for using them are rare, too rare perhaps, but you feel clean like after having a bath when you do get to use them.

2

twovests OP wrote

I never even considered time in a server or the whole mess of floats in emulators. I hope to dink nobody is using floats for time.

I also haven't considered about probabilities getting outside the bound of 1, but I still reserve my right to be angery at floats here. grrr floats.

I also have not considered rational numbers, because, wow, they sound very satisfying, and also even less supported, and I want to be their friends, where can I use them,

1

Moonside wrote (edited )

I actually first stumbled into rational number data type when I was 12 or 13 and learning Lisp (but that story didn't end well and which totally gave me a misleading view of how principled programming languages were). I think all the major functional languages have them as it's not hard to implement as an abstract data type. A super basic is just a product type of two integers and call one the numerator and the other denominator and implement the operations accordingly.

Even Coq has them and if Coq has something implemented, it's probably pretty widespread in Haskell, Standard ML, OCaml, Scala and various Lisps and what have you.

If you really want some numeric nonsense:

  1. Bad implementations of complex numbers. The rectangular form a + bi is good for sums and re^(iθ) for multiplications. Ideally there should be one type for complex numbers and two classes like data Complex = Rectangular a b | Polar r θ in Haskell. This works ok if there are sum types, but apparently this is too avant garde for most languages.
  2. The Haskell numeric tower makes zero sense and is implemented with type classes, which isn't first class and is antimodular to the extent I recommend beginners only use library defined ones and not make your own like at all for a while at least. Like the Num class for numbers: you need to implement the operations (+), (*), abs, signum, fromInteger, (-) where abs and signum are total party poopers as basically what Num is is a mathematical ring with an extra operation. But, for example, complex numbers don't have a notion of absolute value defined for them so this turns sour quickly. I don't know what would make the situation better, however. They'll never fix this, probably.

Also if you want to read a rant about Booleans... this is pretty good. Every time I'm writing a function that takes a boolean parameter, I split it in two functions or somehow avoid testing for equality in the function. Thus pattern matching is bae and matching constructors is heaven sent. The author's piece on why dynamic languages aren't a thing at all is good too.

Phew, I'm glad that I got all that out of my system!

3

twovests OP wrote

Ooh I'm actually learning StandardML for a course of mine! I'll have to read these blog posts later too, I luv rants and I luv booleans so I'll probably love this

2