Dear Squad

[raziel420]

I know one of the "kracken" bugs is due to rounding errors in unity. I found an idle game that I've been playing for a few weeks, which involves some very very large numbers and is coded in Unity. Then I got to wondering, if they can keep numbers this large in unity, how, and would they be willing to share that information with Squad. The name of the game is AdVenture Capitalist, and it can be found here on Kongregate.

[stupid_chris]

I think it's important to note that rounding errors and using lage numers is /not/ the same thing. Handling large numbers can be easily done with scientific notation. Rounding errors are harder to control and are not necessarily related to large numbers.

Also the "kraken" has been fixed in 0.17, but for some reason tyhe community likes to blame every bug or weird error on it yet.

EDIT:

Also after a quick look at the game, if what you mean as large numbers is the price of some things and the money count, this is not the same thing at /all/. And also those numbers are pretty small compared to what KSP has to deal with okay it gets rather large, but thats still far from the same situation KSP has to deal with.

Edited August 10, 2014 by stupid_chris

[Ruedii]

I would say the original Kracken is 99.99% fixed. It only happens in extreme situations.

It also sometimes likes to play with ships in the distance, sending them spinning or smashing crashed-landed fuel tanks against the planet's surface. I think this could be fixed with a second pass of krackenbane that puts each major object that is more than 10m from any other object on it's own physics layer, with it's own kerckenbane reference.

Furthermore, by placing each non-associating object on it's own physics layer with it's own krackenbane base reference, the maximum distance for physics simulation could be greatly increased, allowing players to finally have their released stages properly parachute to the surface.

Edited August 12, 2014 by Ruedii
Moar elaboration

[technicalfool]

I would say the original Kracken is 99.99% fixed. It only happens in extreme situations.

Or 99.9999999997% on a Pentium 60?

And for future reference, a "rounding error" can happen in number systems other than binary. 10/3 would be an obvious example. Funnily enough, "10/3*3" on Windows calculator will give 10, even though 10/3 = 3.3333333333333333333333333333333, and if you take that number on its own and multiply by 3 you get 9.9999999999999999999999999999999. Someone somewhere programmed in a little attempt to "hide" that particular rounding error.

[vexx32]

Tech -- that's a bit of a flawed example anyway, since the base calculations would have to be done in binary in any case, no? But that's essentially what a lot of programming languages do -- they try to "hide" the little rounding errors that turn up, especially where floats are concerned.

[allmhuran]

Funnily enough, "10/3*3" on Windows calculator will give 10, even though 10/3 = 3.3333333333333333333333333333333, and if you take that number on its own and multiply by 3 you get 9.9999999999999999999999999999999. Someone somewhere programmed in a little attempt to "hide" that particular rounding error.

Unfortunately 10 / 3 * 3 is, in fact, exactly 10.

[technicalfool]

Unfortunately 10 / 3 * 3 is, in fact, exactly 10.

Thankyou for underlining my point?

[allmhuran]

What I'm saying is that there is no coding trickery necessary to get this result on a calculator, or need to "hide a rounding error". It's just doing exactly what it should do. Similarly 10/3 is indeed 3.3 repeating, and 3.3 repeating by 3 is of course 9.9 repeating (which is exactly 10). The calculator, not having an infinite display size for you to enter an infinite number of figures, nor an infinite amount of ram to store those figures, of course can't work with an infinitely repeating decimal. But it doesn't have to be able to, and it's not doing anything wrong when you multiply 3.33333333333 (non repeating) by 3 to get 9.99999999999 (non repeating)

Edited August 13, 2014 by allmhuran

[Kasuha]

The problem with KSP is not that double precision float is not precise enough for KSP purposes; it is. It is perfectly irrelevant whether your speed is 10 m/s or 9.99999999... . The real problem is that PhysX engine runs at single precision and nothing really can be done about it. That introduces errors that are orders of magnitude larger than rounding errors in double floats. Plus, there are still some errors in calculations that wait to be fixed and polished.

[Renegrade]

The real problem is that PhysX engine runs at single precision and nothing really can be done about it.

D:

Single precision is to deep space distances (even in the "tiny" kerbalverse) as -7 is to Pi.

Color me horrified. 64-bit engines with 24-bit mantissas. Nice. Oh well, I gues PhysX works well enough for bouncing giblets around a tiny room in an FPS..

(increasing the precision to double would only change '-7' to '4', however, unless care is taken)

[Red Iron Crown]

I thought the orbital mechanics were handled in double precision by custom code, PhysX was only used for the interactions inside the physics bubble.

[Master Tao]

That's right –

. Orbital mechanics are double precision. The custom code also moves the universe around the ship once it's 6 km above sea level (Krakensbane) and changes the universe's velocity instead of the ship over 750 m/s (speed Krakensbane).

You'd notice if the orbital mechanics weren't double precision and the other two fixes weren't there. Out at Jool's orbit, your ship could jump several kilometers every frame due to floating point precision errors.

[Eric S]

That may be the case. I know that in order to deal with the precision, things are done within a sliding window so that they can still maintain high precision within the window, but I don't know the details about how that's done.

[Dunbaratu]

Or 99.9999999997% on a Pentium 60?

And for future reference, a "rounding error" can happen in number systems other than binary. 10/3 would be an obvious example. Funnily enough, "10/3*3" on Windows calculator will give 10, even though 10/3 = 3.3333333333333333333333333333333, and if you take that number on its own and multiply by 3 you get 9.9999999999999999999999999999999. Someone somewhere programmed in a little attempt to "hide" that particular rounding error.

No such effort was necessary.

The rounding you're referring to is not a special case to handle this one situation. It's what it *always* does when the correct representation can't fit in the display, and with a value like 0.9999999999 ... etc forever, it *always* can't fit in the display because it's infinitely long. It's the act of rounding it to the nearest thing that will fit in the display that makes it show up as 1.0. It gets to the last digit it *can* display, and goes "okay, this digit is a 9. Do I round it up or down? Well, what's the next digit past the display... oh, it's a '9', that means I round this place up from a 9 to a 10, meaning a zero goes here and I carry the 1 back, it looks like carrying it back caused the previous digit to go from 9 to 10, so again, put a 0 here and carry the 1 back,..... and so on, propagating all the way back so it becomes 1.000000000 eventually.

There is no special case code to handle this situation and make it round to 1.0. Rounding *any* value that won't all fit in the display is always done, and that code gives you this "fix" for free without extra work.

[Renegrade]

I thought the orbital mechanics were handled in double precision by custom code, PhysX was only used for the interactions inside the physics bubble.

That's right –

. Orbital mechanics are double precision.

..Thank goodness.

That's an interesting video, I haven't seen that before. Thanks for the link.

The moving origin/frame of reference is not unlike a system I made a ways back for a 'trek'-like game...