Ought to be fixed now

Python version broken (see below)

Ok, I'll raise an issue and you can resolve it when fixed.

Yes your solution is correct, there seems to be an issue with the code. I'll fix it sometime soon

Hi,
Possibly a mistake from on my side, but can I just check that the Python version is correct?
What does the C++ version get for this test case? I get 118 but the expected answer is 120.

[252675239, 362192384, 382111017, 102436662, 804562879, 67875051, 918098597, 550760272, 672682358, 562441881, 244526967, 988445274, 466603325, 299923249, 610523466, 787257402, 693127002, 251117314, 274854186, 132680743, 37459911, 14834957, 356231355, 335781937, 858812500, 458441030, 637311869, 73745211, 791787211, 861578469, 303806301, 600898913, 774940912, 507068751, 899220219, 277356214, 377089866, 89899198, 562096927, 685989640, 69944625, 412794039, 821294229, 573899793, 98368861, 410483038, 506027728, 150314858, 975884181, 748126866, 911792198, 337223145, 759500864, 502300412, 406805122, 167525438, 391836287, 320020089, 866141493, 665536709, 450230733, 409647119, 790920766, 376319592, 758002143, 847823692, 52201469, 322112020, 815885044, 918761827, 62364468, 751740058, 493245527, 498082433, 758828960, 607493212, 289831800, 467744000, 117178299, 156008901, 358090920, 473442205, 706432727, 187103, 101678660, 595372718, 946560762, 904900923, 872198964, 923598946, 93254700, 964102678, 822079129, 853742706, 705540492, 825356904, 616340042, 403197242, 511851652, 959117247, 880360930, 692982960, 744805904, 582350530, 846408292, 251199337, 860645266, 399052838, 367146139, 811071120, 86066388, 537042740, 867961536, 758098684, 235224287, 380599736, 959657936, 203694131, 15459309, 444249517, 230214952, 127024582, 789638186, 771424527, 40829331, 63146714, 59506, 411956640, 110991310, 720172051, 788647540, 667417108, 121734674, 632863051, 55666913, 240211076, 604460690, 801651972, 896855229, 59706928]

For the answer, I sum the ranges: 0: 1, 1: 2, 2: 3, 3: 5, 5: 7, 7: 10, 10: 14, 14: 17, 17: 25, 25: 30, 30: 35, 35: 43, 43: 50, 50: 57, 57: 63, 63: 70, 70: 80, 80: 89, 89: 96, 96: 104, 104: 114, 114: 140

Which gives final array [252675239, 362192384, 382111017, 906999541, 985973648, 1785884511, 1999498815, 2090907870, 2261772903, 2822863790, 3085935096, 3296464738, 3463105325, 3476983466, 3502496909, 4091105787, 4202517658, 4958864982, 5187675555, 5391006507, 5784692340, 10373557896]

One operation is combining any two adjacent numbers by adding them, so only addition is allowed. The answer for that particular one is adding all the 1s to get [3,3,3,4,4,4,4,4]

Removed using namespace std and passing n to the function.

As for the vector<ull>, it became a habit of mine to always take in inputs as ull or ll after overflows on CF and the like. But I changed it to vector<int> as you suggested.

I hadn't thought of that. Mb, switched to vector<pair> instead

Sample test cases probably shouldn't be put inside a std::map<vector<ull>, int>, iteration order of std::map is by key order, so it destroys the original test case order as presented in the tests. A std::vector is more suited for the job.

Please follow usual C++ coding practices:

• using namespace std; should not be the default, or at least only use it in a scope that doesn't leak
• std::vector already has .size() so passing in n is redundant, it'd only be meaningful in C (and even then it'd usually be the second argument)

Also, since 1 <= arr[i] <= 1e9, should arr really be std::vector<ull> instead of std::vector<int>? If our intermediate calculations require ull that'd be up to ourselves, but ull would imply the input is much larger than it should be.

@poltrona14 my solution is O(1) with no brute forcing involved uwu

Eh sometimes you gotta use it, not here ig. This can be done in O(1) without any loops