And the log output is this:
ScaleX: 0.8, Wall offset: 0.09999999
Needles to say that division is incorrect and wall offset should be returned as (1 - 0.8) / 2 = 0.1. So why does it now work properly? This is really messing up my player controls, since it’s throwing player off course incrementally.
Also it’s not any different in any version of Unity; floating point is floating point and always works the same. Any apparent differences you might have gotten before would have been due to printing out a rounded version of the number rather than the actual number. (Which is a solution by the way; just round the number.)
Well, I’m doing a game in which the player can move only in 4 directions and only in a grid (dimensions 1x1), so that difference matters when bumping in obstacles. I already found a workaround by not using division. I was just wondering why it is so, because I’ve never seen that kind of a behavior and I’ve been a programmer for 10 years now.
In Unity 5.4 I’ve used the same piece of code with no differences and it never returned that kind of result, so something must be different in game engine. Never used rounding either.
Don’t design a character controller that requires 7 decibels of precision. For instance ff you’re on a stepped grid based system, get the direction and find the nearest node in that direction then assign that nodes position as the goal.
now think of that in decimal notation.
0.3333 + 0.3333 + 0.3333 = 0.9999
intuitively you know its actually 1.0 but theres only so many digits you can write out.
computers don’t have that same intuition they see 0.3333 and see it as 0.3333 and not 1/3 (granted they see it in binary not decimal but the concept is the same).
The reason why you weren’t getting it before could very well be because you may have been using a local scale that made it cleanly divisible in binary. like (1 - 0.5f) / 2f returns a clean number of 0.25f, or in binary 0.01
Edit: FYI 0.2f in binary is 0.000110011001100110011 (repeating 0011 infinitely)
No. I tried it in Unity 5.4 and it gets the exact same result, as expected. It’s about the way floating point works in computers, which is independent of the game engine.
I’m betting something else changed. Either the numbers you were using or the way the string was formatted. Float division is fairly fundamental, and no one has changed it in decades.
Occasionally something like Mathf changes. There was a switch a couple years back where some casts to and from double were removed. This had the effect of speeding up the operation slightly at the cost of precision.