# Why are angles usually represented by floats in programming?

My idea is that, if an unsigned 32-bit integer is used for representing angles in a way that 0 is 0°, 231 is 180° and 232−1 is just under 360°, all possible values are used and evenly distributed among all angles. Rising large values would naturally overflow to 0, which corresponds to the equivalence of 360° and 0°. (Edit: 216 → 231; it's supposed to be a half of 232.)

Most language libraries and game engines that I used have goniometric functions for angles in radians as floats. If a 32-bit floating-point number is used for representing angles, not all of its range is used, and values just under 360° are less precise than values just over 0°. If an angle is increased beyond 360°, it needs to be explicitly wrapped below 360°.

What are some advantages of using floats for angles in radians? In other words, why isn't the whole range of integers used for representing angles more often?

• Because PI is not an integer, and therefore the number of radians in a circle is not an integer. See en.wikipedia.org/wiki/Radian. How would you interpret each value in an int in comparison to degrees or radians? Commented Oct 12, 2021 at 14:09
• The real-world things you're trying to simulate in the game are floats by nature. Time, distance, weight, probabilities... none of those are naturally integers. And if you're going to calculate everything as floats you might as well keep everything in float variables. Commented Oct 12, 2021 at 14:17
• The use of floating point is readily available almost everywhere. From built in types, built in math functions, to additional libraries, you can declare a float and use it. If you want to use integers for angles - either using fixed point instead of float, or defining a full circle in some new 32 bit wide unit - you need to create the code to handle all the math. Either converting from your ints to float (and possibly back), or rewriting from scratch things like trig functions, square roots, matrix math, etc. That would be a lot of effort to get code that will probably run slower. Commented Oct 12, 2021 at 14:27
• I feel that this is very much a computer science, not a software engineering question. So is probably off topic here. You'd likely get a much better answer at cs.stackexchange.com. Commented Oct 12, 2021 at 15:05
• But since you've asked it here, the short answer is because it's way faster to use floats than ints for angles as that most operations with angles involve lots of trig, which in turn requires lots of division and floating point division (even on basic integer-based hardware) is faster than integer-based division. For a 32 bit float. division involves dividing the 24 bit mantissa and a subtraction of the 8 bit exponent, which is quicker than dividing all 32 bits in the case of an int. Commented Oct 12, 2021 at 15:19

Why are angles usually represented by floats in programming?

Because floats are the best we have for this, out of the box.

My idea is that, if an unsigned 32-bit integer is used for representing angles in a way that 0 is 0°, 231 is 180° and 232−1 is just under 360°, all possible values are used and evenly distributed among all angles. Rising large values would naturally overflow to 0, which corresponds to the equivalence of 360° and 0°. (Edit: 216 → 231; it's supposed to be a half of 232.)

What you're doing is called fixed point arithmetic. You've simply chosen a scaling factor of 2π/232. It works. But using it is, well, work. It's not supported directly by typical hardware, languages, or libraries. Least none that I know. This means to use it with any of those you're going to be converting it. And once you convert it you lose much of what you were hoping to gain from it. Which frankly is only a few mantissa bits. If you want to work with it natively you'll have to stick with a subset of operations that still work natively.

What you lose is the ability to float your precision. Which might not be important to your applications but might be for the apps of others. This is why floating point won over fixed. Even when the number range only goes from 0-2π using floating point lets you express two numbers closer together then fixed point can with the same number of bits. And that might be useful even if you know that the number is expressing an angle.

Most language libraries and game engines that I used have goniometric functions for angles in radians as floats. If a 32-bit floating-point number is used for representing angles, not all of its range is used, and values just under 360° are less precise than values just over 0°. If an angle is increased beyond 360°, it needs to be explicitly wrapped below 360°.

That depends on the library. Some are happy to calculate sin(720°). If not, modular division lets you do it yourself.

Knowing that the number is an angle doesn't really help as much as you might think. You're just wrapping the number line around a circle. There are an infinite number of numbers between 0 and 2π, circle or no circle. You're not going to be able to express them all.

Fixed point's biggest advantage is that it's conceptually simple. Take every expressible number and place them evenly spaced over your number line.

Floating point doesn't insist on even spacing. By doing that it can put some expressible numbers closer together. The closer the numbers are to zero the closer together they are. Why? For the same reason you care about miles when planning a trip from city to city but not inches. But do care about inches when trying on shoes. At different scales, significance shifts. A floating point scheme takes that into account.

To visualize the difference here's a sketch. It starts out showing a fixed point scheme. Each expressible number (the dots) is evenly spaced. To move to a floating point scheme, the next line takes out every other dot and moves them close to zero. Same number of dots (because we're using the same number of bits) but now we have some numbers closer together. The third line simply continues the pattern.

0    .    .    .    .    .    .    .    .    .    .    .    .    .    .    .    1 Fixed
0..........         .         .         .         .         .         .         1
0____......                   .                   .                   .         1 Float

That seems weird because it is weird. But it lets us express very small numbers with very few bits without breaking the math that lets us work with them. Now sure, it also lets us express very large numbers that, for this, you don't care about. But it wasn't designed just for you.

Fixed point is conceptually simpler but less flexible. If someone told you computers can't do fractions in anything but floats they lied. But for computers designed to support fractions natively IEEE floats are the most popular, for good reason.

• This is a good answer but can I suggest rewording the section before the diagram? It's a little confusing. There are also so minor typos e.g. 'factions'. Commented Oct 13, 2021 at 15:32
• @JimmyJames better now? Commented Oct 13, 2021 at 16:15
• It's this sentence I am struggling with: "Then each line every other expressible number is lost and replaced with new ones on the left that are placed close together" I'd suggest an edit but I'm not sure I fully understand it. Commented Oct 13, 2021 at 16:21
• @JimmyJames how's this? Commented Oct 13, 2021 at 16:49
• @JimmyJames the cost comes at whatever "scale" you would have used had you stayed with fixed point. Bits gotta come from somewhere. But a fixed points imposed scale comes at the cost of effectively doing things like measuring the distance between cities in inches. Which, really, if you want to insist on doing things the fixed point way, you can just call the fixed distance a unit and count them using integers. Just have to convert it. Like counting pennies rather than dollars. Commented Oct 13, 2021 at 17:41

It is much more natural for angles to be in radians than degrees. For example, sin x ≈ x for small x, cos x ≈ 1 - x^2. Basically any calculation will involve multiplying by pi/180 first, so you will always waste time and a bit of precision.

And you seem to think that 390 degrees and 30 degrees are the same. They are not. Try turning your head to half that angle. You can’t distinguish +180 and -180 degrees. That’s a fatal failure.

You focused at what you can do and neglected to look at what you can’t do. Like dividing an angle into three equal parts.