ZScript's single-precision float type should be dealt with

phantombeta · Post by **phantombeta** » Thu Jan 31, 2019 7:27 am

Basically, the 32-bit floating-point type is janky as hell. It barely works - the VM can't actually do single-precision FP arithmetic, so the only purpose of it is to export a few classes from the C++ side and introduce some nasty glitches (specially in MP) due to FP round-off issues.
There's really two ways to solve this - either implement it properly, or change the few places where it's needed to be double-precision instead and turn "float" into an alias for "double".

This isn't really the best place to put this, but I have no idea where else it could go - it's not a feature suggestion, and it's not a bug report.

Post by **Major Cooke** » Thu Jan 31, 2019 9:31 am

I agree. It kinda gives the wrong impression too, which is just convoluted as all hell.

It's just a shame that it was introduced as a 'float' in DECORATE.

Post by **Graf Zahl** » Fri Feb 01, 2019 1:48 am

The only purpose of it is to define structs or arrays with it. The last time I proposed removing the shorter types (int 8, int 16, float32) there was some vocal opposition that this would be detrimental to their space saving efforts.

Also, what's the problems? All internal math is done as doubles, when a single precision float is read it is immediately converted to a double, only when written back it is as a float again. so it's hard to see how this can cause desyncs. The code should be the same for everyone so the round-off glitches should also be the same, unless some compilers screw this up.

That said, I have no problem removing all support for this type except for declaring native class members, and I think I can also remove the small number that still exist.

phantombeta · Post by **phantombeta** » Fri Feb 01, 2019 3:31 am

Graf Zahl wrote:Also, what's the problems? All internal math is done as doubles, when a single precision float is read it is immediately converted to a double, only when written back it is as a float again. so it's hard to see how this can cause desyncs. The code should be the same for everyone so the round-off glitches should also be the same, unless some compilers screw this up.

Basically, not all processors do floating-point arithmetic in the exact same way, due to differences in how they're designed. While this is fine for most cases, this is horrible for things that need to be perfectly synchronized to work - the amount of FP error will be very slightly different, and it will also slowly build up. With client/server, this probably wouldn't matter too much, but I'm fairly sure it does matter a lot with P2P.
This is specially true between different architectures.

Post by **Graf Zahl** » Fri Feb 01, 2019 12:46 pm

Any IEEE conformant FP unit should do single<->double precision conversions the same. Is this just some theoretical concern or do you have something verifiable where errors accumulate?

Post by **_mental_** » Fri Feb 01, 2019 2:32 pm

Actually, most of game engines stick to single-precision floating point numbers only. And they somehow work.
For example, take a look at a quite popular commercial physics middleware. It uses just floats while depending on use case it can be affected by their imprecision.
In other words, particular bugs caused by FPs should be reported and fixed. Some generic concerns won’t fly here, sorry.

ZDoom