Reservations in the tavern. There are long tables consisting of N small ones. Behind each little one, you can seat 2 people, and only beyond the extreme - 3 (two on the sides and one at the head of the table, it turns out):
xxxx x[ ][ ][ ][ ]x xxxx 1 2 3 4
There is a variant of long tables, when there is a place at the head of a table on one side only.
Visitors choose a table and indicate how many people there will be.
The desired booking algorithm should choose the best places for K people at their chosen table. For example if 3 people arrived and the table is empty so far - let them go to the last table, of course. 2 came to them from the other end.
oxxo o[-] [ ][ ] [-]x oxxo 1 2 3 4
It is undesirable to replant - bought - received a letter with a ticket for two at a table 21 (3), for example. Maybe it was better for two people to saw off the 3rd table, because more likely that someone else will need 3 places at once? What does teverver say?
There are two more questions:
- Do you know the "classic" algorithm for such a task of gradual cutting?
- How would it be better in the code to describe such long tables and their current fullness? The language is unprincipled, but now I write it on JS, a long table is an object (there is also drawing it in SVG). From the server about the long table comes JSON with numbers of sub-tables
: )for each reservation:
The feeling that I invent the bicycle, does not give rest. Need a fresh look!