|
edit: wrong tab whupsCarbon dioxide posted:The size is still 11, and according to the histograms, 10 is possible, and so is a sub-200 cycle account. If anyone has any thoughts on how to get there, please share them. code:
Cycles 307 Activity 2 edit N+1 Another thing you can streamline is the fact that the TJMP step itself takes a cycle, so if you can pack more useful operations into a given execution of the loop the exa wastes less time doing its logic check. This ugly abomination does batches of 2 variables but as an ugly kludge has to work around the fact that it even numbers and odd numbers behave differently (it does this by adding another dummy entry at the beginning, then erasing it once the iterator has finished doing its thing) code:
Size: 24 Activity 2 A couple of further tweaks actually make it a lot easier just to split it into two loops, by varying the number (in this case 8) you can change the batchsize code:
Size 26 ...which is both faster and also slightly less horrendously inelegant, but I dunno if you really want to get into @rep structures just yet. silentsnack fucked around with this message at 04:29 on Dec 19, 2021 |
# ¿ Dec 19, 2021 00:07 |
|
|
# ¿ Apr 18, 2024 11:58 |
|
Oof. This puzzle made my brain hurt. There's a trick to speeding up operations by running multiple instances in parallel instead of sequentially, but then you have to deal with non-deterministic outcome of race conditions like when two EXAs try to take the same link in the same frame, so solutions would sometimes work and sometimes break for no apparent reason. This was my previous fastest solution, with some fairly insane workarounds:code:
All of the superfluous LINK 1 interlaced in the logic was because I kept running into problems with race conditions and/or having too many EXAs pile up in a host. I guess 38 is okay, and as a plus it looked really stupid in motion: Quackles posted:If a number goes above 9999 or -9999, it is set to 9999 or -9999. Ah, yeah this is what I was missing. Uggggh. code:
code:
...and as the other world-weary burnouts have said, "you get used to it" and "this is silly" silentsnack fucked around with this message at 02:28 on Jan 1, 2022 |
# ¿ Jan 1, 2022 02:26 |
|
Carbon dioxide posted:A 1-activity solution would be possible only if we could grab the last date from the log file and reuse that. However, the devs thought of that and have a test where the oldest log line isn't from today, so that won't work. Dunno, kinda vague but also Doubtful This one has a some reasonable optimizations and one really stupid trick. First up to reduce file size you can simply test every single value instead of skipping over the ones you know expect to return false, at the expense of wasting a lot of cycles. Also instead of having to COPY F M to transmit the ID which you'll need on multiple EXAs and necessitates another COPY M X operation, you can just COPY F X and then REPL code:
And for reducing the cycle count... think of the silliest thing you could try to make a program run faster, and see how it compares to what you're about to see. First here's something with generally the same general function+structure as your 58 cycle solution, but uses loop unrolling and TJMP spam to make the file search run a bit faster code:
code:
|
# ¿ Jan 15, 2022 21:51 |
|
GuavaMoment posted:You can have one exa feeding in the row data: If you're aiming for the theoretical minimum cycle count, you need your first #DATA input to be on cycle 2 (and then keep writing once every cycle. But as I later noticed we both ran into similar problems with getting the exit/cleanup down to 0 cycles) code:
This is about where the game starts throwing puzzles at you with enough complexity where it becomes more relevant that when an EXA tries to write to the M register, even if one is already waiting to receive, the sender still has to waste a cycle in the "I'm waiting to send!" state. Also the @REP in XC needs to be any number that isn't 3 or 9 because if the loop trying to JUMP then XC doesn't crash until another cycle later when trying to arithmetic a nil due to EOF. edit: it can actually be 24 lines instead of 26 if you don't mind being harder for human readers to parse, since if XA and XB are both trying to LINK 800 then XB goes first, drop XA's NOOP and COPY setup and swap the ADDI and REPL lines. ...also it occurs to me that it might be possible to make it even faster. Just gotta crash all EXAs on the same cycle #DATA is finished. The issue with the previous arrangement was being unable to kill XA before XA:26 wrote the last character, but that delay also required killing XA:27 which wasted a cycle. code:
...which turns out to be an even cruder approach, forgoing loops in favor of recursion and bruteforce @REP spam silentsnack fucked around with this message at 05:50 on Jan 23, 2022 |
# ¿ Jan 22, 2022 23:57 |
|
GuavaMoment posted:I've also got an 83 cycle solution now. Sending file 300 data over M saves a cycle from not having to wipe the file. I have a bunch of killer exas though and the solution is entirely dependent on exa ordering (which I found from trial and error) so the right exas get killed at the right times to save the last two cycles. It's clunky but it works. Another minor refinement is to combine two things I'd mentioned separately: we know file 300 has 27 entries and we need to COPY M #DATA on cycles [4,7,10,13...] so we need a COPY F M on [3,6,9,12...] since writing to M takes 2 cycles to complete, which lets us squeeze in some control logic instructions on [5,8,11,14...] and have XC loop/break smoothly so it kills XA at the right time and terminates on cycle 82 code:
silentsnack fucked around with this message at 20:42 on Jan 23, 2022 |
# ¿ Jan 23, 2022 20:30 |
|
1: depends on your definition of "friends" 2: depends on your definition of "always" Carbon dioxide posted:Shaving off those last three cycles is going to be tricky. Perhaps we can get rid of those unconditional jumps, but most of my ideas would require making more EXAs earlier and that wouldn't save any cycles because only one EXA can traverse any network link at a time. For the small solution, you can also use "link to a variable" and rearrange the code to fall through from the cloning operation to a different version of the clone, which eliminates the need for a JUMP/MARK pair in order to make both EXAs merge onto the same script. code:
And as you mentioned, if you want the fastest solution for this puzzle you don't have any spare cycles for clever/elegant JUMP flow control, just weapons-grade spaghetti code:
edit: part of the challenge in this problem is the fact the target host has very limited room. So if we use the recursive self-replication trick we need some way to avoid forkbombing ourselves into an impassable traffic jam. In this case we know the destination is exactly 4 jumps away so we can just make the loop somehow end after 4 jumps, easily done by adding a count variable to the loop. But here's a more general solution that would work in just almost any arbitrary-sized network (so long as there's no other traffic) but the code is bigger/slower because each clone cycle the main loop needs to spawn a separate process to handle the kill/grab/return routine, but the loop also needs to attempt to crash before it runs out of space to duplicate itself: code:
silentsnack fucked around with this message at 02:55 on Jan 30, 2022 |
# ¿ Jan 29, 2022 22:51 |
|
Carbon dioxide posted:By the way, using numeric MARK names doesn't make the code any easier to read. GuavaMoment posted:My fastest solution is fundamentally identical to yours, I've just found a few cycles to squeeze out of some places, and I squoze one more cycle out from the seek 124 trick; I was previously seeking to the end and going backwards through the files. 89/70/7 Files are at least 15 entries, but it's also possible to exploit the fact that they don't get much bigger, and that there are at most 7 files per tape. And you don't necessarily have to find the correct host since the filename is unique. code:
The REPL TAPE1 branch is because it takes the longest to reach TAPE3, so that one will be the limiting case and its EXA does as little else as possible. But the fact it's running a single codeblock and JUMP detours take more time, it required finding some place to wedge in between other operations. For reducing size further, dividing by zero is an efficient way to crash an EXA. As is grabbing a nonexistent file. code:
also here's a vote for 'thanks' even if it's just a meaningless nicety. as for the other question, who *doesn't* have a weird history with berkeley's EECS department? silentsnack fucked around with this message at 20:14 on Feb 5, 2022 |
# ¿ Feb 5, 2022 20:04 |
|
idhrendur posted:How long have you pretended to be human Carbon dioxide posted:let me know what further improvements are possible. Looking at my solutions... I don't even remember writing this but aside from obviously being the product of trial and error it seems crude/unfinished? Maybe I'm just tired but I'm not seeing what it does all that differently, other than minor improvements like combining COPY F X and an ADDI X F X operation into ADDI F F X. code:
|
# ¿ Feb 14, 2022 18:08 |
|
Sometimes/how? You can use some fallthrough structure to reduce size too code:
And to reduce time, the usual parallel countdown/kill shenanigans can work code:
edit: ...and after randomly thinking about this again a couple of days later, it occurs to me that there might be a more efficient way make the timers and #NERV writing run both in parallel and serial, but actually implementing that plan ends up requiring a special-case for the first pair: code:
1 cycle faster but it's tiredbrain'd garbagecode silentsnack fucked around with this message at 06:58 on Feb 28, 2022 |
# ¿ Feb 26, 2022 21:13 |
|
code:
code:
megane posted:I bet it was fun edit: GuavaMoment posted:...aside from leaving incorrect files in your home node, but as long as one of them is correct it works. I played the entire game naming my REPLs as REPL. I wonder if there is a fancy MODI command to cycle through every number and have that exa die on it's own at some point instead of using ADDI X 1 X. That would save the need for the KILL command. another method for execution/flow control is to pass a token between EXAs, like the M register or having each generation attempt to run a sequence that becomes invalid due to another EXA specifically not crashing: code:
Tinkering around further, turns out splitting the LMAO subroutine across two separate EXAs saved a bunch of cycles/lines. Also looks sillier, which is extremely important. code:
silentsnack fucked around with this message at 03:49 on Mar 20, 2022 |
# ¿ Mar 19, 2022 17:18 |
|
GuavaMoment posted:No idea. Spacechem has different properties on different platforms, so maybe he's not on windows? Nope. Copypasting CO2's 2918-cycle solution gives the same statistics, which should mean in the slowest run both our machines count up to the same highest value of 990. Assuming all three of us are running the same version of the game with the same pseudorandom seed; did you maybe mean "1967" in your post and/or skip a trivial detail in your explanation? The former would roll over from 1000 to 999 and SWIZ 321 is effectively MODI 1000 but as for the latter... SWIZ 1967 321 X = SWIZ 967 321 X = 967 SWIZ -1 321 X = -1 MODI 1967 1000 X = MODI 967 X = 967 MODI -1 1000 X = 999 ...MODI behaves differently with negative numbers.
|
# ¿ Mar 27, 2022 01:14 |
|
A/C As for solution optimizations you can reduce size a bit more by dropping the EOF test code:
And faster solutions are possible if you leverage the fact that all the files have >34(?) entries, and save lines for the unroll by squeezing some control operations into cycles where the receiver is waiting for the next M signal. code:
|
# ¿ Apr 2, 2022 19:54 |
|
Carbon dioxide posted:I'm gonna guess this is a vote for the Ember scenes? ayup
|
# ¿ Apr 2, 2022 20:08 |
|
Nth Doctor posted:I haven't started my pay through yet, but I was definitely considering how SWIZ could be used to help get the number of jumps to a book. both SWIZ X 3 T or DIVI X 100 T would accomplish that. but if you want an EXA that specifically goes to the right host, instead of just blindly spamming clones, there are multiple ways to go about it. Here's a sample code that only goes to pick up the first file in the list: code:
edit: and as usual some completely unrelated random thing reminded me go back and take another look at the Phage/Heart solution, because it kinda bugged me to have 3 separate control structures redundantly running independent countdowns of the same number. And it turns out the suspicion that there should be a better way was correct, it just required approaching the timer from a different angle. Previous best time was 62/50/45. code:
code:
silentsnack fucked around with this message at 23:03 on Apr 6, 2022 |
# ¿ Apr 3, 2022 22:51 |
|
Carbon dioxide posted:By the way, now that I got the second zine, here's a full explanation of the @REP macro. code:
Nth Doctor posted:Mass media is a sham and You never know... Nth Doctor posted:Lol I quoted Junpei and removed the tag for my post. Guess it would have been funnier to keep the meta-joke going by directly copying instead? silentsnack fucked around with this message at 02:29 on Apr 10, 2022 |
# ¿ Apr 9, 2022 23:14 |
|
GuavaMoment posted:I'm still chasing down one cycle I know is possible, so maybe you all can help? "depends on which cycle you mean" and/or "maybe you can figure the rest of this mess out" because 23 is feasible with a bit of effort and paying attention to order of operations, so i'm blaming you for this one: code:
and a 22 cycle solution is possible, but I haven't found a way to make it fit inside the solution size limit code:
|
# ¿ Apr 18, 2022 17:14 |
|
Beartaco posted:I've been playing through the game myself and I never once thought to do this. I'd been storing my index values on X and using repeated TESTs for all of my loops. Much appreciated! I think all the examples use X and they don't outright give you the minimalist loop structure since it's a puzzle game, but the first zine drops a few hints that "TEST operations overwrite whatever value is in the T register ...but it also has the same features as the X register, so you can also read/modify it however you want, and TJMP/FJMP only check whether or not T=0"
|
# ¿ Apr 20, 2022 20:59 |
|
Entropy always wins eventually, and I guess "business reasons" supposed to be a euphemism for money?Carbon dioxide posted:I feel like this might be the right approach to get to the smallest size. There's actually some duplicate code in there. But I can't quite figure out how to get rid of it. code:
Carbon dioxide posted:Runs at 47/72/24, which is still 10 whole cycles away from the top percentile. Most of it wasted on walking back and forth. I think I can't get any better without involving the M register. Here we can do some shenanigans that rely on something from the zine: "nerve voltages oscillate around -70mV but can spike up to 50 or down to -120" but here if we look at the testdata M shows all the characteristics but I think this is the first time we've seen sensory nerves like H and P that always stay near -70. Why is that useful? It means they're all 2-digit numbers and always have the same sign, but EXAs can handle 4-digit variables, at which point you can probably guess where this is going... code:
|
# ¿ Apr 30, 2022 18:33 |
|
GuavaMoment posted:silentsnack continues to otherwise kick my rear end. TBF quite a few times you've posted solutions better optimized than mine, in one stat or another, and it might not have been obvious but in going back through the game I've used some tricks derived from your posts, which I probably never would have thought up on my own. edit: ...or in some cases we've independently come up with the same technique, like this one GuavaMoment posted:Very easy to tweak this to save two cycles - have XA do a file copy of 7 length instead of 14, replicate an exa to do it again, and transfer 7 digits over at a time. It's a little faster because now you have two exas who can read and copy values at the same time instead of one doing everything. 35/56/21 silentsnack fucked around with this message at 01:52 on May 1, 2022 |
# ¿ May 1, 2022 01:47 |
|
Hacking is obviously its own reward if we're already bothering to play a goofy hacking puzzle game / arcade game? There are a couple of minor tweaks to get the solution smaller the first being to compress the auth sequence so long as the rest of the code to unpack it isn't longer than 12 more lines and/or you can have some parts perform multiple functions. code:
GuavaMoment posted:Major speed tips - the files are always multiples of 12, so unroll files into 12 long loops. I transmit the files, then go back through and replace the SSEA code. There's a third timing exa IN LOCAL MODE that exas in the buffer must communicate with first so that long files get done before short files. Also the longest files are 36 entries, so you only really need at most two EOF checks. And since the file sizes are somewhat predictable, IF we use one way or another to measure how big a file is, we can add a variable delay to make short files wait a bit to make sure they don't get dropped before a previous big file... which at some point requires experimentally finding values that work code:
My absolute fastest solution clocks in at 2265/123/1562 and is mostly the same as the 2304 version except for adding this to the end of XA, make XB/READER do @REP 36 x COPY F M and also instead of XB/WRITER and XC doing the patch substitution in the "buffer" node and simply dropping the output file directly where it's needed, they use our home machine for its extra storage space code:
What this version does differently is that it makes the writer patch files as fast as possible and EOF-crash to drop them someplace they won't cause traffic jams and also won't get picked up at the wrong time by the output bot (which is also involved in one of the achievements). The new XA now enters a loop of spamming clones that start in buffer, run back to home to try to grab whatever the next file is supposed to be, and if they're successful they report the success so no matter which order files get finished, XA only picks up the correct one because we know which filename is supposed to come next. silentsnack fucked around with this message at 23:56 on May 11, 2022 |
# ¿ May 7, 2022 23:22 |
|
Jade Rider posted:It's complicated and Better is subjective. GuavaMoment posted:I know 17 cycles is possible though. (.....) My lowest size is 25, and I know 21 is possible. once again I'm blaming you for making me do this. because that's definitely a reasonable thing to do. also because it was easier to copypaste and tweak your code than to untangle my previous 19 cycle kludge code:
code:
silentsnack fucked around with this message at 14:48 on May 26, 2022 |
# ¿ May 25, 2022 23:27 |
|
Similar to the Wonderdisc puzzle, we can reduce cycles for logic-jumps by @REPing some of the slowest and most repetitive processingcode:
As for size optimization, what if we compared scores directly instead of sending a bunch of busywork transmissions and VOIDing them? code:
berryjon posted:You'd Be Smarter than that silentsnack fucked around with this message at 20:45 on Jun 4, 2022 |
# ¿ Jun 4, 2022 17:38 |
|
GuavaMoment posted:No one on my friends list has a faster time, and one person ties me on lines, so this might be a time I can best silentsnack. There's one catch though - two friends have 24 for activity, and I'm not sure how that's possible. As you've tried to do! Yeah my best scores were 28 cycles and 22 lines, and my fast solution is mostly similar except significantly less efficient due to laziness and aiming for a goofy solution gif
|
# ¿ Jun 12, 2022 18:48 |
|
small solutioncode:
fast solution: code:
Quackles posted:Hacking those ATMs was your idea, Ember. And I'm not sure I understood it. silentsnack fucked around with this message at 20:57 on Jun 19, 2022 |
# ¿ Jun 19, 2022 16:27 |
|
GuavaMoment posted:I had a 60 cycle solution I was playing with last week, but it's gone? I must have done something and accidentally deleted it. I remade at least it but with more lines somehow? 50 cycles is possible. I've accidentally deleted a solution when I was trying to make a copy to experiment with several times, but luckily if you find the savegame directory (under My Documents on winders) there's also a 'deleted' folder which does what you might expect. It's tough to optimize size since it requires making tradeoffs, like if you write "300" before scanning the account list you don't need to TEST EOF which means you can use the T register for storage, but it requires SEEK code:
As for low-cycle solution, sending the number from accounts making withdrawals can be parallelized but at some point the JUMP operation in the file300 write routine imposes a speed bottleneck, so it's possible to save a few cycles by partially unrolling that loop. code:
|
# ¿ Jun 25, 2022 16:20 |
|
code:
GuavaMoment posted:The "Area code" (472) is always the same so you can skip some of the digits of phone numbers. That's the only serious change I think, it's a pretty straightforward challenge. code:
going with "Is it going to be enough?" and "Nothing about this is normal" silentsnack fucked around with this message at 22:06 on Jul 9, 2022 |
# ¿ Jul 9, 2022 21:59 |
|
GuavaMoment posted:After receiving a signal over M, create 5 exas, one for each centrifuge. Test to see if your centrifuge has the highest pressure, otherwise die. Yes, there's only room for 4 exas, but one will die soon enough for the 5th to enter the testing room. Then go turn off your centrifuge and send a done signal. 136/97/22. My low line is, uh, 86, so I don't think I've ever tried very hard at making one. 44 is the best low line among my friends, so good job on that! For all you wizards, get a solution down to 54 cycles. Somehow. Like the fact that the hardware registers are so annoying here's a solution that only includes one instance of ["#ZGC"] code:
Also here's one that's really suboptimal, it's just about the point in going for speed where I quit trying to do anything elegant or clever and just aimed for something that works code:
code:
|
# ¿ Jul 20, 2022 01:32 |
|
GuavaMoment posted:No thanks. Tthough I do like the UGH branch. That does make a lot of sense - find out what your slowest solution for turning off 4 centrifuges are, then turn everything off one cycle after. welp, that's okay anyway because apparently I was wrong. friday night a couple weeks later is obviously the perfect time for brain to decide I'm not allowed to sleep until I take another swing at this, because there was a bunch of useless/wrong junk code left in that 75 cycle solution from earlier attempts. after deleting the delay-juggling cruft it ended up going from 75/87/32 to 68/82/40 but then had some terrible ideas that I will unapologetically inflict on the universe: code:
|
# ¿ Jul 30, 2022 07:12 |
|
berryjon posted:There's something about this latest challenge that seems more by-the-numbers. It's not that standout or offers any technically interesting, just gathering numbers and sending them on their way. Sorta depends on what you're going for? Like if you're going out of your way to optimize for the fastest possible solution or whatever, the more (and more diverse) moving parts a program has the trickier it can be to keep parallel operations working in sync without adding too much extra overhead. But if all you're doing is bashing out any solution that solves the puzzle and moving on, yeah you can just keep doing what you've been doing before and gradually extending it without needing to get inventive and rely on structures where timing doesn't matter since each operation waits for the other to complete before continuing. Both are equally valid and especially for a first-playthrough where you don't have an audience, quick and dirty is good enough code:
code:
|
# ¿ Jul 30, 2022 20:12 |
|
One optimization is after a successful test showing we have 16 consecutive digits that are all [0~9], if we move to the next set in the file we already know that 15 of its 16 digits have passed the "F = -9999?" test so we only need to test the newest digit. If you're searching forward then that means after reading the 16th value the next one in the file needs to be -9999?'d then you jump back 16. if you're searching backward from the end then it's even more straightforward but ... uh, we'll get to that later. Or for a low-line solution, we can replace the whole first-pass -9999? test with two lines, so long as we use a tweaked algorithm that produces a final checksum that is negative IFF any one of its digits is negative. code:
Also as you suggested it a solution can handle a lot of stuff over the M register which ends up being faster since we can freely overwrite the X/T registers of a clone and then let it crash which avoids having to read the file twice with a SEEK -1 between. Even with parallelization, fast solutions start hitting a limit around 1500 cycles without looking at the comparison at the end that shows individual times to solve each different run of the puzzle, but once again if you start from the end and search backward most testruns end up being fairly fast (indicating the valid credit card numbers are mostly toward the latter half of the file) but several end up taking much longer. One way to do this is to make a separate copy of the beginning of the garbage file, like in this example exactly the first 100 entries, and check that independently while another EXA starts at position 85 to catch the overlap. code:
The fastest solution I've managed searches backward from the end and instead of copying the file it handles the slowest/earliest cases with a goofy hack that takes advantage of the fact that testdata for each run can apparently be uniquely identified by the first 3 digits of the garbage file. code:
berryjon posted:Could use some work
|
# ¿ Aug 9, 2022 00:04 |
|
Ember isn't getting progressively more ominous at all, is she?NHO posted:Good Conversation? A couple of test cases have 6 files to return, which creates a limitation in fast solutions in that you might run out of space for clones which can stall REPL spamming and throw the solution out of sync. My fastest solution uses 5 parallel search EXAs but one of them actually sits in host П-0004 generating clones which then link to П-9999 to try grabbing a file. code:
Though now that I think about it differently, maybe it would have been faster just to special-case grabbing one or two files from the biggest tests to make room, but whatevs I'm satisfied with 65 cycles And for small, it's another case where we can make a single loop do everything, in exchange for taking far longer to run. code:
It uses a single variable to countdown grab attempts from file 304 (which doesn't exist, but makes sure we get a few more KILL instructions before it tries to grab 299) all the way down to 0 (wasting cycles on another 199 attempts for nonexistent files) before the search hits 0 and triggers the logic to KILL all the remaining EXAs in the network.
|
# ¿ Sep 17, 2022 18:04 |
|
hehbewilderment posted:You've gotta be making GBS threads me. for optimizations, from the histograms it looks like 32 lines should be possible, maybe 31, but the best i've managed is 33 code:
fast solution isn't too mind-blowing, mostly splitting functions for parallelization with hard-coded delays so that the variable message length doesn't break loop synchronization code:
silentsnack fucked around with this message at 16:44 on Sep 25, 2022 |
# ¿ Sep 25, 2022 16:29 |
|
|
# ¿ Apr 18, 2024 11:58 |
|
You can speed things up a bit by initially collecting only the hostnames and using a shortened sorting method that only takes the lowest value instead of bothering with reordering the list each time; while that sort routine searches for the next host ID, a separate EXA builds the actual output file by retrieving the #NERV value from each host in sequence.code:
|
# ¿ Oct 2, 2022 07:15 |