I was going through my code for finding suffix arrays and decided to change the dollar character (a character with small value, which is appended to the end of the string in many implementations) to std::numeric_limits<char>::min() hoping it won't change the program's behaviour.

Interestingly, it did.

This is what I found out:

#include <iostream>
#include <limits>

int main() {
	std::cout << (std::numeric_limits<char>::min() < 'a' ? "Yes" : "No") << '\n';
	std::string s1, s2;
	s1 += std::numeric_limits<char>::min();
	s2 += 'a';
	std::cout << (s1 < s2 ? "Yes" : "No") << '\n';
	std::cout << int(s1[0]) << ' ' << int(s2[0]) << '\n';
}

Program Output:

Yes

No

-128 97

I have no idea why std::string behaves like this. I ran this program on MinGW, MSVC and Clang and got the same output every time.

I solved a problem recently using floating point arithmetic. I suspect the solution should not work for some test case because of floating point precision errors, but cannot find a case where it would fail. Moreover, the solution gets "Accepted" verdict.

Link to the submission (Codeforces Round #660 E): 89366718

The submission is an implementation of the Convex Hull Trick approach mentioned in the editorial of the problem.

If you look through the code, you will find that I have maintained forbidden ranges of cotangents of an angle and then iterate over the critical angles (i.e. extremeties of some range of forbidden angles, which are not forbidden themselves).

I suspect that float(xr[j] - xl[i]) / (y[i] - y[j]) should return unequal values for some mathematically equal fractions (like $$$5/3$$$ and $$$15/9$$$) because of precision errors.

In such case, let's say there are two ranges $$$[a, b]$$$ and $$$[c, d]$$$ with $$$b = c$$$ (mathematically). In such a case a possible value that is not forbidden is $$$b$$$. This obviously will not work if there are precision errors which make the calculated values of $$$b$$$ and $$$c$$$ such that $$$b$$$ is slightly greater $$$c$$$. Then, $$$b$$$ will become part of a forbidden range.

My question is, does the above case not show up in the test cases of the problem or is the floating point arithmetic in my code guaranteed to be exact because of some reason?

Can you suggest a case where the program would break?

The following program shows though that the precision errors I mentioned do occur:

#include <cassert>
#include <iomanip>
#include <iostream>
#include <random>
using namespace std;

float foo (int n, int d, int c)
{
    return float(n * c) / (d * c);
}

int main()
{
    default_random_engine generator;
    uniform_int_distribution<> dist(1, 10000);
    while(true)
    {
        int n = dist(generator), d = dist(generator), c1 = dist(generator), c2 = dist(generator);
        float f1 = foo(n, d, c1), f2 = foo(n, d, c2);
        cerr << "Testing with n=" << n << ", d=" << d << ", c1=" << c1 << ", c2=" << c2 << '\n';
        cerr << fixed << setprecision(10) << "Received f1=" << f1 << " and f2=" << f2 << '\n';
        assert(f1 == f2);
        cerr << "OK\n";
    }
}

I tested the following code with three different compilers and saw some peculiar results. First of all, I am not sure why the program compiles (no errors with isalpha) indicating that cctype/ctype.h is being automatically included allowing the compilation of the program.

As far as I know and according to cplusplus.com, neither cctype namespace nor ctype.h header file is amongst the automatically included header files for iostream. Also, iostream does not inherit from cctype/ctype.h.

#include <iostream>
using namespace std;

int main()
{
	cout<<isalpha('a');
}

On my local machine with MinGW (32 bit), it prints 2.

On Codeforces compiler, it prints 2.

On ideone, it prints 1024.

All the above compilations were done for C++14.

It would be great if someone could share the reason for this behaviour.

I am sure that my submission for problem A is correct, but the judge says "Idleness Limit Exceeded". It may be due to some issue with C++17 Diagnostics, which I mistakenly selected during the contest to submit the problem. What should I do now?

UPD: Thank you Reyna for putting it on rejudge.

UPD2: The submission got accepted.