Illogical Decider?

[markw]

So I was trying to understand this article with blueprint: 118296, and the technique used to balance the asteroid grabber content was to use a constant combinator with a decider combinator. The constant combinator was set to 10k each of metallic, carbon, oxide asteroids. The decider combinator is set to Each < 10k, Each value 1. What I don't get is why that should work, but it seems to be setting the grabber to grab oxide. Any of the deciders that are connected to the grabbers can be examined in the above blueprint. Here is image with open decider:

Screenshot_decider.png (753.99 KiB) Viewed 355 times

Can anyone explain to me why this is (obviously) working, yet makes no logical sense? The each for Oxide asteroid must surely be 10k + 14, which is not less than 10k, so why is it being output with value 1? The grabber is happy too, and the asteroid count is balanced. How does the balancing occur?
One difference I realilzed: when I populated the blueprint I used any quality buildings, so the asteroid grabbers actually have less storage than was designed. They get full at 39. Why the signal are showing 15, 15, 14 for their storage content, I cannot explain either.

[atomizer]

I'm guessing not all of those "10k" values are exactly 10000. If the constant signal is 10000, and the condition "< 10015", then it makes sense.

[eugenekay]

This Excellent Post by mmmPI is the simplest, best way that I have found to get a Single-Decider Circuit to automatically store X chunks in the Grabbers, without overflowing or complicated Counters. You must adjust it by entering the formula into the Textbox as-written: "2^31-5" (trying to type the "Integer version" wil get truncated); or just import the Blueprint provided.

It works by straddling the "Signed Integer Overflow" near 2^31 (ie, a 32-bit Number with Negatives), and it works reliably. As-blueprinted, loading 5 chunks of a type will cause the Signal to exceed the 2^31 Limit, and therefore stop grabbing that type of Chunk. You do need one Constant-Combinator to provide the Baseline Signal, but this can be shared by all the Grabbers.

Good Luck!

[markw]

ah! @atomizer you were right! The values are not exactly 10k. they were e.g 10015. So that explains it. Great! thanks.
@eugenekay Yes, I saw that technique, its a little crazy to use such features because sooner or later they're going to switch to 8 byte integers I guess, in fact they already have. I guess Lua or whatever is still doing 4 byte integers or something.

[eugenekay]

ah! @atomizer you were right! The values are not exactly 10k. they were e.g 10015. So that explains it. Great! thanks.
@eugenekay Yes, I saw that technique, its a little crazy to use such features because sooner or later they're going to switch to 8 byte integers I guess, in fact they already have. I guess Lua or whatever is still doing 4 byte integers or something.

I doubt that they would switch from Signed Int32 types for representing Circuit wire values (unchanged since…. Ever?) to a larger (less-performant) bit representation. Values above “2.1 Billion” are rarely encountered in the wild. The use of a Combinator Named Logistic Group makes it trivial to adjust the settings globally anyway.

[markw]

eugenekay: agreed. Still, I will avoid this technique unless I have no other choice.