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 498 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.

[dupraz]

working on rational numbers in p/q format, both p and q being integers

This is exactly how "fixed-point" works. The library linked is a "48.16" implementation, meaning 48 bits for p (including 1 for parity), and 16 for q.

[Harkonnen]

working on rational numbers in p/q format, both p and q being integers

This is exactly how "fixed-point" works. The library linked is a "48.16" implementation, meaning 48 bits for p (including 1 for parity), and 16 for q.

I mean that initial values should map directly to that that kind of representation, but we have things like 0.1sec all over the place. Not only that 0.1 does not have finite base-2 representation, 1/60 of it wouldn't either both base-2 and base-10, so the only reasonable way to go is fixed point, but on ticks (1/60sec), and that's quite an overhaul for in how many places this is currently used. One way to go though while technically staying at floats is to resnap it back to 1/60 grid after every +-*/, e.g. v = floor(v*60е8+0.5)/60e8

P.S: Etymologically the word "second" comes from "second minute", so Factorio ticks deserve their place in vocabulary as the "third"

[dupraz]

One way to go though while technically staying at floats is to resnap it back to 1/60 grid after every +-*/, e.g. v = floor(v*60е8+0.5)/60e8

Again, this is exactly how the /= operator works, and what is effectively being used for quality effects already, which is stored as an integer at a fixed resolution, which is then divided "for display purposes", only issue is that the resolution it was fixed at before 2.1 was... 1/10, which was not even accurate for even the most basic calculations. No idea why this wasn't the default approach.

I can't stress enough that floating-points are wildly inadequate for the simple reason that the innacuracy in absolute terms increases at high values to the point it quickly skips entire whole values (up to over 2^31 for a single step), the entire point being to allow for a greater dynamic range (say 2^127 instead of 2^31 for 32-bit), not higher precision.

Factorio doesn't need to store values up to 2^1024 (FP-64), not even 2^64 in fact, so it can afford to simply use these extra digits for decimal places (say 5 or 6), or rely on symbolic, fixed-point representations like any CAS.

Of course, that doesn't solve issues where the "ratios" being calculated by the game are neither able to be represented by decimal nor binary numbers, like the current Heat exchangers (1/97, prime denominator, which is admitedly silly), but then again, whether the inaccuracy is down to 6 decimal places, or 31, in these edge cases, makes little difference.

See also

[Hurkyl]

working on rational numbers in p/q format, both p and q being integers

This is exactly how "fixed-point" works. The library linked is a "48.16" implementation, meaning 48 bits for p (including 1 for parity), and 16 for q.

You've misunderstood something.

48.16 means that when you write out numbers in binary notation, there are always 16 places to the right of the point and 48 places to the left of the point. (thus, the position of the point is "fixed")

That corresponds to q being hard-coded to the constant 65536 in the rational number format. (and p being a 64 bit integer)