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
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> 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 >> >> 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>> 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 >> >> 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 >> >> >>
