Ad
  • Custom User Avatar

    No random tests.

  • Custom User Avatar

    Your task is to find the smallest primitive root modulo n.

    Given n, presumably? The task might be stated more clearly as a function ( signature ).

  • Custom User Avatar

    1, 2, 4, 8, 16, 32 % 9 -> 1, 2, 4, 8, 7, 5 ( 64 % 9 = 1, restarting the cycle )

    Wouldn't that make 2 a primitive root?

  • Custom User Avatar

    I did the description updates last, decided for null instead of undefined to remain closer to Python, updated the Submit tests, but apparenty forgot to update the Sample tests ( again ).

    We apologise for the inconvenience. Please Refresh ( don't forget to save your code ).

  • Custom User Avatar

    cr@p. did I forget to update the sample tests again?

  • Custom User Avatar

    Approved. Thanks for taking the time to translate this, I'm sure it wasn't the easiest.

    Not that it matter much, but I'm curious as to why the reference soluion and example are different or run at different times. Does the reference take advantage of already knowing where it ends or something?

    Also, nice one on giving the user more time, it's really annoying when you have to way 6 seconds for the reference solution to solve.

  • Custom User Avatar

    I tested it and it doesn't seem to be generating infinite generators.

    However, as you said, I'm not sure if it really is that big of a deal. Specifically hardcoding the fixed tests seems like much more work than it's worth and the infite part of the challenge isn't that big of a deal.

    So let's leave it be then. I also don't really feel like or have the time to be rewriting this right now. I'll approve your tranlation.

  • Custom User Avatar

    I managed to translate it; I'm not aching to do a complete rewrite in JS.

    I think testing never actually gets to infinite iterators, but there's fixed tests for that, the kata is approved without anyone complaining and the rating is good enough - let sleeping dogs lie.

  • Custom User Avatar

    It's been 3 months, I don't really remeber my intentions, but I'm pretty sure that when I wrote maximum < 0, I meant maximum - minimum - first < 0.

    On the tests being overengineered. Yeah, they probably are, I couldn't find a better one at the time. But no, there's no good reason, it was what I found that worked.

    I could try to make it simpler or if you have something simpler in JS, I can translate it in Python before approving your translation.

  • Custom User Avatar

    I never ran into any problem. I had no idea there was any. I also have no idea why there was a difference between Submit and Sample Tests anyway.

    ETA: it's probably a refactoring fossil

  • Custom User Avatar

    JS translation

    the example solution is not the fastest, but the reference solution is actually a lot better ( example solution runs in ~9 seconds; reference solution in ~3 ), so I hope solvers have a reasonable amount of time for their solution to run.

    minor changes to the description, also because I did not bother to preload iterator.take.

  • Custom User Avatar
    first = randrange(maximum - minimum - total)
    ...
    yield from randoms(1, total + 1, maximum - minimum - first) # Some random extra tests, may be infinite if maximum < 0
    

    this never goes to infinity. there's always at least total left. given the comment, this may not be intentional. also, maximum is never < 0.

    the random tests are heavily overengineered; they are a total pain in the neck to translate. can't that be done simpler?

  • Custom User Avatar

    Of course it works. Because testing is necessarily finite.

    If you think setting Infinity to 100 000 won't come back to bite you some day, have at it. I think you actually know better.

  • Custom User Avatar
  • Custom User Avatar
  • Loading more items...