Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In mathematics, there are notations for asymptotic lower bounds, upper bounds, and tight (within-a-constant-factor) bounds. When describing the growth of functions in general, it makes sense that all three might be relevant to some function or other.

In algorithm analysis, asymptotic notation is usually used to describe the growth in time or space requirements.

To me, it seems logical that I may be interested in the maximum, the minimum or the expected requirements. Ignoring the expected requirements, I might be interested in the lower bound of the best case (minimum space/time) or the upper bound of the worst case (maximum space/time).

I can't imagine why I should ever be interested in the lower bound of the worst case or the upper bound of the best case. Since the lower bound is a kind of best case and the upper bound a kind of worst case, these seem like "best case of the worst case" and "worst case of the best case" mismatches to me.

But on several occasions, I've had replies to answers/comments that suggest this may be a failure of imagination on my part.

So - what is it that I'm failing to imagine?

I won't consider a statement along the lines of "it's quite common to say that the lower bound of the worst case of the blah algorithm is blah" to answer the question, unless it also says why people care.

share|improve this question
add comment

1 Answer

up vote 5 down vote accepted

The lower bound of the worst case can be used to prove that an algorithm is not going to work for you.

In particular think about real time programming. I need to have my code execute in at most time x because it needs an answer in time to send the right message to a piece of machinery that needs to receive messages on a very precise schedule or else things go wrong. If a lower bound on the worst case exceeds x, then that proves that you absolutely have to think of something better. It doesn't matter if 99.99% of the time you're fine, because that remaining 0.01% of the time could seriously damage something.

share|improve this answer
    
Checking if I understand... I can see that the lower bound of the worst case can prove that the algorithm is (for that worst case) always too slow, but at first sight it seems like an over-strong (and overly hard to prove) way of saying "sometimes too slow". But perhaps "always too slow within the worst case" is sometimes easier to prove? Maybe it makes sense to redefine the worst-case to be more selective until the set of fast-enough cases within that is empty? –  Steve314 May 7 '11 at 1:12
    
@Steve314: A lower bound for the worst case is often easier to prove than exact performance for the worst case. Furthermore thinking about those bounds often gives you insight into why it is hard, and therefore what sorts of other ideas you can immediately discard. –  btilly May 7 '11 at 1:34
    
I think I'm happy with this now. If the "worst case" is sometimes, but not always, too slow then there must be greater and lesser degrees of "worst". Choosing to focus on the worst of the worst makes sense. That should naturally lead to an "always" proof, if one is possible. –  Steve314 May 7 '11 at 1:40
1  
@Steve314: It is worth noting that one often notices a lower bound for the worst case when you were actually looking for an upper bound for the worst case. In other words when trying to show you are in the right track, you sometimes notice that you were on the wrong one. :-) –  btilly May 7 '11 at 1:50
    
@Steve314: It is also worth noting that the most important outstanding CS problem is proving that NP-complete problems are not in P. This is a proof of lower bounds for the worst case for a lot of problems. –  btilly May 7 '11 at 1:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.