Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skills definition #460

Closed
braktar opened this issue Feb 23, 2021 · 1 comment · Fixed by #482
Closed

Skills definition #460

braktar opened this issue Feb 23, 2021 · 1 comment · Fixed by #482

Comments

@braktar
Copy link
Contributor

braktar commented Feb 23, 2021

The current model expects the jobs, shipments to have all or none the field skills
Moreover, having a field with an empty array returns an error Missing skills.
It is expected to provide at least a dummy 'skill' for every jobs and vehicles.

My expectation was, that a vehicle with an empty array of skills could serve jobs or shipments without particular need (with an empty array of skills as well). And a job with an empty set of skills can be served by any vehicle.

@jcoupey
Copy link
Collaborator

jcoupey commented Feb 24, 2021

Yes, there is an input check that enforces that skills are either always or never provided. And currently an empty skills array behaves as if there were no skills key at all.

I remember I had to make this choice back when skills were introduced a while ago. The rationale for enforcing always having values was that a default behavior seemed inconsistent with other constraints. If no skills (or empty skills array) for a vehicle means that this vehicle can only serve tasks with empty skills, then it's actually imposing a strong constraint. Whereas for other constraints (think TW), not defining the key defaults to no constraint. I was worried that the "no key -> no constraint" approach for skills could confuse users into thinking that a vehicle without specific skills can actually serve any task.

a vehicle with an empty array of skills could serve jobs or shipments without particular need (with an empty array of skills as well)

On the other hand, this is a clear way to describe a sound behavior, and it's actually consistent with the current skills documentation stating that "job j is eligible to vehicle v iff j.skills is included in v.skills" (an empty array is included in any array).

Also this change would be backward compatible (only opening new easier ways to model certain situations). The icing on the cake is that it would only be a matter of loosening the above checks because the current vehicle/task compatibility checks would work out of the box with empty arrays (except of course for the assert):

bool is_compatible = true;
assert(!jobs[j].skills.empty());
for (const auto& s : jobs[j].skills) {
if (v_skills.find(s) == v_skills.end()) {
is_compatible = false;
break;
}
}
_vehicle_to_job_compatibility[v][j] = is_compatible;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants