The same in C++.

The test looks correct to me. It tests the frequency of use of each allowed character. In 10000 generated passwords, each allowed character should be used equally often. As there is some randomness, the test allows for a deviation of 50% for each character's frequency from the mean.

In short: you need to make sure that all characters are used with the same probability / frequency.

Brute force doesn't generally seek to exploit relationships or break the problem into smaller pieces. By "brute force" I mean something like the approach a colleague used in his attempt to solve for just the base-10 parasitic number ending in 6. His approach was to start with 6 and increment that by 6 and then test the digits. Of course, he never completed the puzzle and that approach was doomed.

I have the same problem. Slx64, can you verify that your tests are correct for C++?

I tested my solution and I get uniform distribution of all available characters, and i still don't pass without bias test.

Any update here? I can't seem to pass the should_generate_passwords_without_bias test. I'm using rand() for random number generation.

Same error here, I can't pass that test.
The note about what is considered randomness is extremely vague.
I have tried what was suggested above: limiting the number of occurrences of each character in a password to 33% / 50% (tested each), but it still doesn't work.

just I can't see any other sense of that coniditon

maybe author means maximum appearance-rate (ar), like "eR5qeS7en" - 'e' ar is 33%, and it is normal ar maximum for one (or few) symbols ?

"...all characters should have less than 50% occurance..." means, that one character shouldn't appear in string more, than (string.size() / 2) times
and i have the same problem with "should_generate_passwords_without_bias" - can anyone explain what it actually means

Thanks! :)

Hi,

I just checked and you're right, the "training" version is not the good one. But I checked too the last java translation (in its edit panel) and this one is fine... :-o

@noLan : Do you know what's going wrong there ? Maybe you have to "deactivate" in some way the older java translations ?

All set, thanks Blind4Basics!

That will be fixed as soon as noLan will approved the corrected version.
Sorry for the trouble.

Hmmm... obviously the straight-line distance should never be greater than the distance via a third point, so the issue is with the distanceTo method. I guess the problem was my decision to express distances as an Integer rather than a float, which introduces the possibility of rounding errors. I'll see if I can fix the problem when I get time, maybe this weekend.