Robot Name Requirements about problem-specifications HOT 10 CLOSED

Hm, yeah, I see what you mean. We should clarify that.

The original intention was to avoid collisions, but in tracks where there are no tests about that this might be more part of the discussion than part of the original requirement.

from problem-specifications.

Actually while we are looking at it, does it read to you that the randomness of the names is a requirement? Or would an acceptable solution (+1) iterate the names as a means to avoid collision?

from problem-specifications.

The way I read it randomness is a requirement, but you're right--this could be reworded to provide a broader range of acceptable approaches.

from problem-specifications.

Fixed in #131

from problem-specifications.

@kytrinyx ... i took a quick look to see how other people implemented this. it looks like in many cases people just use either sample or rand, without explicitly preventing duplicates. Even with the committed change, it's not entirely clear what the intent is:

1. follow TDD and allow use of rand or sample as sufficient to meet the requirements for random number generation
2. write or use an algorithm that is less likely to generate predictable / repeatable random values (SecureRandom)
3. include additional logic to reject generated random names that have already been used (lightweight ephemeral registry via array/hash/set)

I'm curious if this might be better served with another test to verify that a given random name is already in use (implying a name registry of sorts):

• test for valid_name to verify a previously assigned name is rejected as a duplicate

from problem-specifications.

I'm not sure. It seems a bit awkward for the robot API to expose a method for checking whether or not a name is valid, but I do think that you're right that the problem becomes more interesting if we are able to ensure that names are not duplicated.

from problem-specifications.

The test(s) would have to be reformulated to track for that. While the robot generator would have to guard against duplicates it would be weird to have the generator prove each name is unique.

I read the problem to indicate the the name had to be in the format LLNNN, which ends up limiting the total namespace. Fundamentally having to enforce randomness and uniqueness is tricky given the finite namespace. It would definitely make the problem harder to solve.

It would also make the tests more complex and you would need tests that make an attempt to exhaust the available namespace to make a collision. It could be required that the generator signal exhaustion of the namespace. It gets complicated! In my JS solution I ended up throwing an error if the namespace was all used up and added a test to check for that condition.

The uniqueness/randomness of the names could always be the style-points award, a place where solutions distinguish themselves in implementation rather than be an absolute requirement.

from problem-specifications.

@tleen I followed the JavaScript one in the C++ track. I have one test that verifies that the letter prefix changes when the digits are exhausted, I think. I didn't want to write a test that tried to verify that all generated names were unique by exhaustively generating all the names and then checking them for uniqueness. To me, it made more sense to assert this by induction in the tests.

from problem-specifications.

We should keep in mind this is just an exercise, don't want to make the tests too burdensome.

from problem-specifications.

Yes, I agree. I don't think gold plated engineering is the point of exercism. I've seen some of that in the C++ track where people are thinking that the point of the exercise is to create the most bulletproof thing you can possibly imagine. My point of view is to take the problem statement as a general guide and then use the tests to guide what my implementation should do. If the test doesn't require me to do something, then I view that as not required 😸.

from problem-specifications.