ðŸŽ‰ Exercism Research is now launched. Help Exercism, help science and have some fun at research.exercism.io ðŸŽ‰

# JaeHyoLee's solution

## to Robot Name in the Lua Track

Published at Jul 13 2018 · 3 comments
Instructions
Test suite
Solution

Manage robot factory settings.

When robots come off the factory floor, they have no name.

The first time you boot them up, a random name is generated in the format of two uppercase letters followed by three digits, such as RX837 or BC811.

Every once in a while we need to reset a robot to its factory settings, which means that their name gets wiped. The next time you ask, it will respond with a new random name.

The names must be random: they should not follow a predictable sequence. Random names means a risk of collisions. Your solution must ensure that every existing robot has a unique name.

## Running the tests

To run the tests, run the command `busted` from within the exercise directory.

## Further information

For more detailed information about the Lua track, including how to get help if you're having trouble, please visit the exercism.io Lua language page.

## Source

A debugging session with Paul Blackwell at gSchool. http://gschool.it

## Submitting Incomplete Solutions

It's possible to submit an incomplete solution so you can see how others have completed the exercise.

### robot-name_spec.lua

``````local Robot = require('robot-name')

describe('robot-name', function()
it('has a name', function()
local robot = Robot:new()
-- lua does not support fixed patterns like %w{2}%d{3}
assert.are.equal(string.match(robot.name, '^%a%a%d%d%d\$'), robot.name)
end)

it('name is the same each time', function()
local robot = Robot:new()
assert.are.equal(robot.name, robot.name)
end)

it('different robots have different names', function()
local robotOne = Robot:new()
local robotTwo = Robot:new()
assert.are_not.equal(robotOne.name, robotTwo.name)
end)

it('is able to reset the name', function()
local robot = Robot:new()
local originalName = robot.name
robot:reset()
assert.are_not.equal(originalName, robot.name)
end)
end)``````
``````local robot_name = {}
robot_name.__index = robot_name

local seed = 0
local function generate_name()
math.randomseed(seed)
seed = seed + 1
return string.char(math.random(65,90), math.random(65,90)) .. math.random(9) .. math.random(9) .. math.random(9)
end

function robot_name:new()
return setmetatable({name = generate_name()}, robot_name)
end

function robot_name:reset()
self.name = generate_name()
end

return robot_name``````

I think that your names are not random. You are seeding the function each time based on a fixed number which will guarantee that the random function always returns the same results.

This also won't prevent name collisions. Giving a different random seed does not guarantee that the results will be different. Instead, it would be good to keep track of all of the names you've used and make sure that you do not use them again. If you want to be really slick you can use the __gc metamethod to free up names so that they can be used again, but this is not really required.

Solution Author
commented over 4 years ago

so... not seeding everytime is safer? what else we can do to guarantee that it is actually random? without keep tracking of the names already been generated? I thought seeding is at least we can do.

Seeding restarts the random number generator. The best way to do it is to seed it with some random value (like the start time) and then let the random number generator continue to use that seed.

If you seed it continuously, then you may break the pseudo-randomness of the generator. In this case, you are seeding with constant values so you will get values that look somewhat random, but that are always the same. Because this isn't a security application it is not such a big concern.

Unfortunately, you will actually need to keep track of the names that you have already allocated. This is because even with a truly random number generator, you are not guaranteed to have no repeats. Getting the same number 10 times in a row is a possible output from a random number generator. The tests are not capable of showing this problem, though.

### What can you learn from this solution?

A huge amount can be learned from reading other peopleâ€™s code. This is why we wanted to give exercism users the option of making their solutions public.

Here are some questions to help you reflect on this solution and learn the most from it.

• What compromises have been made?