• I work full time, hence my intermittent replies. I like the idea of 50/50 generated test cases, but I also don't have the time to implement them. If a mod wants to approve changes on my behalf, I'm happy to forgo any kind of ownership (this Kata was authored years ago when I had way more free time).

  • Users can see only long, but this does not mean 32 bits, because its platform dependant. In the worst case, you risk a fact that you generate 32-bit values and pass them to a function excpecting 64-bit input.

    Well I don't necessarily hope for people that are 7 kyu to understand what int32_t is, so the chances are astronomously higher that the user will be familiar with long instead.

    That risk is like throwing 0.5f into a function that takes double. In any case, good thing is that we are NOT losing any of the numbers. Long is 32bit in the LP32 data model, and only 64bit in LP64 data model although it's much more recommended to be using long long at that point (just for the sake of backwards compatibility).

  • Hey. The tests use int32_t, but the solution uses long as arguments, just to indicate to the user that the values might be large (i.e. 32bits).

    But how does this help the user? User cannot see that int32_t is used, because they cannot see the test suite. Users can see only long, but this does not mean 32 bits, because its platform dependant. In the worst case, you risk a fact that you generate 32-bit values and pass them to a function excpecting 64-bit input.
    It's just a kind of coincidence that currently both int32_t and long are 32 bits (if they indeed are).

    I haven't found a way to figure out how to DM the author or anything yet unfortunately.

    Unfortunately, you can't do that easily :( There are some ways to force a notification, but they are just workarounds.

  • Hey. The tests use int32_t, but the solution uses long as arguments, just to indicate to the user that the values might be large (i.e. 32bits).

    The print was left in without any reason - I just forgot to remove logging. It was just so I can check everything is working correctly and as it should.

    "Whether author and translator decide to use the technique is up to them. It started as a suggestion from my side."

    I would honestly love for the author to chime in and consider this solution too. I haven't found a way to figure out how to DM the author or anything yet unfortunately.

  • My bad, sorry!

    • tests use int32_t to generate values, but solution uses long as arguments. These two should be brought together. I am not sure which one is better, but since kata is about bits, I think I'd go with int32_t.
    • I am not sure if tests should print anything, I would remove the printing statements, users can always print inputs if they want to.

    But if you are going to keep them (and I can understand why), they should be moved before the assertion. Otherwise, when assertion fails, the printing does not happen and user is left misguided with the failure message preceeded by the previous, successful test case.

    Besides, printed message is not very meaningful, just two random numbers and a random 0 or 1 at the end: it should be explained to the user what the numbers are and what does the third printed value mean.

  • Why that should be true?

  • I see this in the python test cases: (16, 8 -> False)
    Why is this False?
    16 => 10000
    8 => 01000

  • (also I don't see why C++ tests need to be different from other languages)

    They do not have to. It was just my proposal to create tests which, as opposed to other languages, are not crippled in range and balanced better. Inputs generated by "totally random" generators have poor coverage and are unbalanced. Here is my attempt at creating and educating users how to create random generator which does not just "spray and pray" to produce something useful, but where randomly generated test cases are actually meaningful.

    Currently, test cases from other languages are limited to values ut po 1000 or 2000 without any particular reason, and 80% of test cases leans towards true scenario but even without guarantee that any false case will be generated (luckily, still very likely to have at least a couple of them). Ideally, C++ test would not be different from other languages, but tests for other languages would also be improved in terms of coverage and balance.

    Whether author and translator decide to use the technique is up to them. It started as a suggestion from my side.

  • "(also I don't see why C++ tests need to be different from other languages)"

    Well, they don't need to be necessarily. The problem here is that hobovsky said true pairs are generated about 80% of the time using just random and evaluating the outcomes - so we're kind of trying to force 50/50 pairs here.

    Hope that makes a bit more sense. Also, Check out this kumite, I did - and will implement this here.

  • .. did two comments here just get removed somehow? one from hobovsky one from me? I see mine on the front page, but no longer here.
    So confused.

    edit: Oh, no, after posting this, they show up again. Because that makes sense.

  •           int32_t a = rand()%20000;
              int32_t b = rand()%20000;
              while (... == false)
                  b = rand()%20000;
    

    if a only has 1 bit, that loop will go on forever

    (also I don't see why C++ tests need to be different from other languages)

  • Yeah the true number generator doesn't really work -> here's why:
    If it somehow generates number 3 or some low numbers then the binary complement for example for 3 is 100, when multiplied by -1 it returns a value of 100, which has no common bits with 011.

    I've modified the generator function, but this is basically back to square one since I had no idea in what way to accomplish what I wanted.

    Esentially what I did is:

    • Generate a and b with random - while loop until condition is satisfied to keep rerolling for b. -> true nums
    • Do b = a & b-1, and if that condition again isn't satisfied then generate a random number between 0 and 30, and throw 2^that number (because then the bit will be something like 0b000100000000000000) -> i.e. only one possible bit.

    Now this is a completely ridicilous way to do this, but my mind really doesn't work at 2AM.
    For what it's worth, any normal solution should be able to pass these tests (with the given one taking around 3s for each run).

    If you have a better idea to generate bits, I'd be happy to hear it.

  • yeah, keep on studying other people's code, this is one of the best features of codewars!

  • Loading more items...