Factorio Forums

I have filled a cryogenic plant to the brim with legendary productivity module 3, and selected the promethium science pack as the recipe. I would expect that this results in an output of 2.4/s, as confirmed by FactorioLab, but instead I get:
The numbers for the input are also off -- that should be "0.8", "0.08", and "2", respectively.

Is this just a visual glitch or will this actually run ever so slightly too slow?

Thanks for the report. This is simply how floating point numbers work. After all the math is done, what an infinite fraction system would say ends up as “2” may end up 1.999999998 and when showing the numbers as strings it shows only one decimal place.

Thanks for the reply!

Rounding 1.99999998 to a precision of 2 decimals for display would still end up with 2.0. So it seems to me that either no such rounding happens (just a simple truncation of the string), or the result here would be more like 2.3949999999 which seems surprisingly inaccurate?

I agree this should be looked into, because I just put two Speed Module 1s into an Assembling Machine 2 making copper cable.

While the float representation of `4 * 0.75 * 1.4` does indeed come out to `4.199999999999999`, it gets rendered as `4.19` in-game. It is being truncated, not rounded.

There is no perfect answer for displaying fractional numbers as decimal strings. While you may think rounding is best: 0.04 rounded to 1 decimal place is 0 and will generate its own bug reports.

Rounding out of output precision is one thing, but accounting for floating point being base-2 and giving one bit off is another - just add 1e-8 prior to rounding down (or round to nearest by adding 0.5 or 0.005). E.g "(std::stringstream() << std::fixed << std::setprecision(4) << 1.234567).str();"

Another thing on that - got today situation when rocket is 100% in silo, but "Launch" button says "it's not ready yet" (might be a bit misleading) when just a single crafting remained. For that kind of stuff it better be 0% when value is 0/M, 100% when value is strictly M/M. and everything else is clamped to 1%-99% range

0.04 rounded to 1 decimal place is 0 and will generate its own bug reports

0.04 truncated to 1 decimal place is also 0 (or rather, 0.0), so at least for this example, rounding vs truncation doesn't seem to make a difference.

Ralfinator wrote: Sun Jun 28, 2026 3:23 pm

0.04 rounded to 1 decimal place is 0 and will generate its own bug reports

0.04 truncated to 1 decimal place is also 0 (or rather, 0.0), so at least for this example, rounding vs truncation doesn't seem to make a difference.

I'd say that showing 0 when value is 0.04 (and when that has importance) is a bug, but not in precision plane - it's UI/UX problem that shown value has too few decimal places to represent. When it's miniscule, it's not a bug ofc.