Hi there, while working on this problem, I ran into a situation where using std::upper_bound(set) TLE'd, while replacing the set with a sorted array was comfortably within the time constraints. (TLE submission: 145179964, AC: 145179970). AFAIK, these two should be equivalent O(log n), up to constants. In practice, is it just that those constant factors are great enough to TLE solutions that are asymptotically within the constraint, or is there something else I'm missing when using std::upper_bound with sets instead of vectors?

Thanks!

In working on upsolving https://codeforces.net/contest/1513/problem/D, I ran into this weird aspect of c++ I need some help explaining:

Part of the solution involved iterating over a sorted ordering, which I initially achieved by inserting everything into a map (not hashmap). I understand that iteration over a map in c++ should produce elements in sorted order. However, this produced a WA result, like in this submission: https://codeforces.net/contest/1513/submission/112967965.

On replacing the map with an array and then manually sorting that array however, the solution was accepted, like here:https://codeforces.net/contest/1513/submission/112968002

The only difference between the two submissions is changing the map to a sorted array. To me the logic seems equivalent; iterating over a map should produce an equivalent sorted ordering to the one if you manually sorted an array, however it seems like thats not the case. I was wondering if anyone had any insight on why?

Thanks!

Hi, just got done upsolving this problem: https://codeforces.net/problemset/problem/1360/F,

and it was surprising to me that the problem had such small values of n and m (<= 10). I was curious if this problem can still be solved in better than O(n * m * |ALPH|), in cases where the constraints are larger?

Thanks!

As of this morning, I had a lot of trouble logging into codeforces, and wanted to put this up in case anyone else ran into a similar issue, and so that hopefully this can be fixed:

Trying to use username/pass login resulted in me seeing a 403 Forbidden Page, with the console yielding warnings like:

Cookie “JSESSIONID” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Thankfully the fix is relatively simple, changing the cookie state from Secure: false, to Secure: true allows login instead of receiving a 403 Forbidden message. This change can be done through the storage tab in the developer settings of either chrome or firefox.

Hope this helps someone, and hopefully this gets fixed soon so that cookies don't need to be manually edited to enable login!