Floating-point inaccuracies permeate the game.

[dupraz]

As you may know, a burner miner consumes 150 kW of energy to produce one mining operationg every 4 seconds.
Therefore, you might assume that using 600 kJ of energy, you should be able to yield one. Or more practially, that using 3 pieces of coal of 4 MJ each, or 12_000 kJ, a total of 20.
Here is what happens in practice.

factorio_1782510400.png (552.48 KiB) Viewed 311 times

There are countless, examples of this happening in nearly every calculation made by the game. Since the game is fixed at 60 UPS, is there any rational whatsoever in the liberal usage of floating-points in every aspects of what should essentially be integer math? I am not filling a bug-report since I already know this will be immediately disregarded as a "won't fix" or "minor" issue.

[Rseding91]

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.

[radical_larry]

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.

All those factors could still be accounted for in fixed point math. There's no point (ha) in using floating point math in a game engine that is fully deterministic.
I remember a time when Wube tried to program things correctly out of principle.

[dupraz]

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.

All those factors could still be accounted for in fixed point math. There's no point (ha) in using floating point math in a game engine that is fully deterministic.
I remember a time when Wube tried to program things correctly out of principle.

This is essentially correct, floating-point arithmetic has a very specific use-case, it is also referred to as "scientific computation", because it's supposed to be used when dealing with the analogical measurement of natual phenomena, that is, using sensors of varying degrees of accuracy, that can be estimated to be within error intervals, where the innate inaccuracy of floating-points are meant to be a strict bound for this degree of noise, ie. half-precision (16-bits), full-precision (32-bits), double precision (64-bits), etc. while providing a sufficient dynamic range to remain equally (in relative terms) accurate at small and large scales.

You don't need floating-points to draw a circle using discrete pixels, or to calculate PI within an arbitrary degree of precision, which is how every CAS operates.

[zwickau]

Huh, I'm surprised to see this, I never noticed! I guess I expected that this problem would be magic-ed away somewhere in the background.

I'm not sure if the post author is making this assumption, but: integer division isn't necessarily faster than floating point division. Actually, I think it's usually the case that integer division is the slower operation. Given the importance placed on performance and the ubiquity of such math in the running of the game, it's the clear choice, right?

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.

All those factors could still be accounted for in fixed point math. There's no point (ha) in using floating point math in a game engine that is fully deterministic.
I remember a time when Wube tried to program things correctly out of principle.

I'm not sure how the game being deterministic is relevant.

[Khaylain]

Huh, I'm surprised to see this, I never noticed! I guess I expected that this problem would be magic-ed away somewhere in the background.

I'm not sure if the post author is making this assumption, but: integer division isn't necessarily faster than floating point division. Actually, I think it's usually the case that integer division is the slower operation. Given the importance placed on performance and the ubiquity of such math in the running of the game, it's the clear choice, right?

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.

All those factors could still be accounted for in fixed point math. There's no point (ha) in using floating point math in a game engine that is fully deterministic.
I remember a time when Wube tried to program things correctly out of principle.

I'm not sure how the game being deterministic is relevant.

I just took a quick look, and according to https://deepwiki.com/arturbac/fixed_mat ... ting-point it appears that fixed point (not integer) calculations are generally as good or better than floating point calculations.

[dupraz]

I just took a quick look, and according to https://deepwiki.com/arturbac/fixed_mat ... ting-point it appears that fixed point (not integer) calculations are generally as good or better than floating point calculations.

Sounds like a drop-in replacement for the float type that could be used strategically for entity processing time (division) and status effect calculations (multiplication) with no loss of precision nor performance, but which would only give exact results. Do they care enough to try? This requires at least C++ 17.

https://github.com/arturbac/fixed_math

Another solution would be to use the (C++ built-in) integer division operator /= with a fixed resolution, just like is currently used for quality effects, for example using integers shown as multiples of 0.00001 for display, since factorio is a 64-bit game the loss in dynamic range would not be significant. There are many ways to go about solving this.

https://arturbac.github.io/fixed_math/division.html

Decimal floating-points would also work.

It's also fair to mention that binary floating-points (having no practical use-case in the game), is usually non-deterministic across CPUs, and might even be a cause for desyncs.

[dupraz]

The game is not fixed at 60 ups, and machines may run faster or slower depending on beacons, modules, and available power. Functionally, these things don’t matter at scale - scale the game heavily encourages and incentivizes.

Are you just going to bury this issue even after practical solutions have been provided to you? None of the concerns you stated are technically relevant, and I don't even see what you mean by UPS not being fixed since 1 second of in-game time is always 60 ticks, no matter the game.speed or how fast your computer runs.

[Hurkyl]

This is essentially correct, floating-point arithmetic has a very specific use-case,

There is also the very specific use-case of high-performance calculation, since CPUs have the floating-point logic built-in and often have a more robust suite of operations for efficiently working on floating-point values.

I've done work with high-performance integer calculations, and have seen situations where it's actually faster to use the CPU's floating-point logic (carefully managed so that floating point error doesn't occur, or doesn't affect the end result) rather than its integer logic for the exact same sequence of operations.

[dupraz]

This is essentially correct, floating-point arithmetic has a very specific use-case,

There is also the very specific use-case of high-performance calculation, since CPUs have the floating-point logic built-in and often have a more robust suite of operations for efficiently working on floating-point values.

I've done work with high-performance integer calculations, and have seen situations where it's actually faster to use the CPU's floating-point logic (carefully managed so that floating point error doesn't occur, or doesn't affect the end result) rather than its integer logic for the exact same sequence of operations.

Even if that's the case, it would be a hack based on a quirk of the state of current CPU designs, which isn't even currently implemented correctly, considering the discrepancies in the results are clearly visible.
I don't even see how you would ensure consistency without rounding (which can be expensive), or somehow making sure you're only making divisions over whole binary values, since floating point operations produce an irreversible loss of information, which compounds.

See solutions like NTT.

[vemusa]

...these things don’t matter at scale...

I don't agree.
There is a thing called "productivity", and another thing called "circuit-controlled recipe". When these two things come together, inaccuracies matter.
Because productivity bar can also stuck at 99% when it should give a bonus craft.
In theory, this is the only chance to switch recipe without losing productivity.
But in practice, if productivity bar is stuck at 99% , switching recipe will lose the maximum possible amount of productivity.

[Harkonnen]

Simple fixed point wouldn't help much either, what would - working on rational numbers in p/q format, both p and q being integers, but it may quickly overflow int64 unless everything is rescaled to sort of base-60 representation so instead of seconds time things are represented in ticks.