[04:46] MSG: Read error: Operation timed out [04:54] Join: impomatic joined #corewars [05:01] MSG: Read error: Operation timed out [05:11] Join: OoS joined #corewars [05:19] MSG: Ping timeout: 245 seconds [05:23] Join: OoS joined #corewars [05:30] * OoS wonders what's for breakfast [07:28] MSG: Ping timeout: 245 seconds [08:48] Join: Mizcu joined #corewars [08:48] Join: Miczu joined #corewars [08:49] MSG: Client Quit [08:49] Part: Miczu left #corewars [08:53] Join: Mizcu joined #corewars [08:53] goddamn these irssi windows [16:26] bleh. [16:41] MSG: Ping timeout: 245 seconds [18:11] Join: Metcalf joined #corewars [18:11] Hi :-) [18:29] hrm. [18:29] * bvowk wonders. [18:30] evenin [18:31] whats up Miz? [18:31] quite a little [18:32] munching bacon/chedder cheesecurls while reading forums [18:33] Hi Bvowk, Mizcu [18:33] (and i was about to ask Metcalf again why my strangeopaper scores better with } than >, but i guess that should just remain a mystery) [18:35] Did I hint that I know the answer or not? [18:35] kinda like why the hell reepipaper work better with switched silk.. [18:36] you only mentioned about the bomb-mangling, which i dont consider to be big enough deal to make such a difference [18:36] I'm sitting in the garden with a bowl of Mango sorbet and a glass of rose wine, working on something for corewar.co.uk [18:38] But if you mangle one bomb, doesn't it overwrite all the others? [18:40] Hasn't anyone figured out the reepicheep thing yet? :-/ [18:41] damn, my creepypaper is on other puter, cannot confirm how the mangling happened [18:44] found it in the logs [18:49] and now, under quick tests and randopunched steps, the best-scoring "mangling" turns out to be the most obvious [18:50] i hate it when its hard to see when a change is a mess-up in pattern or just a design-flaw [18:54] ah, what the heck, it not that good anyway [18:54] spl @0, pstep1 [18:54] mov }-1, >-1 [18:54] mov.i #0, <1 [18:54] spl pstep2, step [18:54] mov.i }-2, }-1 [18:54] mov.i {-3, {1 [18:54] djn.f *pstep3, Just add processes and spice with prepostdecincrements. [19:03] With spl pstep2, >step against an imp you risk breaking the anti-imp [19:03] And with spl pstep2, >step against a paper you risk turning the opponent into weak imp [19:03] yes, < scores best [19:07] There's a minor risk of mutating your opponent into a clear [19:07] Back in a bit, family have arrived! [19:09] I don't know if I mentioned the answer to the 82% score in a round-robin tournament? [19:09] Cowboy in ICWST'88, http://corewar.co.uk/icwt1988 [19:13] MSG: Ping timeout: 245 seconds [19:39] 'reepicheep thing'? [19:40] reepicheep is a seriously strong paper/stone, with a paper that has an oddity [19:40] the base element for a ordinary paper today is the silk, the spl @0, <>{} stepsize | mov }-1, >-1 [19:41] but nobody knows the 'oddity' [19:41] plain spl @0, stepsize will work, but adding the <>{} will give a small, free attack to the location before the paper overwrites the location [19:41] * evitable nods [19:41] well, the most generic ordinary paper is silk silk attack reverse-silk [19:42] ok you lost me a bit there :P [19:42] well i guess not [19:42] since there is code after the mov [19:42] and reverse would what.. just copy at a negative step, or copy in reverse? [19:43] that would be mov jmp (or jmz or jmn or djn) [19:43] because a third spl mov would leave extra processes to die at the end of paper [19:43] right [19:44] i see [19:44] but where the reepicheep differs is the second silk, which is spl step, 0 | mov >-1, }-1 [19:44] this variant has been considered inferior because it doesnt allow the use of <>{} [19:44] otherwise it functions the same [19:45] but it actually works better? [19:45] yes [19:46] and nobody(except the author?) knows why [19:46] Metcalf and Grabun were testing all sorts of weird stuff in testwarriors, and the paper with that anomaly scored best [19:46] i guess i'd have to work out what 'works better' means before i thought about that [19:46] well, you see, Metcalf is the other writer of reepicheep, and he doesnt know either why it does so. [19:47] well the obvious difference is the order the processes execute in [19:47] spl step starts the new paper sooner(?) [19:47] er what am i talking about [19:47] @0 [19:47] hee. [19:47] ah, you misunderstood a bit [19:48] still get mixed up a little with the modifiers [19:48] i follow now :P [19:48] it was a normal spl @0, step | mov -silk that was replaced with spl step, 0 | mov [19:48] right.. i read that as spl 0 [19:48] till i scrolle dback up [19:48] or, remembered it as* [19:49] Join: Neo_away joined #corewars [19:50] Roy used to do some research in the reepipaper, and he once almost figured it out, only to find out he was wrong [19:50] Nick Change: Neo_away changed nick to Neogryzor [19:50] hello [19:50] hi Neo [19:50] hi Miz [19:51] well [19:51] what's up? [19:51] a number of things still cmoe to mind [19:51] come* [19:51] hi evitable [19:51] got a link to that paper? it'd be better than spouting redundant ideas [19:51] ;P [19:52] since the mov is pretty much irrelevant (i don't know if the reversal of > and } was intentional, but i can't see it making a difference), it's the spl that matters [19:52] http://users.ociw.edu/birk/COREWAR/94/HILL/reepicheep.red [19:52] if spl @0 gets modified, things go awry but if spl 0 gets modified, at least functional code is still running, more or less [19:53] err [19:53] no, in both cases any modification to either the a or b-field will lead to an instruction being not copied [19:53] Roy used to do some research in the reepipaper [19:53] that paper [19:53] :P [19:53] heh, discusing about reepicheep's paper? :) [19:53] * evitable shrugs [19:54] i was just asking about it [19:54] since someone mentioned it [19:54] unfortunately that is the original warrior, its not really in easy-to-read mode [19:54] Mizcu: yeah, an instruction doesn't get copied right, which leads to the next paper failing [19:54] but spl 1 just puts more processes into the current one [19:54] instead of off into lala land to die [19:54] but the paper-part itself is the first 11 lines so thats ok [19:54] where spl @1 ..? [19:55] i guess it'd go to -1 [19:55] Silk-style papers will never again run the spl's after the start [19:55] which is the same as spl 0? [19:55] bleh [19:55] silk-papers are run with 8 processes on top of each other [19:55] * evitable nods [19:55] i need more study [19:55] hehe [19:55] brainstorming comes naturally though! [19:55] so its runs the first split eight times, then the mov eight time [19:55] i <3 puzzles [19:55] right [19:55] (8 is the most common number, there are others too) [19:55] i'm just saying that, the spl is the only 'change' [19:56] so what can happen to that command and how will it differ between the two versions [19:56] one thing that can happen is it gets inc'd/dec'd [19:57] the other thought i had is perhaps the 'free attack' which is modifying code in the location you are copying to is causing more unreliable results by screwing up executing code before the copy [19:57] i think thats the point [19:58] problem is that we need someone to matlab up the places where the paper "branches" on top of itself and cause the self-mutation [19:59] :D [19:59] with two ordinary silks there are two places that can cause mumbling with the dec/inc/whatever, but with one normal and one "switch" silk there is something in the pattern which overlaps but continues anyway [19:59] you don't need matlab [20:00] reepicheep is also notorious for the "growing" of processes in individual papers to cause bigger carpets [20:00] bvowk: when one has a hammer.. [20:01] so the point comes to that we need a mathematical model for the behaviour of cheep, and lot of people consider that to be a limit where fun becomes obsession [20:01] although Neo is not a monsterravinglunatic even though he did matlab one of hes papers to be "optimal" [20:02] try to calculate all the places where paper copies are located is a nightmare. Keep in mind there can be many mutations [20:03] let alone in reepicheep where there is a stone throwing curveballs [20:03] Unfortunately my Matlab silk analizer is lost :'( [20:04] its still in rgc [20:04] is it? I'll check [20:05] or atleast in the google archive of it [20:06] by the way, is there a particular warrior that the reepicheep silk makes a marked difference against? [20:06] never tested, actually [20:07] reepicheep is also notorious for the "growing" of processes in individual papers to cause bigger carpets [20:07] more processes = splitting into itself instead of into space, i would think [20:08] problem is that the stepsizes are optimized for that particular paper-type, and switching the silk would require new steps, which is not anymore the same [20:08] since the paper has three offshots [20:08] kinda like taking swordsman, and analyzing him by giving a mace [20:08] if one gets mangled and makes more processes, the ones after it would have more procs running on them? [20:08] hee [20:08] but it does the same thing [20:08] code-wise [20:08] evitable: that happens simply by two copies of paper overwriting eachother, Inversed has an example of it in RGC [20:09] it might not behave optimally against other warriors or something, but for comparative purposes..? [20:09] give me a sec and ill get the results [20:16] don't mind me too much, i'm still a noob [20:16] i has an idea [20:16] damnit, second mistake i make during 15 mins [20:19] here is something interesting [20:19] if you run reepicheep by itself [20:20] after 80k cycles [20:20] it has 5881 processes [20:20] if you modify it so that the second silk matches the first [20:20] after 80k cycles, it has 1247 processes [20:20] which makes sense [20:20] since it's a paper, it's more likely to attack itself than something that's just sitting there [20:20] so it is successfully destroying plenty of its own processes [20:21] and each one it successfully kills cuts off a whole branch of procs [20:21] the difference of course is, less procs = more movement [20:21] http://users.evtek.fi/~mikaos/reepaper.log [20:21] and more procs = less movement, but more stuff [20:21] by those scores, i hold by swordsman-comparison [20:21] by -> my [20:22] i wonder if it'll max out on procs if i make them both into the second version [20:23] hm nope, 4k or so [20:24] anyway, that's not really representative, you change too many variables :P [20:24] gotta determine first if the score change is in how it affects itself or how it affects the opponent [20:25] two things that pop out now that i analyze [20:25] a) scores same against willow and crazyshot b) huge difference in strenght against SoV [20:25] perhaps it just strikes a better balance between standing processes and movement [20:25] wonderful [20:25] gives me something to look at :> [20:25] all you did was change the second paper to match the first, ya? [20:25] now i get son of vain and watch what happens [20:26] i changed the instruction, not the stepsize [20:26] right [20:26] that's what i did, just made the commands the same [20:26] see, the thing about comparing them both with optimized stepsizes is [20:26] the stepsize that is "optimal" is the one that gives the best results in combat [20:26] also, those scores against (whole) reepicheep are really messed up [20:26] but that doesn't help you compare one set of code against the other [20:26] i gotta watch this on graphic [20:27] it just helps you compare the "best" each one can do against each other [20:27] which isn't what the goal is [20:27] so your mace analogy is only correct in the context that we don't want to work in :P [20:28] or i'm just confusing myself [20:28] i keep getting interrupted by work [20:28] * evitable thinks [20:28] the change makes an obvious difference in the comparative best results [20:29] i guess that makes it kinda hard to pin down [20:29] since the change in stepsize alters a ton of things over the course of the run [20:30] but if you want to find the difference the code itself makes... you want a drastic difference and a simple change [20:30] so i guess watching the versions you have vs son of vain could be a big clue [20:30] you want to figure out why one version is dying and the other isn't [20:30] and maybe run them both again with the other 'best' stepsize [20:31] http://users.evtek.fi/~mikaos/ree2.png http://users.evtek.fi/~mikaos/ree3.png [20:32] ree2 uses what you should be looking at is the +0..0---..... [20:33] oh, of course.. the idea that was slipping away from me just came to me [20:33] ;P [20:33] what really needs to be done is pick a step size that favors neither version [20:33] preferably scores the same against the target warrior (SoV) [20:33] and then the only thing responsible for the score difference will be the code [20:33] i don't know what that screen means :( [20:33] there is an early branchcollision which is not affected by <, curious, since there are decrements (---) on the dying papers [20:34] bright white =executing [20:34] - = dec'd [20:34] + = inc'd? [20:34] bright = dead, blank = processes [20:34] mk [20:34] . = something moved [20:34] the early branch collision could be responsible for the difference in processes [20:35] well, backtracking the string-of-though "why there are different amounts of processes" ends up with a collision [20:36] but why the switch turns the collision harmless? [20:36] which on makes it harmful? [20:36] the 'weird' one or the normal? [20:37] my entirely unsupported thought about papers is that [20:37] if they keep making more processes they become more vulnerable [20:37] so the ideal is to maintain some sort of balance between the copies so that they can't all be murdered [20:37] on the other hand, more processes makes it resistant to getting stunned so meh [20:37] not exactly, but i do every once in a while hold such train of thought [20:38] and then, is the collision responsible for better scores or not? one wonders [20:38] anyway, i know what i'd want to test next.. that's changing the stepsize so it's not optimal for either one [20:38] that way the results when comparing the two code versions aren't biased by optimization in the favor of only one of them [20:39] true, there probably is a magical optimal position in the number of processes, but in practise more is better (because it takes longer to kill all of them, and the timelimit on '94 is somewhat tight when there are really defensive warriors around) [20:39] yeah, besides some are gonna die anyway [20:41] oh, as to your question about why the switch turns the collision harmless... [20:41] the one with less processes has more dec-attacks [20:41] so that makes sense.. taking away the "free attack" is killing itself less often [20:41] not true [20:41] ? [20:41] the free attack is on the place where the paper will copy itself next [20:42] just going by numbers [20:42] my numbers* [20:42] so even if there is no pre-attack, you will still get carpeted by another paper [20:42] sure [20:42] but then your processes are just going to launch new papers [20:42] and the decs happen a possible long time before the copies [20:42] if you have many processes, you have to wait for them all to have a turn before you execute the movs [20:43] true, but we are not talking about attack-dodging [20:43] so if dec'ing the target location causes the processes to die, they won't be executing the copied paper [20:43] then if you don't dec it, the target location gets overwritten only to run the paper itself [20:44] the target location being a friendly process, in this case [20:44] you should notice that a non-decrementing version of the non-switchpaper scores about the same as decrementing non-switchpaper [20:44] which are both worse than the switched paper [20:45] mk [20:45] oh, but here you are talking about scoring against other warriors again [20:45] using the stepsize that gives the best results for one of the three [20:46] if you'll allow me some add, i had another thought earlier too [20:46] another idea that would help tell if the number of processes is responsible for the performance difference, [20:46] you could limit the processes to something like 1000 [20:46] but the warriors you run it against would have to not be harmed by that limit i guess [20:47] there are atleast two cases of process-based fitness testing around [20:47] well that helps [20:47] i guess? [20:48] other one in SGB.pdf (Steves guide for Beginners) and another in Corewarrior newsletter, the tutorial to pmars-macros [20:48] anyway, i'm thinking that if you optimized the one that kills itself, it wouldn't kill itself [20:48] no, i was wrong with SGB [20:48] and so the number of procs isn't a likely focus for attention [20:49] ho hum [20:49] i can't actually do much of anything to play around while i'm at work ;| [20:50] no worries about that, sorry about draining your efficient work-time [20:50] haha [20:50] nah, i'm just saying that i should be testing rather than talking [20:51] i got a long run on the machine right now but i know better from the last few days than to get sucked into playing with code [20:51] ;) [20:51] i think i had a 4 hour day on tuesday or something :P [20:51] never came back from my lunch break [21:21] Join: Metcalf joined #corewars [21:21] Hi :-) [21:24] hi [21:27] Hi Mizcu [21:28] see our fruitful discussion which was held while you were away [21:30] was it fruitful? :| [21:31] it made me open pmars again after a few month break, so in that way, yes [21:39] I'm surprise no-one has figured out why Reepicheep's second silk works well [21:40] do i hear a hint of mock in your words? [21:40] No [21:41] We know you have Incredible! somewhere, give all the secrets you have! [21:41] maybe it's not the second one that's working well :> [21:42] maybe it's the first one klobbering the second one! [21:42] I'm just surprised so many people looked, but no-one saw why it works. At least if they did, they haven't publically mentioned it. [21:42] Remind me about Incredible ;-) [21:42] * evitable reminds Metcalf about Incredible [21:42] i don't have a redcode Stash [21:42] but i wanna play around with this reepicheep now [21:43] i don't suppose i could prevail upon you to hook me up with what you used to optimise it/test it? [21:43] just so i can be using the same stuff [21:45] #corewars is the irc.koth.org Core Wars discussion channel. [21:45] * Metcalf wonders how that ended up on his clipboard! ^ [21:46] oh wow [21:46] haven't seen that version in a while [21:49] What version? [21:52] Evitable: I used a similar benchmark to this to optimize Reepicheep http://corewar.co.uk/ss2002/ssr5bm.zip [21:56] I guess this is Incredible: [21:56] Program "Incredible!" (length 5) by "John Metcalf" [21:56] ;strategy tweaked away one instruction [21:56] Last battle concluded at : Sun Dec 1 17:26:58 EST 2002 [21:56] Survived to 180 on '94 draft hill and was once Koth ;-) [21:57] (15:37.42) [Metcalf VERSION reply]: XiRCON 1.0B4 [21:57] that version [21:57] Metcalf: i dunno, i read of the existence of some programs and i wouldn't know what settings to use etc [21:57] just wanted reproducible results to play with [21:57] ;) [21:57] i'll check it out when i have more time [22:01] I have Chatzilla, but I prefer not to get kicked out of #corewars every time Firefox crashes [22:02] evitable: I notice you was asking about imp launchers. Did you see http://corewar.co.uk/nw02.txt [22:07] aha [22:08] no, i haven't read any of that one yet [22:08] also do i need to pick up certain warriors for that optimizer thing? [22:08] well, the point is that the warrior will drift towards getting better at killing what you feed it [22:09] so best would be fighting as many warriors as possible, but it takes a little too much processing power [22:10] (unless you are bvowk) [22:10] so generally you either put stuff through different benchmarks in different parts of development, or you give it a multipurpose "balanced" benchmark [22:11] ive had paper that scores 75% wins against two ultra-tough scanners but only average against general opponents [22:13] Did anyone notice paper / scissors / stone works in reverse on the nano hill? ;-) [22:13] re: imp launchers, i don't really like copying code, so i just wrote my own and i was curious if it sucked or not [22:13] Metcalf: yes, we already have [22:13] i haven't done anything on nano but that's pretty funny [22:14] actually i have an idea i want to try now :> [22:15] but no time to code it aw [22:41] Okay, question of the week - [22:46] Who first used the word 'Warrior' to describe Corewar battle programs? [22:47] one of those oldbeard-questions.. [22:47] AKD used only 'program' [22:51] Buckley? [22:54] nano stone actually don't beat anything, (almost my stones don't...) [22:54] almost equ at least [23:09] time to sleep [23:09] * Neogryzor waves [23:09] MSG: