Ad
  • Custom User Avatar

    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.

  • Custom User Avatar

    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

  • Custom User Avatar
  • Custom User Avatar

    It seems to be. Thanks!

  • Custom User Avatar
  • Default User Avatar

    should be fixed, can you check ?

  • Custom User Avatar

    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.

  • Default User Avatar

    "The first index a will always be lower that than the string length;
    the second index b can be greater than the string length.
    More examples in the test cases. Good luck!"

    the second index b cannot be greater than the string length else it will be out of range.

    can someone explain me the instruction?

  • Custom User Avatar

    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"
    
  • Custom User Avatar

    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

  • Custom User Avatar

    Resolved with fork above approved

  • Custom User Avatar

    facepalm

    So there is no particular order to restore. Thanks.

  • Default User Avatar

    i can confirm that the random tests in C produce garbage due to a faulty pointer dereference. however, you can still pass the tests as you do not need to print or strcmp the array elements, but merely swap them

  • Default User Avatar

    C fork

    • fixing the issue below (strings in random tests contain random memory)
    • greatly simplyfing the tests suite (down from 141 lines of code to 66)
    • adding a note in the initial code about the memory model of the function (swapping is to be done in-place, as it's more idiomatic and also what the author's solution does)
    • better assertion messages
  • Custom User Avatar

    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.

  • Loading more items...