One Point Solution

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Wednesday, 6 March 2013

SRM 572: hmnn

Posted on 05:54 by Unknown

As I write this around the end of the challenge phase. I can tell for sure that I solved the easy problem correctly. The medium one is a bit more of a mystery.

Div1 500: The one with digits

You have a set of guesses for a number of at most 9 digits. For each guess, you also know the number of correctly guessed positions it had. If there is a unique result for the number, return it. If there are no results, return "Liar", else return "Ambiguity".

This was looking tough until I noticed that the number of digits is at most 9. It is large for trivial brute force, but not TOO MUCH larger.

My first approach was optimized backtracking. Makings sure to crop the search whenever there is certainty a digit position would be wrong.

It is also necessary to cut the search whenever you find more than one result.

First tests seemed promising. But I was able to come up with a test case that made it time out. (A Liar case).

But it seems unlikely that a non-"Liar" case would require many steps. So I added something that stops the search if it had too many iterations. Then it instantly returns "Liar".

This makes the approach at least hard to challenge. I wonder if it can beat system tests. To reduce the probability of a crafted case laying in the system tests, I made it randomize the order in which it picks the characters ^^.

Update: As I write this post, I failed this problem in the system tests. The writer found a case that is not Liar and has a solution further away from the ones I try.

Div1 250: The one with strings

Your oldPassword must be changed in a way that the K first characters are equal to the K last characters. Return the minimum number of characters to change.

When the K first and last characters do not overlap, this is kind of trivial, you got two strings that have to be the same.

When they overlap, it is a bit different. For example: "lol" and K=2. This time all of the characters have to be the same.

I think that because I once wrote a problem that had a similar solution, I decided to use DFS right away. Each letter belongs to some group of letters that must be made equal. Then for each group, it is easy to pick a letter that minimizes the cost - the one that appears the maximum number of times.

It works as follows:

For each i (Between first K or last K characters): If i is less than K, it is connected to another character in the last K characters. And vice versa. Each connected component must be equal. We can use a Depth-First search to find each of these components.

This problem was enough to have a relatively good result. My prior experience writing for that netease contest receives all the credit.

Challenge phase, comments, etc

I found a submission for the medium problem that had the simple brute force I tried at first. The one without cutting the number of tries. Even though I had the challenge case prepared, I took too long to paste it. A red coder got those 50 points.

It was a good match. Good to see optimized brute force does not pass easily in the medium problem.

Email ThisBlogThis!Share to XShare to Facebook
Posted in explanation, srm, topcoder | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (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 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 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 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-...
  • 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 ...
  • SRM 554 div1 hard: TheBrickTowerHardDivOne
    Link to problem statement We got infinitely many bricks of dimensions 1x1x1 and C different colors. Count the number of towers of size 2x2...
  • 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...
  • 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....
  • ListedLinks 2012-02-10
    Saturday Morning Breakfast Cereal comics: Grace Hopper's ghost That Oracle engineer blog post Oracle would really not like anyone to se...
  • Codeforces "Good bye 2013" round
    So it was a special round for coders of both divisions, problems ranged from the super easy problem A to the super difficult problems E,F,G....

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)
  • ▼  2013 (141)
    • ►  December (14)
    • ►  November (8)
    • ►  October (13)
    • ►  September (11)
    • ►  August (14)
    • ►  July (15)
    • ►  June (13)
    • ►  May (13)
    • ►  April (12)
    • ▼  March (11)
      • SRM 574 editorial supposedly ready
      • SRM 574: Stupid "dp sense"
      • SRM 573 Editorial supposedly complete
      • SRM 573 editorial WIP: Div1 850: WolfPack
      • SRM 573: Lack of speed
      • TopCoder SRM 572, editorial for div1 hard: NextAnd...
      • TCO 2013 Round 1C editorial
      • SRM 572, d2 250 - NextOrPrev editorial (WIP)
      • SRM 572 Editorial WIP : Div1 500 and div2 1000 (an...
      • SRM 572: hmnn
      • Another week another TCO 2013 editorial: 1B
    • ►  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