I think in this context tee means T-shirt :) (https://www.urbandictionary.com/define.php?term=tee)

You should suggest Google to produce famous Code Jam tea as a reward for the contestants.

It would also have been helpful to have a test case in D where some of the numbers were not 1 ...

(I was super lucky in the sense that I was doing a problem quite similar to D just before the contest, and that I managed to catch an error 5 min before the end of the contest without actually constructing additional test cases...)

1. Divide vertices on two sets: 1) x < 0 (for those vertices set x = -x); 2) x > 0.
2. Sort both sets in non-descending order.
3. Now we should add vertices to graph (which initially contains only vertex 1) and note time of its adding (initially 0). If value of next vertex from set 1 are less or equal to the number of currently added vertices (initially 1) than add it (increase time by 1 if value is equal to the number of currently added vertices) else add vertex from other set (set time equal to vertex's value).
4. Continue until both sets become empty.

// #pragma comment(linker, "/stack:200000000")
#pragma GCC optimize("Ofast")
//#pragma GCC target("sse,sse2,sse3,ssse3,sse4,avx,avx2")

#include <bits/stdc++.h>

#define fi first
#define se second
#define all(x) x.begin(), x.end()
#define sz(x) (int)(x).size()
#define LL long long int
#define ULL unsigned LL
#define LD long double
#define PB push_back
#define PF push_front
#define FORi(i, a, b) for(int i = a; i < b ; ++i)
#define FORd(i, a, b) for(int i = a; i > b ; --i)

using namespace std;
using pii = pair<int, int>;

struct Edge {
    int id, from, to;
};

int main(){
    ios_base::sync_with_stdio(false);
    cin.tie(NULL);
    cout.tie(NULL);
    mt19937 rng(chrono::steady_clock::now().time_since_epoch().count());
    clock_t start_t = clock();

    int t, n, m, x;
    cin >> t;
    FORi(ti,0,t){
        cin >> n >> m;
        set<pii> after, time;
        FORi(i,1,n){
            cin >> x;
            if (x > 0){
                time.insert({x, i});
            }
            else {
                after.insert({-x, i});
            }
        }
        vector<map<int, Edge>> edg(n);
        FORi(i,0,m){
            Edge e;
            e.id = i;
            cin >> e.from >> e.to;
            --e.from;
            --e.to;
            edg[e.from][e.to] = e;
            swap(e.from, e.to);
            edg[e.from][e.to] = e;
        }

        vector<int> parent(n, -1), at(n, 0), ans(m, 1e6);
        parent[0] = 0;
        for(auto e: edg[0]){
            parent[e.second.to] = 0;
        }
        int timer = 0, connected = 1, v;
        while(!time.empty() || !after.empty()){
            if (!after.empty() && after.begin()->first <= connected){
                timer += after.begin()->first == connected++;
                v = after.begin()->second;
                after.erase(after.begin());
            }
            else {
                timer = time.begin()->first;
                connected++;
                v = time.begin()->second;
                time.erase(time.begin());
            }
            assert(parent[v] != -1);
            at[v] = timer;
            ans[edg[parent[v]][v].id] = at[v] - at[parent[v]];
            for(auto e: edg[v]){
                if (parent[e.second.to] == -1){
                    parent[e.second.to] = v;
                }
            }
        }
        assert(connected == n);

        cout << "Case #" << ti+1 << ":";
        for(auto y: ans){
            cout << ' ' << y;
        }
        cout << '\n';
    }

    return 0;
}

The important idea is that, for a list of (numerical) latency, there always exists a way to set the weight on the edges conforming the latency requirement: for an edge (x-y), the weight is

if they are not equal, or any nonzero number otherwise.

The rest is described as gultai4ukr

What's wrong with having to test your solution yourself?

And no sample for D-hard. I would understand this from some random competition but I always treated GCJ as the best competition in the world and now this shit...

EDIT: well, it's obviously a small detail in the whole competition but next time I would be happy to see useful samples. It makes the competition less random. (I had another opinion a few years ago btw.) It's just hard to imagine organizers deciding that it's better not to provide a test for D-hard.

The third argument of std::unique must be ==, not <, maybe that's why

I was mistaken, please ignore.

Probably overflow.

Random tests are shit in this problem, you won't get any special combinations of collinear points.

I Think this is wrong:

if (one == 0 && even > 1)
	{
		total--;
	}

Try this:
answer is 6

1
6
0 0
1 0
100 10
110 10
1000 15
1100 15

The ball gets stuck at $$$(0,2)$$$ for your construction. When a ball enters a hole that is not connected to another hole, it stops.

The ball stops at (0, 2). Note they are holes, so once the ball hits a hole, it will stop unless the hole being connected to another hole via a link.

Lol ,it took me a minute to realise what you are talking about because I was really not having any idea about second one. RIP to me

I did, but pretty late.

What is your user name there, I was just curious to look at your solution. Thanks in advance for replying

C++ arrays have garbage values in them outside the declared bounds. As far as I know, declaring arrays in C++ is simply allocating a bunch of memory (unlike Java, where arrays are objects and out-of-bound access is an undefined operation and will throw an exception). So if you don't go too far, the compiler may not even notice.

I remember in problem B of round 1A (Pascal Walk) I had an int[500][500] and I went as far as index 1000 in the first testcase, but got AC (lol), so it is just something to pay attention to.

Me also, strongly don'e like it, as I always write buggy code.

Set instead of multiset in B, and 1e9 instead of $$$\sqrt{2e18}$$$ in A were enough to fail hidden tests in both and to kick me out of qualification. Although, my time was very enough and good.

Who said there is some mistake in immediate feedback. Each contest(or better, website) has its own way. Its nice that there are different variants of contests so its not boring with a same ICPC format.

I actually miss the days when a lot more competitive programming contests were evaluating the skill of testing your implementation. In the long run I feel that it certainly helped me to write working code on the first try more often.

So the last 15 minutes of this round, for example, instead of focusing on D.small, I specifically was testing my solutions (1-line max test for A, multiple manual tests for B.large since B.small is useless for testing that etc.). Every contest has different rules and you have to be able to adapt your strategy to each one of them.

I know that feel bro: screencast. Fixed one char and got AC 50 seconds after the end

Why do you complicate things introducing treewidth even though you can say that removal of any pair of matching parentheses disconnects graph, so you can take centroid of the tree on the left and forget about the right one? Of course I am a big fan of treewidth but I don't see any profit here

EDIT: OK, I understand, removal of any pair of matching parentheses indeed disconnects the graph, but not in the way as the left tree disconnects, cause brothers of removed vertex stay connected. Now I see the point.