here I need to think about how I would arrange the node, there is a hell of a lot to do...

I guess 2 does the check and sorting and sends them left or right. Once a 0 comes in, it should send a signal left and right to send the their current value down.

p.s. preparation :)
pps. pita small nodes :(
I'll check tomorrow, too much beer... but wait, there is night out... maybe weekend.

pps. I attach this for tomorrow morning :)

At first i had no clue what that meant... Then i thought to how i resolved it and said DOY!! Of course :P

The code i ended up taking was something akin to:

[code]
mov up, acc
mov acc, left
mov acc, left
mov left, down
[/code]

which allowed me to restore the number before accepting the result to pass on...

I think to reset my current model (see first post), I could write a very high fake number into node 9. But this would be cheating?

Why would you have to?

Consider. If you sub and compare if it's below zero...

Why not.. negate the answer, subtract and check if it goes above zero?

Hmmm... let's try that logic.

max: 0 - 10 = -10
max: 10 - 12 = -2 so the newest is larger.

so: ...?

min: 0 + -10 = -10

min: -10 + -12 = -22
min: 10 + -12 = -2

min: 10 + -5 = 5 (inconsistent)

or

min: 0 - -10 = 10

min: 10 - -12 = 22
min: -10 - -12 = 2

min: -10 - -5 = -5 (also inconsistant...)

hmmm.... i'd have to think about it longer...

I think i had it where on the first input take it automatically accepted that as the 'higher' number before it tries to figure out what's the min number...

Well here's what my listing for the min was (from my save):
[code]
@5
MOV UP, LEFT
START:MOV UP,ACC
JEZ FINAL
SAV
SUB LEFT
JLZ LSM
MOV LEFT, LEFT
JMP START
LSM:MOV LEFT,NIL
SWP
MOV ACC, LEFT
JMP START
FINAL:
MOV LEFT,DOWN
MOV LEFT,NIL
[/code] Why would it be cheating? If you have room for it, the largest number the minimum could be is 999. So if you got 999 and did subtraction you'd get 0. So the input being:

999
0

999 would be the correct answer... (for the min and max)

The one I posted as a screenshot does work, but it will not accept anything higher than the last. So I could simple do something like this in node 9:
mov up, acc
so: jro up
mov up, acc
jmp s0
mov acc, up
jmp s0
mov acc, right
mov 999, acc << set it to a ridiculous high number after passing the last value for tor the last sequence over to the right.
jmp s0

My logic is more like:
move stuff left for the min value left
node 1 will run the main stuff and control the node 5 below
the ndoe 5 controls the node 9

the main node 1 sends the signal to subtract to node 5
node 5 will substract the value from node 9
if it is negative, it will change node 9's value to node 5's value
if not, it will get the next command from node 1

if the main cell hits a 0 (end of sequence), it will send a kill-signal to the node 5, which sends a kill-signal to node 9, with will send its value (always lowest in the current sequence) to the right and set itself to 999

p.s. and for max value, I look for JGZ instead of JLZ on the right and set it to -999... later

pps. If I initialise 9 with 999, I can even skip the whole first pass-through of the first number of all sequences.

Hmmm i'd seriously consider not using JRO or signals/messages until you have more complex problems where you don't have enough nodes or space to complete it otherwise. This is mostly because although you explain it well, you don't have the functions marked so any fixes make them more difficult to debug if you forget to update them...

I tend to notate them, usually a single letter hint of what they are and their offset. So new/get/set would be #N-1 #G1 #S3, etc. I'd also program them with those notations (which give you red lines telling you to update them) until your logic in the other functions are complete and correct.

I know for division when you definitely run out of room, depending on the scale of the function you can denote the logic (or loop counter) entirely to another 1-2 nodes leaving the work to be done in the accepting node... (Assuming you don't go for the simplest approach :P) Glancing at my division function, it has several mov 1, down lines followed by the finishing mov 9, down... But that's following a more binary/bit approach where i am working with 7 bits and it's a fixed loop vs a variable sized list...

I use JRO since the third program, its beautiful :)

The idea with giving them meaningful numbers, I try to do it. But this is very raw and there I just use s0 (first jump point) s1 (second jump point) or sub1 for a sub of s1 etc.

s0
s1
s2
s3
...

It can make more compact code, and faster code... But glancing at the screenshot i had a little trouble trying to follow the logic until i noticed the JRO. Still a numeric offset note helps it to stand out. Or make labels even if they aren't used, based on their offset. (A-Z or Sⁿ as you have it).

But each person thinks a bit differently...

Reminds me... For one of the first ones, i changed the input from -2 to 2 as 1-3, and used JRO... saved 3 whole cycles :P later updated it to 7 cycles, in exchange for 3x the instructions used...

edit: Fun, revisited the same one (signal comparator) and tried to do a simple 2x processing... and seems there's 39 elements, meaning it hangs on the last one... Yet any more complexity and it doesn't work... Tell it to handle 3 and it works, sorta... but slower.. much slower...

edit2: and i keep trying to optimize some of these more and they just go slower...

half the job done :)

p.s. I have 1/2 hour left...
510 :/

pps. I would need to merge these two, somehow... damn need to go to the pub now...

Let me necro this.

I'm not too happy about the JRO, because it only saves me one or two cycles + one instruction. Maybe there's a more effective use for it.