1
# Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
rentable_items = [ 
  %w(x x x - - - x x x - - -), # item1
  %w(- - - - - - - - - - - -), # item2
  %w(x x x x x x x - - - - -), # item3
  %w(x x x - - - - x x x x x) ]# item4

Ok,given that data-structure (which represents rent-slots in months of the items) where "x" stands for not-rentable and "-" stands for rentable, i have the following question.

When I have an incoming request for the period from April till June i want the result in the following priorized order:

items = rentable_items.ideal_utilization_for("2010/03/01", "2010/06/30")
items # [item1, item2, item4] #where item4 is the worst

The idea behind this is to fill the gaps of an item first and try to produce as few new gaps as possible.

I need no complete solution, but an advice which tools (library, gem, alogrithm) are availalbe for such a problem. Exemples would be very appreciated.

[Edit: Removed the second example, to focus on the real problem.]

Sebastian
  • 1,253
  • 1
  • 10
  • 11
  • If you're already amenable to swapping items out in the middle of the request period, does it really matter exactly which item you're giving them? – Anon. Jan 27 '10 at 20:28
  • Why is item1 "better" than item4 for that period? Why would splitting a rental over two items be preferred over one? – BlueRaja - Danny Pflughoeft Jan 27 '10 at 20:32
  • no, this doesen't really matter, as long as the given item produces not a new gap. hmm, with this in mind i see, i have to edit the examples :) – Sebastian Jan 27 '10 at 20:34
  • @BlueRaja: item1 is better than item4 because item4 would produce a gap of 1 month at the end of the period. – Sebastian Jan 27 '10 at 20:35
  • @Sebastian: But item2 would produce a gap of 6 months... also, if you are not concerned about having to swap-out items midway through the rental, the gap does not matter since during month X you will always have Y people wanting items and Z items available. The best algorithm in that case would simply be to grab the first one that's available. Other things you may want to consider in a real-life situation: how often the item has been used, what kind of condition it's in, when does the warranty end, etc. – BlueRaja - Danny Pflughoeft Jan 27 '10 at 20:42
  • hm, ok. in lack of real conditions i will change my question a little bit. – Sebastian Jan 27 '10 at 20:52
  • So really, you don't want to reduce the gaps, but give the answer that will require the least amount of item-swaps-per-rental? My next question: Do you know all the rentals ahead of time, or do they come one-by-one? If they come one-by-one, you can get as complex a statistical algorithm you want; if you know them all ahead of time, we should be able to guesstimate the best utilization. – BlueRaja - Danny Pflughoeft Jan 27 '10 at 20:59
  • Exactly, i want to get the items with the least amount of item-swaps-per-rental. And no, the rentals coming in one-by-one. The aim is, to fill existing gaps, without creating a shorter gap, than the existing one. – Sebastian Jan 27 '10 at 21:10

1 Answers1

1

I want to get the items with the least amount of item-swaps-per-rental ... the rentals coming in one-by-one.

Then since we can't predict the future, any algorithm we give you will simply be statistical, and it'll be easy to find a case where the algorithm gives you sub-par results.

Without having to worry about rental patterns for users, or rentals we know about ahead of time, I would simply map each item to its contiguous available date-range (meaning some items will have more than one date-range), then sort by the length of each of those ranges. When a new order comes in, use the smallest date-range that completely fills the order. Remember that a date-range should get smaller as we pass through it in real time, since we don't care if the item was available a week ago.

If people are able to reserve items, wait until the day-of to assign an item to them, then assign them from shortest-to-longest.

This is of course just one answer; there are literally infinitely-many heuristics that you could apply.

BlueRaja - Danny Pflughoeft
  • 84,206
  • 33
  • 197
  • 283