Here's a quick implementation in java. The idea is to find how many cards can be picked each step by counting the number of cards with a number below this step and subtracting the number of cards already picked. Of course a lot of work is unnecessarily repeated, but this should give a good idea of how to approach this problem.
public class PickCards {
public static int countLessOrEqualThanMax(int[] cards, int max) {
int count = 0;
for (int number : cards) {
if(number <= max) count++;
}
return count;
}
public static void main(String[] args) {
int[] cards = {0, 1, 2, 4, 3};
int numberOfWays = 1;
for(int i = 0; i < cards.length; i++) {
int ways = Math.max(0, countLessOrEqualThanMax(cards, i) - i);
numberOfWays *= ways;
}
System.out.println(numberOfWays);
}
}
Third time's the charm, I hope. I combined my original idea to sort the list first with Snowman's suggestion of using set theory. The basic algorithm is:
- Sort the pairs in lexicographic order by the first range.
- Group adjacent pairs by if just the first ranges overlap. I prove below that lexicographically sorted ranges will never overlap without being adjacent, which allows this step to be done in
O(n). This creates sets where the first ranges overlap.
- Within each of those sets, sort again by the second range, and group by if the second ranges overlap. This splits sets where the first ranges overlap into sets where the second ranges also overlap.
- Within each set of sets, repeatedly combine pairs until you have one merged pair.
Here's an O(n log n) implementation in Haskell:
import Data.List
import Data.Tuple
type Range = (Int, Int)
type RangePair = (Range, Range)
rangesOverlap :: Range -> Range -> Bool
rangesOverlap (a,b) (c,d) =
c <= a && a <= d ||
c <= b && b <= d ||
a <= c && c <= b ||
a <= d && d <= b
pairsOverlap :: RangePair -> RangePair -> Bool
pairsOverlap (a, b) (c, d) = rangesOverlap a c
combineRanges :: Range -> Range -> Range
combineRanges (a,b) (c,d) = (min a c, max b d)
combinePairs :: RangePair -> RangePair -> RangePair
combinePairs (a, b) (c, d) = (combineRanges a c, combineRanges b d)
combineOverlapping :: [RangePair] -> [RangePair]
combineOverlapping = map swap . concat .
map (combineSets. makeSet . map swap) . makeSet
where makeSet = groupBy pairsOverlap . sort
combineSets = map (foldl1 combinePairs)
We wish to prove that if
the ranges are lexicographically sorted, all the overlapping ranges will
occur in adjacent rows. Assume a counterexample exists where overlapping
ranges are not in adjacent rows. It will take the form of:
(a, b)
(c, d)
(e, f)
where (a,b) and (e,f) overlap with each other, but (c,d) does not overlap with either.
In order for (c,d) not to overlap with (a,b), d must be less than a or b
must be less than c. c <= d because it is a range, and a <= c because of
lexicographical sorting, therefore d >= a. e <= b because of overlapping,
and c <= e because of lexicographical sorting, therefore c <= b. Therefore,
if (a,b) and (e,f) overlap, then (a,b) and (c,d) always overlap, and no
counterexample exists.
Best Answer
(Update: now allows a gas tank size maximum)
You can solve this in linear time as follows:
First, we look at the case where we don't have a gas tank with a maximum.
Essentially, in the first for-loop, we just drive the circle around, not caring if our fuel tank has negative fuel or not. The point of this is that no matter where you start, the difference between how much there is in your fuel tank at the start (0) and at the end is the same.
Therefore, if we end up with less fuel than we started (so less than 0), this will happen no matter where we start, and so we can't go a full circle.
If we end up with at least as much fuel as we started after going a full circle, then we search for the moment our fuel tank was at its lowest point (which is always just as we get to a gas station). If we start at this point, we will never end up with less fuel than at this point (because it is the lowest point and because we don't lose fuel if we drive a circle).
Therefore, this point is a valid solution, and in particular, there always is such a point.
Now we'll look at the version where our gas tank can hold only so much gas.
Suppose our initial test (described above) we found out it is not impossible to go the entire circle. Suppose that we start at gas station i, we tank at gas station j, but our gas tank ends up being full, so we miss out on some extra gas the station has available. Then, before we get to station k, we end up not having enough fuel, because of the gas we missed out on.
We claim that in this scenario, this will end up happening no matter where you start. Suppose we start at station l.
If l is between j and k, then we either stop (long) before we can get to station k because we started at a bad station, or we'll always have at most the amount of fuel that we had when we started at i when we try to get to k, because we passed through the same stations (and our tank was full when we passed j). Either case is bad.
If l is not between j and k, then we either stop (long) before we get to j, or we arrive at j with at most a full tank, which means that we won't make it to k either. Either case is bad.
This means that if we make a round starting at a lowest point just like in the case with the infinitely large gas tank, then we either succeed, or we fail because our gas tank was too small, but that means that we will fail no matter which station we pick first, which means that the instance has no solution.