Day 30 of 30! One leetcode problem a day or I pay a follower $500. No AI. No autocomplete. No copilot This may be the hardest problem I solved in my career Tomorrow will be the final post for this challenge Problem of the day : 3655. XOR After Range Multiplication Queries II Same problem as yesterday but 100x the constraints. The parameter that makes it slow is the parameter that makes it fast. k is the stride. A large k means a short progression, so walking it directly is cheap. A small k means a long progression, but small k also means there are fewer than sqrt(n) possible values of k, so every query sharing a stride can be settled in one sweep. Balancing at sqrt(n) is not a heuristic. It is where the two costs cross. At n = q = 100,000 both sides land near 3 * 10^7. Measured worst case: 70 ms, with the two halves contributing roughly equally. Two bugs in here are quiet and both cost me time: → the closing marker goes at last+k, not r+1. r+1 usually sits in a different residue class, so cancelling there corrupts a chain the query never touched, and the wrong answer shows up nowhere near the query that caused it. → last is l plus ((r-l)/k)*k, not r, because the progression normally stops short of r. Neither shows up on k = 1 tests. That is exactly what makes them dangerous. *code in the first comment