One Point Solution

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

Friday, 7 October 2011

Codeforces round #89

Posted on 10:05 by Unknown
I have been meaning to participate in Codeforces again since a couple of months ago. But CF has the habit of always picking the worst possible schedules for me. Today was not going to be the exception, but thanks to social unrest, I didn't have class today so I tried CF again.

C - Fancy Number
Problem statement
I opened this first. In reality I think that in these division 2 contests I should open D first. What's done is done. I had a little disruption while solving it, went to eat something. Anyway.

At first I really didn't understand exactly what the statement meant by repeated digits. For example, 00001122 has 8 repeated digits. At the end I concluded that it means that at least one digit must be repeated at least K times.

So, there are only 10 available digits. Let us try the minimum cost to have one of those digits repeat at least K times AND the lex-first string that has such cost. Then we pick the best result among all digits.

Given a digit ch, build the minimum cost, lex-first string that contains that digit at least k times. We just need to pick the best k positions in which we will place ch. Of all positions, let's find the cost to turn that position into ch. Note that we should always pick the k minimum costs. Not doing that will yield a higher total cost to convert the string. However, sometimes there will be more than k positions we could use for the same cost. Then we need a tie-breaker to ensure that the first string is the lexicographically-first.

So, how about this, if two positions would yield the same cost to turn into ch, we need to pick the one that would yield the lexicographically-first string.

* If one of the positions had a digit larger than ch and the other didn't, pick the former.
* If both positions had a digit larger than ch, pick the earliest one. Because the first position has priority when doing lexicographical comparisons.
* If If both positions had a digit smaller than ch. Pick the latest position.

This is somewhere in which std::pair is helpful.

So, here is the solution:
int n, k;
string digits;

pair<int,string> make_best(char ch)
{

set< pair<int, pair<int, int> > > pos;
// Rate all the positions in the string
for (int i=0; i<n; i++) {
int low = 0;
int ni = i;
if (ch == digits[i] ) {
low = 1;
} else if (ch > digits[i]) {
ni = -i;
low = 2;
}
int c = abs( ch - digits[i] );

pos.insert( make_pair( c, make_pair(low, ni) ) );
}
//pick the k best positions to put a ch there.
string nw = digits;
int sum = 0;
for (int i=0; i<k; i++) {
set< pair<int, pair<int, int> > >::iterator q = pos.begin();
int c = q->first;
int ni = abs(q->second.second);
nw[ni] = ch;
sum += c;
pos.erase(q);
}
return make_pair(sum, nw);
}

void solve()
{
pair<int, string> best = make_pair(1000000, string("ERROR") );
for (char ch='0'; ch<='9'; ch++) {
best = std::min(best, make_best(ch) );
}
cout<<best.first<<endl;
cout<<best.second<<endl;
}



A - B
There is really nothing to say about these problems. They are just about implementation. So , you better know your language. I failed A twice because I didn't expect Y to be considered a vowel and because I really didn't notice that you were supposed to convert upper case consonants to lower case. Need to pay more attention.


D - Caesar's Legions
Link to statement.
I think this problem was easier than C, to be honest. K1 and K2 were very low (<= 10) . I am not sure why. But there is a dp solution.

Let us say that we have r1 footmen and r2 horsemen left to place. The previous lastn positions, contain footmen or horsemen depending of the value of a variable lasttype, if lasttype = 1, then the previous lastn positions contain horsemen. So, we in fact remember the contents of the previous positions, we just have to make sure that lastn does not ever exceed k1 or k2 depending on whether they are footmen or horsemen.

Let f(r1,r2,lasttype, lastn) the total number of ways to solve that sub-problem. The final result will be f(n1,n2, 0,0) (There are n1 footmen to place, n2 horsemen, and we can pretend that there are 0 footmen in the previous positions). So, let us think of transitions:

* At each position, we can place a footman, or a horseman. Depending on what we do, we increase lastn or set (lastype = 1, lastn = 1) in case we placed a different type of unit than the previous one.


That yields the following dp solution:
const int MOD = 100000000;
int n1, n2, k1, k2;

int mem[101][101][2][11];

int count(int r1, int r2, int lasttype, int lastn) {
int & c = mem[r1][r2][lasttype][lastn];

if (c == -1) {
c = 0;
// place r1
if (r1 > 0) {
if (lasttype == 1) {
c += count(r1-1,r2,0,1);
} else if (lastn < k1) {
c += count(r1-1,r2,0,lastn+1);
}
}
//place r2
if (r2 > 0) {
if (lasttype == 0) {
c += count(r1,r2-1,1,1);
} else if (lastn < k2) {
c += count(r1,r2-1,1,lastn+1);
}
c %= MOD;
}

if (r1 == 0 && r2 == 0) {
//all done!
c = 1;
}

}
return c;
}

int solve()
{
memset(mem,-1,sizeof(mem));

return count(n1, n2, 0,0);
}


Problem E
Problem statement
Thank you CF, apparently I needed to be reminded that graph theory is not my strength.

Things that I tried and failed:
a) Assumed that for there to be a solution, there needs to be a Hamiltonian cycle in the solution. Then the solution is to build that cycle. At first, for some reason I was finding and building Eulerian cycles instead, and that's wrong. Once I tried to do Hamiltonian cycles instead, I noticed that the idea is probably wrong. Building such cycles is NP-hard :/.

Update: So the idea about cycles was close. All vertices must belong to the same cycle = They should belong to the same strongly connected component.

Hacks
Apparently CF thought that the best thing they could copy from TC was the randomness from the challenge phase. Unfortunately, you need flash to look at the solutions. Why? Really, why? You have this web-based contest system that is very portable and easy to setup, and you ruin it with flash? I mean , gosh.




Conclusion
Quite honestly, CF's problem sets seems to have gotten less annoying and better than back when I stopped it. Though this is only the div2 contest, I am not sure how div1 is now. Hacks however, really need to stop requiring flash.

I will participate in more CF contests, provided the schedule works for me.
Email ThisBlogThis!Share to XShare to Facebook
Posted in codeforces, explanation, rant | 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)
    • ►  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)
      • SRM 522: Double meh
      • So, about that CF contest today
      • SRM 521: Meh
      • Codeforces round #89
      • SRM 520: Bad day
    • ►  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