Factorio Forums

Science pack 3 (blue) is not filling up the bar it is like the bar is 1000 but the Science pack 3 is 999.9

I have 10 labs I put 9 in 4 of them and 1 I put I in it, lab 2,3,4,5 had looks like full bars(see pick)

I don't understand the problem. The technology requires blue science pack, so the bar will not move as long as there is none.

dos this help

I understand (I think).
If you have a research needing 100 red, green and blue science packs, you'll need an additional maybe 1% of blue pack to actually finish the research, as if a blue science pack did not give 100% but 99.9%. At least I think this is what this report is saying. Haven't tested this myself.

some what, if you have a Research with 4 red, green and blue science packs and 2 labs.

you put 1 red, green and blue science packs in lab1
and then add 2 red, green and blue science packs in lab2
lab2 looks like it has not done (eat) the 3nd set of red, green and blue science packs.

I fixed 2 sources of rounding problems related to research (those that I could reproduce) for 0.12.25, I believe it will fix these problems.

The best way to avoid rounding errors is to just use fixed point (integers). If you don't require dynamic range then floating point numbers are the wrong tool for the job. Might seem like a pain at first, but it's well worth the effort to avoid all these corner-cases.

flatmush wrote:The best way to avoid rounding errors is to just use fixed point (integers). If you don't require dynamic range then floating point numbers are the wrong tool for the job. Might seem like a pain at first, but it's well worth the effort to avoid all these corner-cases.

Not true in this case, as fractional numbers can appear here.

Fixed point numbers handle fractions just fine (it's kinda the point), what you probably want in this case is Q16 or 16.16.

I'm not going to describe the whole process here cause wikipedia can explain better than me, but you basically scale the number:
https://en.wikipedia.org/wiki/Fixed-point_arithmetic

If you're compiling with GCC, it actually supports them natively with an extension, so you can use them just like floats.

If the science pack fraction is just like 100, then multiply the integer by 100, that way there can be no rounding error.

EDIT: I think I see what you mean, the fraction is defined by the number of research labs? I was assuming there'd be a minimum fraction of a pack that can be used, to avoid rounding errors like that.

Still, for fracitons fixed point can easily be more accurate. A single precision float only has 24- bits of accuracy, while a fract32 has 32, or fract64 has 64. You can use an 80-bit float on x86 though (long double) and that's always as accurate cause it has a 64-bit mantissa.

flatmush wrote:Fixed point numbers handle fractions just fine (it's kinda the point), what you probably want in this case is Q16 or 16.16.

I'm not going to describe the whole process here cause wikipedia can explain better than me, but you basically scale the number:
https://en.wikipedia.org/wiki/Fixed-point_arithmetic

If you're compiling with GCC, it actually supports them natively with an extension, so you can use them just like floats.

If the science pack fraction is just like 100, then multiply the integer by 100, that way there can be no rounding error.

EDIT: I think I see what you mean, the fraction is defined by the number of research labs? I was assuming there'd be a minimum fraction of a pack that can be used, to avoid rounding errors like that.

Still, for fracitons fixed point can easily be more accurate. A single precision float only has 24- bits of accuracy, while a fract32 has 32, or fract64 has 64. You can use an 80-bit float on x86 though (long double) and that's always as accurate cause it has a 64-bit mantissa.

Exactly, with fractions, like 1/3, it won't help you having the fixed point at 1/100. And yes, we use doubles for that and it is enough.

We use fixed point numbers on some places where it is appropriate, like the map coordinates.