CVar numbers are wrong!

[Taehl]

My current project has CVars which allow server admins to apply multipliers to various aspects of the game. However, I've noticed something nasty: The CVars, when shown on the client, don't report the right numbers! For instance, 0.1 becomes 0.10000000149012 and 0.2 becomes 0.20000000298023.

What the hell? And, more importantly, what can I do to fix or work around it?

[Entoros]

Yeah, I've seen stuff like that happen. Just round it to the nearest tenth and you'll be fine.

There's probably an easier way or another function I can't find, but here's how I'd do it:

[lua]
function RoundDecimal(n,place)
local dec = string.Explode(".",n)[2]
if string.len(dec) > place then return n end

local ret = n
if string.Left(dec,place) == "5" then ret = ret + 0.5 * 10 ^ -place
else ret = tonumber(string.Left(dec,place)) + tonumber(dec[1]) end

return ret
end[/lua]

[Somer]

[lua]function math.decRound( nNumber, nPlace )
return math.Round( nNumber * 10^nPlace ) / 10^nPlace
end[/lua]

That's the best I could come up with.

[Taehl]

No idea why it happens, then? Oh well. It's good to know that it's not my fault, at least.

Here's my solution, rounding to three places:
[lua]n = math.floor( GetConVarNumber("whatever") * 1000 + 0.5 ) / 1000[/lua]

[Overv]

I'm pretty sure it has something to do with floating point arithmetic rounding errors. Nothing we can do anything about, except the rounding as shown above.

[Python1320]

It's related to the binary repersentation of floating points that gets transmitted over the network. Odd thing is that they should still be in sync with the same (mis)accuracy unless saved/transmitted differently.

Floating points are subject to this kind of "rounding errors" where we get "random garbage" in the end of after the decimal point.
Nothing we can do about it except, like Overv said, round it.

[url]http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems[/url]
"floating-point numbers achieve their greater range at the expense of precision"

PS: Welcome to the deeper, Lower, level of computing. It's like playing with quantum particles. You never know what happens until you've done it once, twice or more. Ok, not totally true but still ;)

[Gbps]

Yeah, it appears your CPU is overheating. That's usually the number one cause of floating point rounding.

[editline]05:01PM[/editline]

Download [url]http://files.extremeoverclocking.com/file.php?f=103[/url] and see if you pass it.

[andrewmcwatters]

[QUOTE=Gbps;19238670]Yeah, it appears your CPU is overheating. That's usually the number one cause of floating point errors.[/QUOTE]

Fascinating, I was never aware of such things, I would think that things these complex would have checks and balances.

[Gbps]

You'd be giving random numbers if someone said "Count to 1000" while putting a blowtorch on your butt.

[Taehl]

[QUOTE=Gbps;19238670]Yeah, it appears your CPU is overheating. That's usually the number one cause of floating point errors.[/QUOTE]
I pass. Hell, I'm not even overclocked right now. Might Gmod not being happy with my dual-core processor? I'm not aware if Source is built for such things or not...

[|FlapJack|]

I get floating point errors on my i7 laptop. Runs at 55 degrees... are you sure that's the problem?

[Gbps]

It's the problem when it happens to me. Dunno, just giving advice *shrugs*

[Taehl]

I feel it'd be overkill to make usermessage-sending concommands just to set a number in the exact same way one might set a CVar...

[Dr Magnusson]

Floating points aren't precise, and it has nothing to do with overheating.

It has to do with the way they are stored, and how the computer performs arithmetic on them. There's nothing you can do about it, except rounding like stated earlier.

You can read more about it here [url]http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems[/url]

[theJ89]

This is specifically a problem with sending the float over the network. Somewhere in the source engine (either on the transmitting end or on the receiving end) a few bits have been truncated from the float and the accuracy of the number has been affected. This specifically has been observed when sending floating point numbers from the server to the client. It's worth mentioning that the error only seems to affect the fractional accuracy. If your number doesn't have a decimal point, this error does not occur.

REPEAT: THIS IS NOT CAUSED BY YOUR PROCESSOR OVERHEATING.
You should be able to reproduce this error on any system. Every time you send a float "A" from the server, you will receive a float "B". In other words, sending A will always result in B, ignoring processor overheating.

[Gbps]

I didn't say it's the only thing that is causes floating point errors. It happens locally as well, it's not always a network issue.

[Deco Da Man]

[QUOTE=Gbps;19244570]I didn't say it's the only thing that is causes floating point errors. It happens locally as well, it's not always a network issue.[/QUOTE]

Processor overheating cannot cause it.
If it's hot enough to change a low bit, nothing is stopping it from changing a high bit.

[Gbps]

[QUOTE=Deco Da Man;19246921]Processor overheating cannot cause it.
If it's hot enough to change a low bit, nothing is stopping it from changing a high bit.[/QUOTE]

But it can round a floating point, is what I'm saying. The whole point of Prime95 is to check to see if any of your cores are rounding floating points.