Page Comparison

...

Crashes
Basic Execution Node
- Registers
  - ACC
  - BAK
  - NIL
    - This is useful if you have a node that accepts an input from another node, and under certain conditions the input from that other node isn't needed, and your node needs to use its ACC register to store something (so you can't do "MOV <DIRECTION>, ACC"). You can just say "MOV <DIRECTION>, NIL" to clear the input from that other node.
    - It's also useful to keep your code easy to understand in situations where your node doesn't need to use ACC (so you could just say "MOV <DIRECTION>, ACC"), because it'll be clear that that input was unneeded.
  - LEFT, RIGHT, UP DOWN
  - ANY - I still haven't used this one.
  - LAST - I still haven't used this one.
- Instruction Set
  - Comments
  - Labels
  - NOP
  - MOV
  - SWP
  - SAV
  - ADD
  - SUB
  - NEG
  - JMP
  - JEZ
  - JNZ
  - JGZ
  - JLZ
  - JRO
    - -1 refers to the instructino instruction before the current line.
    - 2 skips the next instruction
    - ACC will use the value in ACC to determine what line to jump to.
Stack Memory Node
- Attempting to write to a full memory node or trying to read from an empty memory node will result in a block.
Keyboard shortcuts
- Ctrl + Z - Undo last change
- Ctrl + Y - Redo last change
- Ctrl + X - Cut
- Ctrl + C - Copy
- Ctrl + V - Paste
- Ctrl + Arrow - Navigate to the adjacent execution node
- F1 - View instruction set quick reference
- F5 - Begin running the current program
- F6 - Step or pause the current program
Breakpoints
- Put an exclamation point (!) at the beginning of a line.
- When you hit a breakpoint, click 'Play' to resume execution. Execution will stop again if the breakpoint is hit again.
Visualization Module
- The format for out put is 1) the starting X coordinate, 2) the starting Y coordinate, 3) one or more color values, and 4) a terminating negative value (e.g. -1).
- The coordinate system starts at (0,0), which is in the top-left of the display.
- Available colors:
  - 0 - Black
  - 1 - Dark grey
  - 2 - Bright grey
  - 3 - White
  - 4 - Red
- Resolution - 30 characters wide and 18 characters tall.
  - The sandbox is 36 wide and 22 tall.

...

Self-test diagnostic
1. Instructions:
  1. Read a value from IN.X and write the value to OUT.X
  2. Read a value from IN.A and write the value to OUT.A
2. Pattern(s) taught:
  1. Use the MOV command to accept input, to pass data from one node to another, and to pass data to the output.
Signal amplifier
1. Instructions:
  1. Read a value from IN.A
  2. Double the value
  3. Write the value to OUT.A
2. Pattern(s) taught:
  1. You can save values to ACC.
  2. You can add two values by adding them both to ACC.
  3. You can multiply a value by adding it repeatedly to ACC.
Differential converter
1. Instructions:
  1. Read values from IN.A and IN.B
  2. Write IN.A - IN.B to OUT.P
  3. Write IN.B - IN.A to OUT.N
2. Pattern(s) taught:
  1. You need to use NEG to solve this one.
  2. This is maybe the first puzzle where realizing something about the nature of the problem can allow you to simplify the way that you write your program.
  3. If you don't realize that you can negate one subtraction to get the value of the other one, and instead try to implement each subtraction separately, you'll find that ACC isn't enough memory to do what you need, and so you'll either need to use SAV or another node.
  4. General lesson: Try reusing data as late as possible in the transformation from inputs to outputs. The earlier you reuse it, the more logic you may need to write.
Signal comparator
1. Instructions:
  1. Read a value from IN
  2. Write 1 to OUT.G if IN > 0
  3. Write 1 to OUT.E if IN = 0
  4. Write 1 to OUT.L if in < 0
  5. When a 1 is not written to an output , write a 0 instead
2. Pattern(s) taught:
  1. This is the first puzzle that requires using conditional logic (JEZ / JLZ / JGZ).
  2. This is also the first puzzle that requires that you use labels (the targets of the jump statements).
Signal multiplexer
1. Instructions:
  1. Read values from IN.A and IN.B
  2. Read a value from IN.S
  3. Write IN.A when IN.S = -1
  4. Write IN.B when IN.S = 1
  5. Write IN.A + IN.B when IN.S = 0
2. Pattern(s) taught:
  1. This again requires using labels.
  2. This is arguably the first puzzle where you need to write statements that will accept data that you will not be using. In other words, this is the first puzzle where using MOVing data to NIL is appropriate.
  3. You can have one node that takes in a value of <1, 0, or 1, and based on that value it can pass either of two other nodes' values. The IN.S node in this puzzle could probably just be copy-pasted into other puzzles. You can imagine pairing the IN.S node with another node that makes the determination of whether the value passed to the IN.S node should be -1, 0, or 1.
Sequence generator
1. Instructions:
  1. Sequences are zero-terminated
  2. Read values from IN.A and IN.B
  3. Write the lesser value to OUT
  4. Write the greater value to OUT
  5. Write 0 to end the sequence
2. Pattern(s) taught:
  1. This is the first puzzle that has you output a zero-terminated sequence rather than a single number for each input.
  2. This is the first puzzle where it seems intended for you to use SAV and SWP.
Sequence counter
1. Instructions:
  1. Sequences are zero-terminated
  2. Read a sequence from IN
  3. Write the sum to OUT.S
  4. Write the length to OUT.L
2. Pattern(s) taught:
  1. This is the first puzzle where you need to read a zero-terminated sequence as an input rather than a single input or an input of a defined length.
Signal edge detector
1. Instructions:
  1. Read a value from IN
  2. Compare value to previous value
  3. Write 1 if changed by 10 or more
  4. If not true, write 0 instead
  5. The first output is always 0
2. Pattern(s) taught:
  1. This seems to be the first puzzle that has you work with continuous interconnected input rather than discrete inputs.
  2. I'm honestly not totally sure what they were trying to get you to learn with this one.
Interrupt handler
1. Instructions:
  1. Read from IN.1 through IN.4
  2. Write the input number when the value goes from 0 to 1
  3. Two interrupts will never change in the same input cycle
2. Pattern(s) taught:
  1. This seems to be the first puzzle where you have a node's ACC value used to track the changing binary values of multiple other nodes.
    1. But I'm not sure it's a repeatable pattern, because there's a stipulation that only one node can change at a time.
Signal pattern detector
1. Instructions:
  1. Read a value from IN
  2. Look for the pattern 0,0,0
  3. Write 1 when pattern is found
  4. If not true, write 0 instead
2. Pattern(s) taught:
Sequence peak detector
1. Instructions:
  1. Sequences are zero-terminated
  2. Read a sequence from IN
  3. Write the min value to OUT.I
  4. Write the max value to OUT.A
2. Pattern(s) taught:
3. How I broke it down:
  1. I made a program that, for each sequence, sends a '0' to both outputs. You can do this through a single path from input to output.
  2. I realized that you should forget about one of the outputs. Focus on creating an actual working solution for one of the outputs and you'll be able to modify that solution to get the other output working as well.
  3. I realized that, to find the min, you're going to need to delegate some work out of the 'main path' from input to output. You'll need to pass some input into this node and then get passed back the min.
  4. I realized that I would need to delegate work from this side-box to still another side-box, which would take two numbers and return the smaller one.
Sequence reverser
1. Instructions:
  1. Sequences are zero-terminated
  2. Read a sequence from IN
  3. Reverse the sequence
  4. Write the sequence to OUT
2. Pattern(s) taught:
Signal multiplier
1. Instructions:
  1. Read values from IN.A and IN.B
  2. Multiply the values
  3. Write the product to out
2. Pattern(s) taught:
3. Thoughts
  1. I start by realizing that I've had to do this in Human Resource Machine, and the solution is to just keep adding the first value to itself while adding to a counter until it equals the second value (or decrementing the second value until it's zero).
  2. I start by just moving A to the end.
  3. I notice that I get the right answer when the first value is zero, so I say "I'm going to try to make the zero and one cases work first, since hopefully they're easier."
  4. I get the zero case working when A is zero.
  5. I notice the "stack memory nodes" and figure they're probably necessary to solve the problem.
  6. I figure out how to return every 'A' value multiplied by two, or zero if 'A' is zero.
4. Thoughts from a previous attempt at solving the puzzle:
  1. I realized that to do the multiplication, I would need to use one of the inputs as a counter, which I would decrease by one over and over again, and I would add the other input to itself repeatedly, for each of those counter iterations. (I had already solved this challenge in Human Resource Machine, and so I had a tiny head-start, in that I knew the basic approach I would probably need to use.)
    1. I'm finding myself spending a lot of time staring at those stack memory nodes and trying to figure out how I'm supposed to use them. The idea I have for how to solve this puzzle doesn't involve a stack.
  2. I decided to start by making it work for the edgecase where either of the inputs are zero, since I knew my idea for how to solve the general case would not work when either input was zero. Getting this working required me to basically delete everything I had up to that point. So now it works where, if either input is zero, the output is zero, and otherwise it just outputs the second value. The logic to make this work took up an entire node.
    1. I created a stub node where it just takes the inputs and returns the second one.
    2. I realized that this stub node wouldn't have any other non-memory nodes around it to delegate work to, but that if I flipped the orientation of the solution horizontally, I'd have a node I could delegate to. So I flipped it, which was pretty easy (just renaming a few commands).
    3. I decide to use the newly-available node to just send '1' repeatedly, so I can subtract 1 easily (there's no '--' operator).
    4. Consider listening to music while working! It may help you stay in the zone, just like when you're playing a game.
    5. It's really, really helpful to keep your program in a 'working' state at all times. So it'll always run and produce output without breaking somewhere along the line.
  3. I've now got a version that decrements properly, so the only thing I need to figure out now is how to keep adding the right value to itself.
    1. When looking at your code and trying to figure out what to add next, clear out any junk that isn't actually necessary! It's easy for that stuff to accumulate, and it makes it harder to see where the new code needs to go.
Image test pattern 1
1. Instructions:
  1. Fill the image buffer with the specified target test pattern (a fully-white image)
2. Pattern(s) taught:
Image test pattern 2
1. Instructions:
  1. Fill the image buffer with the specified target test pattern (a checkerboard)
2. Pattern(s) taught:

Exposure mask viewer

Instructions:
1. Read an X value from IN
2. Read a Y value from IN
3. Read a width value from IN
4. Read a height value from IN
5. Draw a rectangle of that size at the specified location
Pattern(s) taught:
1. This may be the first level where using JRO is necessary. It's the first level where I used it.
2. This is also the level where I had to stop thinking in terms of my usual programming idea of treating a node identically to a traditional function. It's not the same as a function, because you don't have as-easy access to variables outside your current scope. To make it possible to access variables outside your current scope, you basically want to set up two parallel columns of nodes, each column corresponding to a particular scope.
3. When you need a two-level loop, have four nodes arranged in a square, where the data enters the top-left node, the inner loop's data is tracked in the top-right node, the output is done in the bottom-right node, and the left nodes are used to handle the outer loop's data.
My struggles
1. The essential struggle I'm dealing with here is that:
  1. the solution seems to require two loops: an X loop and a Y loop...
  2. and it also seems that the loops must be able to communicate with each other to know when to stop...
  3. and I can't figure out how to do that in the space I have within each node.

Intermediate conclusions I come to as I solve it: (this is really good to do, it reminds me of solving the LSAT logic games)

It seems that the X loop should definitely be the inner loop.
1. Why: Each successive X coordinate only requires a single additional output (the color, "3" in this case), whereas looping downwards as the inner loop requires terminating the current sequence with "-1", then re-specifying the X and Y coordinates for the new coordinate, etc.
DONE (#3): It seems I will need to store the original X coordinate.
1. Why: As I iterate through the Y loop, I will need to know what X coordinate each new line should begin on.
DONE (#2): It seems I will need to store the width.
1. Why: As I iterate through the Y loop, I will need to know how many times to iterate through the X loop for each new line.
DONE (#1): It seems I will need to store the remaining width on the current line.
1. Why: This is how I will know when to break out of the X loop.
It seems I will need to store the remaining height.
1. Why: This is how I will know when to break out of the Y loop.
It seems I will need to store the current Y position.
1. Why: As I iterate through the Y loop, I will need to know what Y position each new line should be at.
It seems that having the functionality in series rather than passing data out orthogonally may be the better way to do things.
It seems that it might be better if the inner loop was closer to the output node than the outer loop.

Python version of the desired code:

Code Block

language	py

while True:
    x = input()
    y = input()
    width = input()
    height = input()

    for current_y_offset in range(height):
        current_y_position = y + current_y_offset

        output(x)
        output(current_y_position)

        for current_x_offset in range(width):
            output(3)

        output(-1)

Histogram viewer
1. Instructions:
  1. Read a value from IN
  2. Draw a line that many units long to the right of the previous line drawn
2. Thoughts while going through it.
  1. Ok, well since I've just finished the previous challenge, a clear difference here appears to be that the X loop is going to be the outer loop here and the Y loop is going to be the inner loop, whereas in the previous challenge the Y loop was the outer loop and the X loop was the inner loop.
  2. The challenge is thus going to be that for each "lit up" coordinate I will need to output the X position, Y position, color (3) and then -1.
  3. The X-value's looping doesn't need to know about the Y loop's value. It just needs to be told when to increment.
  4. (After having solved it:) I solved this one very quickly (in maybe 30 minutes) after spending a tremendous effort to solve the previous puzzle.
3. Data I will need to store:
  1. DONE (#1): I will need to store the current X position.
  2. I will need to store the remaining height of the bar.
  3. It might end up being desirable to store the current Y position, even though it could be calculated from the remaining height.
4. Intermediate problems / mini-puzzles:
  1. Draw just the top coordinate for each bar in the histogram.
5. Pattern(s) taught:
  1. Just like the previous problem, this requires a square pattern for tracking the variables of an outer and inner loop.
  2. Also like the previous puzzle, the 'intended solution' seems to require using JRO for space-efficient conditional communication between nodes.
Signal window filter
1. Instructions:
  1. Read values from IN
  2. Write the sum of the last 3 values to OUT.3 and the sum of the last 5 values to OUT.5
  3. Assume prior in values are 0
2. Thoughts while going through it:
  1. I see two stack memory nodes, so I'm probably going to need to use one or both of them.
  2. The first few inputs need to have an output for them which accounts for there not yet being 3 / 5 inputs.
  3. Also, you can't create a 'simple version' that just adds three inputs and outputs the result, because it won't produce a moving sum. It'll just produce a sum of every three inputs.
  4. An easier intermediate problem might be to have a moving sum of every two inputs.
  5. And a tricky thing about these memory nodes is that they don't tell the 'calling' nodes that it's 'empty'; it just locks instead.
  6. I think instead of using those two memory nodes separately, I may need to use them together as two different stacks. And when I'm producing these sums I'll need to use the execution node between them to shuttle the inputs from the one stack to the other and then back again. And then that 'middle' execution node (diagonal from the memory nodes) would be the 'coordinating / control' node.
  7. Actually, what I may need to do here is to create a queue using the two stacks.
    1. Hmm..but wouldn't you need two queues?
  8. I can deal with the first two inputs by having a one-off piece of code that adds two zeroes to the memory node.
  9. The fact that both memory nodes are on the same side of the grid seems like a clue to me.
3. Data I will need to store:
  1. I will need to store the last five inputs.
  2. I may need to separately store the last three inputs.
  3. I may need to store the previous calculated sum of the last three and five inputs.
    1. This will allow me to just subtract the oldest input rather than needing to recalculate everything from scratch.
4. Intermediate problems / mini-puzzles:
  1. DONE (#1): Have a moving sum of every two inputs.
  2. DONE (#2): Have a moving sum of every three inputs.
    1. Mini-mini-puzzle: Replace the bottom-most number from a stack of three inputs.
    2. The main insight here (which was probably based on something I'd heard before) was that I should use the two stacks to implement a queue.
    3. Here was a first (failed) attempt at solving this mini-puzzle by using the same approach that I used to get a moving sum of every two inputs:
  3. DONE (#3): Have a moving sum of every four inputs.
    1. This was the one where I needed to use NOP for the first time, to get the timing right between the execution node that adds new values to the memory node and the other execution node that swaps between the two memory nodes.
  4. DONE (#4): Have a moving sum of every five inputs.
    1. I don't have a picture for just this goal because before I even got it working it was clear how to get both the last-three and last-five sums at the same time.
  5. DONE (#5): Have a moving sum of both the last-three and last-five inputs.
    1. Here are the stats on this solution:
    2. I needed to have three NOPs to have the timing right between the two nodes writing to the memory node.
5. Pattern(s) taught:
  1. If you need to have some group of commands executed a certain number of times, just stick a JRO at the end of them and use another (relatively empty) node to keep track of how many times they've been done and when it's time to quit. Just have a bunch of lines in the other node that say "MOV -3, UP" or something like that.
  2. The NOP command is useful to get the timing right between two execution nodes that both read and/or write to a memory node, and must do so in a particular order.
  3. (Again) Use JRO to have nodes control other nodes!
  4. You can use two (stack) memory nodes to implement a queue.
    1. ...but it takes up so much space that I doubt this pattern will be used in another larger puzzle.
Signal divider
1. Instructions:
  1. Read values from IN.A and IN.B
  2. Divide IN.A by IN.B
  3. Write the quotient to OUT.Q
  4. Write the remainder to OUT.R
2. Data needed:
  1. a running tally that'll be the quotient
  2. it seems to me that the remainder doesn't necessarily really need to be stored
3. Sub-puzzles:
  1. (DONE #1:) Find just the remainder.
  2. (DONE #2:) Find just the quotient.
4. Pattern(s) taught:
5. Misc thoughts:
  1. I solved this one relatively quickly...I'm getting better!
Sequence indexer
1. Instructions:
  1. Sequences are zero-terminated
  2. Read a sequence from IN.V
  3. Read index values from IN.X
  4. Look up index value in sequence
  5. Write indexed value to OUT
2. Data that needs to be stored:
  1. Obviously the sequence needs to be stored.
  2. The count of how many numbers have been pulled off the first stack and onto the second one
  3. The total size of the sequence needs to be stored
3. Thoughts while solving it:
  1. It's immediately clear that I'll need to move the list into one stack and then pull it onto the other stack to access the requested elements.
  2. I think the node two nodes beneath IN.X is likely to have a lot of logic in it.
4. Sub-puzzles:
  1. (DONE #1:) Get the input onto the first stack, not including the zero.
  2. (DONE #2:) Have the count moved into ACC of the node below the node underneath IN.V
  3. DONE #3: Have the count tell the node between the stacks when it's safe to begin querying.
  4. DONE #4: Got it working for the first IN.X ("0").
  5. I now see that I'll need to store the numbers in the bottom stack because 1) the top stack stores the sequence backwards (last input popped first), and 2) the code handling IN.X doesn't know how big the sequence is, and so it can't adapt to deal with a backwards sequence (e.g. change the indices to the sequence's length minus the 'original' index).
  6. Nevermind, decided to just send the count to the other side
5. Pattern(s) taught:
Sequence sorter
1. Instructions:
  1. Sequences are zero-terminated
  2. Read a sequence from IN
  3. Sort the sequence
  4. Write the sequence to OUT
2. Pattern(s) taught:
  1. When what the node does next should depend on what happens on another node, use JRO. Don't use JMP and then MOV to ACC.
3. Sub-puzzles:
  1. (DONE #1) Read a sequence from IN and write that same sequence to OUT.
  2. (DONE #2) Read a sequence from IN, store it in a stack, and then write the zero-terminated sequence to OUT.
  3. (DONE #3) Rather than counting the size of the stack as you add elements to know when to stop pulling from it, add an extra element (a leading zero) so that you can just check when you've hit a zero to know when you've hit the end of the stack (this reduces the complexity of that part of the code, making it possible to add more functionality to each node that contains that logic).
  4. Without regard to the output, just store incoming elements into the stack until the stack is full.
  5. Read the first two elements from each sequence and return them in order of increasing value.
4. Thoughts:
  1. The basic way I see this working is that you'll have a sorted stack that has the smallest number at the top, and every time you introduce a new number, you'll start moving numbers from one stack to the other until you get to a number that is larger than your new number, and at that point you'll move your new number onto the first stack and add back all the numbers you'd moved onto the second stack.
    1. I can't think of another way that it could work *other* than that way.
  2. General trick: if you're doing more than one thing in a node and you're running out of space, look for a way to move logic out of the node into a different one.
  3. (SOLVED) One tricky thing is, when the code is popping from the stack, how does it deal with the case where it gets to the bottom of the stack? It seems like it would need to know how big the stack is, otherwise it'll just lock up when it tries to get a number from the empty stack.
    1. Answer: You add a leading zero before you start adding numbers to the stack, then look for that zero when pulling elements off the stack.
  4. 2018.05.01
    1. Rather than counting how large the stack is as I add elements to know when I need to stop pulling from it, I can instead just put a zero at the "end" of it and look for that. It's a lot less code.
    2. When trying to add new functionality to a simpler version of the solution, it can help to step through the code and think "What needs to happen now in the code to make the computer do what I think it needs to do next?"
    3. You cannot pass the input through the stack memory node on the top row to the node in the right corner as a way of getting logic out of the center node, because the node to the left of the top stack memory node has no way to know when it should or should not pass data through the stack memory node...unless the center-left node were to tell it? Hmm...seems complicated.
  5. 2018.07.11
    1. It seems like the best approach is to sort the numbers as they come in, but I wonder if it would be possible to sort the numbers once they're all in the stack. I don't think this would have any advantages, but it's a thought that popped into my mind.
    2. It's line 4 of my partial solution where I need new logic. Right now I have 'MOV ACC, DOWN', where it just immediately moves the input number to the stack, but instead of that I need to 'call a function' that will insert this number in the appropriate place in the stack.
    3. Ok, so if I move the input number to the node on the right (the node underneath the top stack), what further communication (if any) would be required between those two middle nodes? Hmm...if the node on the left is going to pull from the bottom stack when it hits a '0' from the input, then the node on the right would need to tell the node on the left that it's OK to continue pulling from the input. But if the node on the left is only ever telling the node on the right what to do, then the node on the right would not need to communicate with the node on the left. But in that case both the code for pulling from the bottom stack when sorting and also the code for pulling from the bottom stack when outputting would both need to go in the node to the right of the bottom stack.
    4. Ohhh, if I use the top stack for the 'real' stack and the bottom stack for the 'temp' stack, that lets me put the logic that's currently in the middle-left node into the top node, which frees up a lot of space for the sorting logic. This could be a big breakthrough.
    5. The top node will have these roles: it pass a new number to the sorting logic, and it will tell the sorting logic when it's time to send the stack to the output.
    6. I'm going back to my solution for the 'Sequence Generator' puzzle because I think I could use that logic in this puzzle.
    7. Here's my guess at how the sorting logic should work:
      1. The sorting logic will receive a number_to_be_sorted.
      2. It will then move the top number from the permanent stack and the number_to_be_sorted to some comparison function.
      3. If number_to_be_sorted comes back as the larger number, it will move the number_from_the_stack to the temp stack and pull a new number_from_the_stack.
      4. If the number_to_be_sorted is smaller, it will add that number to the permanent stack and then add back all of the temp numbers.
      5. If it hits a '0' from the permanent stack, it will add back the '0', then add the number_to_be_sorted, and then add back the numbers from the temp stack.
      6. After all this is done it will inform the input nodes that it has finished.
    8. Hmm...I feel myself struggling. I feel like I'm having trouble keeping track of all of the constraints. The nice thing about the process I ended up with when doing the LSAT logic games was that I always knew what I should be doing next and I never felt like I was losing track of other constraints that would later come back to bite me. Here I feel like I make a move (e.g. move some logic from one node to another) only to realize later that that move violates some constraint I had noticed earlier but forgotten about.
  6. 2018.07.12
    1. I re-read the manual and I'm wondering if I can make use of the ANY and/or LAST registers for this puzzle.
5. Data that needs to be stored:
  1. The sequence of numbers, sorted, with the smallest number at the 'top' of the stack, and a zero at the bottom.
    1. Example:
      1. 15
      2. 27
      3. 67
      4. 86
      5. 0
  2. A stack to temporarily store values when you're trying to insert a new entry into the right place on the "real" stack (the stack that will have its contents moved to the output).
  3. ~~The number of elements in the sequence.~~
    1. This is so that when you're outputting the sequence you'll know how many times to try to take something from the stack.
    2. Alternatively, you could put a '0' at the bottom of the sorted stack and use that to know when to stop pulling from it. That might be a lot simpler.
6. Plain-english description of how it should work:
  1. Loop:
    1. Move a 0 onto both stacks.
    2. Take a number from INPUT.
    3. If the number is zero, output what you've got on your sorted stack, then restart from the beginning.
    4. If the number is not zero, pop one number at a time from the sorted stack, and compare that number to the new number.
      1. If the new number is smaller, add the popped number back where it was popped from, then add the new number, then add all of the numbers from the temporary stack.
      2. If the new number is larger, move it onto the "real" stack, then move the compared number, and then move the rest of the items from the temp stack onto the real stack.
7. Problems I'm encountering:
  1. 2018.07.11 - There needs to be some communication between 1) the nodes which take from the input and add new numbers onto the stack and 2) the nodes which remove numbers from the stack and send them to the output. That leads me to put all that logic in a single node, the node immediately above the bottom stack.

...

Versions Compared

Old Version 80

New Version 81

Key