It reads, "remove those two digits from the string", but then the spaces are both assumed and relevant, part of the string which never really got "smaller" (shorter). If it means "replace those two digits with spaces", and "return the minimum possible number of remaining ones and zeroes" then it should say that. Also that apparently was a question in the past, but now it's a direct instruction, and it still has a question mark.

What do m and s even represent?

past or present denominators, or defaults

If the value before the most recent left choice was l/m and the value before the most recent right choice was r/s then the new value will be (l+r) / (m+s).

That line, paraphrased / decoded / whatever:

(l+r)/(m+s) is each new fraction (next iteration), before substitution and simplification. Let l/m represent whatever the fraction was, just before you most recently parsed an L choice. Let r/s represent whatever the fraction was, just before you most recently parsed an R choice.

This is how values of l, r, m, s are obtained most often. But l = 1, r = 0, m = 0, s = 1 are defaults, used when there is no previously parsed L or R (or neither, as shown in the way that the initial 1/1, corresponding to the empty string, is formed entirely out of them).

HTH

wat.

It seems to be. Thanks!

The sample test

test.assert_equals(solve("codingIsFun",2,100),"conuFsIgnid")

shows that if the second index is past the end of the string, you simply reverse from the first index to the end of the string.

In C, random tests seem to be pulling in & also reversing the null terminator, thus truncating the "expected" string.

a = 13, b = 14
string =   "oWcZBIOiwforzI"
expected = "oWcZBIOiwforz"
actual =   "oWcZBIOiwforzI"

a = 0, b = 11
string =   "RzMWhjXMSkA"
expected = ""
actual =   "AkSMXjhWMzR"

a = 2, b = 6
string =   "VAXDkc"
expected = "VA"
actual =   "VAckDX"

edit++: When printing input and results, it appears that I will pass several or even some dozens of random tests before failing this way. Of course I tried re-submitting, but this happens every time, eventually.

fixed_tests
random_tests
a = 0, b = 1
string =   "Q"
expected = ""
actual =   "Q"

so I didn't need to store the whole sequence up to n, and that was a mistake, but if you ever need that, here it is

facepalm

So there is no particular order to restore. Thanks.

Random tests in C give me really random things such as "%@" H%@ =%@. I thought, maybe I'm supposed to sort / alphabetize this, since top-middle-bottom and sky-rainbow-ground are in descending alphabetical order-- but then head-body-tail isn't in any order. And then I got %@ %@ %@ which includes non-printable bytes in front of the 2nd and 3rd %s which show as a red dot in this editor but not on the page afterward.

~ $ xclip -o | hexdump
0000000 4025 1a20 4025 0820 4025

So it must be the 0x1a and 0x08. I couldn't run hexdump and middle-click in that terminal because (apparently) it caught 0x1A as Ctrl+Z and dutifully stopped.

Whoever put the spoiler flag on this needs to learn what a spoiler is and is not. Remarking on my own failure to correctly perform manual memory management is not revealing anything useful or interesting about any kind of solution. "Oh he used manual memory management to solve the problem" is not useful or interesting. Go read a book or something.

neglected to free() on top of doing too much work ITFP

Disregarding some 3rd-party utility library's private (non-standard) conventions, all strings in C are null-terminated.

If you did't find the trailing 0, then either you're not at the end yet, or else it's the provider's bug upstream sending you a defective malformed "string", as in, you segfaulted by reading beyond your given memory without finding it.

This was me, it is my old solution, and it is shameful. The fact that it gathered some votes is shameful and seems closely related to the disaster we are in.

reduction fail

640GB ought to be enough for anyone

The rank of 7 is the first clue that whatever mystery code for transforming input to output will not be particularly complex. I looked for low-hanging fruit, and there it is. If you want to re-calibrate your horrible-ometer, try some Bongard Problems. The point is to figure out what all the things on each side (left or right) have in common, and what and how that makes them different from / opposite to all the things on the other side. gl hf