One Point Solution

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg
Showing posts with label behindthescenes. Show all posts
Showing posts with label behindthescenes. Show all posts

Saturday, 8 June 2013

TCO 2013 round 2A: I wrote the 550 points one

Posted on 12:12 by Unknown

Another year, another year in which I don't get to round 3 of the TopCoder open. But like last year, this brings an opportunity, I can try wearing my problem setter suit this time.

550 points: Block3Checkers

Remember when I talked about problem setting SRM 579 and how we had issues just a day before the match?

Block3Checkers was the problem that was initially intended to be in SRM 579.

First version

You have a NxN board. There are three checkers in the board that belong to Alice, their positions touch the border of the board. 0 to 61 checkers occupy other slots and are neutral (can't be moved). What is the minimum number of squares in the board on which you have to add new checkers so that it is impossible for Alice to move any pair of her checkers to two adjacent cells (She is only allowed to move a checker horizontally or vertically to an empty spot).

I thought of this while walking/running. SRM 579 was nearby and there was no div1 medium. This was my chance to shine. My chance to make 125 bucks. But I didn't have a medium. So my mind started wandering.

The first version of the problem had this intended solution: Let us name Alice's checkers X,Y and Z. We need at most 3 checkers to block the path between X and Y (because we can always surround any of them with only 3 checkers, thanks to them being in the border of the board). We need at most 3 checkers to block the path Z and X or Y. The intersection. Of these two solutions would be THE solution. We just need two brute forces for three cells, and then somehow merge them. Similar to a meet-in-the-middle.

It seemed interested, proposed it. rng_58 liked it, although not because of my approach, but because he thought of another approach, a faster one that I didn't understand at all. But all was right. Kept developing this problem and the others as SRM 579's date approached.

Until the night before SRM 579. In which ivan_metelsky helped us figure out that this clever idea of a solution was wrong. This is a case it gets wrong:


..#A#...
A#.#N...
#.......
...N.N..
.......A
N.......
NN......
.NNN.N..

The Ns are neutral checkers, the As are Alice's checkers and the # are the positions in which to place 5 of Bob's checkers. The clever approach with intersections returns 6.

Pre SRM 579 crisis

So we only had few hours before the match. We didn't have a replacement problem and we knew two things: a) My solution, the intended one, was very wrong. b) rng_58's was probably not wrong but is certainly not easy to find. So we were undecided for a couple of hours whether to use the problem, but allowing brute force (it would become a very simple problem, you bruteforce for up to 5 cells on which to place the checkers, if you don't find a solution, you can return 6 directly). Or find a replacement. As you know, we eventually found a replacement.

TCO revival

This problem still existed, and I knew that, using the solution that rng_58 found, it had potential to either be a div1 hard or be used in the TCO rounds. I made the problem available for the TCO. And it was approved.

It took me a good while to understand the new solution. It requires you to take advantage of the checkers touching the border of the board. They effectively divide the perimeter of the board in three parts. Imagine if there was a 8-connected path of N or B checkers between one segment of the perimeter and another. This would effectively make a cut. Between all checkers inside and all checkers outside the space delimited by the path. So there are four six of connected components of N/B checkers:

1) Does not touch the border.

2) Touches only one of the segments of the border

3) Touches TWO of the segments of the border.

4) Touches all THREE segmens.

In case 1) or 2), this connected component does not block any path between Alice's checkers. If one component like 4) exists, the problem is already solved. Else we need two different components of the kind 3) (Each Connecting a different pair of segments)

So, the problem is, for every possible way to accomplish this, find the minimum number of Bob's checkers to add. What's the minimum number of checkers to make two different pairs of segments connected? What is the minimum number of checkers to make a center checker (N or B) connected to all three segments?.

Constraints discussion

This approach can be implemented fast , in fact it works for 50x50. But it needs work for such an optimization. I initially wanted the constraints to state as 8x8, it would make it not needed to make more test cases. And people would get tricked into making the wrong solution. But it didn't click with the admins. Too much risk to have a situation in which an optimized brute force of up to 5 cells passes.

Then it seemed like up to 12x12 was a fine idea, those bruteforces would be inviable. But rng_58 thought of an exponential approach that relies on dp. You can imagine that all empty cells connected to each of Alice's checkers have a specific color. So all empty cells connected with X are red. All empty cells connected with Y are green and all those connected with Z are blue. The remaining cells, are black. Clearly, two cells of different colors (except black) can't be adjacent, so that they weren't connected. this allows an optimized dp that would pass for n=12. So we needed to increase the constraints, again.

Too bad I learned of that during the morning. I had to give up some hours in the IPSC because of this. I kept my first IPSC hour making new challenges.

Read More
Posted in behindthescenes, explanation, tco, tco12, tco2012, tco2013 | No comments

Saturday, 18 May 2013

SRM 579 - Disaster averted?

Posted on 10:45 by Unknown

Yep I helped write the problem set this time.

I gave up trying to write div1 500s and div1 1000s. It has gotten a bit difficult to get things that are interesting and difficult enough for these slots. So I sent the admins some ideas for problems for the easier slots. Hoping that maybe there is a coder out there with the exact opposite issue - all his problems are too difficult for the easier slots.

UnlicensedPrimalCreatures

I thought of this one some time after playing a game. (Pro-tip: Spell Grez backwards). Seemed appropriate for div2 easy.

There are some creatures of different power levels. Your creature wants to defeat as many opponents as possible. A creature can only defeat creatures with a strictly smaller power level. When you defeat a creature, its power level divided by 2 is added to your own power level.

Just sort the creatures. If you make sure to always attack the weakest available creature until you cannot defeat anyone your power level will be maximum possible at the time you face any given creature. (If you face creature #i, you can assume you have already defeated all the creatures before).

UndoHistory

I dunno, I thought of this during a rush.

Initially UndoHistory = { "" }, Buffer = "", and contents = {}.

If you type a lowercase letter, then Buffer = Buffer + (the letter). And the new buffer is added to UndoHistory

If you press enter then Buffer is appended to contents[].

If you double click, you can do Buffer = (any element of UndoHistory)

You are given lines an array of strings. What is the minimum number of (key presses + mouse clicks) needed to make contents= lines ?

Let us say you are interested in typing the contents of the i-th element of lines, you can assume that all of the previous elements were also typed and added to contents. This means that all of the prefixes of each of the previous elements are in UndoHistory.

So we have two choices: a) Restore an element of UndoHistory (Always restore the one with the largest common prefix as lines[i]). And b) If the buffer is currently a prefix of lines[i], you can also continue typing. Note that there are times where even if b) is possible, it is still better to do a).

MarblePositioning

I proposed this problem for a previous SRM as a div2 hard. IT was rejected because it was too easy. So we tweaked that match's div1 250 into a problem that ended up being too hard. So now we prefer to try this "too easy" problem.

Given a list of up to 8 circles each with a given radius, line them up over a straight line so that the distance between the tangent point of the line and the left-most circle and the tangent point between the line and the right-most circle are as small as possible. You can place the circles in any order and they should not overlap.

A classical problem, since 8 is very low, we can try any permutation, what is left is to find the minimum distance given the chosen order.

Place the first circle, there is no condition to follow, so just place it at position 0.

Then whenever you place circle i, find the minimum position larger than 0 at which you can place the circle without overlap. This means that it should not overlap with any of the previous circles. For each of the previous circles, you can find the minimum positions at which circle i can be placed without overlap. The maximum of all these values is the new position for i.

Given two circles of radius r1 and r2, the minimum distance between the tangent points should be one such that the distance between the centers is exactly r1 + r2. The centers are located at (0, r1) and ( min_dist, r2). So you only need to solve an equation. The result is 2*sqrt(r1* r2).

TravellingPurchasingMan

I wrote this problem aeons ago. We even developed it and test cases. But we decided that it was too easy/not interesting enough for division 1 500 and put another problem instead.

This week, when I was offered the chance to write most of the problems of SRM 579, because someone else (Turns out it was ir5) had a div1 hard but no easier problems. We didn't have a div1 500. On Wednesday, I thought of a problem that seemed *WONDERFUL*. It was a lovely little problem with a interesting solution. However, just last night we found out that the interesting solution was wrong. There was still another interesting solution, but it would have been too hard for div1 medium. So with less than 16 hours before the contest, we had no viable div1 medium.

I remembered about TravellingPurchasingMan. It is very easy, but at least it exists - However, we had to spend the last 4 hours tweaking this problem so that it is not awful. It initially had 14 interesting stores. But since the problem was looking too easy we increased it to 16. It also had a much more complicated input format that required far more parsing. It was too annoying so we had to work into removing all that mess.

The solution is a strange dynamic programming one.

Edit: I regret nothing. And no, this is not a "standard TSP by dp", you still need to figure out that edges depend on the minimum time of your current vertex. And just because this extra step is trivial for you, it does not necessarily mean it was trivial for everyone (And the submission rate suggests it wasn't). Let me be frank: Not all div1 500s have to be made with the high level yellows and reds in mind. Quite honestly, we are sick of you guys being the only ones that solve more than one problems. If you could solve this problem easily, then great news! At least this time you had time to try and solve div1 1000; And since you are so good, I bet you solved it, right?. Meanwhile, at least more coders in the blue and mid to low yellow were able to enjoy more than *ONE* problem in a TopCoder match.

Also, it was either this problem or an alternate version of the marbles div2 hard with n<=10 we didn't have many choices, you know.

Read More
Posted in behindthescenes, explanation, problemsetting, topcoder | No comments
Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • TopCoder SRM 557 - finally
    SRM 557 Explanation for division 1 Easy and match recap. Explanations for div2 easy and div2 medium. It feels like it has been ages since t...
  • SRM 590 recap and editorial
    Another week another Topcoder match. Not a great day. I had a bad flu and still do. Div1 500: The one with Xor Given a list of cards with nu...
  • SRM 589 Editorial
    I have finished writing the editorial for TopCoder SRM 589: http://apps.topcoder.com/wiki/display/tc/SRM+589 . As you most likely noticed. L...
  • SRM 601 editorial (minus div1 hard)
    It is up: http://apps.topcoder.com/wiki/display/tc/SRM+601 This was a very dry editorial to write. All problems were mathy ad hoc or complex...
  • SRM 546: relief
    I figured I should post something about this SRM. I've been very busy these weeks because the semester is ending and I tried to win a t-...
  • TopCoder SRM 570: CentaurCompany and CentaurCompanyDiv2
    Another 570 editorial update: http://apps.topcoder.com/wiki/display/tc/SRM+570 . This time for the division 2 hard and division 1 medium. My...
  • SRM 533: Div1 500 MagicBoard explanation
    Finally solved it. It is a nice problem that is worth explaining in a post. You have a grid/board of at most 50x50 cells. Some cells contain...
  • SRM 526: The killing wait for results
    While I wait for results, here is my perspective on this algorithm contest. It began with issues, it had to be postponed 15 minutes. TC has ...
  • Member SRM 505: Part 1
    So, let me explain a couple of problems from a Topcoder Member SRM that I wrote and never got an editorial. BTW, it was the last member SRM....
  • SRM 586 div1 easy and hard editorials
    They are ready. PiecewiseLinearFunction StringWeight I solved div1 hard yesterday. Although it is probably not the easiest solution to expl...

Categories

  • acm
  • algorithm
  • answers
  • arenaplugin
  • badday
  • behindthescenes
  • bugs
  • c++
  • censorship
  • codechef
  • codeforces
  • contests
  • crocchamp
  • editorial
  • editorial.srm
  • embarrassing
  • explanation
  • gcj2013
  • gmp
  • goodday
  • google
  • googlecodejam
  • greed
  • groklaw
  • health
  • html
  • httpseverywhere
  • implementation
  • ipsc
  • ispc
  • java
  • kawigiedit
  • kindagoodday
  • lamebook
  • languages
  • lego
  • listedlinks
  • marathon
  • nasa
  • offtopic
  • ouch
  • postmortem
  • postportem
  • practical
  • probably_not_a_good_tip
  • problemsetting
  • programming
  • python
  • quora
  • rant
  • recap
  • slightlygoodday
  • snippet
  • srm
  • stl
  • strategy
  • swerc
  • tco
  • tco12
  • tco13
  • tco2012
  • tco2013
  • ternarysearch
  • topcoder
  • tricks
  • ubuntu
  • uva
  • vjass
  • vkcup
  • wc3
  • zinc

Blog Archive

  • ▼  2014 (1)
    • ▼  January (1)
      • Per problem memory and Time limits in Greed
  • ►  2013 (141)
    • ►  December (14)
    • ►  November (8)
    • ►  October (13)
    • ►  September (11)
    • ►  August (14)
    • ►  July (15)
    • ►  June (13)
    • ►  May (13)
    • ►  April (12)
    • ►  March (11)
    • ►  February (11)
    • ►  January (6)
  • ►  2012 (94)
    • ►  December (5)
    • ►  October (6)
    • ►  September (8)
    • ►  August (6)
    • ►  July (3)
    • ►  June (5)
    • ►  May (8)
    • ►  April (10)
    • ►  March (20)
    • ►  February (16)
    • ►  January (7)
  • ►  2011 (51)
    • ►  December (7)
    • ►  November (12)
    • ►  October (5)
    • ►  September (1)
    • ►  August (3)
    • ►  July (4)
    • ►  June (3)
    • ►  May (7)
    • ►  April (3)
    • ►  March (2)
    • ►  February (1)
    • ►  January (3)
  • ►  2010 (9)
    • ►  December (4)
    • ►  October (1)
    • ►  June (1)
    • ►  May (1)
    • ►  January (2)
  • ►  2009 (1)
    • ►  December (1)
Powered by Blogger.

About Me

Unknown
View my complete profile