About Robot name

[bid0uille]

Instructions for the "Robot name" problem ask for two independant things:

• at any time, each robot name has to be unique;
• when reset, a robot gets a new random name.

From that, what I understand is that:

• when creating a robot, we have to check for current names of robots currently up;
• when reseting a robot, we do the same, given that obviously this one is currently up and has a current name.

Most solutions I saw are checking against all already given names: they not only ensure that names are unique in "space", but also in "time".
We may think that's not a big deal, but something else makes this kind of solution unsatisfying. From instruction, we may deduce there are 676000 possibles names:

• so a right implementation should handle the case were there is no more name to give, to avoid bad things;
• in a strict interpretation, that means 676000 possible different robots, while in the mainstream one it's about 676000 names attribution, which makes a big difference.

To me, the strict interpretation is more interesting. Anyway, instructions should be refined to help people to get it, or they should be reformulated to reflect how most people currently understand them (still an interesting problem).

[coriolinus]

Makes sense to me. This repo will be accepting PRs again soon; perhaps create one which implements these suggestions.

[joshgoebel]

so a right implementation should handle the case were there is no more name to give, to avoid bad things;

I definitely think a test should be required for this for a solution to be "correct"... otherwise it's entirely uncertain what should happen when someone tries to boot up the 676,001th robot. This is something I always walk students thru on this exercise to think about this edge case.

strict ... vs ... mainstream

I'm feeling a bit stupid now, but I'm not sure I understand the nuance you're asking about here... can you give an example?

---

My understanding of this exercise is that "robots live forever"... so that names (once taken) never flow back into the pool unless a robot was reset (in which case then it's name might would either return to the pool, or still be allocated forever)... perhaps this is the distinction you were getting at?

[bid0uille]

it's name might would either return to the pool, or still be allocated forever

Yes, that's the ambiguous point, as that's not clearly stated. Most people, if not all (hence why I called it "mainstream") go for the simplest "forever", and why not! But to me the point of deleting a name is about to free it, not to make a robots graveyard :)