Floating-point inaccuracies permeate the game.

[dupraz]

q requires zero bits of storage; it's hard-coded.

That's the point of a fixed-point data type: it's functionally identical to floating-point representations, but you don't have to use any bits to store the exponent part because you fix it to a constant (in this case to -16) and never change it. So you get a 64 bit significand rather than the 53 bit significand of the standard 64-bit floating point type which is great if you're in the range where you have enough precision and aren't wasting too much. (and the fixed exponent helps if you have to do a software implementation using integer types)

I don't think this is correct, at least in the context of the implementation I shared.

You're missing the point that there are other, relatively arbitrary multipliers on things like power usage. For example, brownouts can throttle energy usage by an amount depending on the available and required power. Modules can change the energy usage too, which can again be fairly arbitrarily scaled if the beacon they're in is partially powered.

In cases where the base of the ratio becomes arbitrarily based on the number of machines, then I suppose it would be fine to round to the nearest value, which is already happening anyway, unless you fully switch to rational types (which again, you can afford, since the ratio only gets updated whenever a source of power goes offline, not every tick).

I'm betting that there's an off-by-one error in expectations. Like, if you turn it on at tick zero, your burner miner outputs a coal at tick 240, 480, 720, and so forth.

Then it's an actual bug (if 2.5J are being used in excess), not just a floating-point inaccuracy.

[Hurkyl]

q requires zero bits of storage; it's hard-coded.

That's the point of a fixed-point data type: it's functionally identical to floating-point representations, but you don't have to use any bits to store the exponent part because you fix it to a constant (in this case to -16) and never change it. So you get a 64 bit significand rather than the 53 bit significand of the standard 64-bit floating point type which is great if you're in the range where you have enough precision and aren't wasting too much. (and the fixed exponent helps if you have to do a software implementation using integer types)

I don't think this is correct, at least in the context of the implementation I shared.

The implementation you link takes the integer abs_value and computes the decimal representation of (the real number) abs_value / 65536.

In cases where the base of the ratio becomes arbitrarily based on the number of machines, then I suppose it would be fine to round to the nearest value, which is already happening anyway, unless you fully switch to rational types (which again, you can afford, since the ratio only gets updated whenever a source of power goes offline, not every tick).

You'll have to update it -- in this case subtract the energy consumption from the fuel value -- every tick.

Also, you're going to bloat the size of the data type representing every machine, and all of the performance implications that can cause.

I'm betting that there's an off-by-one error in expectations. Like, if you turn it on at tick zero, your burner miner outputs a coal at tick 240, 480, 720, and so forth.

Then it's an actual bug (if 2.5J are being used in excess), not just a floating-point inaccuracy.

It's not being used in excess, though; it's still just consuming 2.5J per tick and outputting an item every 240 ticks. It's the expectation the machine can still output an item on a tick when it's inoperable that is violated. I'm of mixed opinion if the display should read 100% if this is what's happening, though.

I've seen a similar situation on the forum too where someone was seeing greater-than-expected nutrient consumption in a biochamber, and IIRC the explanation wound up being that the machine would be crafting and spend a tick realizing that it

I agree it's surprising if intended, since one usually doesn't think about the things a crafting machine does aside from crafting. Nor do I dispute (nor do I affirm) the idea it should be changed. But I don't think it's accurate to call it an actual bug.

[dupraz]

You'll have to update it -- in this case subtract the energy consumption from the fuel value -- every tick.

But this already happens with floating-points? The actual calculation only needs to be done once, then cached, then added every tick, which is the current behavior. Rational addition is much less expensive than multiplication, in fact, it's equivalent to integer addition if the divisor is normalized.

Also, you're going to bloat the size of the data type representing every machine, and all of the performance implications that can cause.

The memory usage would go from one FP64 for floating-point, to one INT64 for fixed-point, and for rational types to one INT64 plus maybe one INT8 or INT16 for denominators, which only matters for specific properties, which there aren't many of at any given time (about 2 or 3 per entity?). That's like a few bytes per, even if you have 10k entities, that's completely insignificant. Only the compute cost matters, because you have to do 2 INT multiplications instead of 1 FP multiplication.

[Harkonnen]

Chinese remainder theorem anyone? for even better precision

[dupraz]

Another issue to consider is, what happens when an operation should take a non-whole valued tick duration to complete? For example 60 + 1/2. At tick 60, it's not done, at tick 61, it's overshot by 1/2 tick, is this taken into account for the next cycle already?

[Harkonnen]

Another issue to consider is, what happens when an operation should take a non-whole valued tick duration to complete? For example 60 + 1/2. At tick 60, it's not done, at tick 61, it's overshot by 1/2 tick, is this taken into account for the next cycle already?

I think it is to some extent. In one of FFF's there was an issue when legenary foundry crafted gears too fast for these overshots to matter