This one can be solved in O(nlgn) using a segment tree.

First we convert all powers to numbers in range 0..n-1 to avoid working with segments as large as 10

^{9}in our segment tree. Then for each of the men we should find number of men who are placed before him and have more power let's call this gr[j]. When ever we reach a man with power x we add the segment [0,x-1] to our segment tree , so finding gr[j] can be done by querying power of j in our segment tree when it's updated by all j-1 preceding men.Now let's call number of men who are standing after j but are weaker than j as le[j]. These values can be found using the same method with a segment-tree or in O(n) time using direct arithmetic:

le[j]=(power of j -1)-(i-1-gr[j])

note that powers are in range 0..n-1 now.

Now we can count all triplets i,j,k which have j as their second index. This is le[j]*gr[j]

so the final answer is

( \sum_{j=0}^{n-1} le[j]\times gr[j] )

Is implementation of segement tree really tough?

Thanx.

It more or less look like "familiar" Binary Search.

BIT?BIT implementation

Explanation:

Let's try to solve a simpler version of the problem. Let's say, we have to find the number of inversions. That is, we have $$$a_1,a_2,a_3,...,a_n$$$. Then, we want to find out the pairs $$$a_i>a_j$$$ such that $$$i<j$$$. Then we can start from $$$n$$$, count the number of elements smaller than

`a[i]`

in the BIT, then we can update the tree with the ith element's info. That is, increase the a[i]th position in the BIT by one.As we go with this loop, we can find the total number of inversions. Cool.

Now let's try to extend this to our use case. We need $$$a_i>a_j>a_k$$$, such that $$$i>j>k$$$. We already have done a part of this.

We can have another BIT that saves the number of inversions for each element as we're going from

`n`

to`1`

in the loop. This information can be used to querythe number of inversions that are present after the current number, for the numbers having a magnitude smaller than the current number. So, the loop looks like:Where

`ans`

is the correct answer.`BITS`

is the BIT that stores presence of elements.`BITZ`

stores the number of inversions for the elements. You can use segment trees too here, if you change the BIT's implementation by a segment tree's one. But that isn't really necessary here I think.I did it using BIT. 83312596. The idea is simple and is mentioned with the code itself.

Can this be done using merge sort ...

like inverse counting problem?

Yes. For each index i, you can first find number of all inversions that have i as their first element and then all those that have i as their second element. Then just multiply them to find number of three-inversions (j,i,k) with i as their middle element.

well, why do you have to multiply? what about building two arrays: inv1, where inv1[i] — number of j < i such that a[j] > a[i] and inv2, where inv2[i] — number of j > i such that a[j] > a[i]. If I am wrong, could you please expand the idea of multiplying?

What is the meaning of this line "we add the segment [0,x-1] to our segment tree".

An example would be very helpful.

my solution using merge sort algo to find inversions. http://codeforces.com/contest/61/submission/33820916

For the second time of inversion counting, I got the gist of what you are doing, namely, finding for each element, the number of inversions in which it is occurring as the first element. Please can you elaborate more on the thought process behind the processing you have done before you invoke the inversion count the second time?

In the year 2018, we have new-age technology that makes this problem fairly trivial to solve: Policy-based data structures. Specifically, order statistics trees. We can query them directly to find the number of elements less than x. So none of that coordinate compression/segment tree nonsense needed! See my solution here: http://codeforces.com/contest/61/submission/40569977

See here for more information regarding the data structure: https://codeforces.com/blog/entry/11080

wow

Can you tell me where am I going wrong? 93427689

In your code l is integer and r is integer and their product can be exceed range of integer that's why you are getting wrong answer.

Yep, you are right. Thanks.

for more explanation on this problem "sorry for my bad English :) " :

simply we can sort the elements and save the old index(we can do that by taking an array of pairs the first is the real power and the second is the index and sort this array).

the problem says that we should take three indices, so we loop through the middle one in O(n) and now we should find how many element before him and bigger than him and how many elements after him and less than him

let's take in the first how many elements after him and less than him, this can be done by the following way(we store the results on _right[MAX]):

take a segment tree in each node in the segment tree we store how many elements below it the segment is empty in the first, but we know that the first element is the smallest so nothing is less than him so we add it to the segment using update function(it is very simple we add 1 in the location of the element, the location is the index before sort)

now we loop through the elements of the sorted array and every time we find how the res by getting the numbers of elements to exist in the range [id + 1, n] (id is the index before sort)

and after we find the result we add that element using the update function

how does this work? because when we sort the array and work from small to big, so we are sure that if there is an element in the range [id+1,n] then the element in it is less than the current number.

we clear the segment tree using memset so all nodes now zero because no element is added until now.

reverse the array because now we should find the greater elements

now we also know that the first element is the greatest so nothing is greater than him so we add him using the same update function in the previous method.

we loop also through elements and now the only difference is that the query should be in the range [1,id-1] and also id is the index before sort.

now after finish the loop we reverse the _left array, why we do that? because as we know the final result is the summation of the _right[i]*_left[i];

so if we don't reverse the _left array then the indices are reversing so we should find the summation of the _left[n-i+1] * _right[i];

sure we can do that instead of reverse it.

my code: https://ideone.com/sG31aS

if you still don't understand please ask :)

If solving this problem with a segment tree is tough, I would suggest this easier version:

For a permutation $$$a[1],\ldots, a[n]$$$ of $$$1,\ldots, n$$$ find the number of inversions using a segment tree: i.e., the number of pairs $$$i<j$$$ with $$$a[i]>a[j]$$$.

Here the segment tree can be built from an array $$$s[]$$$ where $$$s[k]= 1$$$ or $$$s[k]=0$$$ means that the number $$$k$$$ was seen, or not seen, respectively. Then we may traverse $$$a$$$ backwards: the number of inversions which

beginat element $$$a[i]$$$ equals the number of elements less than $$$a[i]$$$ which have already been seen; this is the query of our segment tree from $$$1$$$ to $$$a[i]-1$$$. Then we update $$$s[a[i]]=1$$$, and continue.