GenerateRandomSearch

Interval Scheduling Generator

When bookings compete for one room, taking whichever finishes soonest is provably the best you can do — you cannot fit more in by any other method. Taking whichever starts soonest, which is what a first-come queue does, is not. This generates competing requests, applies the optimal rule, and reports what the intuitive rule would have managed instead, so the gap between them is a number rather than an argument.

What this generator does

Generates overlapping time requests, then selects greedily by earliest finishing time — which is optimal for this problem — and separately counts what the earliest-start rule would have granted, so the difference is visible.

How to use this tool

  1. Choose how many competing requests to generate.
  2. Generate and read how many could be granted.
  3. Compare that against the earliest-start count in the notes.
  4. Re-run a few times to see how often the two rules differ.

Understanding the controls

How many requests
Between 2 and 40 competing windows on the same resource. More requests means more overlap and a bigger gap between the two rules.

Common use cases

  • Demonstrating that first-come-first-served is not the most efficient rule
  • Practising the activity selection problem on fresh instances
  • Producing booking conflict data for a scheduling exercise
  • Teaching why a greedy rule needs the right key to be optimal
  • Generating test cases for a room or resource booking system

How this generator works

Requests are sorted by finishing time and taken greedily whenever they start after the last accepted one finishes. That rule is optimal, which is a genuinely strong claim: no selection of any kind fits more requests in. The tool separately runs the same greedy sweep sorted by start time — the first-come rule — and reports its count for comparison. Before display the granted set is re-checked for overlaps, and the first-come count is confirmed never to exceed the optimal one, since that would be impossible.

Randomness and fairness

Uses your browser's cryptographic random source for the request windows by default. A seed reproduces the same instance, deterministically and not cryptographically securely.

For how randomness is produced across the whole site, see how Generate Random works.

Limitations and good to know

  • Every request counts equally, so this maximises the number granted rather than the hours used or the value delivered — weighting them is a harder problem needing dynamic programming.
  • One resource only; several interchangeable rooms would change the answer and the method.
  • Requests are fixed windows that cannot be moved, which is what makes this tractable and unlike most real diaries.
  • No priorities, no recurring bookings, and no partial grants.

Privacy and your data

Requests are generated and scheduled entirely in your browser, with nothing transmitted, stored or included in analytics.