golfmiketango wrote:Yeah, I'm not sure, myself, that I get what they are saying is going to happen... but I've only skimmed through the thread where it's proposed; it seems like the full intent is spelled out pretty clearly there but I'd probably need to sit and scratch my head longer than I have to fully grasp it. Wish I could link to it but I can't find the damn thread anymore... was just reading it yesterday... bah... *throws up hands in frustration*
You're talking about this thread: 13706
The two main reasons for the change are:
1. The current user interface is ambiguous, because it doesn't tell you what is meant by "input count". Is it the count of the input to the predicate function? Or is it the count of the signal that you actually want to output
? It's also downright confusing, because it will take the count of the output from a different signal than the output itself.
2. While the current behavior allows for obscure solutions like summing a bunch of different signals in a single combinator (as demonstrated by XKnight above), it does not allow a much more common (and arguably more useful) scenario, namely to use the decider as a tri-gate (think of a triggerable "valve"). In version 0.13 this will be very easy: apply "Blue = x" and "Red" to a decider; let ONLY "Blue = x" pass through if and only if "Red = 1"; currently not possible because you can't pass the count from Blue, unless you pass "Everything (input count)", which is what most people do but it's often quite ugly.
Just try to solve the following problem in 0.12: you have a wire with many signals on it (e.g. "A", "B", "C", "D", ...). Extract a single one of these signals from the wire (e.g. "B"), but only if signal "Red" is equal to "0" (i.e. not on the wire). Or in other words: make a filter extracting "B" which can be disabled with "Red = 1".
Not exactly an exotic problem (it comes up all the time when you have a shared message bus), and if you look at the Decider Combinator your first impression will be that it's straightforward, but it's not.
So that was a lengthy explanation of the change, I hope it helps.
It's a good change, but some people are violently against it because it can break some setups.
golfmiketango wrote:It's much harder to rigorously prove something can't be done than that it can
That's not true. Negative proofs are not inherently more difficult than positive ones, it's just a matter of applying the correct proof technique and reasoning.
We don't have the formalism for making actually rigorous proofs about combinators. Your delay problem doesn't really require that, though: you can't compare A to B before B even exists, q.e.d. :)
Negative proofs can never be constructive
, i.e. they can never give an example for something that is proven to not exist -- which is probably what makes you think they're more difficult, because you like to think in examples.
But in mathematics, computer science and logic, proofs are usually not made by way of listing examples, so it's really not important if you're trying to prove a positive or negative statement.
Negative proofs are often done as "proof by contradiction": if you want to prove that "S is false", you assume instead that "S" is true, and then show that this leads to a contradiction.
Interesting use of a splitter-bus. What inspired you to do it that way? Personally I've made it a habit never to drop items directly into or pull items directly out from splitters as I pretty quickly came to the conclusion that I didn't know what the rules were, but the crap I expected to happen wasn't happening -- but that's just a fancy way of saying I've been too lazy to learn some stuff.
I got that idea from here: http://imgur.com/a/WytKJ
I just love it and always use it when I have to unload from a row of chests onto a belt.
If you insert into the splitters, then your inserters can't clog eachother up, they will always work at maximum speed as long as the belt is not backing up. This is because every splitter is like a mini-buffer for 1 item that drops the item onto the belt (at the exit). If you drop directly onto the belt, there might be an item in the way and your inserter would be delayed for a moment.
The splitter bus is also a lot more compact than the usual way of merging several lanes hierarchically. Which is why I love it for train unloading and I've also started to use it at the exit of a smelting setup (from the buffer chests onto the belt).
I'm not sure if we'll still need that construction with the new rapid inserter that is coming with 0.13. It might be awesome in combination, or not needed anymore at all. We'll see.