PFOO-U yields impossible result

[nickstanisha]

I tried PFOO-U with a short test trace and discovered what appears to be an impossible solution. My trace was

1 1 10
2 1 10
3 2 10
4 1 10
5 2 10
6 2 10
7 2 10
8 1 10

ran with cache size = 11 and max-valued step size, and my solution from PFOO (using OHRGoal/PFOO-U/pfoou) was

// output from PFOO-U
// ID, Size, Utility, decision_var, is_hit

1 10 0.1    1    0
1 10 0.05   1    1
2 10 0.05   0.1  0
1 10 0.025  1    1    **
2 10 0.1    1    0.1  **
2 10 0.1    1    1
2 10 0      0    1
1 10 0      0    1

I've highlighted the two rows that I believe yield an impossible solution as caching both objects entirely would exceed the cache size. The regular FOO-U (OHRgoal/FOO/foo) implementation seems to yield the correct integer hit rate of 4/8

// output from FOO
// Time, ID, Size, decision_var

1 1 10 1
2 1 10 0.1
3 2 10 1
4 1 10 0.1
5 2 10 1
6 2 10 1
7 2 10 0
8 1 10 0

As a result of this the miss rate from PFOO-U (3/8) is less than the miss rate from FOO-U (4/8) on this trace which seems like it violates the claim from the paper that PFOO-L ≤ FOO-L ≤ OPT ≤ FOO-U ≤ PFOO-U