Originally Posted by
Calchas
At least in the past (and we're going back quite a few years) I had a similar query and was told that some of the routing codes and extensions codes were applied as a filter after the searching was complete. So although you think you're helping the engine by narrowing the parameters, it is really the number of potential travel days that matters. When you click on a particular day, the engine re-runs the analysis on the single day and has time to find more results.
The problem space really is vast (formally it's not merely N-P hard but computationally undecidable), even for a single city pair on a small number of days. So the engine applies heuristics, that sometimes works against what we as a human know can be done.
Even if I constrain it to a single duration value, it's coming back with wrong "lowest" prices on a couple of days. Here's a particularly weird example.
query; note: preventing overnights on the outbound but not the return
calendar results
results for Feb 12
Perhaps most importantly, the supposed lowest fare according to the calendar view was $1754, which isn't even a UA fare. But if I remove UA from the search, then the calendar view is correct. The fact that this only happens on a handful of days and in such an odd manner implies a bug, not an issue of computational complexity.