Project

General

Profile

Actions

Bug #442

open

Networking float/fixed-point naming issues

Added by Alina Lenk 7 months ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
General
Target version:
-
Start date:
04/11/2024
Due date:
% Done:

0%

Estimated time:

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
Actions #1

Updated by Alina Lenk 7 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)
  • 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
  • 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
  • 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
  • Doing nothing:
    • Upsides:
      • No work needed
    • Downsides:
      • Everything stays bad

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.

Actions

Also available in: Atom PDF