It’s poetic that your handle is pigeon and the question involved pigeon hole principle xD. This question involved both bitwise operations and one very important observation.
If you want to practice regular bitwise operation problems, I’d suggest this. There isn’t much to read. You’ll just have to know how bitwise operations work, and the rest just comes from practice.
/* Name of the class has to be “Main” only if the class is public. */
class Codechef
{
public static void main (String[] args) throws java.lang.Exception
{
try {
Scanner sc=new Scanner(System.in);
int t=sc.nextInt();
while(t–>0)
{
int n=sc.nextInt();
long arr[]=new long[n];
HashSet set=new HashSet();
IMO, there is nothing to study. You gain experience by solving a lot of bitwise problem. The link I tagged was from MAY20 challenge, and solving that (without any help) would definitely be of some help to your learning curve!
The complaint about brute forces getting AC is not valid because after at most 60 * (60 + 1) / 2 + 1 iterations we will always find a duplicate subarray OR(pigeonhole principle).
The only correct argument is solutions which just check if every prefix OR is a sub mask of the next element getting AC(or suffix OR). If you check both prefix OR and suffix OR then it is a correct solution.
As you can see, I had a function called ‘prefix defense’ to tackle these kinds of solutions. And guess what, I did another mistake while returning the vectors from that function. I returned a randomized version of the vector which I wasn’t supposed to do. So my whole ‘prefix defense’ function was all for nothing and really helped me to get bad impressions by making the test cases really weak!
The two mistakes I made in this contest are this one along with the palindromic checker(Invitation to CodeChef July Cook-Off 2020 - Codeforces) and I was really aware of them and don’t know how I actually ended up making the mistakes.
Sorry for the issues. I have fixed that stupid ‘prefix defense’ function and added a few new test cases. Hopefully, everything will be fine.
If you have any other complaints please let me know.
The editorial says if n>62 directly reject otherwise do brute force in O(n^2) but if have 300 test cases (max possible) each having n around 60. Then we’ll have 300*(62^2) operations which is greater than 10^6.
In this case wouldn’t we get TLE?
It’s nice of you to give an explanation of what went wrong with the test cases. It shows us that we are all humans. It is already hard enough think of alternate solutions that should or shouldn’t pass a problem, let alone preventing them from getting accepted.
i faced the same issue man …i was just keep wondering for a optimised approach.
here everyone has written that around operations upto 10^8 are allowed but here n^2 approach performs 10^10 operations…please someone help me with this issue