--- Log opened Wed Mar 17 00:00:30 2004
01:08:31 -!- grabek [~grabek@nat-b.acn.pl] has quit [Ping timeout: 180 seconds]
01:08:35 -!- grabek [~grabek@nat-b.acn.pl] has joined #corewars
01:35:03 #corewars: < brx> http://ww3.tg.ch/default.cfm?TreeID=1503&CFID=864172&CFTOKEN=75096023 <- www.sharereactor.com
02:46:47 -!- sasha [~sasha@node-423a728a.bos.onnet.us.uu.net] has joined #corewars
02:46:59 #corewars: < sasha> hey.
02:52:16 #corewars: < brx> hey
02:53:51 #corewars: < brx> reboot
02:53:54 -!- brx [~as@pD9EAAF40.dip.t-dialin.net] has quit [leaving]
02:55:18 -!- joonas [jpihlaja@kruuna.helsinki.fi] has joined #corewars
02:55:27 #corewars: < sasha> hi Joonas
02:55:36 #corewars: < joonas> hi sasha
02:55:53 #corewars: < joonas> science.fiction.org is up I see.
02:55:55 #corewars: < sasha> I have a few days of uninterrupted time.  
02:56:27 #corewars: < sasha> yes
02:56:30 #corewars: < joonas> what, a really long weekend? ;)
02:56:58 #corewars: < sasha> well. There are a surprising number of distractions but my biggest is class. (Which I had today.) 
02:57:15 #corewars: < sasha> Grad seminar in Evolutionary theory... 
02:57:36 #corewars: < joonas> what was todays topic?
02:57:37 #corewars: < sasha> I think I've had enough classes for several lifetimes. 
02:57:59 #corewars: < joonas> heh
02:58:38 #corewars: < sasha> http://www.courses.fas.harvard.edu/~oeb271/Weekly_Readings/Week%206%20Readings.htm
02:59:35 #corewars: < sasha> so, after we spoke I remembered a few reasons why I think "films" are important. 
02:59:45 #corewars: < joonas> seems like just what you were talking about
02:59:56 #corewars: < joonas> the reading/topics I mean.
03:00:07 #corewars: < joonas> yes?
03:00:45 #corewars: < sasha> It's a great class and I'm actually using the Coreworld as the bassis of the term paper.
03:01:23 #corewars: < sasha> But I'm still very, very tired of classes. As for films... 
03:02:32 #corewars: < joonas> go on
03:02:42 #corewars: < sasha> they help make it possible to analyze what's going on over many simulations
03:03:06 #corewars: < sasha> you know I want the server to start each new contest where the previous contest left off
03:03:13 #corewars: < joonas> yes
03:03:22 #corewars: < sasha> so where does the new warrior go? 
03:03:31 #corewars: < sasha> put the new warrior on its own film 
03:03:43 #corewars: < sasha> kill off a film in the world. 
03:04:54 #corewars: < sasha> but I do agree this is one of the weakest areas of the whole thing.  Not enough data and lots of speculation. 
03:04:57 #corewars: < joonas> hm.. do you plan to incorporate some kind of movement between films other than the random flip/clear of cells?
03:05:13 #corewars: < joonas> uh, cells -> cores between films.
03:05:34 #corewars: < sasha> Well, one possibility is to chain the films together.
03:05:49 #corewars: < sasha> Say you have ten films in a "water column"... 
03:05:56 #corewars: < joonas> what's a water column?
03:06:14 #corewars: < sasha> a verticle column of water in, say, the ocean... 
03:06:14 #corewars: < joonas> somehow "on top" of each other?
03:06:26 #corewars: < joonas> ok.
03:06:46 #corewars: < sasha> yes.  Then you (periodically) exchange cores directly on top of each other 
03:07:00 #corewars: < joonas> ok.
03:08:16 #corewars: < joonas> so is there any other kind of chaining?
03:08:24 #corewars: < joonas> or linking of films together?
03:08:50 #corewars: < sasha> as I already mentioned I'm thinking of adding privilege or "energy" ... 
03:09:12 #corewars:  * joonas nods
03:09:21 #corewars: < sasha> so there could be a gradient of energy from top to bottom
03:09:40 #corewars: < sasha> a gradient of -new- energy 
03:09:58 #corewars: < sasha> at the end of each simulation the top film could be deleted 
03:10:09 #corewars: < sasha> and a new warrior would be inserted at the bottom 
03:10:44 #corewars: < sasha> so moving up in the water column is a good thing but at the very top you will eventually be eliminated... 
03:10:50 #corewars: < joonas> so the new warrior has zero energy at the beginning?  or does it start with some allotment of energy at first?
03:11:10 #corewars: < sasha> say we charge one unit for mov.i and give you 8000 units
03:11:12 #corewars: < sasha> each film is 10x10 
03:11:20 #corewars: < sasha> (coresize units) 
03:11:22 #corewars: < joonas> ok.
03:11:39 #corewars: < sasha> then you could spread around 80 instructions in every core in the new film
03:11:50 #corewars: < sasha> periodically we delete a core 
03:12:07 #corewars: < sasha> periodically we put some energy in random spots in random cores
03:12:12 #corewars: < sasha> more as you go up the column. 
03:12:33 #corewars: < joonas> how do you harvest the energy from a core cell?
03:13:04 #corewars: < joonas> btw, the labels on the graphs are *really* small
03:13:44 #corewars: < sasha> re. labels -- yeah -- it was OK to print but even then it was my first attempt at using "R". 
03:14:29 #corewars: < joonas> I have some questions about the graphs.
03:15:12 #corewars: < sasha> Ideally I'd like to make the software backward compatible with pmars but that may be a distant goal.   In the meantime suppose we eliminate SPL and replace it with RPR and WPR (suggestions are welcome!) 
03:16:02 #corewars: < sasha> RPR = Read PRivilege and WPR = Write PRivilege 
03:16:25 #corewars: < sasha> what are your questions? 
03:16:48 #corewars: < joonas> ok. hang on.
03:17:09 #corewars: < joonas> 1. why is each film twice?
03:17:52 #corewars: < joonas> 2. why do Blue and Red start from the middle value of fitness almost always?
03:18:05 #corewars: < joonas> 3. and why do the others start from 0 fitness?
03:18:41 #corewars: < joonas> 4. what's wrong with Virulent Virus and No-Quantum-Virus?
03:18:52 #corewars: < sasha> well in the simulation (graph) the "classical" replicator is placed with all the viruses and the "quantum" is placed in its own film. 
03:19:31 #corewars: < sasha> The virulent virus can hurt the classical replicator but it doesn't do much more. 
03:20:07 #corewars: < sasha> should have read "in the TOP simulation" 
03:20:21 #corewars: < sasha> in the bottom simulation the "quantum" replicator is placed with all the viruses. 
03:21:25 #corewars: < joonas> ok, so there are two simulations graphed.
03:21:26 #corewars: < sasha> There are three films and what's on each film in each simulation is labeled. 
03:21:36 #corewars: < sasha> yes. 
03:21:58 #corewars: < joonas> you don't show graphs per film?
03:22:10 #corewars: < sasha> the raw data is there... 
03:22:15 #corewars: < sasha> but not in the graph. 
03:22:38 #corewars: < joonas> I'm a little confused that there are 5x10 graphs on the top.
03:22:39 #corewars: < sasha> actually these graphs are why I think somethine else is required. 
03:22:46 #corewars: < sasha> just replicates
03:23:02 #corewars: < joonas> replicates of what?
03:23:02 #corewars: < sasha> 50 simulations x 2 
03:23:33 #corewars: < joonas> ok
03:24:15 #corewars:  * joonas is still digesting the graphs
03:25:19 #corewars: < sasha> the reason that the "infected" replicators do better than uninfected is that the virus takes over for one task.  I.E. the uninfected warrior has two tasks and therefore runs twice as slowly. 
03:25:56 #corewars: < joonas> the light dawn.
03:25:58 #corewars: < sasha> but if the second task dies then the uninfected warrior will do just as well as infected (if there is no competition)
03:26:05 #corewars: < joonas> dawns even, about the graphs.
03:26:29 #corewars: < joonas> so each graph is graphing one simulation.
03:26:38 #corewars: < sasha> so do you know why some start (seemingly) half way up and others at zero?
03:26:54 #corewars: < sasha> each graph is one simulation -- yes. 
03:27:16 #corewars: < joonas> somehow I thought that a block of 5x5 graphs showed fitness for one simulation, each graph showing fitness in a core.
03:27:25 #corewars: < sasha> the horizontal axis is time.  the vertical axis counts the number of cores that have an active process of that "color". 
03:28:11 #corewars: < sasha> There are three films 5x5 each.  
03:28:18 #corewars: < sasha> so fitness ranges from 0 - 75 
03:28:41 #corewars: < joonas> I still don't understand why some start half-way up.
03:28:57 #corewars: < sasha> well there are two replicators -- red and blue 
03:29:02 #corewars: < sasha> and three viruses that don't replicate
03:29:12 #corewars: < sasha> unless they are replicated by a replicator 
03:29:29 #corewars: < joonas> ok.
03:29:29 #corewars: < sasha> Roy submitted a warrior but (not surprisingly) it didn't replicate. 
03:29:50 #corewars: < sasha> the virulent virus is never replicated. 
03:30:05 #corewars: < sasha> so you can only expect to see red and dark red 
03:30:07 #corewars: < joonas> but I'm looking at the postscript version using a zoom and the red and blue ones definitely don't "climb" from zero at the very start to the middle through replication.
03:30:08 #corewars: < sasha> blue and dark blue 
03:30:12 #corewars: < sasha> or yellow 
03:30:34 #corewars: < sasha> well, they mostly do. 
03:30:59 #corewars: < joonas> so is time measured in cycles?
03:31:08 #corewars: < joonas> what is the unit of time in the graph?
03:31:24 #corewars: < sasha> Time might not be in the same units in those graphs. 
03:31:43 #corewars: < joonas> what do you mean?
03:31:56 #corewars: < sasha> I saw Roy upload a warrior but I was in the middle of changing parameters
03:32:07 #corewars: < joonas> lol
03:32:08 #corewars: < sasha> I should really reset the whole thing. 
03:32:35 #corewars: < sasha> The intent is one million cycles, exchanges between films every ten thousand cycles, 
03:32:50 #corewars: < sasha> deletions every ten thousand cycles (but the first deletion starts at 5,000) 
03:33:02 #corewars: < joonas> ok, so the unit of time is 1000 cycles.
03:33:04 #corewars: < sasha> The graphs have one thousand data points 
03:33:22 #corewars: < sasha> Yes. But I believe the later graphs have 5,000,000 cyles
03:33:38 #corewars: < sasha> which is why it looks like the programs start in the middle
03:33:43 #corewars: < joonas> right, I see now.
03:33:46 #corewars: < sasha> in that number of cycles they fill their films. 
03:34:48 #corewars: < sasha> so suppose we execute at every location with "energy". 
03:35:14 #corewars: < sasha> energy moves around in the usual way that task pointers move 
03:35:34 #corewars: < joonas> ok
03:35:51 #corewars: < joonas> it's not spent by executing?
03:36:08 #corewars: < sasha> first pass will only charge for mov.i
03:36:12 #corewars: < joonas> ok, good.
03:36:14 #corewars: < sasha> (I think.) 
03:36:26 #corewars: < joonas> heh
03:36:27 #corewars: < sasha> but you still need at least one unit of energy to have a task pointer at all.
03:36:32 #corewars: < joonas> ok.
03:36:50 #corewars: < sasha> syntax of the rpr and wpr needs to be worked out
03:37:44 #corewars: < joonas> maybe you only need a "move energy instruction"
03:37:58 #corewars: < joonas> so you need to allocate core cells to hold your excess energy
03:38:19 #corewars: < sasha> well you want to know how much is there. 
03:38:30 #corewars: < joonas> and when you want to spawn another process you must move some energy wherever it will start executing.
03:38:46 #corewars: < sasha> yeah that's what I had in mind. 
03:39:24 #corewars: < joonas> in the beginning for a new warrior, you could either put the energy linearly right after the warrior's load position, or randomly distribute it in his core.
03:40:01 #corewars: < sasha> well, you might as well put it on the spot where "end" points. 
03:40:11 #corewars: < sasha> just as it works now...
03:40:23 #corewars: < joonas> so a core cell can have more than one unit of energy?
03:40:25 #corewars: < joonas> ah, of course.
03:40:44 #corewars: < joonas> otherwise you couldn't have two task pointers pointing at the same insn.
03:41:08 #corewars: < sasha> well... I don't know about that... 
03:41:21 #corewars: < joonas> so how about mov.i moving one unit of energy from the source location to the destination location?
03:41:37 #corewars: < joonas> hm.. no.
03:42:09 #corewars: < joonas> don't know about what?
03:42:12 #corewars: < sasha> As I mentioned before I wanted to eliminate "hidden" state but
03:42:25 #corewars: < sasha> it might be a bad idea to eliminate task pointers. 
03:42:53 #corewars: < sasha> If energy replaces task pointers (a kind of "c" field in every instruction.) 
03:43:13 #corewars: < sasha> then it's true you wont be able to have two pointers to the same instruction in core. 
03:43:50 #corewars: < sasha> because, implementation wise, I'd imagine an array with every location with priv. >0 
03:44:02 #corewars: < sasha> if I have say n such locations then 
03:44:14 #corewars: < joonas> n locations with priv > 0?
03:44:43 #corewars: < joonas> hm.. wait, when you say "an array with every location"
03:44:54 #corewars: < joonas> do you mean that every core location has an array attached to it?
03:45:14 #corewars: < sasha> I'd just choose n random numbers ranging from 1 to n every cycle.  locations whose priv. became 0 or >0 that cycle would be added to the array NEXT cycle. 
03:45:35 #corewars: < joonas> or do you mean that every core location has an extra field that maintains the energy of that  cell?
03:45:36 #corewars: < sasha> each film has an array that, in principle, 
03:45:57 #corewars: < sasha> could be number of cores multiplied by number of locations per core
03:46:21 #corewars: < joonas> I see.
03:46:37 #corewars: < sasha> this replaces the separate warrior and task queues I have currently in each core 
03:46:59 #corewars: < joonas> hm.. it sounds like your execution model is more like rasmussen's core world rather than traditional core war.
03:47:37 #corewars: < joonas> implementation wise you'd probably still need some kind of task queue.
03:47:57 #corewars: < joonas> maybe a single global task queue rather than per warrior queues.
03:48:53 #corewars: < joonas> or if not a queue, then a set at least.
03:48:54 #corewars: < sasha> well, you would need a pointer to the core location and it would help if you could figure out which core the pointer belongs to if necessary. 
03:49:52 #corewars: < sasha> One pass through the entire array lets you delete a core (or swap cores) 
03:49:57 #corewars: < joonas> do you intend to execute cells with energy in a random order or some fixes order?
03:50:17 #corewars: < sasha> random. 
03:50:41 #corewars: < sasha> on average you get the same amount of time but generally there can be a great deal of variability. 
03:51:08 #corewars: < sasha> my experience in the existing model has been very good but concurrency primitives were pretty much necessary. 
03:51:15 #corewars: < joonas> hm.. that means I guess, that the same cell will be eligible to execute twice?
03:51:21 #corewars: < sasha> Test and Set 
03:51:55 #corewars: < sasha> yes. in one core you could have many things going on
03:52:17 #corewars: < joonas> is that mostly due to the way ports work?
03:52:32 #corewars: < joonas> I mean the test-and-set insns being required.
03:52:42 #corewars: < sasha> partially. 
03:52:57 #corewars: < sasha> suppose you are trying to write "mice" for the coreworld
03:53:27 #corewars: < sasha> because of the masochistic port mechanism I used you were required to spawn a process on the other side of the port to help you
03:54:04 #corewars: < sasha> but this other process is not synchronous with you. (because of the randomization) 
03:54:06 #corewars: < joonas> re: same cell being able to execute more than once per cycle, IMHO that's a horrible idea.  if a process can't even rely on being executed serially (w.r.t. itself, not other processes) then programming it will be a major headache.
03:54:38 #corewars: < sasha> the same process is, of-course, executed serially.  
03:55:19 #corewars: < joonas> if a cell can only have one process in it, then it can't execute more than once in a cycle, right?
03:56:38 #corewars: < sasha> if a core has 8000 locations each with >0 priv. and JMP 0 then all of those will happily execute in the same cycle.  If that's the only core in the film then each cycle 
03:56:55 #corewars: < sasha> some of those will execute once, others will execute 0 times, and others 2+ 
03:57:26 #corewars: < joonas> I don't understand.
03:58:30 #corewars: < joonas> first: each cell either has or hasn't priv (i.e. is it a boolean thing?)
03:59:04 #corewars: < sasha> I often say cell=core 
03:59:17 #corewars: < sasha> so then I don't say a core has 8000 cells. 
03:59:23 #corewars: < sasha> I say a core has 8000 locations. 
03:59:36 #corewars: < sasha> Are you talking about cells or locations
03:59:45 #corewars: < joonas> oh.  I say a core has 8000 cells.
03:59:53 #corewars: < joonas> so we're confusing each other.
04:00:09 #corewars: < sasha> yeah. (I say that too but it's VERY confusing to a biologist.) 
04:00:35 #corewars: < joonas> so we'll talk about locations and cores, then, and avoid the term cell.
04:00:55 #corewars: < sasha> In writing I avoid the word cell entirely and say core=compartment 
04:01:20 #corewars: < sasha> =)
04:01:31 #corewars: < joonas> :)
04:02:03 #corewars: < joonas> so with our terms set straight, couuld you talk me through privs and energy and processes again?
04:02:18 #corewars: < joonas> here's how I thought you meant it:
04:02:45 #corewars: < joonas> - each location has a boolean flag "priv" that says whether the location has one unit of "energy".
04:03:00 #corewars: < sasha> So. A location in core has: OPCODE, MODIFIER, MODEA, MODEB , OP-A mod Coresize , OP-B mod Coresize , Priv mode Coresize, Qubit  (Hidden Genotype ID.)
04:03:34 #corewars: < joonas> ok, except the bit about Priv.
04:04:06 #corewars: < sasha> why Priv. mod Coresize? 
04:04:15 #corewars: < joonas> yes.
04:05:00 #corewars: < joonas> and what priv=0 and priv>0 mean.
04:05:42 #corewars: < sasha> in traditional corewar priv=0 means there is no pointer in any task queue pointing at that location
04:05:52 #corewars: < joonas> ok
04:06:05 #corewars: < sasha> priv >0 doesn't matter except for MOV.I which reduces
04:06:09 #corewars: < sasha> priv. by 1 
04:06:29 #corewars: < joonas> priv of the location where the MOV is, you mean?
04:06:38 #corewars: < sasha> Every instruction moves priv. around... 
04:06:52 #corewars: < sasha> Just as, now, every instruction changes task pointers... 
04:07:00 #corewars: < joonas> ok.
04:07:12 #corewars: < sasha> that was the thought.  but you have a good idea. 
04:07:44 #corewars: < sasha> hmmm...
04:07:45 #corewars: < joonas> so how much priv does a process get in the beginning?
04:08:03 #corewars: < sasha> well, continuing with what I had in mind... 
04:08:38 #corewars: < sasha> I mentioned before we could start a "genotype" (warrior) out with Coresize priv. at the location where it would normally have its taskpointer.
04:08:49 #corewars: < joonas> ok
04:09:01 #corewars: < joonas> so priv isn't mod coresize after all?
04:09:10 #corewars: < sasha> Well Coresize-1  
04:09:15 #corewars: < joonas> ok.
04:09:31 #corewars: < sasha> smile. It's really arbitrary. 
04:09:36 #corewars: < joonas> :-D
04:09:53 #corewars: < joonas> heh
04:09:54 #corewars: < sasha> The point is that depending on the size of the film 
04:10:15 #corewars: < sasha> the amount of instructions you can spread around will be determined by that number 
04:10:35 #corewars: < sasha> so if you have a ten by ten film. you can have about 80 instructions in every core. 
04:10:47 #corewars: < joonas> 'k
04:11:32 #corewars: < sasha> As I mentioned I want to replace ports with a "dual" modifier. 
04:11:40 #corewars: < joonas> yes.
04:12:17 #corewars: < sasha> Syntax I have in mind is something like MOV.A' 0, 1 
04:12:33 #corewars: < joonas> looks reasonable
04:13:10 #corewars: < sasha> moves the executing instruction to the dual core. 
04:13:37 #corewars: < joonas> oh.  it *looks* like it would move the.. ah, right... hm.
04:13:46 #corewars: < sasha> So copies to location PC+Coresize/2+1 
04:14:34 #corewars: < sasha> Whether the dual core is up, right, down, or left depends on destination. 
04:14:45 #corewars: < joonas> can you change the destination?
04:15:07 #corewars: < sasha> yeah. you can copy to 1/4 of each neighboring core. 
04:15:36 #corewars: < joonas> so you have a SetDual instruction or something?
04:15:40 #corewars: < sasha> this means my replicators will be tiny and will no longer have to synchronize with a process in the other compartment. 
04:15:51 #corewars: < sasha> no setdual. 
04:15:56 #corewars: < sasha> that's what the ' was for. 
04:16:12 #corewars: < joonas> right, this is why I thought you might not need the concurrency instructions.
04:16:13 #corewars: < sasha> If you put it before the modifier it means the a operand refers to the dual core
04:16:25 #corewars: < sasha> if you put it after the modifier it means the b operand refers to the dual core. 
04:17:19 #corewars: < joonas> by changing the destination I meant whether or not you could set which direction (up/do/le/ri) the dual was.
04:17:25 #corewars: < sasha> I'm still sure you will want the concurrency instructions because coordinating with your fellow(s) is somethign you want to do... 
04:18:00 #corewars: < joonas> also, the MOV.A' syntax looks like it would move the a field of the source to the a-field of the destination location.
04:18:24 #corewars: < sasha> it moves the a field of the current location a "0" 
04:18:42 #corewars: < sasha> to the a field of the dual PC+Coresize/2+1 
04:19:11 #corewars: < joonas> ok, right, I meant the destination location in the dual.
04:19:19 #corewars: < sasha> (if it was a 20) it would be PC+Coresize/2+20
04:19:20 #corewars: < joonas> but why do you have the term Coresize/2+1 ? 
04:19:27 #corewars: < joonas> but why do you have the term Coresize/2 ? 
04:19:40 #corewars: < sasha> You really need to look at a diagram.
04:19:45 #corewars: < sasha> I have one just a sec... 
04:20:40 #corewars: < sasha> Do you have the PDF from my "PQE talk?" 
04:20:50 #corewars: < joonas> not anymore.
04:20:56 #corewars: < joonas> where's the url
04:20:57 #corewars: < joonas> ?
04:21:04 #corewars: < sasha> It's at: http://non.fiction.org/~await/qcw/pqe-talk.pdf
04:21:33 #corewars: < sasha> Look at page 28. 
04:21:48 #corewars: < joonas> it's still making the transatlantic journey
04:21:58 #corewars: < joonas> ok, looking.
04:22:09 #corewars: < sasha> So. I've modified the way that pmars displays the core
04:22:24 #corewars: < sasha> the first 2000 locations are displayed in the upper left quarter
04:22:31 #corewars: < sasha> then 2000 locations upper right
04:22:49 #corewars: < sasha> then 2000 locations LOWER RIGHT 
04:22:55 #corewars: < sasha> then 2000 locations lower left 
04:23:10 #corewars: < sasha> So an imp will go "clockwise" around the core
04:23:23 #corewars: < joonas> ok
04:24:25 #corewars: < joonas> the arrows don't make much sense to me
04:24:30 #corewars: < sasha> so absolute locations 0-1999 will point to absolute locations 
04:24:51 #corewars: < sasha> 4000-5999 in the core directly above it. 
04:25:46 #corewars: < joonas> sorry, you lost me
04:25:56 #corewars: < joonas> what are absolute locations?
04:26:17 #corewars: < sasha> all addressing in corewar is PC relative. but memory still has absolute addressing
04:26:21 #corewars: < sasha> (internally)
04:26:28 #corewars: < joonas> yes
04:27:07 #corewars: < joonas> I don't understand how absolute locations can "point" to anything.
04:27:17 #corewars: < sasha> so eventually addrA and addrB are absolute addresses in pmars. 
04:27:39 #corewars: < joonas> yes..
04:27:40 #corewars: < sasha> every absolute address has a "dual" 
04:28:06 #corewars: < sasha> the picture shows how address 0 = 4000 in the core above it. 
04:28:16 #corewars: < sasha> address 2000 = 6000 in the core to its right
04:28:26 #corewars: < sasha> adress 4000 = 0 in the core below. 
04:28:44 #corewars: < sasha> address 6000=2000 in the core at the left.
04:28:47 #corewars: < joonas> ok
04:28:51 #corewars: < joonas> I see now.
04:28:53 #corewars: < sasha> without the factor Coresize/2 this would not work. 
04:28:59 #corewars: < joonas> hm.
04:29:58 #corewars: < sasha> This is my fifth time going through this -- implementing a "multicore" and then writing warriors -- I thin it's a step forward but what do you think?
04:30:30 #corewars:  * joonas is thinking
04:31:27 #corewars: < joonas> I'm thinking that basing the dual core on the absolute address is breaking the notion in CW that core is cyclical.
04:31:32 #corewars: < joonas> a single core that is.
04:32:06 #corewars: < joonas> maybe it could be rather be based on the distance between the PC and the absolute address.
04:32:29 #corewars: < sasha> so, up to now, my replicators are not relocatable because ports were at fixed -absolute- locations. 
04:32:42 #corewars: < sasha> but what i've now proposed IS relocatable. 
04:32:49 #corewars: < sasha> a program will work no matter where in core it is.
04:33:02 #corewars: < sasha> unless it's at a "boundary". 
04:33:23 #corewars: < sasha> i.e. mice writes half of itself into the upper core and the other half into the right core.
04:33:50 #corewars: < sasha> It's all slightly counterintuitive. 
04:33:50 #corewars: < joonas> so address PC would always map to the dual address PC in the core to the left of it, address PC+2000 would map to the dual address PC+2000 in the core above it, PC+4000 -> PC+4000 in down core, PC+6000 -> PC+6000 in right core.
04:34:24 #corewars: < joonas> in the case where the dual is based on the distance of the absolute address from PC.
04:34:49 #corewars: < sasha> confused...
04:35:00 #corewars: < sasha> I think you are suggesting what I've suggested.
04:35:07 #corewars: < joonas> possibly...
04:35:07 #corewars: < sasha> (and badly explained.)
04:35:29 #corewars: < sasha> so mov.A' 0, 1 
04:35:45 #corewars: < sasha> is located (for example) at location 1500 
04:36:08 #corewars: < joonas> in my model the absolute location of mov.A' wouldn't matter.
04:36:13 #corewars: < joonas> which is my point.
04:36:43 #corewars: < sasha> hm. 
04:37:07 #corewars: < sasha> ah
04:39:12 #corewars: < joonas> actually, let me refine it a little bit.
04:39:18 #corewars: < sasha> go ahead
04:40:31 #corewars: < joonas> the absolute locations [PC-CORESIZE/4, ..., PC+CORESIZE/4-1] should correspond to the same locations in the left dual core.
04:41:10 #corewars: < joonas> sorry, make those CORESIZE/8
04:41:45 #corewars: < joonas> the idea is that the core cells surrounding the PC should correspond always to "left" dual core.
04:41:47 #corewars: < joonas> and 
04:42:57 #corewars: < joonas> "right" is the next CORESIZE/4 locations, 
04:43:15 #corewars: < joonas> "up" the next CORESIZE/4, and finally "down" are the last CORESIZE/4 locations
04:43:48 #corewars: < joonas> the actual directions don't matter. it could be "left", "up", "right", "down" instead.
04:44:16 #corewars: < joonas> all this is *relative* to the PC.
04:44:36 #corewars: < sasha> hm. 
04:46:16 #corewars: < joonas> the reason for taking [PC-CORESIZE/8, PC+CORESIZE/8-1] is that MOV.A' 0, -1 addresses the same dual core as MOV.A' 0, 1
04:47:00 #corewars: < joonas> (this is picked up from the 94 draft read/write limits that work this way.)
04:47:16 #corewars: < sasha> What I didn't want is being able to address the entire core from the current core. 
04:47:26 #corewars: < joonas> right, that's not happening.
04:47:45 #corewars: < sasha> well, you can by moving around no? 
04:48:01 #corewars: < joonas> hm. you mean addressing the entire core from within the same core?
04:48:17 #corewars: < joonas> or the entire dual core?
04:48:25 #corewars: < joonas> ...from one location.
04:48:30 #corewars: < joonas> the latter isn't happening.
04:49:09 #corewars: < joonas> from one location you're able to access 1/4 of all dual cores, and you get to pick which dual core you access.
04:49:52 #corewars: < sasha> but with indirection you get everything? don't you?
04:50:03 #corewars: < joonas> and the most important point is that the way you pick the left dual core, say, doesn't change according to what location you're at.
04:50:25 #corewars: < joonas> no, because the choice of the dual core is done at the very end of operand evaluation.
04:50:48 #corewars: < sasha> ah.
04:51:24 #corewars: < joonas> starting to make sense?
04:51:34 #corewars: < sasha> suppose you have a bunch of dwarfs (all executing in parallel as we've discussed) 
04:51:43 #corewars: < joonas> yes
04:51:52 #corewars: < sasha> they can cover all four neighbors completely? 
04:52:48 #corewars: < joonas> hm.. well one dwarf could cover one quarter of each neighbour.
04:53:28 #corewars: < sasha> yes. and four could cover all of each neighbor
04:53:29 #corewars: < joonas> yes, if they are evenly spaced in core.
04:53:49 #corewars: < sasha> I think the absolute addressing is better than it sounds. 
04:54:12 #corewars: < joonas> ok
04:55:41 #corewars: < sasha> of-course, we can try both but the point of having "locality" is that you have some separation from the enemy.  If you know the enemy can only come from one side then you can put your code out of harms way and attack as entry into your core is attempted...
04:56:10 #corewars: < joonas> oh, I didn't mean "ok" to sound so blunt. :)
04:56:40 #corewars: < joonas> yes, I see.
04:56:45 #corewars: < sasha> i made the ports really restrictive because I wanted to analyze the contests. It's hard (but not impossible because of the stochastic execution system) to slip through 
04:57:02 #corewars: < sasha> this will make it much easier but still harder ... 
04:58:07 #corewars: < sasha> (than the read/write model.)  I've thought about read/write limits for a long time (since 1994?!?) but as I mentioend I didn't they they solved any problems. 
04:58:44 #corewars: < sasha> That is, I thought the problem was being confined to a 1-dimensional space. 
04:59:25 #corewars: < joonas> my basic concern was that you could be addressing a different dual core by accident since you can't know, due to the relative nature of executing in a core, what the dual of an operand is.
04:59:43 #corewars: < sasha> i know. 
04:59:45 #corewars: < sasha> this is a problem. 
05:00:10 #corewars: < joonas> re: read/write limits, IMHO they've not been explored enough to be able to say that one dimensionality is a problem.
05:00:35 #corewars: < sasha> In my simulations it was perfectly fine to start every program in the same core at absolute lcoation 0 
05:00:39 #corewars: < joonas> a second dimension is exciting nevertheless.
05:00:43 #corewars: < sasha> well... 
05:01:50 #corewars: < sasha> Re. read/write limits.  I agree that exploring a restricted 1d space in Corewar is still interesting. 
05:02:39 #corewars: < joonas> consider that there are only a handful of read/write limited warriors, and no real hill since the ibm hill went away.  (and I'm not sure even that supported a read/write limited hill.)
05:03:08 #corewars: < joonas> anyway, back to the quantum coreworld.
05:03:14 #corewars: < sasha> smile. 
05:03:25 #corewars: < joonas> :-D
05:03:36 #corewars:  * joonas wonders why he's being told to smile every now and then
05:03:49 #corewars: < joonas> you mentioned stochastic execution model.
05:04:18 #corewars: < joonas> and that a core location can be executed more than once per cycle.
05:04:22 #corewars: < sasha> [laughing] so how do I say I'm smiling? (without using a smiley)
05:04:23 #corewars: < sasha> =^) 
05:04:52 #corewars: < joonas> can you say you're smiling without a smiley?  what a strange concept. :)
05:05:04 #corewars: < joonas> ./me smiles
05:05:07 #corewars: < joonas> without the "."
05:05:41 #corewars:  * sasha smiles 
05:05:49 #corewars: < sasha> oh. 
05:05:50 #corewars:  * joonas grins back
05:05:55 #corewars: < sasha> that's very advanced.
05:06:07 #corewars: < sasha> I'm not ready for that. 
05:06:25 #corewars: < joonas> ok, baby steps.  keep smileying for now.
05:06:34 #corewars:  * sasha laughing
05:06:58 #corewars: < sasha> The stochastic execution model, you say?
05:07:24 #corewars: < joonas> hey, you're getting the hang of it!  before you know it you'll be "w00t"ing and loling like a pro.
05:07:30 #corewars: < joonas> yes
05:07:37 #corewars: < sasha> So a film consists of a 2d grid of cores as arranged in the pqe-talk (pg28) 
05:07:44 #corewars: < joonas> ok
05:08:25 #corewars: < sasha> Within each of those cores every location with priv > 0 is executed, on average, once per cycle. 
05:08:50 #corewars: < joonas> why not exactly once per cycle?
05:09:49 #corewars: < sasha> because too much depends on the execution order 
05:10:06 #corewars: < sasha> one possibility is to shuffle the execution order
05:10:10 #corewars: < joonas> well you could permute the order
05:10:13 #corewars: < sasha> (every cycle) 
05:10:22 #corewars: < sasha> yep 
05:10:23 #corewars: < joonas> yes, using a random permutation.
05:10:48 #corewars: < joonas> hm. ah
05:10:56 #corewars: < sasha> ah?
05:11:03 #corewars: < joonas> ah!
05:11:36 #corewars: < sasha> [honestly] I don't know of an o(1) way to do that. 
05:11:53 #corewars: < joonas> so when you were saying that a process executes twice, you meant that the privs were being updated within the same cycle.
05:12:36 #corewars: < joonas> you maintain a set using two arrays:
05:13:05 #corewars: < joonas> the first array the same as your priv array.
05:14:28 #corewars: < joonas> hm... hang on.
05:14:40 #corewars: < joonas> I've explained this once.. I'll find the url.
05:15:09 #corewars: < sasha> sure. 
05:16:29 #corewars: < sasha> This comes up in the concurrency literature (that I don't know especially well) but I realized that whatever the solution was might not be as nice as an AVERAGE of 1 execution step per cycle. 
05:17:34 #corewars: < joonas> http://www.cs.helsinki.fi/u/jpihlaja/colouring.ps
05:17:58 #corewars: < joonas> section 5 on sets of integers
05:18:04 #corewars: < sasha> In Biology replication is a complicated process that uses various check-point mechanisms to make sure everything stays synched.  Different parts of the process, of-course, occur at the same time and don't happen in exactly the same amount of time. 
05:18:35 #corewars: < sasha> Thank-you for the link. 
05:19:12 #corewars: < joonas> a short writeup of a data structures course work thing.
05:19:24 #corewars: < joonas> graph colouring in linear time.
05:19:55 #corewars: < joonas> came up with the O(1) operation priority queue all by myself too.
05:19:58 #corewars:  * joonas shows a little pride
05:20:18 #corewars: < sasha> Nice. 
05:20:19 #corewars: < joonas> it's well known, of course.
05:21:03 #corewars: < joonas> the integer set supports all operations you need in O(1) time too.
05:21:26 #corewars: < sasha> Yeah. I switched to the 1 step per cycle on average model in version 1 (2?) of the multicore but only fixed the resulting task-queue overruns in version 4.
05:21:44 #corewars: < joonas> lol
05:21:49 #corewars: < joonas> I feel your pain.
05:22:10 #corewars: < sasha> task queues of all warriors are in the same memory array in pmars
05:22:33 #corewars: < joonas> yes.
05:23:16 #corewars: < sasha> =^) I worked around the "problem" by making the size of taskqueue 500,000+
05:23:32 #corewars: < joonas> :)
05:23:52 #corewars: < sasha> [Sigh] 
05:24:50 #corewars: < joonas> I can send you an implementation of the integer set if you want.  clean & lean code too -- not like my usual stuff.
05:25:28 #corewars: < sasha> so by making execution stochastic, eliminating spl and replacing it with priv., and adding 2D locality (with the dual modifiers) we have what?
05:25:52 #corewars: < joonas> QCW?
05:25:53 #corewars: < sasha> still need to nail down read/write priv. 
05:26:15 #corewars: < sasha> still need atomic test and set/clear 
05:26:37 #corewars: < joonas> from your first description I thought privs were boolean flags.
05:26:41 #corewars: < sasha> If you want a reasonable chance to co-operate with new programs that you spwan
05:26:55 #corewars: < joonas> and that one cell could only hold one unit of energy.
05:27:07 #corewars: < sasha> you don't think that anymore?
05:27:35 #corewars: < joonas> no. you said priv was a number between 0 and coresize
05:27:42 #corewars: < sasha> yes. 
05:27:49 #corewars: < joonas> so one priv could hold coresize-1 units of energy.
05:27:54 #corewars: < sasha> yes
05:28:02 #corewars: < sasha> one location
05:28:07 #corewars: < joonas> right
05:28:10 #corewars: < joonas> typo
05:28:54 #corewars: < sasha> my current plan is to stay with SCC and SCS 
05:29:02 #corewars: < sasha> Skip if Clear then Cleear
05:29:08 #corewars: < sasha> Skip if Clear then Set
05:29:31 #corewars: < sasha> This operation changes -does- change a single bit. 
05:29:56 #corewars: < joonas> what bit?
05:30:14 #corewars: < joonas> qubit?
05:30:28 #corewars: < sasha> yes. But with no quantum instructions it's just a bit. 
05:30:46 #corewars: < sasha> SEQ.I and SNE.I and MOV.I also affect this bit. 
05:30:57 #corewars: < sasha> All other instructions have no effect. 
05:31:08 #corewars: < sasha> Except for QOP/QCN. =^) 
05:31:29 #corewars: < joonas> what's QOP?
05:31:34 #corewars: < joonas> and QCN?
05:31:56 #corewars: < joonas> you mentioned in one paper that QOP affected a Quantum OPeration on a qubit
05:32:23 #corewars: < sasha> A QOP is a "single qubit" operation. (It's a 2 by 2 matrix with complex number entries that satisfies certain algebraic properties.) 
05:32:44 #corewars: < sasha> QCN is the "quantum control not" operation. 
05:33:01 #corewars: < joonas> ah, ok.
05:33:04 #corewars: < sasha> My plan for QOP is to predefine a bunch of these matrices
05:33:19 #corewars: < joonas> so it's something like: QCN controller, controllee
05:33:26 #corewars: < sasha> Arg. A specifies the qubit Arg. B specifies the matrix 
05:33:45 #corewars: < sasha> A kludge but it seemed reasonable.  
05:34:28 #corewars: < sasha> It's known that only a very small number of these are "necessary".
05:34:59 #corewars: < sasha> if we end up with too many predefined matrices then it creates a lower bound on coresize which is weird. 
05:35:39 #corewars:  * joonas wishes he'd read the paper more closely.
05:35:44 #corewars: < joonas> from www.qubit.org
05:36:27 #corewars: < joonas> hang on, you needed QCN and phase shift operations to be complete, no?
05:36:35 #corewars: < joonas> or those were complete at least.
05:36:45 #corewars: < joonas> or maybe not.
05:36:51 #corewars: < sasha> There a good intro here: http://arxiv.org/abs/quant-ph/0207171
05:37:43 #corewars: < sasha> yeah. you need nearly ANY single qubit op and control-not but hadamard alone is NOT enough. 
05:37:57 #corewars: < sasha> hadamard + control-not is not enough.
05:38:32 #corewars: < sasha> but obviously if somebody had a single qubit operations they wanted we would just give it to them. 
05:38:54 #corewars: < joonas> so QOP would be an arbitrary phase shift
05:39:01 #corewars: < joonas> with resolution CORESIZE
05:39:08 #corewars: < joonas> ?
05:39:51 #corewars: < sasha> QOP 1, #0 does nothing
05:39:57 #corewars: < sasha> QOP 1, #1 does hadamard
05:40:04 #corewars: < sasha> QOP 1, #2 does something else
05:40:19 #corewars: < sasha> QOP 1, #3 something else 
05:40:32 #corewars: < sasha> same syntax as JMZ and friends 
05:40:42 #corewars: < sasha> syntax = defaults
05:41:05 #corewars: < joonas> so how do you do a phase shift of 33 degrees?
05:42:45 #corewars: < sasha> looked at source
05:43:05 #corewars: < sasha> #2 is sigma x 
05:43:12 #corewars: < sasha> #3 sigma y
05:43:15 #corewars: < sasha> #4 sigma z 
05:43:34 #corewars: < sasha> There are a few sites that give circuits for various things 
05:44:14 #corewars: < sasha> Single qubit matrices are pretty easy to "evolve" with genetic algorithms but for now we could just add
05:44:25 #corewars: < joonas> ah, this one was what I was looking at: http://arxiv.org/abs/quant-ph/9708022
05:44:41 #corewars: < joonas> no, sorry wasn't it.
05:44:50 #corewars: < sasha> #5 = phase shift 33deg
05:45:51 #corewars: < sasha> to do something really interesting you'd probably need to write a compiler that produced the redcode instruction that do what you want... 
05:46:15 #corewars: < joonas> www.qubit.org/library/intros/comp/houches.ps
05:46:41 #corewars: < sasha> not necessarily very hard but as you know my first priority is to make the Coreworld of interest to biologists. 
05:47:33 #corewars: < sasha> All three of those people are very cool.  It's probably a good paper!
05:47:37 #corewars: < joonas> ah, this was the quote I was remembering:
05:48:00 #corewars: < joonas> the hadamard gate and the phase gate can be combined to construct any unitary operation
05:48:23 #corewars: < joonas> so all you need is hadamard, phase shift, and QCN.
05:49:19 #corewars: < joonas> phase shift you can probably do at 2Pi/CORESIZE steps only
05:49:27 #corewars: < sasha> yeah. there are a "million" papers exploring these but given that we are assuming "perfect" gates I think the intention of the coreworld is to allow any unitary gate.  For example, if programs were allowed to specify in their genotype the definition of qop that would be perfectly fine. 
05:50:12 #corewars: < sasha> with the sigma gates you can get arbitrarily fine precision
05:50:17 #corewars: < sasha> if you are willing to wait long enough. 
05:50:23 #corewars: < sasha> don't need anything else. 
05:51:11 #corewars: < sasha> (But N.B. I've already said it's fine if meaning of QOP is specific to each genotype.)
05:51:20 #corewars: < joonas> but they take a parameter.
05:51:29 #corewars: < joonas> yes, ok.
05:51:40 #corewars: < sasha> It's just a two by two matrix with complex entries so
05:51:46 #corewars: < sasha> a total of eight real numbers
05:52:13 #corewars: < sasha> (it's actually less because not all matrices are valid.) 
05:53:04 #corewars: < sasha> Think of a pure "qubit" as a vector on the surface of a sphere 
05:55:23 #corewars: < sasha> The sigma x, y, z operations let you do rotations around the various axis so in combination you can get arbitrarily close to any point on the sphere.  (I seem to have forgotten if you need another gate or not.) 
05:57:06 #corewars: < sasha> The best thing to do is to definite every gate used in every circuit in the literature =^) 
05:57:28 #corewars: < joonas> there are an infinity of sigma x, sigma y, sigma z rotations
05:57:30 #corewars: < sasha> Nobody should be spending their time figuring out how to do one single qubit gate or another. 
05:58:38 #corewars: < sasha> a few books seem to have wandered out of reach
05:59:26 #corewars: < sasha> let me see if I can give you a reference for completeness
06:00:54 #corewars: < sasha> and in the meantime libquantu api docs are quite good.
06:01:49 #corewars: < sasha> http://www.enyo.de/libquantum/api/node4.html
06:02:04 #corewars: < joonas> I meant by completeness just the ability to define any unitary transform using a set of primitive transforms.
06:02:05 #corewars: < sasha> see "Pauli spin operations" quantum_sigma_x 
06:02:08 #corewars: < sasha> etc. 
06:02:27 #corewars: < sasha> I know . 
06:03:30 #corewars: < joonas> hm.
06:04:07 #corewars: < sasha> People in the field worry about this sort of thing: http://arxiv.org/abs/quant-ph/0309002
06:04:10 #corewars: < joonas> surely you can't even approximate an arbitrary unitary transform using just the sigma_{x|y|z} transformations
06:05:59 #corewars: < sasha> Add a rotation "part-way" around any axis... but again it really doesn't matter.   
06:07:19 #corewars: < sasha> When I first started thinking about this I thought we could let an entire a field or b field be quantum mechanical.  (The math works out but it's just silly.) 
06:08:35 #corewars: < sasha> Seriously, this is getting us (painfully) in the direction I want to go. 
06:08:54 #corewars: < joonas> ...right, ok, that works as long as the "part-way" is not a rational multiple of pi.
06:09:00 #corewars: < joonas> hm.
06:09:15 #corewars: < sasha> yeah. 
06:09:19 #corewars: < joonas> sorry, was caught up a bit.
06:09:27 #corewars: < joonas> I get caught up by details sometimes.
06:09:40 #corewars: < sasha> I ignore details too easily... 
06:09:52 #corewars: < sasha> I've spent some years as a manager and it shows. 
06:10:16 #corewars: < joonas> aw
06:10:28 #corewars: < sasha> ok. So recap: 
06:10:40 #corewars: < sasha> new instructions: 
06:11:00 #corewars: < sasha> QOP -- qubit, #5  (like JMZ) 
06:11:12 #corewars: < sasha> QCN -- source qubit, target qubit 
06:11:45 #corewars: < sasha> SCS -- qubit -- skip if clear then set (like JMP) 
06:12:04 #corewars: < sasha> SCC -- qubit -- skip if clear then clear 
06:13:05 #corewars: < sasha> RPR -- source loc, dst location -- read priv. (a ignores modifiers, b respects and .F puts priv in both a and b field?) 
06:14:16 #corewars: < sasha> WPR -- amount, dst location -- write priv. (actually subtracts priv. from current location, if not enough fails but continues) 
06:14:34 #corewars: < sasha> any others? comments? 
06:15:31 #corewars: < joonas> could SCS and SCC be changed to JCS and JCC instead?
06:15:52 #corewars: < joonas> they would mirror JMN/JMZ
06:16:18 #corewars: < sasha> absolutely. 
06:17:15 #corewars: < sasha> I really have nothing good to say abot RPR/WPR but I'm also tempted to implement unless you have syntax suggestions. 
06:17:50 #corewars: < sasha> I think we need both because it's silly to make it a huge hassle to figure out how much priv. there is somewhere.  
06:18:10 #corewars: < joonas> well I'm still a little fond of having a restriction of at most one unit of energy per location.
06:18:48 #corewars: < joonas> then you could have JMZ.P and JMN.P
06:18:51 #corewars: < joonas> and MOV.P
06:19:05 #corewars: < sasha> Explain?
06:19:36 #corewars: < sasha> There is a major topic we haven't covered yet... 
06:19:41 #corewars: < sasha> and also one instruction... 
06:20:24 #corewars: < sasha> I definitely want to get back to this though and if you want to explain now that's cool!
06:20:40 #corewars: < joonas> one core location for you is: (OPCODE MODIFIER AMODE BMODE, AOPERAND, BOPERAND, QUBIT, PRIV, HIDDEN GENOTYPE)
06:20:57 #corewars: < joonas> i.e. the same as in normal core war except for the last three fields
06:21:05 #corewars: < joonas> the last one being, of course, hidden.
06:21:13 #corewars: < sasha> and minus task/warrior queues. 
06:21:19 #corewars: < joonas> right
06:21:29 #corewars: < sasha> (back to 84 corewar)
06:21:42 #corewars: < sasha> pre spl
06:22:05 #corewars: < joonas> in normal core war we have modifiers for A,B and their combinations AB BA F X (and I, but that's a special case.)=
06:22:05 #corewars: < sasha> please, go on, sorry for interrupting!
06:22:18 #corewars: < joonas> what you could do is add modifiers P and Q
06:22:27 #corewars: < joonas> so you have MOV.P src, dst
06:22:37 #corewars: < joonas> moves the PRIV from src to dst
06:22:52 #corewars: < joonas> the process that was executing at src now magically starts executing at dst.
06:23:32 #corewars: < joonas> and MOV.AP, MOV.PA, say, would function as RPR/WPR
06:24:12 #corewars: < sasha> Yes. definitely.  I decided not to do this because I didn't want all those modifier combinations. 
06:24:19 #corewars: < joonas> the Q modifier may not be necessary and hard to integrate with the rest, but the P one makes sense.
06:24:39 #corewars: < joonas> well most of them don't need to do anything.
06:24:51 #corewars: < sasha> yeah. that's why initially I thought priv. should be mod coresize
06:25:34 #corewars: < joonas> you could still have that.
06:25:45 #corewars: < sasha> This is similar to the pspace issue.   
06:25:47 #corewars: < joonas> PRIV could also stand for "process PRIVate"
06:26:11 #corewars: < joonas> no, scratch that.
06:27:07 #corewars: < joonas> having a DAT at location where you have PRIV > 0 doesn't mean the process is dead, it's just not doing anything (much)
06:27:08 #corewars: < sasha> well... why don't we leave it for a moment? 
06:27:24 #corewars: < joonas> you kill the process by MOV.AP 0, dst
06:27:25 #corewars: < sasha> yes (re DAT)
06:27:44 #corewars:  * joonas puts it on the back burner
06:27:51 #corewars: < joonas> what's the other thing you wanted to talk about
06:28:01 #corewars: < joonas> some other topic completely
06:28:08 #corewars: < sasha> the execution model doesn't work well if priv is just a bit.
06:28:35 #corewars: < sasha> (because then you have lots and lots and lots of dats around doing nothing but using simulator time and then you have to think of ways to deal with this...) 
06:28:53 #corewars: < sasha> well, one thing is relatively easy. 
06:29:07 #corewars: < joonas> true enough re: doing nothing.
06:29:19 #corewars: < joonas> so have priv take values 0..CORESIZE-1
06:29:35 #corewars: < joonas> funny thing would be that you could kill a process by ADDing too much priv to it. :)
06:30:20 #corewars: < joonas> but if you're going to have energy then you don't necessarily need MOV.I depleting energy
06:30:22 #corewars: < sasha> yeah lots of weird things with priv modifiers... maybe good? 
06:30:30 #corewars: < joonas> you could have a constant amount of energy in core
06:30:38 #corewars: < joonas> that the warriors fight over.
06:30:55 #corewars: < joonas> or maybe that's not so good after all.
06:31:06 #corewars:  * joonas thinks it could be good
06:31:43 #corewars:  * sasha smile
06:31:55 #corewars: < sasha> that should have been "smiles"
06:32:04 #corewars:  * joonas puts it on the back burner again
06:32:09 #corewars: < joonas> :)
06:32:13 #corewars: < sasha> ok. so the 'easy thing' 
06:32:58 #corewars: < sasha> the only way to create a new instruction at the moment is with mov.i and mov.i (at the moment) costs 1 unit of priv.
06:33:34 #corewars: < joonas> 'k, go on.
06:33:35 #corewars: < sasha> What if a program wanted to go "look for" priv out there somewhere in the film. 
06:33:52 #corewars: < sasha> Either it should be able to mov instructions around
06:34:09 #corewars: < sasha> move (as in the english word not mov the redcode instruction)
06:34:27 #corewars: < sasha> or it should be able to turn an instruction back into priv.
06:34:34 #corewars: < sasha> or both. 
06:34:43 #corewars: < joonas> it could use jmz.p and then mov.p the priv to itself.
06:35:25 #corewars:  * sasha totally confused... 
06:35:39 #corewars: < sasha> explain, please.
06:36:07 #corewars: < joonas> well something like this:   jmz.p  0, }1 / mov.p 100, myprivbank
06:36:42 #corewars: < joonas> that sits in the jmz loop scanning forward until it finds >0 priv.
06:37:23 #corewars: < joonas> then it moves the priv from where it found it to some location "myprivbank"
06:37:38 #corewars: < joonas> --> myprivbank becomes a new process.
06:38:02 #corewars: < joonas> that is, if it wasn't one before.
06:38:09 #corewars: < sasha> I'm not following you but are we talking past each other in any case?
06:38:28 #corewars: < sasha> Remember we have a grid of cores so I'm talking about
06:38:31 #corewars: < joonas> no?  this is regarding the scanning for priv.
06:38:41 #corewars: < sasha> priv. that's NOT in the current core. 
06:38:58 #corewars: < joonas> yes.
06:38:59 #corewars: < sasha> and not in any part of the dual cores
06:39:13 #corewars: < joonas> so you send out expedition teams to go look for some priv
06:39:27 #corewars: < joonas> to neighbouring cores
06:39:45 #corewars: < sasha> sure. but creating instructions uses priv. 
06:39:51 #corewars: < sasha> there is no way to move around.
06:40:00 #corewars: < joonas> yes, but the reward will surely be great when they find some.
06:40:19 #corewars: < joonas> this is under the assumption that you start out with >1 priv.
06:40:43 #corewars: < joonas> otherwise you have to first scan the current core for priv, and if you can't find any, migrate your lone process to another core,
06:40:48 #corewars: < joonas> and look for it there.
06:41:04 #corewars: < joonas> ah
06:41:06 #corewars: < joonas> I se.
06:41:16 #corewars: < sasha> Indeed.
06:41:18 #corewars: < joonas> I see.. you can't migrate to another core if MOV.I uses energy
06:41:30 #corewars: < joonas> unless you have a lot of it to spare.
06:41:45 #corewars: < sasha> yep
06:41:57 #corewars: < sasha> The easy solution is add. XCH
06:42:03 #corewars: < sasha> XCH.I in particular
06:42:26 #corewars: < joonas> and that uses no energy
06:42:27 #corewars: < joonas> ?
06:42:42 #corewars: < sasha> yes.
06:42:54 #corewars: < sasha> synthesis takes energy in this world but locomotion
06:42:55 #corewars: < sasha> does not. 
06:43:11 #corewars: < joonas> XCHG.I 0, 1
06:43:32 #corewars: < joonas> hm. of course the gates would kill it.
06:43:50 #corewars: < sasha> this is fairly biological.  Organisms can do a lot with very little energy but they cannot create copies of themselves without "food".
06:44:50 #corewars: < joonas> so what's the hard solution?
06:44:50 #corewars: < sasha> Do you know about the results on reversible computation?
06:45:19 #corewars: < sasha> that if you are willing to go slowly then you can compute using arbitrarily little energy?
06:45:21 #corewars: < joonas> the bit about quantum computing having to be reversible?
06:45:38 #corewars: < joonas> (or some bit like that)
06:45:40 #corewars: < joonas> no, I didn't know.
06:45:42 #corewars: < sasha> so maxwell's demon is possible if it has infinite memory
06:45:54 #corewars: < sasha> but as soon as the demon needs to forget it uses energy...
06:46:49 #corewars: < sasha> well, viruses do a huge amount with very little energy.  It's really very deep.  Some of their enzymes cut through complicated outer defenses all without energy. 
06:47:15 #corewars: < sasha> (Viruses can also keep a little energy around too.) 
06:47:46 #corewars: < sasha> anyway... this is a distraction, sorry. 
06:48:06 #corewars: < sasha> OK So we add XCH.I (and this swaps qubits without measuring them.) 
06:48:26 #corewars: < sasha> well, XCH.* 
06:48:50 #corewars: < sasha> you can also swap qubits without measuring them with three control-nots
06:49:01 #corewars: < joonas> ok...
06:49:21 #corewars: < joonas> so you're going to say next that MOV.I is going measure the qubit, right?
06:49:23 #corewars: < sasha> anyway.  we could still allow recovery of priv. from existing instructions
06:49:35 #corewars: < sasha> yes mov.i does measure it. 
06:49:41 #corewars:  * joonas sighs
06:49:41 #corewars: < sasha> so does seq and sne
06:49:52 #corewars: < sasha> you can't copy a quantum bit. =^) 
06:50:09 #corewars: < joonas> ok.
06:50:23 #corewars: < joonas> yes, this is the bit about reversibility I had heard.
06:51:12 #corewars: < sasha> given XCH.I there is no need for priv. recovery for the sake of "movement" but there is another reason. 
06:51:30 #corewars: < sasha> It's probably the most important reason for players.  How do we keep score in QCW?
06:51:39 #corewars: < joonas> hm.. and that's because the qubits are put into their states using bijections only, and bijections can't do the copy
06:51:48 #corewars: < sasha> And more importantly for biologists what's an organism?
06:52:01 #corewars: < sasha> (and therefore how do we definite fitness.) 
06:52:51 #corewars: < joonas> I thought you were using the hidden genotype field for that
06:52:52 #corewars:  * sasha nods
06:53:25 #corewars: < sasha> re. genotype field-- partially. 
06:53:58 #corewars: < sasha> Microbiologists defined an organism operationally. 
06:54:32 #corewars: < sasha> If they can take a sample. Plate it out.  Take a sample. Plate it out.  Repeat until pure.  
06:54:41 #corewars: < sasha> That's an organism. 
06:54:49 #corewars: < joonas> what's plating a sample?
06:54:58 #corewars: < joonas> oh, cleaning,
06:55:10 #corewars: < sasha> Putting a cell in a petri dish and letting it grow on the "plate". 
06:55:28 #corewars: < joonas> ok. makes sense.
06:55:46 #corewars: < sasha> Of-course, it's not so simple.  Many? Most? organisms
06:55:56 #corewars: < sasha> can't grow in "standard" conditions.  
06:56:17 #corewars: < sasha> And there are all sorts of complicated symbiosis that might require the presence of other organisms. 
06:56:32 #corewars: < sasha> but traditional microbiology relied on this. 
06:56:55 #corewars: < sasha> So every place we have energy in each compartment 
06:57:11 #corewars: < sasha> we have a potential organism. 
06:57:36 #corewars: < sasha> (Virologists usually think viruses are organisms even though they are clearly "unculturable" without a host.) 
06:57:40 #corewars: < joonas> well mov.p should also set the genotype
06:58:25 #corewars: < sasha> An important aspect of pure culture is that it's, well, pure. 
06:58:54 #corewars: < sasha> If a genotype breaks into several tasks doing different things and they start replicating-- it's not an organism. 
06:59:28 #corewars: < sasha> Well, if one task occurs every single time another task occurs the combined thing is probably an organism. 
06:59:47 #corewars: < sasha> but if the tasks can replicate independently of each other (doing slightly different things) that's two organisms.
07:01:22 #corewars: < sasha> This is a really tricky problem... 
07:01:23 #corewars: < joonas> so your question is about identifying organisms as repliating things in the coreworld.
07:01:30 #corewars: < joonas> replicating
07:02:00 #corewars: < sasha> mice replicates in the coreworld. 
07:02:10 #corewars: < sasha> how many mice do we have? 
07:02:20 #corewars: < joonas> just one.
07:02:43 #corewars: < sasha> well, certainly not to a biologist. 
07:02:58 #corewars: < joonas> you yourself wanted intelligence and algorithms in the core world.
07:03:06 #corewars: < sasha> go on. 
07:03:23 #corewars: < joonas> one part of that is letting different parts do different things
07:03:24 #corewars: < sasha> bacteria are very intelligent. =^) 
07:03:32 #corewars: < sasha> (by corewar standards)
07:04:21 #corewars: < sasha> a major aspect of microbiology right now is recognizing that bacteria are "social"
07:04:43 #corewars: < sasha> different parts of a bacterial colony can differentiate
07:04:44 #corewars: < grabek> corewar folk never sleeps
07:04:58 #corewars: < sasha> Hi! Congrats on the MSc. 
07:05:15 #corewars: < sasha> Believe it or not I hope this discussion will end up as part of mine... 
07:05:19 #corewars: < grabek> Hi, thank you sasha 
07:05:25 #corewars: < joonas> if a program replicates many small, yet ultimately disposable, defenders that are, say, scanning a quarter of core for enemies, then would you still score the defenders as a separate organism?
07:05:32 #corewars: < sasha> Well, not the discussion but the resulting work.
07:05:35 #corewars: < joonas> Congratulations!
07:05:36 #corewars: < grabek> i hope that too
07:05:38 #corewars: < grabek> thanks joonas 
07:05:59 #corewars: < grabek> i am just passing by so don't be distracted
07:06:14 #corewars: < grabek> i am having hy morning tea in front of IRC session on #corewars 
07:06:15 #corewars: < grabek> :-)
07:06:19 #corewars: < joonas> you set an example to us all. :)
07:06:29 #corewars: < joonas> to me, anyway.
07:06:40 #corewars: < sasha> Joonas. Absolutely.  Here is a suggestion. 
07:07:26 #corewars:  * joonas really needs to get some coffee
07:07:33 #corewars: < joonas> brb, but do go on.
07:07:37 #corewars: < sasha> Suppose we group different types of instructions by color the way that Will Varfar has done. 
07:07:52 #corewars: < sasha> (in his runtime execution stats.) 
07:08:05 #corewars: < grabek> (ok, you had quite a chat, guys)
07:08:09 #corewars: < grabek> See you later
07:08:14 #corewars: < sasha> 'later! 
07:08:19 #corewars: < grabek> and joonas: it's just a metter of time, you know
07:08:34 #corewars: < grabek> thank you both and all corewar folk for congratulations.
07:08:40 #corewars:  * grabek waves
07:10:47 #corewars: < sasha> Take every point of execution (priv>0) and move backward and forward in core until we get to three(?) in a row of J* or DAT 
07:11:46 #corewars: < sasha> Call this segment of core a "module" 
07:13:00 #corewars: < sasha> My plan (using image magick) is to hash each module.  
07:13:40 #corewars: < joonas> back
07:13:50 #corewars:  * joonas waves at grabek
07:14:11 #corewars:  * grabek waves back at joonas 
07:14:17 #corewars: < grabek> bye
07:14:18 #corewars: < sasha> abs. Fitness for a genotype is the number of phenotypes that include that genotype. 
07:14:34 #corewars: < sasha> (phenotype = hash of module.) 
07:15:51 #corewars: < sasha> given the way we discussed implementing dual cores. I don't plan, arbitrarily, to look past coresize/4 boundaries. 
07:15:59 #corewars: < joonas> hm.. so you want to do run-time grouping the way will has.
07:16:16 #corewars: < sasha> will, does run time profiling of instructions.
07:16:31 #corewars: < joonas> yes, I'm familiar with his approach.
07:16:46 #corewars: < joonas> that could be used here too.
07:17:28 #corewars: < sasha> every "x cycle" I analyze my picture of the core.  I count all the identical patterns.
07:17:30 #corewars: < joonas> you log the entire execution trace of each process and try to find patterns in it.
07:17:40 #corewars: < sasha> You can't do that.  
07:17:51 #corewars: < joonas> then at the end, you find the number of processes executing a certain pattern.
07:17:56 #corewars: < joonas> sure you can.
07:18:01 #corewars: < sasha> sorry. 
07:18:04 #corewars: < sasha> ofcourse you can. 
07:19:51 #corewars: < sasha> The problem is I really do need to answer, in a relatively, straightforward way what's an organism. 
07:20:27 #corewars: < joonas> will's excellent idea was to look at the dynamic profile of what instructions get executed and find patterns in that, rather than estimate the patterns from core.
07:20:48 #corewars: < joonas> rather than estimate then statically from the contents of core, I mean.
07:21:46 #corewars: < sasha> yeah. 
07:21:47 #corewars: < joonas> the answer will has is to try to learn a kind of markov model of process execution and you can do that too.
07:22:51 #corewars: < joonas> the various markov models stick out like, uh, sore thumbs from each other.
07:23:00 #corewars: < joonas> at least in normal core war.
07:23:37 #corewars: < joonas> of course, the trouble is that lots of warriors use *exactly the same sequence of instructions* for the majority of the simulation.
07:24:26 #corewars: < joonas> so this is where I think your hidden genotype can help further distinguish between the warriors.
07:24:36 #corewars: < sasha> the aproach I suggested can distinguish the following
07:24:58 #corewars: < joonas> but honestly, I don't see why a count of energy per warrior at the end of the simulation isn't a good fitness estimator.
07:25:04 #corewars: < joonas> sorry, go on.
07:25:12 #corewars: < sasha> hmm. 
07:25:46 #corewars: < sasha> sorry. yes indeed. 
07:25:58 #corewars:  * sasha still thinking... 
07:26:08 #corewars: < joonas> while you're thinking:
07:26:16 #corewars: < sasha> yes?
07:26:46 #corewars: < joonas> if I were to submit a warrior to the qcw, I don't want my fitness to be distributed between different components of my warrior.
07:26:55 #corewars: < joonas> I want their sum to be my fitness.
07:27:14 #corewars: < joonas> multicomponent warriors are very common in core war today.
07:27:43 #corewars: < sasha> absolutely.  the count of each separate phenotype is summed to give the fitness of your genotype. 
07:28:40 #corewars: < joonas> although the reasons for multicomponents are different in normal core war.  there it's the redundancy against opponent attacks and also to achieve asymmetry of attack vs. defense suring the course of a battle.
07:29:00 #corewars: < joonas> suring -> during
07:29:08 #corewars: < sasha> but, during the course of battle a rarely used part of your warrior might be damaged (or a separate module) and this might actually improve your warrior.  Remeber, on the phone you didn't think this was possible but it's what happens with the replicators and hitch-hikers. 
07:29:59 #corewars: < joonas> I remember.
07:30:15 #corewars: < sasha> The goal is to notice -inheritable- changes in phenotype that are not just looking at new location in core during a scan (or bombing run.)
07:30:41 #corewars: < joonas> brb
07:30:45 #corewars: < sasha> sure
07:32:01 #corewars: < sasha> Clearly such patterns might be picked up in varfar style execution trace. 
07:37:08 #corewars: < joonas> back
07:37:19 #corewars: < joonas> ok, have thought about it.
07:37:39 #corewars: < sasha> go on, please...
07:37:44 #corewars: < joonas> IMHO, you don't want to mix fitness computing and 
07:38:19 #corewars: < joonas> looking for phenotypes
07:38:22 #corewars: < joonas> .
07:38:59 #corewars: < sasha> biomass is often used as an indicator of fitness.
07:39:24 #corewars: < joonas> fitness should be computed as, say, total or average energy per core location with your hidden genotype
07:39:30 #corewars: < joonas> or whatever.
07:39:49 #corewars: < sasha> total fitness is not just the "end result" but measured over time. 
07:40:06 #corewars: < sasha> but you are right we could do that. 
07:40:34 #corewars: < sasha> "biomass" 
07:41:43 #corewars: < joonas> then, when you want to look at the fenotypes you look at the execution logs and apply the willvarfa algorithm or other analysis.
07:41:54 #corewars: < joonas> right, ok, that makes sense.
07:41:55 #corewars: < joonas> hm.
07:42:03 #corewars: < joonas> brb, again.
07:42:20 #corewars:  * sasha thinks some more 
07:46:48 #corewars: < joonas> back, but I have to start working
07:46:55 #corewars: < joonas> been nice chatting with you again.
07:47:04 #corewars: < joonas> sorry to have to cut this short.
07:47:08 #corewars: < joonas> bye
07:47:12 #corewars: < sasha> bye.  
07:47:13 #corewars:  * joonas waves
07:47:17 -!- joonas [jpihlaja@kruuna.helsinki.fi] has quit [ircII2.8.2-EPIC3.004+Kasi --- Bloatware at its finest.]
07:47:19 #corewars: < sasha> This was a good spot to end. 
07:47:48 -!- sasha [~sasha@node-423a728a.bos.onnet.us.uu.net] has quit [Leaving]
09:30:00 -!- willvarfa [~Will@arken-16-57-61.ip-pluggen.com] has joined #corewars
10:00:25 -!- will_varf [~Will@arken-16-57-19.ip-pluggen.com] has joined #corewars
10:03:09 -!- willvarfa [~Will@arken-16-57-61.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
10:29:34 -!- will_varf [~Will@arken-16-57-19.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
11:09:31 -!- Mizcu [Mizcu@dsl-hkigw4icc.dial.inet.fi] has joined #corewars
11:15:33 -!- willvarfa [~Will@arken-16-57-16.ip-pluggen.com] has joined #corewars
11:15:42 #corewars: < willvarfa> good morning folks
11:16:20 #corewars: < Mizcu> will
11:29:12 -!- will_varf [~Will@arken-16-57-104.ip-pluggen.com] has joined #corewars
11:31:40 -!- willvarfa [~Will@arken-16-57-16.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
12:00:15 -!- willvarfa [~Will@arken-16-57-99.ip-pluggen.com] has joined #corewars
12:00:52 -!- willvarfa [~Will@arken-16-57-99.ip-pluggen.com] has quit [Lämnar]
12:02:50 -!- will_varf [~Will@arken-16-57-104.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
12:06:56 -!- brx [~as@pD9EAA27D.dip.t-dialin.net] has joined #corewars
12:30:42 -!- Mizcu [Mizcu@dsl-hkigw4icc.dial.inet.fi] has quit []
12:53:54 -!- willvarfa [~Will@arken-16-57-27.ip-pluggen.com] has joined #corewars
13:02:35 -!- will_varf [~Will@arken-16-57-97.ip-pluggen.com] has joined #corewars
13:05:33 -!- willvarfa [~Will@arken-16-57-27.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
13:19:25 -!- will_varf [~Will@arken-16-57-97.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
13:27:36 -!- willvarfa [~Will@arken-16-57-2.ip-pluggen.com] has joined #corewars
13:32:30 -!- brx [~as@pD9EAA27D.dip.t-dialin.net] has quit [Read error: 54 (Connection reset by peer)]
13:47:46 -!- will_varf [~Will@arken-16-57-105.ip-pluggen.com] has joined #corewars
13:50:24 -!- willvarfa [~Will@arken-16-57-2.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
14:18:46 -!- willvarfa [~Will@arken-16-57-83.ip-pluggen.com] has joined #corewars
14:21:37 -!- will_varf [~Will@arken-16-57-105.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
14:34:20 -!- buck_620 [buck_620@62.123.62.36] has joined #corewars
14:34:25 #corewars: < buck_620> hello
14:34:45 #corewars: < willvarfa> hello
14:34:58 #corewars: < buck_620> It's my first time in this channel :-)
14:35:27 #corewars: < buck_620> I'm quite a newbie in core wars,
14:35:40 #corewars: < buck_620> but I found the topic very interesting
14:35:45 #corewars: < willvarfa> welcome!
14:35:50 #corewars: < buck_620> thanks!
14:36:29 #corewars: < buck_620> could you suggest me an environment to run warriors and tournaments, something like pmars, that goes well with winXP?
14:36:55 #corewars: < buck_620> I found something but it's incomplete (ARES) or is done for Unix
14:37:24 #corewars: < willvarfa> ARES will be good soon, but for now there is just a beta and plenty of work being done behind the scenes
14:37:39 #corewars: < willvarfa> right now, you're best best is either corewin or the SDL version of pmars
14:38:02 #corewars: < buck_620> where can I find that stuff?
14:38:52 #corewars: < willvarfa> the sdl version of pmars is http://www.cs.helsinki.fi/u/jpihlaja/cw/pmars-sdl/
14:38:57 #corewars: < willvarfa> I like that
14:39:02 #corewars: < willvarfa> many people like corewin too
14:39:50 #corewars: < buck_620> thanks... and do you know where I can find corewin?
14:49:26 -!- Neogryzor [~c192e809@brparcunix.cidadeinternet.com.br] has joined #corewars
14:49:47 -!- will_varf [~Will@arken-16-57-108.ip-pluggen.com] has joined #corewars
14:50:21 #corewars: < Neogryzor> pp
14:50:31 #corewars: < Neogryzor> hello
14:52:58 -!- willvarfa [~Will@arken-16-57-83.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
14:53:04 #corewars: < will_varf> buck_620: http://www.geocities.com/corewin2/
14:53:08 #corewars: < will_varf> hello german
14:53:25 #corewars: < buck_620> thanks a lot!
14:53:56 #corewars: < Neogryzor> hi will
14:54:10 #corewars: < Neogryzor> buck =newbie?
14:55:24 #corewars: < buck_620> yes
14:55:27 #corewars: < buck_620> ;-)
14:55:59 #corewars: < Neogryzor> so welcome
14:56:11 #corewars: < buck_620> thank you!
14:56:38 #corewars: < buck_620> I'm just studying some documentation... I hope that soon I'll write some code myself
14:56:40 #corewars: < buck_620> ;-)
14:56:40 #corewars: < Neogryzor> we need more beginners
14:57:15 #corewars: < buck_620> I gotta go now... But see you soon!
14:57:21 #corewars: < buck_620> and thanks for support
14:57:27 -!- buck_620 [buck_620@62.123.62.36] has left #corewars []
14:57:47 #corewars: < Neogryzor> bye
14:58:04 #corewars: < will_varf> so, German, when the next mini challenge?
14:58:26 #corewars: < jaska> i wish i didnt have a zillion projects in the air all the time
14:59:00 #corewars: < will_varf> only a zillion? puff
14:59:42 #corewars: < jaska> s/zillion/unknown large amount/
15:00:23 #corewars: < jaska> most of them are suspended due to lack of resources (money, technology doesnt yet exist etc.)
15:02:30 #corewars: < Neogryzor> +++
15:03:34 #corewars: < Neogryzor> i can't upload anything to the web. Ya.com host works horribly
15:03:36 #corewars: < Neogryzor> asdń
15:03:50 #corewars: < will_varf> ah, likely excuse ;-)
15:03:56 #corewars: < Neogryzor> (this web-irc works really bad too)
15:04:28 -!- Mizcu [Mizcu@dsl-hkigw4icc.dial.inet.fi] has joined #corewars
15:04:35 #corewars: < jaska> web ircs rarely work well :)
15:05:09 #corewars: < Neogryzor> well, still thinking what to propose. My initial idea is maybe a bit too hard for newbies
15:08:33 #corewars: < will_varf> white warriors are fun
15:09:28 #corewars: < Neogryzor> white = prototipe warriors?
15:09:38 #corewars: < Neogryzor> p
15:10:09 #corewars: < Mizcu> warriors whom source is shown
15:10:25 #corewars: < will_varf> white is a testing phrase, meaning 'known source'.  black box testing is where you don't know the sourcecode
15:10:27 #corewars: < Mizcu> "now go and beat this warrior"
15:10:42 #corewars: < Neogryzor> oh, i forgot
15:11:08 #corewars: < will_varf> stack implementations would be neat, especially if you required it to be multi-threaded
15:11:16 #corewars: < will_varf> or travelling salesman
15:13:00 #corewars: < Mizcu> stack implementation would be neat yes,  but newbies wouldnt even know what stack is..
15:13:42 #corewars:  * Neogryzor is fighting pop-ups
15:14:46 #corewars: < Neogryzor> can you read me?
15:14:53 #corewars: < will_varf> there was a neat IRCT a while back where there were three 1-line components (imp, djn and something?)
15:14:57 #corewars: < Mizcu> no, we cant read you
15:15:40 #corewars: < Mizcu> How about mini where you must trick your opponent to suicide some way? 
15:15:58 #corewars: < will_varf> writing switchers for such a pwarrior would be right up pkey's street
15:16:26 #corewars: < Neogryzor> Mizcu: how?
15:17:01 #corewars: < Mizcu> Neo: at first i though about a stone with carelessly placed bomb and djn-stream, but that would be too obvious
15:17:05 #corewars: < Neogryzor> will: yeap. Pros will have a big advantage over newbies
15:17:43 #corewars: < will_varf> but the components are something that beginners can understand well
15:17:50 #corewars: < will_varf> ideal for teaching them about pbrains
15:18:10 #corewars: < Mizcu> peabrains :)
15:18:29 #corewars: < Neogryzor> also pi-brains :)
15:19:43 #corewars: < will_varf> well I didn't understand the math of the last mc
15:19:49 #corewars: < will_varf> but it did seem popular
15:20:09 #corewars: < will_varf> things like travelling salesman are difficult without a randomiser
15:20:53 -!- willvarfa [~Will@arken-16-57-38.ip-pluggen.com] has joined #corewars
15:21:22 #corewars: < Mizcu> i would love some factorization round where p-space would have at the beginning a string of numbers that would have to be processed
15:21:43 #corewars:  * Neogryzor is still fighting pop-ups. They are like replicators. Can't kill them all with my mouse-bomb
15:21:54 #corewars: < willvarfa> lol
15:21:55 #corewars: < jaska> nuclear bomb.
15:22:12 #corewars: < willvarfa> yeap, or if not pspace then maybe a predefined part of core?
15:23:17 #corewars: < Mizcu> (i have been thinking about multiple parallel processors that "run" in redcode and use p-space to communicate between each other..)
15:23:44 #corewars: < willvarfa> handshaking?
15:23:47 #corewars: < willvarfa> pins?
15:23:53 #corewars: < Mizcu> i would like to see some type of communication scheme implemented between X cores
15:24:16 #corewars: < Mizcu> p-space would be rather I/O -ports than what it is currently
15:24:21 -!- will_varf [~Will@arken-16-57-108.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
15:24:29 #corewars: < Neogryzor> ---
15:25:01 #corewars: < Neogryzor> i said, i don't know the mathematical solution to the traveling salesman problem
15:27:04 #corewars: < Mizcu> but that was just an idea i've been having and is not of importance
15:28:27 #corewars: < Mizcu> hmm.. maybe i could start coding today the evo-test 
15:28:36 #corewars: < willvarfa> lots of people seem to be trying to build the next corewars
15:28:42 #corewars: < willvarfa> (which is healthy)
15:29:01 #corewars: < willvarfa> I have in mind the absolutely must-have corewar product, btw
15:29:06 #corewars: < willvarfa> a proper optimiser
15:29:14 #corewars: < Neogryzor> i have to go now
15:29:18 #corewars: < Neogryzor> see you all
15:29:20 #corewars: < willvarfa> cya german
15:29:21 #corewars: < Mizcu> by Neo
15:29:23 #corewars: < Mizcu> bye 
15:29:25 #corewars:  * Neogryzor waves
15:29:29 -!- Neogryzor [~c192e809@brparcunix.cidadeinternet.com.br] has left #corewars []
15:29:48 #corewars: < willvarfa> so Mizcu, you like C or c++?
15:29:52 #corewars: < Mizcu> I still need a better blueprint before i start coding the test..
15:30:07 -!- brx [~as@pD9EAA27D.dip.t-dialin.net] has joined #corewars
15:30:12 #corewars: < Mizcu> Will: i dont even remember Hello World properly in C
15:30:32 #corewars: < willvarfa> how about Ruby?
15:30:48 #corewars: < Mizcu> Still searching for the language i should start learning
15:30:51 #corewars: < brx> how about lisp Mizcu 
15:30:57 #corewars: < Mizcu> Perl gives me headache..
15:31:06 #corewars: < brx> perl is syntactic hell
15:31:14 #corewars: < brx> choose lisp, it does not have any syntax
15:31:16 #corewars: < Mizcu> I dont remember a bit of pascal anymore
15:31:55 #corewars: < willvarfa> pascal is a very nice language
15:31:59 #corewars: < willvarfa> python is popular
15:32:02 #corewars: < willvarfa> java is effective
15:32:10 #corewars: < Mizcu> Java effective?
15:32:23 #corewars: < willvarfa> yeah, you can make apps with it
15:32:28 #corewars: < Mizcu> yes, python is one i could have interest on
15:32:29 #corewars: < brx> sorry, that's bullshit. choose the most powerful language available
15:32:40 #corewars: < brx> don't give a fsck for popularity
15:32:51 #corewars: < brx> choose lisp.
15:33:48 #corewars: < Mizcu> brx to lisp is like..     bvowk to bsd
15:34:26 #corewars: < willvarfa> lol
15:34:38 #corewars: < willvarfa> what kind of apps do you want to write, Mizcu?
15:34:48 #corewars: < brx> Mizcu: if popularity was the way to choose anything, all people would be running windows.
15:35:11 #corewars: < Mizcu> Brx: And pretty much everybody is ;)
15:35:33 #corewars: < Mizcu> will: havent though about it
15:35:52 #corewars: < brx> Mizcu: which is what popularity means i guess.. it's not the best choice for every domain though :P
15:36:20 #corewars: < brx> willvarfa: more modern languages are constantly integrating lisp features into their own feature set
15:36:29 #corewars: < brx> lisp had it all back then
15:36:30 #corewars: < brx> :P
15:36:40 #corewars: < willvarfa> yeap, I like lisp
15:36:49 #corewars: < willvarfa> I just think it a strange thing to suggest anyone write anything in it
15:36:57 #corewars: < brx> lol... how so
15:37:14 #corewars: < willvarfa> ok, go build me a mars in lisp..
15:37:24 #corewars: < brx> it has merit.
15:37:31 #corewars: < willvarfa> so has assembler
15:37:48 #corewars: < willvarfa> languages suit different tasks, so before suggesting languages you have to decide that task..
15:38:04 #corewars: < brx> a mars you say, why not :P
15:38:58 #corewars: < willvarfa> http://www.corewar.info/ueos.htm (the LISP link seems dead)
15:39:01 #corewars: < brx> now will, what am i going to prove to you in doing so though
15:39:32 #corewars: < willvarfa> that you are sufficiently keen on lisp as to attempt something best done with another tool
15:39:42 #corewars: < brx> what do you mean "best done"
15:39:49 #corewars: < brx> :)
15:39:57 #corewars: < brx> i will think about it.
15:39:58 #corewars: < willvarfa> someone famous once said "if a hammer is your only tool, suddenly every problem starts to look like a nail" ;-)
15:40:17 #corewars:  * willvarfa likes lisp, btw
15:40:30 #corewars: < brx> willvarfa: the problem is, i consider all other languages to have but a subset of lisp features :)
15:40:48 #corewars: < brx> all other high abstraction languages i mean
15:41:08 #corewars: < willvarfa> just they have oodles and oodles of libraries too, eh? ;-)
15:41:35 #corewars: < brx> well that doesn't really have anything to do with the languages, only with their popularity :)
15:41:41 #corewars: < brx> besides
15:41:45 #corewars: < brx> i can write stubs
15:41:48 #corewars:  * brx shrugs
15:42:41 #corewars: < brx> you may be right though in suggesting a more imperative (by nature) programming language to Mizcu as a start
15:44:55 #corewars: < willvarfa> we are back to square one; Mizcu, clearly a man without a zillion floating projects, is wondering if he should program apps, and if so what apps, and in what language?  ... I vote Mizcu, that you write warriors instead!
15:45:59 #corewars: < brx> hum
15:46:11 #corewars: < Mizcu> I have currently only creation of better bruteforcer, creation of the evo-test and the network-fantasy
15:46:32 #corewars: < brx> network-fantasy?
15:47:13 #corewars: < Mizcu> I'll be writing the evo-test in basic if i have time during this weekend.
15:47:24 #corewars: < willvarfa> ever played with ruby?
15:47:37 #corewars:  * jaska <3 ruby
15:47:52 #corewars: < Mizcu> brx: i've been fantasizing with idea of creating a small scale p2p-network myself
15:47:57 #corewars: < Mizcu> will: nope
15:48:20 #corewars: < willvarfa> martin ankerl is working on a ruby interface for his exmars (which is the fastest mars known to man, and includes a proper full pmars-compatible parser)
15:48:26 #corewars: < brx> Mizcu: go for c/c++, then choose syntactic hell (perl), then go to lisp and marvel at its simplicity
15:49:02 #corewars: < willvarfa> someone could take that and make an optimiser that can optimise constants in sourcecode even when they are used in expressions
15:51:07 #corewars: < brx> don't get me wrong, i am no lisp zealot. i just think that it deserves much, much more attention.
15:51:23 #corewars: < willvarfa> indeed it does
15:51:59 -!- will_varf [~Will@arken-16-57-111.ip-pluggen.com] has joined #corewars
15:52:23 #corewars: < will_varf> fortran is often unfairly knocked, and I only know two forth freaks (but they are true coders, so forth must be very cool)
15:54:02 #corewars:  * brx wonders what he was up to..
15:54:59 -!- willvarfa [~Will@arken-16-57-38.ip-pluggen.com] has quit [Ping timeout: 180 seconds]
15:55:28 #corewars: < will_varf> now the fun is creating a new language
15:57:48 #corewars: < brx> hum?
15:58:17 #corewars: < will_varf> yeah, until you've created a language or two, you can't really appreciate languages
16:00:37 #corewars: < brx> too late.. i would not really know how to create anything but a lisp dialect :)
16:00:53 #corewars: < will_varf> lol
16:02:37 #corewars: < will_varf> is _every_ language a lisp dialect?
16:03:27 #corewars: < brx> of course not
16:03:38 #corewars: < brx> languages worth knowing are
16:03:41 #corewars: < brx> ;)#
16:03:42 #corewars: < will_varf> lol
16:03:47 #corewars: < will_varf> examples?
16:05:33 #corewars: < brx> hum?
16:05:44 #corewars: < brx> common lisp? scheme?
16:10:41 #corewars: < will_varf> ruby seems interesting, never used it
16:12:13 #corewars: < brx> hm me neither actually
16:12:20 #corewars: < jaska> i use it for some of my work projects
16:12:26 #corewars: < brx> i might take a look though, people seem to be blabbering about it everywhere
16:12:37 #corewars: < brx> jaska: for example?
16:12:54 #corewars: < jaska> central wlan network control (mobility etc)
16:13:00 #corewars: < will_varf> bbs
16:13:01 -!- will_varf [~Will@arken-16-57-111.ip-pluggen.com] has quit [Lämnar]
16:14:14 #corewars: < jaska> #ruby-lang on freenode/openprojects irc network is good.
16:14:17 #corewars: < jaska> and www.ruby-lang.org
16:15:10 -!- willvarfa [~Will@arken-16-57-79.ip-pluggen.com] has joined #corewars
16:16:03 #corewars: < brx> looks similar to perl ;)
16:16:12 #corewars: < jaska> only on the surface
16:16:28 #corewars: < jaska> cig and stuff ->
16:16:39 #corewars: < brx> ah me too.
16:19:02 #corewars: < brx> i am weird. i usually don't like hiphop. i enjoy listening to it while smoking though
16:22:25 #corewars: < jaska> smoking what? heh.
16:24:07 -!- willvarfa [~Will@arken-16-57-79.ip-pluggen.com] has quit [Lämnar]
16:24:36 #corewars: < brx> heh ;)
16:27:02 #corewars: < jaska> np: front line assembly - civilization
17:06:54 -!- CoreChild [~d432ba35@brparcunix.cidadeinternet.com.br] has joined #corewars
17:08:11 #corewars: < CoreChild> Hi
17:08:37 #corewars: < Mizcu> hi CC
17:12:12 #corewars: < CoreChild> Hi Mizcu.
17:34:49 -!- brx [~as@pD9EAA27D.dip.t-dialin.net] has quit [Read error: 54 (Connection reset by peer)]
17:42:59 -!- brx [~as@pD9EAA27D.dip.t-dialin.net] has joined #corewars
17:47:55 -!- MarsFreak [~d432ba35@brparcunix.cidadeinternet.com.br] has joined #corewars
17:48:22 #corewars: < Mizcu> CC^2
17:49:06 #corewars: < MarsFreak> Problems with the webIRC
17:49:19 #corewars: < MarsFreak> I see you're the 2nd oldest on '94nop now :-)
17:50:01 -!- CoreChild [~d432ba35@brparcunix.cidadeinternet.com.br] has quit [WebChat -> www.vIRCio.org  (Ping timeout)]
17:50:04 #corewars: < Mizcu> RECON FELL??
17:51:03 #corewars: < Mizcu> damn, doesnt promise good for stat
17:51:48 #corewars: < Mizcu> not as good as i'd want against blurish'es
17:53:42 #corewars: < MarsFreak> No :-(
17:54:50 #corewars: < Mizcu> (notice that it is given  156,156,157,157 from 4 opponents..)
17:57:34 #corewars: < MarsFreak> Let's hope they hang around for a while then
17:59:09 #corewars: < Mizcu> Ironic, Devilish and Static and all in the bottom-5 ..
17:59:43 #corewars: < Mizcu> And fuse^2 is also stone-style warrior
18:03:11 -!- MarsFreak [~d432ba35@brparcunix.cidadeinternet.com.br] has quit [WebChat -> www.vIRCio.org  (EOF)]
18:05:03 -!- Fizmo [~fizmo_mas@pD9E6EEA8.dip0.t-ipconnect.de] has joined #corewars
18:05:09 #corewars: < Fizmo> hi
18:05:13 #corewars: < Mizcu> Fiz
18:16:45 #corewars: < Fizmo> ouch, Recon 2 is pushed of the hill
18:17:54 #corewars: < Mizcu> Dont know weather should i be crushed (best scoresource gone) or neutral (second oldest warrior)
18:19:53 #corewars: < Mizcu> (damn i dislike the word, dont remember which way it went..)
18:25:57 #corewars: < Fizmo> BTW, you helped Hunter?
18:27:02 #corewars: < Mizcu> not yet
18:27:12 #corewars: < Mizcu> damn, im crushed by things i have to do
18:46:20 #corewars: < Mizcu> fiz, are you going to mail him now or did you just ask?
18:47:33 #corewars: < Fizmo> I just ask
18:48:11 #corewars: < Fizmo> Maybe if I have some spare time on my PC I'll let run Hunters paper abit more
18:48:55 #corewars: < Mizcu> If i have time, i'll search for improvements and mail him today/tomorrow
18:58:51 -!- Metcalf [~John@217.158.137.194] has joined #corewars
18:58:55 #corewars: < Metcalf> Hi
18:59:02 #corewars: < Mizcu> hi Met
18:59:10 #corewars: < Metcalf> Thanks for the forwarded mail Christian
18:59:10 #corewars: < Fizmo> Hi John
18:59:25 #corewars: < Fizmo> np ;-)
18:59:31 #corewars: < Metcalf> Not having much luck with my new warriors
18:59:40 #corewars: < Fizmo> ohh
19:00:06 #corewars: < Metcalf> Well, not so much new, as variations on old themes :-/  Recombining things in ways I haven't seen
19:00:08 #corewars: < Fizmo> I had a lucky hand with Arrow
19:00:32 #corewars: < Mizcu> i have to go now
19:00:39 #corewars: < Mizcu> see you at Friday
19:00:40 #corewars: < Fizmo> I think it's a scan engine never seen before ;-)
19:00:48 #corewars:  * Fizmo waves
19:01:05 -!- Mizcu [Mizcu@dsl-hkigw4icc.dial.inet.fi] has quit [dat {-1, >-1]
19:02:24 -!- Metcalf [~John@217.158.137.194] has quit [Remote closed the connection]
19:02:48 -!- Metcalf [~John@217.158.137.194] has joined #corewars
19:03:17 #corewars: < Metcalf> Hmmm... stupid computer with power key next to delete
19:09:20 #corewars: < Metcalf> No wonder Illuminati doesn't score very well, the paper scores worse than an Imp!
19:10:00 #corewars: < Metcalf> Now, I need to find out why
19:11:01 #corewars: < Fizmo> paper with imp steps?
19:11:30 #corewars: < Metcalf> No
19:12:08 #corewars: < Metcalf> pap1:spl   pstep,       0
19:12:09 #corewars: < Metcalf>      mov   >pap1,       }pap1
19:12:09 #corewars: < Metcalf>      spl   #0,          0
19:12:09 #corewars: < Metcalf>      add.f #istep,      igo
19:12:09 #corewars: < Metcalf>      mov.i #1,          <1
19:12:09 #corewars: < Metcalf> igo: djn   imp-21*istep,#-200
19:12:11 #corewars: < Metcalf> imp: mov.i #istep,      *0
19:12:33 #corewars: < Metcalf> 7 processes in a Jedimp paper with anti-imp bombs.
19:12:40 #corewars: < Metcalf> Hmmm 21 should be 14
19:13:59 #corewars: < Fizmo> hrmm, maybe try a DieHard-style paper. It's really fast in imp generation
19:14:05 #corewars: < Metcalf> It's a five minute warrior, something I though of trying while I was on the bus
19:14:16 #corewars: < Fizmo> lol
19:14:23 #corewars: < Fizmo> and you entered the hill
19:15:13 #corewars: < Metcalf> Only just
19:21:13 #corewars: < jaska> still.
19:21:49 #corewars: < Metcalf> Still?
19:22:00 #corewars: < jaska> 'still, thats pretty good'
19:23:37 #corewars: < Metcalf> Ah :-)  It won't be there for long though, it's right at the bottom
19:24:28 #corewars: < Fizmo> until my new stone/imp is ready to exchange the bottom place ;-)
19:36:47 #corewars: < Metcalf> Okay, it seems that paper is rubbish!
19:37:06 #corewars: < jaska> toilet paper.
19:37:41 #corewars: < jaska> ;)
19:38:13 #corewars: < Metcalf> Thanks Jaska!
19:38:33 #corewars: < jaska> heh.
19:38:51 #corewars: < jaska> oh well, enough bad jokes for today. im out
19:44:50 #corewars: < Fizmo> Did you read todays log about QCW?
19:45:35 #corewars: < Metcalf> Yes, I've saved it to read properly later though
19:51:44 #corewars: < Fizmo> yes, it's a lot to read ;-)
19:52:05 #corewars: < Fizmo>  am waiting for the time that a one days log reaches the 100k ;-)
19:56:08 #corewars: < Metcalf> We've had 100k in the past :-) This time last year maybe
19:57:53 -!- Jeff_K [~sascha@dial-194-8-205-254.netcologne.de] has joined #corewars
19:58:13 #corewars: < Jeff_K> Hi
19:58:14 #corewars: < Fizmo> Hi Sascha
19:58:35 #corewars: < Jeff_K> Hi Dande 3 scores nice on 94draft !
19:58:58 #corewars: < Jeff_K> Which improvements you choose for dande III ?
20:01:15 #corewars: < Metcalf> Hi Sascha.
20:01:20 #corewars: < Fizmo> Dande 3 and III are the same. I've already send it to you!?!
20:01:23 #corewars: < Metcalf> Sorry, it is time for me to get going.
20:01:29 #corewars: < Jeff_K> Oh hi John....bye John..
20:01:38 #corewars:  * Fizmo waves
20:01:40 #corewars:  * Metcalf waves
20:01:59 #corewars:  * Metcalf still wants to download the entire of r.g.cw postings somehow
20:02:00 #corewars: < Jeff_K> No, nothing in my inbox...But Dande 3 is the Version from me or ?
20:02:05 -!- Metcalf [~John@217.158.137.194] has quit [mov.i #1,1]
20:02:56 #corewars: < Fizmo> I've added the Q^4.5 now scoring 151.15
20:03:07 #corewars: < Fizmo> after bootstep optimization
20:03:11 #corewars: < Jeff_K> Hmm, not so much better you guess !
20:03:55 #corewars: < Fizmo> As I told you, because the code is too big leading in a too slow booting and launching of the scanner
20:04:25 #corewars: < Fizmo> about 1.5 points better
20:04:50 #corewars: < Fizmo> but on the hill it scores much better than the no-QS version
20:05:01 #corewars: < Jeff_K> Much ?
20:05:34 #corewars: < Fizmo> without QS it was just on the bottom half of the hill
20:05:53 #corewars: < Fizmo> 16th
20:06:21 #corewars: < Jeff_K> Ahh, i see 3rd ?
20:06:43 #corewars: < Jeff_K> and 7nth
20:06:58 #corewars: < Jeff_K> Oh, Arrow leading with nice gap !
20:07:40 #corewars: < Fizmo> I've just included the zoom-trick and reoptimized everything:)
20:14:14 -!- bvowk [~bvowk@h24-67-137-90.ed.shawcable.net] has joined #corewars
20:33:16 #corewars: < Fizmo> Hi bvowk
20:42:59 #corewars: < bvowk> Greets fiz
20:45:00 #corewars: < Fizmo> how is going?
20:49:53 -!- michal [~michal@host-ip2-246.crowley.pl] has joined #corewars
20:50:31 #corewars: < michal> hi
20:51:47 #corewars: < Fizmo> hi
20:52:31 #corewars: < Jeff_K> Hi Michal
21:00:00 #corewars: < bvowk> its going well fiz
21:00:44 #corewars: < bvowk> I'm finishing up some benchmarks on the fx51 I've got for demo...
21:00:48 #corewars: < bvowk> patching some free boxes
21:01:06 #corewars: < bvowk> playing with a 200W wireless card and a 12DB yagi :)
21:01:42 #corewars: < bvowk> moving my ids images to new versions of snort and ipaudit and everything.
21:02:20 #corewars: < jaska> 200W wireless card
21:02:22 #corewars: < jaska> not mW?
21:02:29 #corewars:  * jaska loots the fx51
21:02:53 #corewars: < bvowk> sorry.. 200mW
21:03:04 #corewars: < bvowk> 200W would be capable of cooking lunch
21:03:08 #corewars: < jaska> yeah
21:03:15 #corewars: < jaska> and birds sitting on your antenna
21:03:23 #corewars: < bvowk> that card really kicks ass
21:03:48 #corewars: < bvowk> we're going to a pub tonite at the top of a tall building on campus to see how much we can find :)
21:03:48 #corewars: < jaska> illegal here :P
21:04:00 #corewars: < jaska> well, atleast with any sizable antenna
21:04:06 #corewars: < bvowk> they're likely illeagal here too
21:04:10 #corewars: < jaska> we have ERP limits
21:04:25 #corewars: < bvowk> well, this card doesn't include an antenna by default..
21:04:27 #corewars: < jaska> iirc theres no ERP limit in FCC area, just card power limit
21:04:29 #corewars: < bvowk> its just got pigtails
21:06:56 #corewars: < bvowk> so.. wings and wireless tonite.. with some pinball :)
22:36:01 #corewars: < grabek> good night
22:36:10 #corewars: < Jeff_K> cu
22:36:14 #corewars:  * Jeff_K waves
22:36:59 #corewars:  * Fizmo waves
22:37:36 #corewars: < Fizmo> BTW, has anyone solved the crosswords at:
22:37:43 #corewars: < Fizmo> http://www.corewar.info/cross1.html
22:37:47 #corewars: < Fizmo> ;-)
22:45:43 #corewars:  * Jeff_K waves
22:46:10 #corewars:  * Fizmo waves too
22:46:13 #corewars: < Fizmo> bye all
22:46:20 -!- Jeff_K [~sascha@dial-194-8-205-254.netcologne.de] has left #corewars []
22:46:28 -!- Fizmo [~fizmo_mas@pD9E6EEA8.dip0.t-ipconnect.de] has quit []
23:25:41 -!- michal [~michal@host-ip2-246.crowley.pl] has left #corewars []
23:25:42 -!- michal [~michal@host-ip2-246.crowley.pl] has joined #corewars
--- Log closed Thu Mar 18 00:00:44 2004