You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the number remaining displayed in the frontend is the total number of instances of a given item. We want this number to actually reflect the number of available instances given the request interval.
I can think of two ways to go about this, and neither 100% works :'(
Approach 1
Given a new request interval, compare it against the request intervals of all existing requests (there are ways to optimize this if we store existing requests in sorted order). For each existing request that overlaps with the new request, for each item of equipment in that request, keep track of how many instances are occupied. Finally, when returning the list of equipment items, compute the number of available instances by subtracting the # occupied instances from the # total instances.
With this approach, computing the # instances available for all items would take O(number of overlapping requests * avg number of items per request).
There is an edge case that isn't considered by this algorithm. Say we have the following scenario:
If we have two instances of an item contained in all three requests, the above algorithm would incorrectly conclude that no instances are available, whereas there should be one available.
Approach 2
We can keep a list of occupied times for each item of equipment. In this design, checking the number of available instances of an equipment item requires checking this list against the new request interval.
With this approach, computing the # instances available for all items would take O(number of equipment items * avg number of existing requests per item). I think this might be slower than approach 1 (?)
Note that for the purposes of this feature, it does not suffice to store occupied times at the instance level. This is because requests that are submitted but not yet checked out do not have specific instances assigned. The only information they contain is the number of requested instances for an item, which is why we have to rely on a list of occupied times on the item rather than the instance.
We also still run into the same edge case that approach 1 encounters.
The text was updated successfully, but these errors were encountered:
Frama-99
changed the title
Consider changing method of checking equipment item availability in backend
Update method of checking equipment item availability in backend
Dec 22, 2022
Frama-99
changed the title
Update method of checking equipment item availability in backend
Return number of available equipment items from equipment_item endpoint
Dec 22, 2022
Currently, the number remaining displayed in the frontend is the total number of instances of a given item. We want this number to actually reflect the number of available instances given the request interval.
I can think of two ways to go about this, and neither 100% works :'(
Approach 1
Given a new request interval, compare it against the request intervals of all existing requests (there are ways to optimize this if we store existing requests in sorted order). For each existing request that overlaps with the new request, for each item of equipment in that request, keep track of how many instances are occupied. Finally, when returning the list of equipment items, compute the number of available instances by subtracting the # occupied instances from the # total instances.
With this approach, computing the # instances available for all items would take O(number of overlapping requests * avg number of items per request).
There is an edge case that isn't considered by this algorithm. Say we have the following scenario:
If we have two instances of an item contained in all three requests, the above algorithm would incorrectly conclude that no instances are available, whereas there should be one available.
Approach 2
We can keep a list of occupied times for each item of equipment. In this design, checking the number of available instances of an equipment item requires checking this list against the new request interval.
With this approach, computing the # instances available for all items would take O(number of equipment items * avg number of existing requests per item). I think this might be slower than approach 1 (?)
Note that for the purposes of this feature, it does not suffice to store occupied times at the instance level. This is because requests that are submitted but not yet checked out do not have specific instances assigned. The only information they contain is the number of requested instances for an item, which is why we have to rely on a list of occupied times on the item rather than the instance.
We also still run into the same edge case that approach 1 encounters.
The text was updated successfully, but these errors were encountered: