I search backwards from the EOL point, but cache the result of each node to avoid duplicate work. That way if there are nodes which end up doing nothing, I don't ever calculate them.

So, you're memoizing instead of searching a correct ordering to transmit all the data, am I right?

(btw...)

Yes, I remembered that. What I mean is that the info should rather be in the point 4 point 3. Something like

System integrity (these are guaranteed):

All components have valid configurations, but may be disconnected.

I thought this would make it clear, but I'll add an explicit note about it.

EDIT: should be crystal clear now ..

All components have valid configurations, but may be disconnected. This is guaranteed, you don't have to enforce it.

note: what about this one?

• point 4: system integrity: are these guarantees the user can rely on, or things the user has to enforce?

Yes, I've explained this in the description now.

ok. Seems a bit weird to me, but fine.

Alright :) All points have been addressed. I keep the array as output, as I want it to be consistent with my input, which is also an array.

yeah, I suspected something like that. But it's not about adding another visualization at all, it's about adding a clear spec. The diagrams are kinda cool, but it's overly complicated to extract logical information from them.

Concretely, let's says an Adder receives 1,2 and 4,7 from tow inputs, I guess the ouput is then every possible combinations of the inputs? Hence 5,8,6,9? You just have to say this, no need for another ascii art. ;)

I'll rewrite parts of the description to make things more clear. However, about the issue you logged concerning:

• output ordering rule
• Recieving 1, 2, 4, or 1,4,2, or whatever order

Since a set of distinct numbers should be returned for each component, timing calculations are irrelevant.

### **Output**
- An array of tuples:
  1. The ID of each end-of-line component.
  2. A set containing all distinct numbers received by that component.
- The output must be sorted by ascending ID of the end-of-line components.

I'll add a visualisation for each component type to show how numbers flow through these components.

Initial example clarified. I'll check your suggestions/issue above.

Suggestions part:

1. see message below
2. Specs & rules
   • point 3: Both "A" and "M" are only active when both inputs are connected.
     What about no output? (this point seems redundant with the point 4 => maybe remove one?)
     Also, what's the behavior of J with multiple different inputs? can this happen? not? -> This should be specified here.
   • point 4: system integrity: are these guarantees the user can rely on, or things the user has to enforce?
   • the note (except Extractors without incoming and End-of-Line without outgoing) must be removed. By specs, these do not exist. Talking about this would imply the opposite.
3. Output: Why an array instead of an Object/Map? In python, I'd expect nothing but a dict as output. => ?
4. In the last example (Combining operands), the diagram is showing Forks while they are Joins. Also, the user shouldn't have to guess what the specs are about the flow. That's actually an issue.

Issue part:

• When Joining flows, what are the rules to use? Recieving 1, 2, 4, or 1,4,2, or whatever order, what is the output ordering rule? (based on value? on ID of the input element?)
• A specific section should explain the "timing" rules to do the calculations when several flow containing multiple values are received by a calculator element.

Cheers

Honestly, I understand so little to the first section of the description that I really have a hard time to just find the motivation to read the following sections. Especially when considering there are (afaics / edit: I finally saw the examples... => at the very least, one should be clearly visible) no concrete exemple of inputs -> outputs. This is really lacking (imo, you should give that at the end of the first section. Also there is an adder in there, but it's never talked about in the diagram (upper part) => ??)

Nice kata!