Check predictability of names in robot-name exercise#2110
Check predictability of names in robot-name exercise#2110EugenDueck wants to merge 1 commit intoexercism:mainfrom
robot-name exercise#2110Conversation
The README to the exercise states > The names must be random: they should not follow a predictable sequence. Yet there are accepted [solutions](https://exercism.org/tracks/rust/exercises/robot-name/solutions/boso) that violate the requirement. *) The linked solution can unfortunately not be commented on: > Comments have been disabled This new test makes sure that the most obvious kind of predictability - and probably the only one naturally used by anyone - makes tests fail. The test cannot be run concurrently with other tests, for obvious reasons, hence the not very elegant solution using a global RwLock, which every other tests has to `read()`, in order for the new test to run exclusively.
|
This PR touches files which potentially affect the outcome of the tests of an exercise. This will cause all students' solutions to affected exercises to be re-tested. If this PR does not affect the result of the test (or, for example, adds an edge case that is not worth rerunning all tests for), please add the following to the merge-commit message which will stops student's tests from re-running. Please copy-paste to avoid typos. For more information, refer to the documentation. If you are unsure whether to add the message or not, please ping |
|
Hello. Thanks for opening a PR on Exercism 🙂 We ask that all changes to Exercism are discussed on our Community Forum before being opened on GitHub. To enforce this, we automatically close all PRs that are submitted. That doesn't mean your PR is rejected but that we want the initial discussion about it to happen on our forum where a wide range of key contributors across the Exercism ecosystem can weigh in. You can use this link%20The%20linked%20solution%20can%20unfortunately%20not%20be%20commented%20on:%0D%0A%3E%20Comments%20have%20been%20disabled%0D%0A%0D%0AThis%20new%20test%20makes%20sure%20that%20the%20most%20obvious%20kind%20of%20predictability%20-%20and%20probably%20the%20only%20one%20used%20naturally%20by%20anyone:%20enumerating%20names%20in%20order,%20rather%20than%20creating%20random%20ones%20-%20makes%20tests%20fail.%0D%0A%0D%0AThe%20test%20cannot%20be%20run%20concurrently%20with%20other%20tests,%20for%20obvious%20reasons,%20hence%20the%20not%20very%20elegant%20solution%20using%20a%20global%20%60RwLock%60,%20which%20every%20other%20tests%20has%20to%20%60read()%60,%20in%20order%20for%20the%20new%20test%20to%20be%20able%20to%20run%20exclusively.&category=rust ) to copy this into a new topic on the forum. If we decide the PR is appropriate, we'll reopen it and continue with it, so please don't delete your local branch. If you're interested in learning more about this auto-responder, please read this blog post. Note: If this PR has been pre-approved, please link back to this PR on the forum thread and a maintainer or staff member will reopen it. |
|
|
||
| // just checking the easiest kind of predictable sequences here: the difference between | ||
| // numerical representation of consecutive names is always the same | ||
| let d = nums[1] - nums[0]; |
There was a problem hiding this comment.
You could easily beat that by using alternating patterns. How about compiling a set of the differences and check that its length is at least the square root of the length of the names list?
There was a problem hiding this comment.
If you really wanted to prevent any possible predictable sequence, you could get very scientific about this, and it would be impossible to achieve anyway. In the end, even PRNGs are pretty predictable. Tiny algorithms describe PRNG sequences. So where to draw the line?
The goal of this PR is to simply prevent predictable sequences that people would - and in fact did - actually use. More complicated predictable sequences make solutions less simple, so the ranking will take care of hiding them...
2 participants
The README to the exercise states
Yet there are accepted solutions that violate the requirement.
*) The linked solution can unfortunately not be commented on:
This new test makes sure that the most obvious kind of predictability - and probably the only one used naturally by anyone: enumerating names in order, rather than creating random ones - makes tests fail.
The test cannot be run concurrently with other tests, for obvious reasons, hence the not very elegant solution using a global
RwLock, which every other tests has toread(), in order for the new test to be able to run exclusively.