(defun solve (file)
(with-open-file (in file)
(let ((ncases (read in)))
(dotimes (caseno ncases)
(solve-case caseno in)))))
(defun solve-case (caseno in)
(let ((n (read in)))
(let ((wires (make-array (list n))))
(dotimes (i n)
(setf (aref wires i)
(cons (read in) (read in))))
(let ((sol (intersections wires)))
(format t "Case #~D: ~D~%" (1+ caseno) sol)))))
(defun intersections (wires)
(let ((result 0))
(do ((i 0 (1+ i)))
((>= i (length wires))
result)
(do ((j (1+ i) (1+ j)))
((>= j (length wires)))
(when (intersectsp (aref wires i) (aref wires j))
(incf result))))))
(defun intersectsp (w1 w2)
(if (< (car w1) (car w2))
(> (cdr w1) (cdr w2))
(< (cdr w1) (cdr w2))))
Sunday, May 23, 2010
GCJ 2010: Rope Intranet in Common Lisp (Online Round 1C)
I failed at online round 1 this year, although I tried twice in sub-rounds 1B and 1C. The first puzzle in sub-round 1C, Rope Intranet was easy, and I handed in the correct solutions for both the small and the large input in less than ten minutes. Here is the straightforward code:
Sunday, May 09, 2010
GCJ 2010: Theme Park in Common Lisp (Qualification Round)
A trivial implementation will work fine for small cases, but not for a day with 108 rounds! I convinced myself (correctly I think) that I need to memoize intermediate results. I decided that I should memoize, for each group that is at the head of the queue, two values: The number of people (thus Euros) from the head of the group that would fit into the roller coaster, and the pointer to the next head of the queue (the index of the first group that will not fit). Then I could just iterate R rounds starting with queue pointer 0, and add up the (mostly cached) results. I would have to compute the roller-coaster occupation at most once for each group in the queue (max. 1000 in the large case).
However, I still have to iterate R rounds, so depending on the speed of the computer this can take long. During my attempt at the large example, I suspected that the laptop I was running this on wouldn't complete the computation in time, and copied everything over to a faster machine. On the laptop it took 2'40", on the faster machine around 45".
This is the (inefficient) code as used in the contest:
This code takes 0.34 seconds for my large input, even on my netbook at home - which took 20 minutes for my initial (naïve with memoization) solution! Only eight minutes are allowed for submission of a large solution...
In a way I was right not to optimize this further, because the naïve memoized solution turned out to be (just) fast enough. But this is exactly the kind of not-thinking-the-problem-through that will hurt me in the "real" rounds of the competition. Maybe it would be good training to change the solution into one that calculates all possible values up front rather than on-demand (caching).
Followup: Complexity Analysis and Iterative Solution
The complexity of the first algorithm (naïve with memoization) is O(R+N2). The work for each R is just a memory access (within the relatively small cache), an integer addition that fits in 64 bits, and a few assignments. Therefore it can still work when R is close to 108. The N2 comes from computing the occupancies of the roller coaster for each possible group that may be in front of the queue at the start of a round. There are N such groups. For each position, computing the occupancy may take up to N steps. Note that by "computing the occupancy", I always mean computing the occupancy and the next head-of-queue group.
The complexity of the second algorithm (like first but with cycle detection) is O(N2), because each possible position in the queue (there are N of these) can be visited twice at a maximum. Again, the complexity of finding the occupation of the roller coaster given a queue pointer is O(N).
The complexity can be brought down to O(N) as follows: The occupancy is computed completely only for the first queue-head group. Then, the occupancy for each subsequent group can be computed incrementally from the previous one in a small number of steps. Here is an implementation of this algorithm:
For my large-input set, this is not significantly faster than the second program (0.21s instead of 0.34s on my Netbook). But it would scale to a queue with massively more groups. And it is possibly optimal in terms of complexity class.
However, I still have to iterate R rounds, so depending on the speed of the computer this can take long. During my attempt at the large example, I suspected that the laptop I was running this on wouldn't complete the computation in time, and copied everything over to a faster machine. On the laptop it took 2'40", on the faster machine around 45".
This is the (inefficient) code as used in the contest:
(defvar *get-riders-cache*)
(defun solve (input)
(with-open-file (in input)
(let ((n (read in)))
(dotimes (k n)
(solve-case k in)))))
(defun solve-case (caseno in)
(let* ((R (read in))
(k (read in))
(N (read in)))
(let ((gs (make-array (list N))))
(dotimes (i N)
(setf (aref gs i) (read in)))
(let ((*get-riders-cache* (make-riders-cache N)))
(solve-1 caseno R k gs 0 0)))))
(defun make-riders-cache (N)
(make-array (list N) :initial-element nil))
(defun get-riders-cache (N) (aref *get-riders-cache* N))
(defun set-riders-cache (N new)
(setf (aref *get-riders-cache* N) new))
(defun solve-1 (caseno R k gs ptr sum)
(if (= R 0)
(finish-solution caseno sum)
(multiple-value-bind (next-group-size next-ptr)
(get-riders k gs ptr)
(solve-1 caseno (1- R) k gs next-ptr (+ sum next-group-size)))))
(defun get-riders (R gs ptr)
(let ((cached (get-riders-cache ptr)))
(if cached
(values (car cached) (cdr cached))
(multiple-value-bind (size next-ptr)
(get-riders-1 R gs ptr (length gs) 0)
(set-riders-cache ptr (cons size next-ptr))
(values size next-ptr)))))
(defun get-riders-1 (R gs ptr rql size)
(declare (type (unsigned-byte 30) R ptr rql size))
(declare (optimize (debug 0) (speed 3)))
(if (or (= rql 0) (< R (aref gs ptr)))
(values size ptr)
(get-riders-1 (- R (aref gs ptr)) gs (mod (1+ ptr) (length gs)) (1- rql) (+ size (aref gs ptr)))))
(defun finish-solution (caseno sum)
(format t "Case #~D: ~D~%" (1+ caseno) sum))
Back at home, I decided that I had to optimize this some more. In particular, when one finds a cycle (a queue index that has already been encountered during a previous round), one can just compute how many of those cycles can be filled with the remaining rounds, and add that number multiplied with the number of Euros earned during a cycle to the account. Then that leaves only a small (smaller than the cycle) number of rounds to execute. (defun solve-1 (caseno R k gs ptr sum)
(assert (>= R 0))
(if (= R 0)
(finish-solution caseno sum)
(multiple-value-bind (next-group-size next-ptr last-seen old-sum)
(get-riders k R gs ptr sum)
(if last-seen
(let ((cycle-length (- last-seen R))
(per-cycle (- sum old-sum)))
(multiple-value-bind (ncycles remaining-rounds)
(truncate R cycle-length)
(incf sum (* ncycles per-cycle))
(setq R remaining-rounds))
(if (zerop R)
(finish-solution caseno sum)
(solve-1 caseno (1- R) k gs next-ptr (+ sum next-group-size))))
(solve-1 caseno (1- R) k gs next-ptr (+ sum next-group-size))))))
This code takes 0.34 seconds for my large input, even on my netbook at home - which took 20 minutes for my initial (naïve with memoization) solution! Only eight minutes are allowed for submission of a large solution...
In a way I was right not to optimize this further, because the naïve memoized solution turned out to be (just) fast enough. But this is exactly the kind of not-thinking-the-problem-through that will hurt me in the "real" rounds of the competition. Maybe it would be good training to change the solution into one that calculates all possible values up front rather than on-demand (caching).
Followup: Complexity Analysis and Iterative Solution
The complexity of the first algorithm (naïve with memoization) is O(R+N2). The work for each R is just a memory access (within the relatively small cache), an integer addition that fits in 64 bits, and a few assignments. Therefore it can still work when R is close to 108. The N2 comes from computing the occupancies of the roller coaster for each possible group that may be in front of the queue at the start of a round. There are N such groups. For each position, computing the occupancy may take up to N steps. Note that by "computing the occupancy", I always mean computing the occupancy and the next head-of-queue group.
The complexity of the second algorithm (like first but with cycle detection) is O(N2), because each possible position in the queue (there are N of these) can be visited twice at a maximum. Again, the complexity of finding the occupation of the roller coaster given a queue pointer is O(N).
The complexity can be brought down to O(N) as follows: The occupancy is computed completely only for the first queue-head group. Then, the occupancy for each subsequent group can be computed incrementally from the previous one in a small number of steps. Here is an implementation of this algorithm:
(defun solve-case (caseno in)
(let* ((R (read in))
(k (read in))
(N (read in)))
(declare (type (integer 1 100000000) R)
(type (integer 1 1000000000) k)
(type (integer 1 1000) N))
(let ((g (make-array (list N))))
(dotimes (i N)
(setf (aref g i)
(make-group (read in))))
(let ((fill-level 0)
(end 0))
(do ((start 0 (1+ start)))
((= start (length g)))
(setq fill-level
(if (zerop start)
0
(- fill-level (group-size (aref g (1- start))))))
(loop
(when (> (+ fill-level (group-size (aref g end))) k)
(return))
(incf fill-level (group-size (aref g end)))
(setq end (mod (1+ end) (length g)))
(when (= start end)
(return)))
(setf (group-next-pointer (aref g start)) end)
(setf (group-fill-level (aref g start)) fill-level)))
(let ((ptr 0) (sum 0) (found-cycle nil))
(declare (type (integer 0 999) ptr))
(let ((result
(loop
(when (= R 0) (return sum))
(let ((group (aref g ptr)))
(when (and (not found-cycle) (group-last-seen group))
(setq found-cycle t)
(let ((cycle-length (- (group-last-seen group) R))
(per-cycle (- sum (group-euros-at-last-seen group))))
;;(declare (type (integer 1 1000) cycle-length))
(multiple-value-bind (ncycles remaining-rounds)
(truncate R cycle-length)
(incf sum (* ncycles per-cycle))
(setq R remaining-rounds))
(when (zerop R) (return sum))))
(setf (group-last-seen group) R)
(setf (group-euros-at-last-seen group) sum)
(decf R)
(setq ptr (group-next-pointer group))
(incf sum (group-fill-level group))))))
(format t "Case #~D: ~D~%" (1+ caseno) result))))))
For my large-input set, this is not significantly faster than the second program (0.21s instead of 0.34s on my Netbook). But it would scale to a queue with massively more groups. And it is possibly optimal in terms of complexity class.
GCJ 2010: Fair Warning in Common Lisp (Qualification Round)
The maximum possible factor is determined by the GCD between the Great Events in the past. Sorry for the unclear explanation. Anyway, the way I solved this is: I first sort the sequence of ages of past events in descending order. Then I normalize them with respect to the most recent of these events, by subtracting the smallest of these ages. I take the GCD of the other (non-smallest) event ages. This GCD defines a kind of cycle. The apocalypse (or party) will happen at the next possible cycle boundary after OR AT the current time.
Thankfully, Common Lisp has a variadic GCD function and efficient bignum implementations.
Thankfully, Common Lisp has a variadic GCD function and efficient bignum implementations.
(defun solve (file)
(with-open-file (in file)
(let ((ncases (read in)))
(dotimes (caseno ncases)
(solve-case in caseno)))))
(defun solve-case (in caseno)
(let ((nevents (read in)))
(let ((events (make-array (list nevents))))
(dotimes (k nevents)
(setf (aref events k)
(read in)))
;; We would like these to be in canonical order, let's say decreasing
(setq events (sort events #'>))
(let ((solution (time-to-apocalypse events)))
(format t "Case #~D: ~D~%" (1+ caseno) solution)))))
(defun time-to-apocalypse (events)
(let ((reckon (aref events (1- (length events))))) ;time since last event
(dotimes (k (length events))
(decf (aref events k) reckon))
(let ((gcd (apply #'gcd (coerce (subseq events 0 (1- (length events))) 'list))))
(if (= gcd 1)
0
(rem (- gcd (rem reckon gcd)) gcd)))))
GCJ 2010: Snapper Chain in Common Lisp (Qualification Round)
The snapper chain is a simple binary counter modulo 2N. The light bulb is on iff the value of the counter is all-ones. So all we have to do is check for that counter value.
(defun solve (file)
(with-open-file (in file)
(let ((ncases (read in)))
(dotimes (caseno ncases)
(solve-case caseno in)))))
(defun solve-case (caseno in)
(let ((n (read in))
(k (read in)))
(let ((solution (light-on-p n k)))
(format t "Case #~D: ~A~%" (1+ caseno) (if solution "ON" "OFF")))))
(defun light-on-p (n k)
(let ((cycle (ash 1 n)))
(= (rem k cycle) (1- cycle))))
Saturday, November 07, 2009
Mapping IXP access links
IXPs (Internet Exchange Points) are facilities where ISPs (Internet Service Providers) meet and can set up interconnection (peering) and exchange traffic between their mutual customers directly.
There was an interesting paper at IMC'09 called "IXPs: Mapped?", which fused data from various sources to get a more complete picture of peering at IXPs.
Here is one phenomenon that I think would be worth further research:
In the original model, the IXPs is at a colocation facility, where ISPs put their equipment (routers) and connect a router port to the exchange point switch via in-house cabling. But there's another option, where the ISP doesn't put a router up at the physical IXP facility, but instead connects an existing backbone router to the IXP by means of a leased line - could be a leased wavelength, or an Ethernet-over-{MPLS,SDH} service. Looking around me, I see this happening very frequently, e.g. quite a few medium-size Swiss ISPs lease bandwidth to Amsterdam, Frankfurt or London to connect to the large IXPs there (AMS-IX, DECIX, and LINX, respectively).
It is important to understand such non-local peering, because the impact of the access links can be quite large in terms of speed-of-light delay, and some transport media - e.g. Ethernet over MPLS - might be subject to unnoticed congestion. Also, long access links might be more difficult to upgrade in a timely manner when needed.
As an illustration, here's a traceroute between the ISP I work for (SWITCH, AS559) and an ISP in Gibraltar.
Can you guess in which city we interconnect?
There was an interesting paper at IMC'09 called "IXPs: Mapped?", which fused data from various sources to get a more complete picture of peering at IXPs.
Here is one phenomenon that I think would be worth further research:
In the original model, the IXPs is at a colocation facility, where ISPs put their equipment (routers) and connect a router port to the exchange point switch via in-house cabling. But there's another option, where the ISP doesn't put a router up at the physical IXP facility, but instead connects an existing backbone router to the IXP by means of a leased line - could be a leased wavelength, or an Ethernet-over-{MPLS,SDH} service. Looking around me, I see this happening very frequently, e.g. quite a few medium-size Swiss ISPs lease bandwidth to Amsterdam, Frankfurt or London to connect to the large IXPs there (AMS-IX, DECIX, and LINX, respectively).
It is important to understand such non-local peering, because the impact of the access links can be quite large in terms of speed-of-light delay, and some transport media - e.g. Ethernet over MPLS - might be subject to unnoticed congestion. Also, long access links might be more difficult to upgrade in a timely manner when needed.
As an illustration, here's a traceroute between the ISP I work for (SWITCH, AS559) and an ISP in Gibraltar.
$ traceroute www.broadband.gi traceroute to www.broadband.gi (85.115.130.100), 64 hops max, 52 byte packets 1 swiws1-v4 (130.59.4.2) 2.652 ms 0.271 ms 0.259 ms 2 swics5-10ge-1-4 (130.59.15.181) 0.334 ms 0.308 ms 0.317 ms 3 swics3-10ge-1-3 (130.59.15.189) 0.412 ms 0.336 ms 0.340 ms 4 swiez2-10ge-5-2 (130.59.36.18) 0.358 ms 0.347 ms 0.356 ms 5 swils2-10ge-1-1 (130.59.36.205) 4.001 ms 3.916 ms 3.983 ms 6 swiel2-10ge-1-2 (130.59.36.70) 4.081 ms 4.036 ms 4.069 ms 7 swice3-10ge-1-3 (130.59.37.65) 4.826 ms 4.843 ms 4.879 ms 8 ge-0-1-8-1.madrid.sapphire.gi (195.69.144.163) 58.489 ms 58.552 ms 58.530 ms 9 ge0-1-0-0.jcore2.gibraltar.sapphire.gi (85.115.128.63) 75.874 ms ge0-0-5-0.jcore2.gibraltar.sapphire.gi (85.115.128.49) 78.614 ms 78.640 ms 10 85.115.128.18 (85.115.128.18) 76.205 ms 76.101 ms 76.203 ms 11 * C-c C-c
Can you guess in which city we interconnect?
Subscribe to:
Posts (Atom)