[2.0.77] Floating Point Accumulation Errors in Productivity

[Th13f]

I'd like for each gcd batch of productivity crafting to result in an integer amount of recipe finishes to yield expected results. I derive batch size by

Code: Select all

100/gcd(100+productivity,100)

. The in-game scenario this comes up is switching recipes on machines with productivity modules after exact batch completion. The workaround is to hardcode batch sizes + 1 for recipes which yield these FP accumulation errors.

I know floating point math accumulation errors are very difficult, I'd like to humbly suggest the question of whether it is possible or reasonable to tweak epsilon values or take advantage of fixed-point arithmetic in these scenarios. Something like results in the range of [real, real + epsilon] could be preferable to (what I imagine the current status of) [real - epsilon, real + epsilon].

The following is a table of machine productivity and batch size which results in the following recipes missing the last output of the batch. I have attached the test world with all assembler productivity recipes and (same-module) prod module combinations. There is a game BP book with the BP for stamping again if you'd like.

132720 points to 49936 which was last addressed in 2017, I'm hoping to bring it back up with extra details.

Thanks for taking the time, and I hope the table or save file are useful. I definitely understand that this situation is known to the team. Looking forward to pipe circuit connections in 2.1 to make productive autocrafters easier to setup for fluid recipes!

Please let me know if I can assist in any way,
Th13f

RS: Red Science
GS: Green Science
MS: Military Science
BS: Blue Science
PS: Purple Science
YS: Yellow Science
FF: Flying Robot Frame
RF: Rocket Fuel
LDS: Low Density Structure
AC: Advanced Circuit
PU: Processing Unit
EU: Engine Unit
EE: Electric Engine

Code: Select all

productivity level, batch size: items with missing output
08%, 25x:  1: BS
10%, 10x:  0
12%, 25x:  6: FF, LDS, RF, BS, PS, YS, 
14%, 50x:  0
16%, 25x:  6: FF, LDS, RF, BS, PS, YS, 
18%, 50x:  0
20%,  5x:  0
22%, 50x:  4: FF, BS, PS, YS,
24%, 25x: 10: PU, EU, EE, FF, LDS, RF, MS, BS, PS, YS, 
26%, 50x: 13: AC, PU, EU, EE, FF, LDS, RF, RS, GS, MS, BS, PS, YS,
28%, 25x:  0
30%, 10x:  0
32%, 25x: 12: AC, PU, EU, EE, FF, LDS, RF, GS, MS, BS, PS, YS,
36%, 25x:  0
38%, 50x: 13: AC, PU, EU, EE, FF, LDS, RF, RS, GS, MS, BS, PS, YS,
40%,  5x:  0
44%, 25x:  4: FF, BS, PS, YS,
50%,  2x:  0
52%, 25x: 13: AC, PU, EU, EE, FF, LDS, RF, RS, GS, MS, BS, PS, YS,
60%,  5x:  0
64%, 25x: 13: AC, PU, EU, EE, FF, LDS, RF, RS, GS, MS, BS, PS, YS,
76%, 25x: 13: AC, PU, EU, EE, FF, LDS, RF, RS, GS, MS, BS, PS, YS,
100%,  1x:  0

[Loewchen]

As you noticed yourself, this has already been reported and decided.

[Th13f]

Fair enough! Out of personal curiosity, I would be interested to know if there are reasonable epsilon calculation fixes which could fix the behavior. Separately (and more broadly), I'd also be interested to hear about considerations around fixed-point arithmetic implementations compared to the floating point implementation.

If anyone has the time or interest in sharing.

Thanks either way.