# Position not exact (0.999...)

hi,
this is my problem:

I have the following object hirarchy:
gameobject (x:1, y:-3)

• gameobject (x:0, y:0)
• gameobject (x:0 y:1)
• gameobject (x:-1 y:0)
• gameobject (x:0 y:0)
• gameobject (x:1 y:0)
z is always 0
(coordinates displayed in editor)

if I switch to game mode and print out the coordinates of the childs (gameobject.position),
one child is at x: 0.99999… and NOT at x: 1

how can I fix this?

There’s nothing to fix. It’s just floating point error and doesn’t matter.

Welcome to the forum!

That’s normal for floats, but if you really need an integer, you can just use Mathf.Round(float) which is handy when comparing practical values of things which are floats.

ok, thx for the anwers.

if this is normal I have to handle it.

Here’s an interesting fact not many know.

0.99999… = 1

It’s not ever so slightly less than 1. It IS equal to 1.

You can proove it with limits (calculus 101) but here’s the proof I like to use:

1 = 1 (check)

1/3 = 1/3 (check)

1/3 = 0.3333… (check)

3 * 1/3 = 3 * 0.3333… (check)

3/3 = 0.9999… (che…wait a second)

1 = 0.9999… (WTF…you’re right!!!)

When doing straight comparisons, it should be OK, but game programming rarely involves just simple 1:1 comparisons.

Unity is the only engine on the Planet that I own that has this floating point imprecision. Although you place an object at a specific coordinate, somehow it is off slightly but enough that if you are doing a calculation comparison you will need to assume a range +/- .00001~ give or take, I could name all of the engines I own or work with that are 1:1 comparison being equal but it is easier to name the only one that is not capable of this since there is exactly one of those. This gets incrementally worse the further from world origin you get, just an fyi.

I can tell you with almost complete certainty that you’re mistaken. Any game engine that works with values in floating-point format (and that means nearly all of them) suffers from floating-point imprecision. The only question is when, where, and how this imprecision will be made apparent to the user.

As for the behavior under discussion in this thread, my guess would be that there are some computations involved when working with game object transforms that introduce error in some cases. However, this is perfectly normal and is to be expected. Almost any time you’re comparing floating-point values, you have to take the possibility of numerical error into account. It may be that for whatever reason you’ve gotten lucky or haven’t stumbled across any problem areas in the other engines you’re using, but I assure you that they’re susceptible to floating-point error as well.

Yes, that’s exactly how floating-point representations behave (or at least the representations that are most commonly used). The nature of the representations is that precision decreases as magnitude increases, which is something you always have to take into consideration.

In short, there’s nothing unusual about Unity as far as floating-point imprecision goes.

++JesseAnders. If you’re using type float and expect exact matches in any environment, you’re in for a rude surprise sooner or later. jb143, way to go explaining that without complex math.

@jb143, I don’t see how that’s proving anything.

What you base your calculations on is wrong.

This is not check. It’s false. You can’t divide 1 into 3 equal pieces. For the three thirds of 1 to actually be equal to 1 they can’t all be similar because then you either have more than 1 or less than 1. You even show it yourself here: 3 * 0.3333 = 0.9999. This is not 1 and never will be. You can get as close as you want, but never reach 1 and any simple graph will show you that.

Also, this doesn’t actually have anything to do with the OP.

That’s not what he wrote. He wrote 0.33333… and 0.99999… Those “…” are there for an explicit mathematical reason. It’s true that it’s not directly related to the topic since in Unity you get .99999 and not .99999…, but it’s still interesting (something that’s infinitely close to 1 is 1).

–Eric

TwiiK, there’s a subtle but important distinction between what he wrote and what you wrote.

You: 3 * 0.3333
Him: 3 * 0.3333…

0.3333… is one way of saying that the 3s go on forever. Another way is to write 0.3 with a bar over the three.

It surprises me when I clone a gameobject from say 1,1,1 and its now 0.99999 etc. Why isn’t it an exactly match bit for bit of the original number?

Aren’t Doubles quicker for the CPU/GPU than Float?

I’m probably just spoilt… if I place a vertex at 0.0001um (microns) in my 3d package it doesn’t wander, ever!

Would have to see the Unity source code to be sure, but it’s probably due to some internal conversion process or transform that’s being applied to the position. (You didn’t specify under what circumstances this is occurring, so it’s hard to be more specific than that.)

As I said earlier, if an application uses a common floating-point representation, there’s always the potential for floating-point error; the only question is if and when you become aware of it.

I don’t know what application you’re using, but it might use doubles internally (whereas it’s much more common to use floats in games and game engines). Or, it might just be that you haven’t yet encountered a case where floating-point error becomes apparent. Or, it might be that the values are being rounded for display purposes.

Who knows - maybe there’s something that could be changed in the Unity source code that would make 1’s less likely to turn into .9999’s. Regardless, there’s always the potential for error where floating-point numbers are involved, and if the error doesn’t pop up in one place, it’s just going to pop up somewhere else. Better to accept it and get used to it, IMO.

I tend to see the numbers shift more from zero to .x ^ -n, where n is large, than I do for any other whole numbers.

I’ve never seen that happen for the position, and I don’t think it does. For rotations, yes, that does happen, because rotations are converted from euler angles to quaternions, then converted back to euler angles for display, and the conversion suffers a bit from that floating point imprecision.

No, at least not for the CPU, and they take up twice as much RAM.

–Eric

Happens to me all the time. Saving, hitting Play, who knows what, does it.

Hmm, how odd. I haven’t seen it happen and fooling around right now for a few minutes I can only get the rotation to do that, not the position.

–Eric

I know I’ve seen it happen with scale, but I can’t get it to happen with position either at the moment. (If it ever does happen with position though, I’d imagine the circumstances that lead to it might be hard to predict from the user’s point of view.)

It happens both at rotation and position, the problem is when importing other objects from things like Maya or 3D Max, I haven’t had the issues as much with blender, so what ever calculations are done from the import to location in the game seems to throw things off a tad bit, not enough to matter at times (except the bumped half meter ones at complete random) however if I recall back in the early 2.x days, there was some math changes done internally to speed up computations, prior to that change, I didn’t have as much of an issue when hitting play and seeing positions of objects shift even a micron in range, so this has shifted from 2.x into 3.x and will probably be an issue further into the future, how much or how little depends both on individual methods doing computations and internal math issues in Unity.