0

How can we perform time complexity analysis on a function that has no loops?

int somefunction(int param) {
  if (something)
    do this;
  else
    do this;
}

Would the time complexity of this function change depending on how many times the function is called within a program? I currently believe that the time complexity is O(n), because it is dependent on the amount of times that we call it.

Raphael
  • 72,336
  • 29
  • 179
  • 389
Graveyard2.1
  • 1
  • 1
    But what are "something" and "do this"? Do they need constant time only? – Juho Jan 15 '15 at 08:24
  • Have a look at our reference question and see whether you can figure it out yourself. Hint: what about function calls and recursion? – Raphael Jan 15 '15 at 08:35
  • @DavidRicherby: That would be a for-loop, contrary to what was asked. My interpretation was that there are no loops used directly of indirectly (thru method calls). (I also assumed in my answer that there are no recursive calls, since those are more-or-less equivalent to loops. The "no recursive calls" was not stated in the question, though.) – rgrig Jan 15 '15 at 12:13
  • @rgrig Remind me to switch my brain on before I make any more suggestions! :-) – David Richerby Jan 15 '15 at 22:05

3 Answers3

1

The complexity is typically understood to be for one call. If you want to talk about the complexity of a sequence of calls, then you would need to say so.

In your example, you don't really gain anything by looking at sequences of calls. But there are other situations (with loops or recursive calls allowed) in which you would indeed want to look at sequences of calls. One example is when the function typically takes little time but once in a while it decides to do a lot of work. In that case, you need to quantify how ‘once in a while’ compares to ‘a lot of work’. A natural way to do so is to see how much it takes to execute a long sequence of calls (keywords: "amortized analysis").

rgrig
  • 1,336
  • 1
  • 11
  • 15
1

Depends on what something and do this are. In particular, do we have to assume global (or object) state?

Consider this:

int switch(int param) {
  if ( !set.contains(param) )
    set.add(param);
  else
    set.remove(param);
}

Now the runtime clearly depends on the implementation of set and the number of entries it has when switch is called. Calling switch $n$ times starting with an empty set and using pairwise distinct parameters, you might get $\omega(n)$ runtime in total, hence not all calls run in time $O(1)$.

On the other hand, if somefunction does not access state outside of its scope -- assuming that the function itself does not have persistent state -- the runtime can only depend on param. That does not mean runtime is in $O(1)$ -- something and do this may still do non-constant things. Call methods, recurse, etc.

Note that depending on the cost model you use, even adding two numbers has non-constant cost.

Community
  • 1
Raphael
  • 72,336
  • 29
  • 179
  • 389
-1

It does not become linear just because it is called by linear-worst-case code; it retains whatever complexity it would have in isolation, which here looks an awful lot like constant-time, barring certain odd edge cases. Big-O of a chunk of code is not evaluated based on code that might include it in its own Big-O; you don't consider a hashtable access linear just because there's code that uses the hashtable to process a whole list of items and increment their occurrence counts.

Nathan Tuggy I
  • 99
  • 1
  • 5
  • 1
    Not necessarily, it depends on what "something" and "do this" actually are. – Juho Jan 15 '15 at 08:36
  • @Juho: It seems you have (poorly) copied a catchphrase from a different answer without really explaining why the catchphrase is relevant or a rebuttal. – Nathan Tuggy I Jan 15 '15 at 08:56
  • 2
    If you look at the time stamp of my comment to the original question, and the time stamp of the answer you are referring to, you will see this is not the case. To actually answer your question, it is clear that for instance, if something can't be performed in $O(1)$ time, the total time won't be $O(1)$ either. The same holds for do this. – Juho Jan 15 '15 at 09:00
  • 1
    @Juho : $:$ How will he see that? $;;;;$ –  Jan 15 '15 at 09:17
  • @Juho: Thanks anyway, but I already amended my answer. And no, expecting someone to look for a comment on the question that was the same as on the answer that drew the notification is … not particularly going to work. – Nathan Tuggy I Jan 15 '15 at 09:26
  • @RickyDemer As far as I know a comment I make is seen by everyone, as is the time it was posted. – Juho Jan 15 '15 at 10:23
  • @Juho: Sure, I get that, and I leave comments much like that all the time myself. Just that this one wasn't helpful except, as it were, by accident. – Nathan Tuggy I Jan 15 '15 at 10:43
  • 1
    @RickyDemer By looking at the comment and the timestamp printed next to it. The timestamp can be somewhat vague (e.g., "yesterday", "two months ago") but the mouse-over text always gives the exact time. – David Richerby Jan 15 '15 at 10:49