Jump to content
BrainDen.com - Brain Teasers
  • 0


unreality
 Share

Question

VNA

VNA stands for Virtual Node Array, and is the setting for this game, which I based loosely off of Core Wars, an old programming game... but Redcode was pretty hard to understand IMO, I think VNA Code (which I have invented over the past two days) is better and easier to learn. You need no knowledge of Redcode or Core Wars to play this game.

Back to the game.

The VNA is like a computer memory space, one-dimensional, and filled with nodes. A node is like a line of programming code. Before the game begins, all of the VNA's nodes have the BLANK command, but when the game begins, two programs are put into the VNA at random locations. The programs designed by YOU, the players of the game! They retain their order and everything, they're just placed in at a random spot in the VNA, though considerably far away from each other.

Each node refers to itself as 0, while the next line is 1 and the previous line is -1. The VNA wraps around so it's like a loop of nodes.

So in the beginning of the game, both player's programs are put into the VNA, and then each player starts with one 'executor'. An executor starts at the beginning line of the player's program and then executes that node, then the next, etc.

In one round, Player 1 (P1)'s executor executes one node, and P2's executor does the same. Then in the next round, etc.

Using the SPLIT and MERGE commands, new executors can be made or deleted. Let's say P1 has 2 executors while P2 has 1. The game would proceed like this:

Round One

* P1's first executor

* P2's executor

Round Two

* P1's second executor

* P2's executor

etc. Each player can have up to four executors running at any one time.

The goal of the game is to destroy the opponent's executors and be the sole master of the Virtual Node Array! Note that once your initial executor starts running, you have no more impact in the game except to see the outcome.

So how to program in VNA Code?

First, the commands. Each node is essentially a command. Each command (except BLANK) is followed by three values: a,b,c. If not specified, they are assumed to be zero. I call the a/b/c values input vectors, and they can be either a number or a function (will get to functions next).

The commands:


COPY a,b	   copies line a into line b (overriding the current line b)

JUMP a		 jumps execution to line a

BOMB		   destroys the executor that executed this node

SPLIT a		creates a new executor which begins running at line a. Cannot create more than four

MERGE		  deletes the most recently created executor. Cannot delete the initial executor

EDITA a,b	  a is the line number, b is the new a value for that node

EDITB a,b	  a is the line nummber, b is the new b value for that node

EDITC a,b	  a is the line number, b is the new c value for that node

BLANK		  what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can


Note that there are no 'c' fields in usage, but I left the possibility open for both data storage and in case I add more commands later that need a third input value as well


So, a/b/c values are either numbers (usually line numbers, remember that each node refers to itself as line 0) OR functions. So what are functions?


The functions:


a(n)			returns the a value of the node at line n

b(n)			returns the b value of the node at line n

c(n)			returns the c value of the node at line n

add(m,n)		returns m+n

sub(m,n)		returns m-n

mul(m,n)		returns m*n

div(m,n)		returns m/n

mod(m,n)		returns the remainder of m/n

pow(m,n)		returns m^n

com(m,n,o,p,q)  compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q

exe()		   returns the number of executors that you have currently running

num()		   returns the number of lines in the VNA

That's all I've got right now, but I think it's enough. You can nest functions within functions, in case you were wondering - in fact I do that in my example program. I call it 'The Bomber'

COPY 3, 4

EDITB -1, add(b(-1), 1)

JUMP -2

BOMB

Whoa! What's that do? The COPY command copies line 3 (which would be the BOMB) into line 4 (just a BLANK before, now it's a BOMB too). So this part of the VNA looks like this now:

COPY 3, 4

EDITB -1, add(b(-1), 1)

JUMP -2

BOMB

BOMB

In the next round, the next line is executed. The command on this node is EDITB, which edits the b field of a certain line. That line is in EDITB's a field, which is -1, so it's editing the b field of the line right before it. The line is edited to adding the CURRENT b field value [b(-1)] with the number 1. Basically, this EDITB line is incrementing the COPY's b field by 1. So the new code looks like this:

COPY 3, 5

EDITB -1, add(b(-1), 1)

JUMP -2

BOMB

BOMB

The next line is JUMP -2, which sends the executor backwards 2 lines to the COPY node again - phew that was close, we almost hit the BOMB command!

So now the program runs all over again, except this time it copies the BOMB command to line 5 (the next BLANK). Thus, as the executor loops over these three lines, it spews out a chain of BOMBs to eventually march upon the opponent. That's why I call it the Bomber :D

This isn't the perfect Bomber - because it only spews a BOMB command every third round, and the BOMB only advances one node each time. Depending on the size of the VNA, the opponent could have destroyed you by the time you lay the tenth BOMB. One way is to, based on the number of lines in the VNA, skip a certain amount of lines to place the next BOMB.

I made this slightly more complicated program next, I call it the Bomb Evader:

SPLIT -3

JUMP com(exe(),1,4,1,1)

MERGE

EDITA -3, sub(a(-3),2)

JUMP -4

COPY 2, sub(a(-5),7)

JUMP sub(a(-5),8)

JUMP 0

It works by sending a secondary executor backwards toward the opponent, with the initial executor checking to see if it's still alive with exe(). When/if the secondary executor is killed, the executor copies the line 'JUMP 0' to that line and then jumps itself to the JUMP 0 line, thus staying in the same place while the opponent's BOMBs continue past, destroying the original program, looping back around, and killing the Bomber, while the Bomb Evader stays alive. This could fail, however, if the Bomber is, say, 4 lines long and did some math to make a BOMB every 5th line done so that if it looped back around (based on num()) it would avoid itself. Though it would also be unlikely to hit the JUMP 0

If you're interested in building your own battle program and warring with other people, post here :D The cool thing is that I can play too ;D

Link to comment
Share on other sites

  • Answers 197
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 0
get rid of the first three lines (JUMP, BOMB, SPLIT) and then re-place the BOMB and SPLIT after the other lines, so that the COPY is the first line. You'll have to change some of the linepointers to point to the new BOMB instead of -3, and make it SPLIT 47 or 48 or 46 or whatever it is instead of SPLIT 51, etc, but those are minor changes, and you get rid of the pesky JUMP 3 in the beginning which wastes a line and a round ;D

ah, OK, you get rid of the first JUMP by moving the BOMB and SPLIT to after the main program code. I'll give a reason why I didn't do that below, but it actually won't work anyway because I need the split to be before the COPY. Otherwise, when I jump to the SPLIT, I need another JUMP to get back to the start! So the SPLIT needs to stay before the COPY and therefore I need a JUMP as the very first command. After that, I am always inside the program loops, so it only saves a single comand at the start of the game.

However, you are correct that I could move the BOMB to after the program code. But I want a BOMB at the start of all my replicated code so that it cannot be hijacked by a loose executor coming across it. Much better if they run into a BOMB (except for the original code which still has a JUMP in front to get me started).

Edited by foolonthehill
Link to comment
Share on other sites

  • 0

Since activity on this thread has faded a bit, I'm going to share my Eviscerator... it's rediculously deadly against most programs:

The Eviscerator

COPY 16;105;0

COPY 15;add(b(-1),19);0

COPY 14;add(b(-2),-22);0

COPY 13;add(b(-3),-53);0

COPY 12;add(b(-4),46);0

COPY 11;add(b(-5),-35);0

COPY 10;add(b(-6),54);0

COPY 9;add(b(-7),-77);0

COPY 8;add(b(-8),2);0

COPY 7;add(b(-9),-19);0

COPY 6;add(b(-10),20);0

COPY 5;add(b(-11),29);0

COPY 4;add(b(-12),-52);0

COPY 3;add(b(-13),-73);0

EDITB -14;add(b(-14),6);0

JUMP com(b(-15),135,2,2,-15);0;0

BOMB 40;0;0

JUMP com(add(a(a

-1)),add(b(a(-1)),c(a(-1)))),0,com(a(a(-1)),b(a(-1)),com(c(a(-1)),0,1,3,3),3,3),3,3);0;0

EDITA -2;add(a(-2),4);0

JUMP com(a(-3),175,4,4,-2);0;0

COPY -4;add(a(-4),-3);0

EDITA -5;add(a(-5),1);0

JUMP com(a(-6),175,1,1,-2);0;0

COPY 0;add(a(0),c(0));120

EDITA -1;add(a(-1),1);0

JUMP com(a(-2),3,add(c(-2),-2),add(c(-2),-2),-2);0;0

The problem with most Bombers is that they're hilariously inefficient... they bomb once every certain number of rounds (3 is pretty much the MINIMUM) and they do so in a predictable fashion, looping however many nodes til the next space to bomb. This is why I made the Eviscerator :D

The program is 26 lines, though the last 9 lines are the multi-tiered defense system in case it approaches to killing itself or if the code is corrupted, etc, so chopping those off, this is the actual Eviscerator, with my comments in red:

Call the first line "COPY 16.." node 0

COPY 16;105;0 <- drops a bomb 105 spaces away from node 0

COPY 15;add(b(-1),19);0 <- drops a bomb 125 spaces away from node 0

COPY 14;add(b(-2),-22);0 <- drops a bomb 85 spaces away from node 0

COPY 13;add(b(-3),-53);0 <- drops a bomb 55 spaces away from node 0

COPY 12;add(b(-4),46);0 <- drops a bomb 155 spaces away from node 0

COPY 11;add(b(-5),-35);0 <- drops a bomb 75 spaces away from node 0

COPY 10;add(b(-6),54);0 <- drops a bomb 165 spaces away from node 0

COPY 9;add(b(-7),-77);0 <- drops a bomb 35 spaces away from node 0

COPY 8;add(b(-8),2);0 <- drops a bomb 115 spaces away from node 0

COPY 7;add(b(-9),-19);0 <- drops a bomb 95 spaces away from node 0

COPY 6;add(b(-10),20);0 <- drops a bomb 105 spaces away from node 0

COPY 5;add(b(-11),29);0 <- drops a bomb 145 spaces away from node 0

COPY 4;add(b(-12),-52);0 <- drops a bomb 65 spaces away from node 0

COPY 3;add(b(-13),-73);0 <- drops a bomb 45 spaces away from node 0

EDITB -14;add(b(-14),6);0 <- adds 6 to the 'spaces away' of EACH bomber command

JUMP com(b(-15),135,2,2,-15);0;0 <- jumps back to start OR to defense mechanism if getting too close

BOMB 40;0;0 <- the actual BOMB command, waiting at the end of the program

As you can see, every 16 rounds the Eviscerator unleashes 14 statistically even spaced bombs, every 10 nodes from 35 away to 165 away, though not in that predictable order, instead it loosely follows a more statistical route to cover more of the VNA faster. And with a SINGLE edit command, it changes the target of each copy command to jump 6 forward. In just 32 rounds its unleashed 28 bombs covering the VNA in front of it... it's pretty much devastating :P

Link to comment
Share on other sites

  • 0

VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a,b creates a new executor which begins running at line a. b is the index of the executor, from 1 to 5. Use to 0 for b to denote add(exe(),1), in other words fill the next available spot
MERGE a deletes the executor signified by a (1-5). Use 0 to denote the executor with the highest index
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment
SWAP a the current executor trades index numbers with executor 'a'


So, a/b/c values are either numbers (usually line numbers, remember that each node refers to itself as line 0) OR functions. So what are functions?

The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
float(n) returns the float part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
high() returns the highest executor index
line(n) returns the line # that executor n is running at. n must be from 1 to 5. Use 0 to denote the executor with the highest index
e() returns the constant, e
pi() returns the constant, pi
phi() returns the constant, the golden ratio
[/codebox]

What do you think? If we like it, I can change my emulator :D I was going to add trigonometric functions, then decided against it, though I still left the pi constant. As you can see, for commands I changed SPLIT and MERGE, then added EDITX, NODE, EDITI and SWAP. For functions, I added log, base, int, float, equ, geq, leq, high, line, e, pi and phi. I also took away num because it's always 200 lines with max size 30 and program range 30 to 170 away. If that changes we'll know beforehand

So yeah, this should add more functionality and ease for making even better programs ;D I'm sure some crazy stuff can be done with NODE and EDITX (EDITI is just a convenience because I noticed that most EDITs are used to add something to the pre-existing value) and the other stuff I added :P

Link to comment
Share on other sites

  • 0
VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a,b creates a new executor which begins running at line a. b is the index of the executor, from 1 to 5. Use to 0 for b to denote add(exe(),1), in other words fill the next available spot
MERGE a deletes the executor signified by a (1-5). Use 0 to denote the executor with the highest index
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment
SWAP a the current executor trades index numbers with executor 'a'


So, a/b/c values are either numbers (usually line numbers, remember that each node refers to itself as line 0) OR functions. So what are functions?

The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
float(n) returns the float part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
high() returns the highest executor index
line(n) returns the line # that executor n is running at. n must be from 1 to 5. Use 0 to denote the executor with the highest index
e() returns the constant, e
pi() returns the constant, pi
phi() returns the constant, the golden ratio
[/codebox]

What do you think? If we like it, I can change my emulator :D I was going to add trigonometric functions, then decided against it, though I still left the pi constant. As you can see, for commands I changed SPLIT and MERGE, then added EDITX, NODE, EDITI and SWAP. For functions, I added log, base, int, float, equ, geq, leq, high, line, e, pi and phi. I also took away num because it's always 200 lines with max size 30 and program range 30 to 170 away. If that changes we'll know beforehand

So yeah, this should add more functionality and ease for making even better programs ;D I'm sure some crazy stuff can be done with NODE and EDITX (EDITI is just a convenience because I noticed that most EDITs are used to add something to the pre-existing value) and the other stuff I added :P

I think indexing the executors is a ba idea, and will just add numberious lines to our programs. I still think we should leave num() function in. Dont see any need for pi, phi,e,float

Link to comment
Share on other sites

  • 0

Hmm, well mine already uses indexes, 1-5 to store which executor is at which line and which one is running next. I designed the SPLIT and MERGE functions so that you don't have to change anything and it works exactly the same as it did before, ie, SPLIT a,0 is the same as SPLIT a before, and MERGE 0 is the same as MERGE before. So you don't even need to change your code. Though for those that want more control over their executors, SPLIT and MERGE have more versatility now

num() = no. Cuz then we'd have to add other functions returning other constant values such as 30 and 170. num() will always be 200, so we don't need it

pi, phi, e = good idea. I'll remove those. Especially cuz I'm not using the other constant (num)

float = this could be necessary. If we add int(n) we might as well add float(n). Although:

float(n) = sub(n,int(n))

so you're right... it's unncessary to add float(n). I'll remove it too :D

VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a,b creates a new executor which begins running at line a. b is the index of the executor, from 1 to 5. Use to 0 for b to denote add(exe(),1), in other words fill the next available spot
MERGE a deletes the executor signified by a (1-5). Use 0 to denote the executor with the highest index
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment
SWAP a the current executor trades index numbers with executor 'a'


So, a/b/c values are either numbers (usually line numbers, remember that each node refers to itself as line 0) OR functions. So what are functions?

The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
high() returns the highest executor index
line(n) returns the line # that executor n is running at. n must be from 1 to 5. Use 0 to denote the executor with the highest index
[/codebox]

Link to comment
Share on other sites

  • 0
Hmm, well mine already uses indexes, 1-5 to store which executor is at which line and which one is running next. I designed the SPLIT and MERGE functions so that you don't have to change anything and it works exactly the same as it did before, ie, SPLIT a,0 is the same as SPLIT a before, and MERGE 0 is the same as MERGE before. So you don't even need to change your code. Though for those that want more control over their executors, SPLIT and MERGE have more versatility now

num() = no. Cuz then we'd have to add other functions returning other constant values such as 30 and 170. num() will always be 200, so we don't need it

pi, phi, e = good idea. I'll remove those. Especially cuz I'm not using the other constant (num)

float = this could be necessary. If we add int(n) we might as well add float(n). Although:

float(n) = sub(n,int(n))

so you're right... it's unncessary to add float(n). I'll remove it too :D

VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a,b creates a new executor which begins running at line a. b is the index of the executor, from 1 to 5. Use to 0 for b to denote add(exe(),1), in other words fill the next available spot
MERGE a deletes the executor signified by a (1-5). Use 0 to denote the executor with the highest index
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment
SWAP a the current executor trades index numbers with executor 'a'


So, a/b/c values are either numbers (usually line numbers, remember that each node refers to itself as line 0) OR functions. So what are functions?

The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
high() returns the highest executor index
line(n) returns the line # that executor n is running at. n must be from 1 to 5. Use 0 to denote the executor with the highest index
[/codebox]

What will happen if I have a program which "SPLITS" 5 times. using "SPLIT x,0".

Not if I want to merge the current one, I can't. there is no way to do this.

*Suggest change the default value for Merge to "Current Executor"

Now if My Executor #3 is bombed. My total executors is not 4.

Now I want to create a new one, How do I find out that number 3 is empty??

And if I do "Split x,0" 4+1=5 So it will OVERWRITE my #5 executor.

*Solution* have a executor exist function exe( 1 ) will renturn true (1) if executor 1 is alive. But this will involve looping 5 times to check... Makeing programes more complex and larger.

I also think line(n) should be removed. No where is the program is the current line number of any executor usefull and will encorage programs to use absulute lines instead of realitive.

I suggest you change the function geq leq com etc functions to

ifequ( a,b, t,f) where t is the true results, and f the false result

ifgeq

ifleq

ifles

ifgre

iftru

iffal

etc..

Something which you could add which would be usefull would be a rand function

rand(a,b) wil return a random number between a and b. I think this would make the programs really interesting..

Thanks for taking time to consider my suggestions....

PS> I still think you should leave num(). ( Say for example a 3 way battle on a 300 Node Array ;):D

I think moving this handling from the emulator to the user program will scare users of any advanced use of

Link to comment
Share on other sites

  • 0

* I see what you mean about the indexes. I'll remove that stuff

* there's no reason to put "if" in front of each one, that's implied

* I thought about adding rand(m,n) ... I guess it could be useful in placing random bombs or something, though people that use it should be cautious of course ;D I'll add it

* No, no num(). Like I've said a hundred times, if we have a different variety, such as 3 programs in a 300-node VNA, everyone will be informed long beforehand and can edit their programs. Having constants for each pre-known setting just clutters code. No num() or ANY other function constants, and this is the last time I'm saying this lol :D

anyway, thanks for the help and the suggestions! :P This is the newest:

VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a creates a new executor which begins running at line a. Cannot create more than five
MERGE deletes the most recently created executor. Cannot delete the initial executor
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment



The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
rand(m,n) returns a random integer from m to n, inclusive. n>m
[/codebox]

Link to comment
Share on other sites

  • 0
* I see what you mean about the indexes. I'll remove that stuff

* there's no reason to put "if" in front of each one, that's implied

* I thought about adding rand(m,n) ... I guess it could be useful in placing random bombs or something, though people that use it should be cautious of course ;D I'll add it

* No, no num(). Like I've said a hundred times, if we have a different variety, such as 3 programs in a 300-node VNA, everyone will be informed long beforehand and can edit their programs. Having constants for each pre-known setting just clutters code. No num() or ANY other function constants, and this is the last time I'm saying this lol :D

anyway, thanks for the help and the suggestions! :P This is the newest:

VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a creates a new executor which begins running at line a. Cannot create more than five
MERGE deletes the most recently created executor. Cannot delete the initial executor
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment



The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
rand(m,n) returns a random integer from m to n, inclusive. n>m
[/codebox]

To keep the function to some sort of grouping is why I suggest put if in front of all the conditional functions. following this point EDITI Should be EDITXI.

It is possbile to have a character parameter instead of a number

eg

EditX -1,5,c

instead of EditX -1,5,2

I also suggest you rename NODE a to RUN a

Link to comment
Share on other sites

  • 0

* the functions don't need grouping, no need to make it more complicated, they're fine as they are :D

* commands should all be 4 or 5 letters long. I was originally hoping to make them all exactly 4, but it wasn't to be so :( The functions stay, and EDITI stays :)

* I could change NODE to RUN [and in my emulator add an extra space or letter to make it 4 letters], but I like NODE better :P I suppose RUN does fit the purpose of the command better though... hmm... I'll think on this one

* you can't use strings like a or b or c, because the sole point of having an EDITX command (instead of a constant EDIT command) is that you're planning on changing the a/b/c part about it, which means you have to be able to edit the c value of EDITX and change it to something. Because of this, it needs to be a number for both retrieving of it with the c(n) function as well as changing it with the EDITC or EDITX command. Thus a/b/c are represented by numbers. Though I could've picked anything, I think 0/1/2 was the best choice, and can be handled the best mathetically with the mod(m,n) function and whatnot for more efficiency... though if you think they should be represented by different numbers, say so ;D

any ideas for new commands? I thought about a few possible ones, then decided against all of them

Link to comment
Share on other sites

  • 0
VNA 2.0


The commands:

COPY a,b copies line a into line b (overriding the current line b)
JUMP a jumps execution to line a
BOMB destroys the executor that executed this node
SPLIT a creates a new executor which begins running at line a. Cannot create more than five
MERGE deletes the most recently created executor. Cannot delete the initial executor
EDITA a,b a is the line number, b is the new a value for that node
EDITB a,b a is the line nummber, b is the new b value for that node
EDITC a,b a is the line number, b is the new c value for that node
EDITX a,b,c a is the line number, b is the new value, c is 0/1/2 to denote a/b/c to change
BLANK what the original VNA is filled with. You can use BLANK commands too, it's basically a "do-nothing" command. BLANKs cannot hold a/b/c values like other commands can
NODE a execute the command denoted by line a as if it was the current line
EDITI a,b,c a = line number, b is how much is added to the current value, and c is 0/1/2 to denote a/b/c to change. 'I' stands for increment



The functions:

a(n) returns the a value of the node at line n
b(n) returns the b value of the node at line n
c(n) returns the c value of the node at line n
add(m,n) returns m+n
sub(m,n) returns m-n
mul(m,n) returns m*n
div(m,n) returns m/n
mod(m,n) returns the remainder of m/n
pow(m,n) returns m^n
log(m,n) returns log base m of n
base(m,n,o) returns m converted from base n to base o. Both n and o must be less than or equal to 10
abs(n) returns the absolute value of n
int(n) returns the integer part of n
com(m,n,o,p,q) compares m & n. If they are equal, returns o. If m>n, returns p. If n>m, returns q
equ(m,n,o,p) compares m & n. If they are equal, returns o. Otherwise, returns p
geq(m,n,o,p) compares m & n. If m>n or m=n, return o. Otherwise, p
leq(m,n,o,p) compares m & n. If m<n or m=n, return o. Otherwise, p
exe() returns the number of executors that you have currently running
rand(m,n) returns a random integer from m to n, inclusive. n>m
[/codebox]

The changes all look pretty good - and EDITX would have saved me a whole world of issues in 'swarm'! I'm intrigued by NODE (or RUN as Taliesin calls it, which does make some sense :) ), as it means the executors can be protected within a very small loop:

NODE a

JUMP -1

where another line controls the value a.

hmmm. Giving arguments to SPLIT and MERGE make a lot of sense too - the issue I had with swarm was that, if an executor died, there was no way of knowing which one it was, so the rest just had to keep reproducing, hoping that they filled the empty spot!

Edited by foolonthehill
Link to comment
Share on other sites

  • 0

Yeah I figure NODE will be useful (though you would need an EDIT line between NODE and JUMP to control the a-value of the NODE), however it may not actually be as useful as you may think. Even if a BOMB gets planted in one of the lines, the executor will run that just the same if it's told to with NODE. Now that I think about it, the only benefit of NODE that I can see right now is if you want to continually jump 2 forward, skipping a line, and don't want to waste JUMPs to accelerate you to the next spot or something, you could use a NODE-EDIT-JUMP combo to execute only certain lines that you want to. You could put a com() or similar function in the EDIT's b-value that takes input and decides which line to execute next with NODE.... so basically NODE can be used to execute lines in any which order, as long as you have a logical pattern of what the next node to execute is. But it would be more efficient to put them in the best of order as possible with the occasional JUMP or whatever rather than use NODE, because a NODE-EDIT-JUMP combo only executes one line every third

Oh wait a minute, you don't need the EDIT between NODE and JUMP! I see what you mean, you can just use a com() for the NODE's a-value and evaluate input... no EDIT needed. So it's a NODE-JUMP combo. A bit more efficient, but still, NODEs should only be used when it's the best option, though an occasional NODE might be good. It all depends on the program :P

as for SPLIT and MERGE, yeah I was going for more control over the executors too, however as taliesin pointed out, it can get too complicated and paradoxical

So I propose a new command: FLIP. It reverses the order of your executors, making the older one count as the most recently made, etc. So if you had four executors like this:

1: initial executor

2: second executor

3: third

4: fourth

5: N/A

and any one of those executors hit a FLIP command, the new order would be this:

1: fourth

2: third

3: second executor

4: initial executor

5: N/A

and so if it was the SECOND EXECUTOR that hit the FLIP command, the next executor to run wouldn't be the third, it would be the FIRST EXECUTOR. I think this could add some control in deciding which executor to MERGE. What do you guys think? :D

fool: How much simpler do you think you could make Swarm now, with these new ones? Just curious :P

Also, does anyone have any more ideas?

Link to comment
Share on other sites

  • 0
Yeah I figure NODE will be useful (though you would need an EDIT line between NODE and JUMP to control the a-value of the NODE), however it may not actually be as useful as you may think. Even if a BOMB gets planted in one of the lines, the executor will run that just the same if it's told to with NODE. Now that I think about it, the only benefit of NODE that I can see right now is if you want to continually jump 2 forward, skipping a line, and don't want to waste JUMPs to accelerate you to the next spot or something, you could use a NODE-EDIT-JUMP combo to execute only certain lines that you want to. You could put a com() or similar function in the EDIT's b-value that takes input and decides which line to execute next with NODE.... so basically NODE can be used to execute lines in any which order, as long as you have a logical pattern of what the next node to execute is. But it would be more efficient to put them in the best of order as possible with the occasional JUMP or whatever rather than use NODE, because a NODE-EDIT-JUMP combo only executes one line every third

Oh wait a minute, you don't need the EDIT between NODE and JUMP! I see what you mean, you can just use a com() for the NODE's a-value and evaluate input... no EDIT needed. So it's a NODE-JUMP combo. A bit more efficient, but still, NODEs should only be used when it's the best option, though an occasional NODE might be good. It all depends on the program :P

as for SPLIT and MERGE, yeah I was going for more control over the executors too, however as taliesin pointed out, it can get too complicated and paradoxical

So I propose a new command: FLIP. It reverses the order of your executors, making the older one count as the most recently made, etc. So if you had four executors like this:

1: initial executor

2: second executor

3: third

4: fourth

5: N/A

and any one of those executors hit a FLIP command, the new order would be this:

1: fourth

2: third

3: second executor

4: initial executor

5: N/A

and so if it was the SECOND EXECUTOR that hit the FLIP command, the next executor to run wouldn't be the third, it would be the FIRST EXECUTOR. I think this could add some control in deciding which executor to MERGE. What do you guys think? :D

fool: How much simpler do you think you could make Swarm now, with these new ones? Just curious :P

Also, does anyone have any more ideas?

Im not that keen on the FLIP idea, if you want something with this functionally I suggest a SKIP command, SKIP 1 will change to the next executor, skip 2 will run the second.

For running in reverse skip sub(exe() ,1 )

Link to comment
Share on other sites

  • 0

Hmm, I don't think so.... every command is already the equivalent SKIP 1, you know? It doesn't seem practical to have a command to just influence a single switch. If you creator another executor, it has to run too, splitting apart your efficiency. Though SKIP wouldn't really have any effect anyway, as it would take up an executor turn just to do it. If you want to focus all of yours on a certain executor, for example, the current one may say SKIP x to get there (whatever x may be) and then that one runs, but then unless it does SKIP 0 (which would only save itself one turn as it would progress to the next line, so you'd have to have an infinite string of SKIP 0's) then it'll go to the next one after anyway, which could do SKIP -1, but the efficiency is still halved. And you wouldn't be able to figure out the 'x' in SKIP x, because it's not absolute, and due to SPLITs and MERGEs and BOMBs and such, you would have no idea where to skip to. A definite no to SKIP

but FLIP is actually manageable by the programmer and is practical. Why are you 'not keen' on it? It has some good use and is easier to use

Anyway, if there are no further arguments/etc, I'll add FLIP (probably) and finalize VNA 2.0 :D

Link to comment
Share on other sites

  • 0
Hmm, I don't think so.... every command is already the equivalent SKIP 1, you know? It doesn't seem practical to have a command to just influence a single switch. If you creator another executor, it has to run too, splitting apart your efficiency. Though SKIP wouldn't really have any effect anyway, as it would take up an executor turn just to do it. If you want to focus all of yours on a certain executor, for example, the current one may say SKIP x to get there (whatever x may be) and then that one runs, but then unless it does SKIP 0 (which would only save itself one turn as it would progress to the next line, so you'd have to have an infinite string of SKIP 0's) then it'll go to the next one after anyway, which could do SKIP -1, but the efficiency is still halved. And you wouldn't be able to figure out the 'x' in SKIP x, because it's not absolute, and due to SPLITs and MERGEs and BOMBs and such, you would have no idea where to skip to. A definite no to SKIP

but FLIP is actually manageable by the programmer and is practical. Why are you 'not keen' on it? It has some good use and is easier to use

Anyway, if there are no further arguments/etc, I'll add FLIP (probably) and finalize VNA 2.0 :D

Beacause the programmer still knows wehre his exector is stored, what Id it is, and what id is after it.

If I am running on one executor, I have no idea if the one to jump to is before or after the current one. This will require micro management which does not fit into the very small optimized progams required for here..

Link to comment
Share on other sites

  • 0
Yeah I figure NODE will be useful (though you would need an EDIT line between NODE and JUMP to control the a-value of the NODE), however it may not actually be as useful as you may think. Even if a BOMB gets planted in one of the lines, the executor will run that just the same if it's told to with NODE. Now that I think about it, the only benefit of NODE that I can see right now is if you want to continually jump 2 forward, skipping a line, and don't want to waste JUMPs to accelerate you to the next spot or something, you could use a NODE-EDIT-JUMP combo to execute only certain lines that you want to. You could put a com() or similar function in the EDIT's b-value that takes input and decides which line to execute next with NODE.... so basically NODE can be used to execute lines in any which order, as long as you have a logical pattern of what the next node to execute is. But it would be more efficient to put them in the best of order as possible with the occasional JUMP or whatever rather than use NODE, because a NODE-EDIT-JUMP combo only executes one line every third

Oh wait a minute, you don't need the EDIT between NODE and JUMP! I see what you mean, you can just use a com() for the NODE's a-value and evaluate input... no EDIT needed. So it's a NODE-JUMP combo. A bit more efficient, but still, NODEs should only be used when it's the best option, though an occasional NODE might be good. It all depends on the program :P

I think you're missing the biggest benefit that makes NODE incredibly useful: you only need to have one copy of the executing code. For example, with swarm, I had to make sure the code was small because it was being replicated throughout the VNA. With NODE, you only need to know where that code is and multiple executors can then access it.

Of course, if it gets replaced by a bomb then you're in trouble :) !

Edited by foolonthehill
Link to comment
Share on other sites

  • 0
Beacause the programmer still knows wehre his exector is stored, what Id it is, and what id is after it.

If I am running on one executor, I have no idea if the one to jump to is before or after the current one. This will require micro management which does not fit into the very small optimized progams required for here..

Hmmm. I'm not sure about FLIP either. I agree that control over the executor process is good, so that, you can focus activity on a particular executor when necessary and effectively make the others sleep, but the SKIP command would be pretty inefficient as UR says. But what if I wanted to go from executor 4 to executor 2 and miss out 3?

Could there be a command which simply moves an executor within the executor stack. ie they begin the round as 1,2,3,4,5 and EXEC a,b either swaps the position of executors a and b, or moves executor a to position b. eg EXEC 3;1 results in an executor order of 3,1,2,4,5

Link to comment
Share on other sites

  • 0
Hmmm. I'm not sure about FLIP either. I agree that control over the executor process is good, so that, you can focus activity on a particular executor when necessary and effectively make the others sleep, but the SKIP command would be pretty inefficient as UR says. But what if I wanted to go from executor 4 to executor 2 and miss out 3?

Could there be a command which simply moves an executor within the executor stack. ie they begin the round as 1,2,3,4,5 and EXEC a,b either swaps the position of executors a and b, or moves executor a to position b. eg EXEC 3;1 results in an executor order of 3,1,2,4,5

That what I suggested for the SKIP command. SKIP would SKIP Executors.

Skip 2 would move executor from 2 to 4 and execute the command on 4. Also would move the line on executor 2 so it doesn't have a endless loop.

It would create alot of micro management as I mentioned before?

After a Split / Bomb / Split are you using executor 2 or 3?

After Split Split Split Split, Bomb ( on executor 2). Is 2 left blank or is everything moved down one?? How do you know that your executor 2 is the "Dead" one and is empty?

Now another Split using the exe() +1 formula. It replaces number 5??

To make the most of the executors either all this NEEDS to be NOT handled by the program, or by having a lot of advanced functions ( and really long commands )

Edited by taliesin
Link to comment
Share on other sites

  • 0
That what I suggested for the SKIP command. SKIP would SKIP Executors.

Skip 2 would move executor from 2 to 4 and execute the command on 4. Also would move the line on executor 2 so it doesn't have a endless loop.

It would create alot of micro management as I mentioned before?

After a Split / Bomb / Split are you using executor 2 or 3?

After Split Split Split Split, Bomb ( on executor 2). Is 2 left blank or is everything moved down one?? How do you know that your executor 2 is the "Dead" one and is empty?

Now another Split using the exe() +1 formula. It replaces number 5??

To make the most of the executors either all this NEEDS to be NOT handled by the program, or by having a lot of advanced functions ( and really long commands )

I think UR's problem with that is that you effectively get to have 2 commands executed in the same turn - the SKIP 2 command performed by executor 2 and whatever executor 4 does. The alternative is that the command permanently changes the order of executors but that it ends your program's turn. Using my EXEC (that's not a good name, but I can't think of anything else), if executor 2 called EXEC 3,1 to swap executors 1 and 3 then the next executor would be 1, followed by 4, then 3, then back to 2 (assuming 4 executors).

Your point about where SPLIT fills the 'gaps' left by dead executors is an important one though, and one that would require some careful management by the VNA.

Link to comment
Share on other sites

  • 0
I think UR's problem with that is that you effectively get to have 2 commands executed in the same turn - the SKIP 2 command performed by executor 2 and whatever executor 4 does. The alternative is that the command permanently changes the order of executors but that it ends your program's turn. Using my EXEC (that's not a good name, but I can't think of anything else), if executor 2 called EXEC 3,1 to swap executors 1 and 3 then the next executor would be 1, followed by 4, then 3, then back to 2 (assuming 4 executors).

Your point about where SPLIT fills the 'gaps' left by dead executors is an important one though, and one that would require some careful management by the VNA.

and an issure when you need to use Execuitor number for anything ( for example toyr suggested EXEC command

Link to comment
Share on other sites

  • 0

that's why I took out all the exec-indexing in the latest posted version, if you didn't notice :) It's basically a no to SKIP, FLIP, WHIP, QUIP, whatever :P The goal of the multiple executors isn't to be able to make them and then cheat by remanaging your resources - the point is that you can make them if you want to do multiple things at once at different lines, but it halves or thirds (or fourths or fifths) your processing power. That's the point... if you want to make one and then shove it aside, don't waste the lines to do so and not use it

so there will be no more commands/functions related to executors going into VNA 2.0 :D Any other suggestions?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...