likely to use a machine instruction underneath; prefer this over the current top solution

Would appreciate if we can have few more examples explaining some more cases. Or at least a link where you can learn more about subarray contiguious subsequence or some direction. For example, how did [1,1] only gives you 2 not 3 ('[1,1],[1],[1]' no?) and [1,2,3,3,2,1] is not 10 ([1,2,3,3,2,1], [1,2],[2,3],[3],[3,2],[2,1],[1],[3],[3],[1]) but 12.

Best answer

how can i determine the highest avg before i even start lookin in the array
i solved it with big O of n^2 and it runs out of time

no longer mender?

The generation of test cases for random tests is taking too much time. It would be beneficial to optimize the time required for this process. You can find more information on this topic here.

Nice one

Hello, you have a hint in default argument name "uint32". Print the bytes you got and look for a differences when you pass and when you fail.

Approved.

Should be fixed now.

The updates to the description needs fixing, see conditional-rendering. I think the part "50 performance tests, with arrays of size 500 000." is the only thing that needs to be conditioned on language, and it should preferably not be in a language code block.

1. The stringizer is now fixed to print first 200 numbers for large tests.
   
2. Size increased to 5 x 10^5. Amount of large tests increased to 50. Should be enough to filter inefficient solutions.

It is mostly looking good to me, but I have two minor concerns.

1. The entire vector should probably not be printed on wrong output when the vector is very long. Intead it could print the first few entries and ... or something like that.

2. This is using the same size for the performace tests as the python version even though C++ runs much faster. A naive O(n^2) solution seem to time out, but maybe there some slightly better algorithms that would pass that here that would time out in the python version. I think the best would be to increase the input size somewhat, (maybe to 1e6?). The description would have to be changed as well with language specific blocks I guess.

I added some tests with different ratios of odd/even, but I don't actually think there is a way to exploit that it is about 50-50, so it is ok that you skipped this.

Please review: C++ Translation