A list of supported languages can be found at https://hackerrank.com/environment.

More like for Europe in general, it's totally through the night.

Because it is not on codeforces where all contests are convenient for Russia/Europe only

They're just letting European IOI teams try out what it feels like to write a contest when it's the middle of the night in your "native" time zone (since IOI is taking place in Taiwan this year) :)

Yes, scores should be up in about 15 or 20 minutes.

Thanks for participating in the contest!

We can just share the results for the last problem. I have 874, 3K, 15K and 20K.

Glad you enjoyed it. Thanks for participating!

What was the solution for that problem?

One can leverage a hidden C++ datastructure to solve this problem with very little code

#include <stdio.h>
#include <ext/pb_ds/assoc_container.hpp>
#include <ext/pb_ds/tree_policy.hpp>
#include <vector>
#include <algorithm>

using namespace std;

typedef __gnu_pbds::tree< int, __gnu_pbds::null_type, std::less<int>, __gnu_pbds::rb_tree_tag, __gnu_pbds::tree_order_statistics_node_update> ordered_set;
vector<pair<int, int> > v;

int main()
{
    ordered_set st;

    int n;
    scanf("%d", &n);

    for (int i = 0; i < n; ++ i)
    {
        int m, b;
        scanf("%d %d", &m, &b);
        v.push_back(make_pair(b, m));
    }

    sort(v.begin(), v.end());

    long long ans = 0;
    for (int i = 0; i < n; ++ i)
    {
        long long order = st.order_of_key(v[i].second);
        ans += order * (st.size() - order);
        st.insert(v[i].second);
    }
    st.clear();
    for (int i = n - 1; i >= 0; -- i)
    {
        long long order = st.order_of_key(v[i].second);
        ans += order * (st.size() - order);
        st.insert(v[i].second);
    }

    printf("%lld\n", ans);

    return 0;
}

Step 1. If for a certain coordinate there's less than sqrt(n) cache entries, that touch it, just iterate over every pair of cache entries and remember that their other ends are connected (for example into a set of pairs).

Step 2. If for a certain coordinate there's more than sqrt(n) cache entries, that touch it, store that coordinate into a vector. That vector, obviously, will have no more that sqrt(n) coordinates.

Step 3. For every query, first check if it is in the set of pairs from the first step. If it is not, then iterate over all sqrt(n) bad coordinates from step 2, and check if any of them is connected to both ends of the query.

I stored every value that is in a pair with a in a set called adj[a], then for every query (a,b) checked to see if the intersection between adj[a] and adj[b] was not empty and memoized the result:

if (adj[a].sz > adj[b].sz) swap(a,b);
bool ok = false;
if (adj[a].count(b)) ok = true;
else {
	for (set<int>::iterator it = adj[a].begin(); it != adj[a].end(); it++) {
		if (adj[b].count(*it)) {
			ok = true;
			break;
		}
	}
}
ans[make_pair(a,b)]=ok;

Now, the daunting question is... Does that actually work or did I cheat the test cases? :D

Can be solved using bit optimization: for each coordinate store a bit-set of opposite cache entry ends. Query is answered by intersecting two bit-sets. Complexity is Q * N / 64.

**P.S. This solution exceeds memory limit, but the tests were week enough to get passed**

Pick largest 2^k — 1 numbers out of N and print their sum. If 2^k — 1 > N then answer is 1.

HellKitsune's solution is correct, but if you need to see why, represent your guesses as a balanced binary search tree with 2^k nodes. Each guess tells you on which branch the answer is going to be, so if the answer is any of the nodes of this tree, you will get it right.

The strategy in the sample case (nested rectangles) is optimal. However, it is not always possible to build such nested rectangles (for instance, if the very first color is not the same as the very last one, you will not be able to build the outermost rectangle). For the first test case I got the highest score (25pts), the strategy was to first send a run with an assert to verify that first color is indeed equal to the last color (and it is). Then it is seems reasonable that with two colors the perfect configuration is possible (if you land the very first brick into the second column, then you have plenty of buffer for extra bricks of the first color in the first column and plenty of buffer for extra bricks of the second color in the second column). Naive approach was still hitting the issue when all the columns expect the brick of one color, and the next brick has the other color. To avoid it I was building the answer from both ends, merging in the middle.

For other cases the my strategy was similar, except that now building the perfect nested rectangles is very unlikely, so one can allocate several rightmost columns for garbage, and try to build the perfect configuration in the remaining columns. Whenever you have a brick that you don't need in any column of your configuration at the moment, just send it to one of the garbage columns.

You have a high score on the Risk Management problem. Can you describe your approach? Did you use some properties of covariance matrix?

I tried to run Newton's method from random vectors, because it was easy to calculate Hessian matrix here (just the same matrix as in input but with diagonal multiplied by 2). But it seems that local searches are not very good here. So I scored only ~17 points for this problem.

Short answer: you need to keep track the difference in salaries between adjacent vertices. If there are some vertex u such the difference between salaries of parent[u] and u is positive then it's BAD else it's GOOD. And we are able to not care about all other pairs of vertices.

More detailed:

You need to figure out what the ways exists how we can present our tree and current salaries.

Let's discuss the following subproblem: We are required to have such queries:
1) Add to value val to the subtree of u
2) Calculate current value of u.

One of the ways is to write down an array of the vertices during dfs in order of their visit time. Now each subtree is a segment in this array, so you need to add value on the segment and be able to get the current value of some element. But this doesn't leads to the solution. There are some other difficulties we can't handle.

The other way is to think where the vertices u are placed which influence a change of the salary of v if we add a value to the subtree of u. They are parents of v. So they are placed on the path from the root to the v. So we can come up with an another idea of solving this subproblem (another way to represent our tree and salaries):

We can write on the edges (parent[u], u) the difference between salaries of u and parent[u]. Then the cost of the path from root to u will be equals to the actual salary of u. And the path cost from some vertex u to v (let's call it pathCost(u, v)) will be equals to the difference salary[v] - salary[u].

We are able to maintain such thing during processing our queries. To process query 1 we just need to add a value to the edge (parent[u], u). And to answer query 2 we need to calculate cost of the path from root to specific vertex.

So we should answer BAD if there are exist a pair of vertices u and v that pathCost(u, v) > 0. But to have pathCost(u, v) > 0 we need to have at least one edge with a positive value. But if have a positive value on the some edge (parent[w], w) it's already guarantee that at least salary of w is greater than salary of parent[w].

So we have to answer GOOD only if we don't have positive edges in the tree and if there are at least one positive edge then answer is BAD. As the result, the only thing we should track is the number of positive edges. So no data structures are actually needed.

By reading the comments above.