Hi Elias, If I understood your solution correctly, it basically boils down to the (correct, as far as I can tell) assumption that, for every block of adjacent face-down pancakes, you need two flips: - one to flip all the pancakes up to the first face-down one - one to flip the whole block of now face-down pancakes back face-up
This seems to always be correct, except if the very top block is face-down, in which case one extra flip is required for that block. Having understood this, I came up with a slightly different solution: (~↑X)+2×+/2>/X if 0 represents a face-down pancake, and (↑X)+2×+/2</X obviously if 1 represents a face-down one. Does this seem correct to you? If it does, I hope it helped others understand your solution. Cheers, Louis > On 23 Jun 2016, at 02:39, Elias Mårtenson <loke...@gmail.com> wrote: > > No, actually not. The problem statement says that the final state of the > pancake stack should be that they are all facing up. Thus if the final state > is 0,there needs to be an extra flip done. > > Regards, > Elias > > On 23 Jun 2016 02:25, "Juergen Sauermann" <juergen.sauerm...@t-online.de > <mailto:juergen.sauerm...@t-online.de>> wrote: > Hi, > > a minor bug below: > > +/(X,1)≠(1↑X),X←1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 0 > 8 > +/(X,1)≠(1↑X),X←1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 1 > 8 > > Maybe you meant > > +/(X,¯1↑X)≠(1↑X),X←1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 0 > 7 > +/(X,¯1↑X)≠(1↑X),X←1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 1 > 8 > > /// Jürgen > > > On 06/22/2016 08:27 AM, Elias Mårtenson wrote: >> I've CC'ed the gnu-apl list with my answer to Christian's question, since I >> think this is an interesting discussion. For the newcomers, this is about >> the solution to this Codejam question: >> https://code.google.com/codejam/contest/6254486/dashboard#s=p1 >> <https://code.google.com/codejam/contest/6254486/dashboard#s=p1> >> >> It's quite simple actually. The idea is simply based on the observation that >> what you really want to compute is the number of transitions 0→1 and 1→0. >> >> The original list is compared to another list that is the same as the >> original, but shifted one step to the left. The last element shifted in is a >> 1, since you always want the final stack to be face-side-up. >> >> Thus, the comparison is: >> >> 1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 1 >> 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 1 1 >> --------------------------------------- >> 0 0 1 1 0 0 0 0 1 0 0 1 1 0 1 1 0 0 1 0 >> >> Then, all you have to do is to count the number of ones in the result. >> >> Addendum: >> >> I just thought of a different way to think of this. If I simply remove any >> series of consecutive numbers, all I have to do is to count the length of >> the resulting array (subtracting one if the final element is 1). However, >> the method of eliminating duplicates in APL is very similar to the above >> solution (comparing with a shifted array) so even if you approach the >> problem in this way, the code will be pretty much identical. >> >> Regards, >> Elias >> >> On 22 June 2016 at 13:09, Christian Robert <christian.rob...@polymtl.ca >> <mailto:christian.rob...@polymtl.ca>> wrote: >> X←¯1+?20⍴2 >> X >> 1 1 1 0 1 1 1 1 1 0 0 0 1 0 0 1 0 0 0 1 >> +/(X,1)≠(1↑X),X >> 8 >> >> >> Well, 8 is the answer to the question, it says nothing on how to solve that >> puzzle. >> >> A point + on your QI(fr) or IQ(us). >> >> eg: Keep your mind on the question, not on the solution. >> >> if you can elaborate on the 8 here, please do explain. >> >> well, I will dissect your code and try to figure out by myself. >> well, no, finally just tell me how that work. >> >> many thanks, >> >> Xtian. >> >> >> On 2016-06-22 00:47, Elias Mårtenson wrote: >> All solutions are available here: https://www.go-hero.net/jam/16 >> <https://www.go-hero.net/jam/16> >> >> But the relevant core of my solution is here (minus all the file parsing >> stuff): >> >> +/(X,1)≠(1↑X),X >> >> Where X is an array of 1 and 0 representing the state of the pancake stack. >> >> The code should be pretty clear, but please let me know if you need help >> understanding it and I'll be happy to explain. >> >> For reference, the full code is here: >> >> ∇Z←solve_case X >> Z ← +/(X,1)≠(1↑X),X >> ∇ >> >> ∇Z←IN read_case I ;line >> line ← ⎕UCS ¯1↓FIO∆fgets IN >> ⎕←"Case #",(⍕I),": ",(⍕solve_case line='+') >> Z←⍬ >> ∇ >> >> ∇solve FILENAME ;fd;n;s >> fd ← "r" FIO∆fopen FILENAME >> n ← ⍎ ⎕UCS ¯1 ↓ FIO∆fgets fd >> ({(⍵+1)⊣fd read_case ⍵}⍣n) 1 >> FIO∆fclose fd >> ∇ >> >> Regards, >> Elias >> >> On 22 June 2016 at 12:36, Christian Robert <christian.rob...@polymtl.ca >> <mailto:christian.rob...@polymtl.ca><mailto:christian.rob...@polymtl.ca >> <mailto:christian.rob...@polymtl.ca>>> wrote: >> >> Can I see your solution to the stack of pancakes ? >> >> I wrote a Lambda (at that time, 2 months ago) to reverse some pancakes >> off the top of the stack and experimented with that. >> >> No obvious solution came to me. >> >> I only need the mechanics/algorithm, not the READ from file part (but >> you can provide it if relevant). >> >> thanks, >> >> Xtian. >> >> >> On 2016-04-10 07:48, Elias Mårtenson wrote: >> >> Yesterday, I participated in the Google Code Jam (programming >> competition). For one of the tasks, APL was a very good fit. The question is >> here: https://code.google.com/codejam/contest/6254486/dashboard#s=p1 >> <https://code.google.com/codejam/contest/6254486/dashboard#s=p1> >> >> My solution (which I will not post right now, since one of you might >> want to give it a shot first) was terse and simple. A very simple APL >> expression. >> >> However, reading the input a file and formatting the result took >> many lines of very ugly code. >> >> This attempt at using APL to solve a real-world programming problem >> illustrated two separate issues that, needs to be handled: >> >> Firstly, the FILE_IO library is way too low-level. For example, in >> the Codejam tasks, one usually have to read a whitespace-limited sequence of >> numbers. When I solve the problems in Lisp, all I need to do is to call >> READ. A flextible IO probrary that makes these kinds of this simple would be >> nice. >> >> I could (and indeed have considered to) write such functions in APL, >> but this causes a second problem: >> >> Error handling in GNU APL is very bad. In particular, there is >> nothing similar to UNWIND-PROTECT (or try/finally in Java). There is no way >> to safely write code that opens a file, works on it and then closes it. If >> an error occurs, there is no way to ensure that the filehandle is closed. >> When I developed my solution to the Codejam problem, I ended up leaking a >> lot of file handles. >> >> Does anyone know how Dyalog and other vendors handle this? Do they >> have a full exception system? >> >> Regards, >> Elias >> >> >> >
