I have the same problem as BrunoFelthes,
I pass all the tests exept the 9.
if someone have a tips, or a hint.
I’m doing it in Python3.
I did not get the trick with memorization,
However, I have managed to beat the last test by removing actual array manipulation.
So instead of pushing and shifting queue items am keeping track of current index and jump to the beginning of the array if nessesary
1 Like
This one was really challenging for me. I got near the solution multiple times, but for some reason I kept generating incorrect numbers on the last test. Turns out I had several issues with my loops and pointer indexes. Now that I finally achieved 100% ( Rust ), I wanted to share the key that unraveled my bug mystery. Maybe it will help you troubleshoot your solutions.
Try this data set. It’s small enough to hand compute, and contains elements that test your pointer accuracy:
20 20 4
5
10
3
17
Solution:
350
Happy Coding! 
1 Like
thank you so much
Is this large data set test even feasible in Javascript?
Some peple talk about memoization but what data to memoize?
I only use pure array with numbers inside. So the next group is just arr[index+1], memoization can’t beat that.
And a arr[index] gives also the exact number of money earned. Again, memoization can’t be useful because there is no compute task.
Maybe to look for a certain pattern can match in certain cases. Is it the way to go ?
Update : detect a cycle and memoize it is the way to go ;). But don’t forget to remove all printErr unless the large data set doesn’t pass
My code had a bug. The bug was not triggered by any of the test cases. Only at this submit case…
One thing is not covered by tests but will cause you to fail “Works with a large dataset” on submission. If it happens consider case when distance to place where “cycling” starts is bigger than cycle size.
1 Like
Are there any solution on C++ without memoize ?
I tried with arrays,vectors,queues,linklist , everything ran out of time .
Does it wants me not to change queue dynamically ,but just save it once ?
Solving this task in Clojure was real fun. First I tried to implement mine, non-optimal, solution in C++ iteratively, using many defs and ^:dynamics and a while, got 73%. Then I tried to implement the best C++, optimal, solution with some make-arrays, adding and removing elements iteratively, got 86%. After reading this https://kimh.github.io/clojure-by-example/#about I learned that it is not a good idea to use many defs in a Clojure program also that the tail recursion is a very good thing: https://stackoverflow.com/questions/33923/what-is-tail-recursion So I rewrote everything without any defs and using only recursion, got 100%. I’m really impressed how good and fast is the recursion method compared to the iterative one.
1 Like
I honestly think it doesn’t need to be in hard. More like medium.
really powerful idea!
As detailled by some other, I don’t know how are configured the timeout limits from one language to another, but it seems javascript has a huge advantage here.
I couldn’t get 100% and had a timeout even when caching intermediate results, both in Python and in C. Finally tried in Javascript, and got 100% with the most “naive” (I would even say “dumbest”) algorithm possible and no cache/optimisation at all…
bottom line: If you can’t get 100% , try in Javascript!
Any advice or hints how to find patterns for memorization?
I would appreciate a link to basics or to something I should start with looking for memorization’s solution.
…and after thinking “heavily”…
I could calculate range of groups for each starting index (from 0 to N groups), that way that the range is <= places limit. Then each time the ride starts it would be possible to use that range.
That’s seems a lot of calculations at the start and probably it’ll generate more ranges then needed. Thus “in time” creation should be better.
I ponder if that’s memoization/memorization.
Edit: it worked 
Thank you for your help 
First hard problem, I didn’t have too much trouble (in Python). I handcrafted a test case that should take care of everything and is easy to check by hand :
3 n 5
1
2
2
1
1
and the answer is given by
n : 0 1 2 3 4 5 6 7 8 9 10…
answer : 0 3 6 8 10 13 15 17 20 22 24…
TIP: if you write the queue at each step by hand, a repetting pattern should appear and with some arithmetics you can exploit that to quickly find the answer, though it takes a some more lines of code. I don’t know if it is required but is O(min(C, N)) instead of O© wich is significantly faster if you have a few groups (5) and a huge number of ride (10**7): in this case it runs instantly
The same thing happened to me. But to me it stated something along the lines of “timed out”. So you need to optimize your solution.
EDIT:
My problem was C printf formatting. I love uint64_t, but it has a special form:
printf("%" PRIu64 “\n”, C);
I was unwittingly printing it as a regular int. I suppose this truncates, because it was printing everything correctly but C>1^32.
I’m doing this in C.
I am memoizing: if the starting index has been encountered before, it just reads the number of people and the next index.
It works smoothly and fast on all but the last TWO tests.
It does NOT run out of time; it completes on both of them, but prints the wrong number. I changed most of my ints to u_int64_t, doesn’t help. The penultimate test says you need 2^32, well u_int64_t should be fine with that. I also changed all the other ints to unsigned int just in case.
Still, on test 5: 705007704 instead of 4999975000
test 6: 1550915649 instead of 89744892565569
That last solution is under 2^47, but it’s calculating wrong.
Any ideas?
Thank you.
1 Like
Thanks, Ferrus. Alas, my solution calculates that one correctly, but gets the last two wrong.
Hello
Has anyone done it in Javascript?
There’s a “solution” tab where you can select JS and see that 100 users shared their solution in JS.
So, answer is yes, at least 100 users.
(The solutions for a language are visible only if you already solved it in the same language.)
1 Like