One Point Solution

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

Sunday, 11 March 2012

Codeforces: VK Cup round 1 (update 1)

Posted on 10:14 by Unknown
After learning that people that are not in the cup can participate in a rated version of the contest. I really went through a lot of inconvenience to be able to participate in this round.

After I solved problem B (albeit with an overflow bug), I was not able to submit. Some time later codeforces announced the unofficial match won't be rated because unofficials weren't able to submit. At then I stopped trying. Around some time later I check back codeforces and it seems that submission is possible again. So I tried to submit B, failed, fixed and then suddenly I had only less than an hour left... I wish things went differently, I got problem D solved, kind of.

Problem B linky
Only Karts that have stools will be discounted. Now note that once you put a stool in the kart, then you would like to avoid to place any element with smaller cost. Placing elements with larger cost will not change the discount (but it might make you miss the opportunity to receive a discount on that same item in another kart). So, once you place a stool, you really should avoid placing any other item altogether. In cases where there are more karts than stools, there will be plenty of karts to place the elements you do not want to place in karts that already have stools. In the other case, where the number of stools is less than or equal to the number of karts, then there is no need to place those unwanted elements in more than one kart with a stool. Doing this will make you unable to get the discount for that stool, and in fact will make you get a discount for the least expensive item overall.

The best discount you can get will get from stools. If there are less discountable karts than stools, it is better to pick the largest stools to place into each of those karts. Thus the logic goes as follows:

- If there are less stools than karts: Pick a kart for each stools. Distribute the remaining items in the stool-less karts (make sure to place at least one item in each, but the actual distribution does not matter).
- Else, you will need to forcefully place the minimum price kart and a stool in one kart. Place the best (k-1) stools in the other karts and any other element in the kart that has the least expensive element.

Problem A linky
At first I thought you would need fancy std::sets, but since x and y are always the same for all soldiers, it gets a little simple.

Assume that you have the soldiers and vests sorted non-decreasingly.

Now, let us say you are picking the i-th soldier in such order. Since we have already made decisions for all the soldiers with a smaller a_i, then we can get rid of all vests that are smaller than a_i - x. The smallest vest greater than or equal to a_i-x will remain, note that if this vest is less than or equal to a_i+y, you can match it to the soldier, and in fact, you must match it to the soldier. Else it will be impossible to match the vest, but it might be possible to match it with a soldier with a higher preference.

Problem C linky
Seemed interesting, but submission counts suggested D was easier, and they both have the same score, so I skipped to D.

Problem D linky

Since it is a tree, it is quite dp-friendly. Assume we have
decided an arbitrary root for the tree, and such each node is either the root or has a parent and all the other adjacent nodes are children. Let us say we constructed a table dp[x][k], which returns the number of (grand) children of x at a minimum distance equal to k. Once the tree gets an arbitrary root, it is easy to calculate this table: dp[x][0] is 1 for all nodes (the node itself is at 0 units of distance), then it is sum(dp[y][k-1]) for all y that are children of x.

Let us count all the pairs (x,y) that are K edges away and x is a (Grand) parent of y. This is precisely equal to dp[x][K].

But there is a catch, sometimes the parent node x may be just part of the K-size path between two nodes that are children of it (Do not worry about parents of x, you will consider their involvement when they themselves become x).

Well, not so hard, let starting from dp[y][a] for all children y of x, you can easily count the number of paths of length a+1 that start at x and go through the y child. You can merge all such the paths of different sizes a and b such that a+b = k. This requires some trick to make sure the algorithm is not very slow (Let sum[a] be the total sum of paths of length a, sum[a] - dp[y][a] will give the number of paths that do not go through y).

This takes you to a O(n * k) algorithm. Note that the number of edges is O(n), (in the second part whilst doing all the merges, you visit all edges O(k) times).

Edit: here is the code for problem D. I mostly finished it during the match but had the typical bug of increasing the wrong counter inside a for. Then it turns out that when practice room becomes active I actually time out in the largest case. It turns out that the constraints were too large and you couldn't use memoization in the dp part. That's kind of lame.

//================================ 
// Program:
//
int n, k;
int u[50000]; //note that I use 0-based indices instead of 1-based
int v[50000]; //because 1-indexing is crud.

int degree[50000];
vector<int> G[50000];

int parent[50000];

void dfs(int x, int p)
{
if (parent[x] == -2) {
parent[x] = p;
for (int i=0; i<degree[x]; i++) {
dfs( G[x][i] , x );
}
}
}

// dp[j][x] how many grand children does x have away of j distance units?
int dp[501][50000];

long long solve()
{
fill(degree, degree+n, 0);
for (int i=0; i<(n-1); i++) {
degree[ u[i] ]++;
degree[ v[i] ]++;
}
for (int i=0; i<n; i++) {
G[i].resize(degree[i]);
degree[i] = 0;
}
for (int i=0; i<(n-1); i++) {
G[u[i]][degree[ u[i] ]++] = v[i];
G[v[i]][degree[ v[i] ]++] = u[i];
}
fill(parent, parent+ n, -2);
dfs(0, -1);

for (int j=0; j<=k; j++) {
for (int x=0; x<n; x++) {
if (j==0) {
//Base case, when k = 0, the only "child" at a distance 0 is
// the node x itself.
dp[j][x] = 1;
} else {
dp[j][x] = 0;
// Else the sum of dp[j-1][y] for every children y of x.
for (int i=0; i<degree[x]; i++) {
int y = G[x][i];
if (y != parent[x]) {
dp[j][x] += dp[j-1][y];
}
}
}
}
}

long long res = 0;
for (int i=0; i<n; i++) {
res += dp[k][i]; //Paths that start at node #i


// Paths that go through node #i, without using the edge connecting it
// to its parent.
long long sum[k+1];
fill(sum, sum+k+1, 0);
int active = 0;
for (int j=0; j<degree[i]; j++) {
if (G[i][j] != parent[i]) {
active++;
for (int p = 0; p <= k; p++) {
sum[p] += dp[p][ G[i][j] ];
}
}
}
if (active > 0) {
long long tem = 0;
for (int j=0; j<degree[i]; j++) {
if (G[i][j] != parent[i]) {
active++;
for (int p = 1; p <= k-1; p++) {
//a: number of paths of length p that go from node i
//and use the edge towards child j.
//b: number of paths of length k-p that go from node i
//and don't use the edge that towards child j.
long long a = dp[p-1][ G[i][j] ];
long long b = sum[k - p - 1] - dp[k - p - 1][ G[i][j] ];
tem += a*b;
}
}
}
res += tem / 2;
}
}

return res;

}
Email ThisBlogThis!Share to XShare to Facebook
Posted in codeforces, vkcup | 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)
      • Topcoder Open 2012 round 1A
      • Codeforces round #114. 167C: Wizards and numbers
      • Official TCO 2012 blogger
      • Codeforces round #114 (div1)
      • 5 reasons editorial votes in Topcoder are useless
      • Codeforces VK Cup round 2: (ouch)
      • Codeforces round #113 div2 (unofficial)
      • Writing SRM 538
      • SRM 537: oh my
      • Codeforces round #112
      • Language features: Rants and wishes
      • Google code jam registration - Just note something...
      • Codeforces: VK Cup round 1: Problem C: Abracadabra
      • Codeforces: VK Cup round 1 (update 1)
      • SRM 536: heh
      • SRM 535 editorial: The making of
      • Codeforces round #111 (div2 only)
      • SRM 535 : lame
      • A note about SRM 537 and 540 money prizes
      • The March of Destruction begins!
    • ►  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