Bug #442
openNetworking float/fixed-point naming issues
0%
Description
In the network protocol, both on the dataio layer and the delta/packets layer above it, floats are currently treated generally not as floating-point numbers, but as fixed-point numbers, which get multiplied by some factor and then transmitted as an integer; this has been the case since before either delta or dataio has been a thing. However, in the JSON dataio implementation, they are still transmitted as reals with full precision, with the precision/granularity factor being ignored. This means while they are generally called floating-point, they are usually treated as fixed-point, but not always. I consider this inconsistency bad and an error, if not in behavior, then at least in naming/documentation.
I can see a couple of options we have:- Make everything actually transmit full floating-point numbers and get rid of the extra granularity factor
- Make everything, including the JSON protocol, transmit fixed-point numbers and change the language used accordingly
- Have both floating-point and fixed-point transmission support and use each where it's more useful
- Keep the current behavior, but call it fixed-point, even though the JSON protocol still doesn't treat it that way
- Not do anything; actively decide that we consider this inconsistency acceptable
Updated by Alina Lenk 8 months ago
Did a bit of brainstorming on all of the options.
- Going full floating-point:
- Upsides:
- Most simple and straightforward to understand
- Can get rid of most special casing on the packets/delta layer
- If we already had this, I doubt anyone would seriously consider changing it
- Downsides:
- Have to figure out how to safely transmit binary floats given potential platform-dependent representation/endianness
- Can't really do delta (and when we do, have to shut up code analysis tools)
- Upsides:
- Going full fixed-point:
- Upsides:
- Can still use delta where values are actually likely to be equal (e.g. spaceship stats)
- Only need to change very little code
- Downsides:
- Loss of precision
- Arguably an active step back for the JSON protocol in contexts where we like having that precision
- Upsides:
- Doing both:
- Upsides:
- Best of both worlds
- Full precision where delta doesn't make sense
- Increased efficiency where delta does make sense
- Downsides:
- Largest amount of effort
- Have to figure out how to safely transmit binary floats
- Added bloat if we don't really need both options
- Upsides:
- Only changing the names:
- Upsides:
- Almost no work
- Doesn't change the protocol, so we could even do it in older versions
- Downsides:
- Loss of precision
- Still leaves the inconsistency in the JSON protocol
- Upsides:
- Doing nothing:
- Upsides:
- No work needed
- Downsides:
- Everything stays bad
- Upsides:
Personally, I like the full floating-point option best; I don't think losing delta is that relevant for most (current) uses. Though the representation / byte order thing might be an issue; haven't looked deeper into that.