# FAQ: Asymptotic Notation: Conceptual - Adding Runtimes

This community-built FAQ covers the “Adding Runtimes” exercise from the lesson “Asymptotic Notation: Conceptual”.

Paths and Courses
This exercise can be found in the following Codecademy content:

## FAQs on the exercise Adding Runtimes

There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.

If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.

## Join the Discussion. Help a fellow learner on their journey.

Agree with a comment or answer? Like () to up-vote the contribution!

Found a bug? Report it!

Have a question about your account or billing? Reach out to our customer support team!

None of the above? Find out where to ask other questions here!

I think this exercise should be update or something

``````Function that takes a positive integer N:
Set a variable i equal to 1
Loop until i is equal to N:
Print i
Increment i

Set a count variable to 0
Loop while N is not equal to 1:
Increment count
N = N/2
Return count
``````

because in python 3 if you do the second part of the function:

``````def function(n):
count = 0
while n != 1:
count += 1
n = n / 2
return print(count)

function(10)
``````

by setting n = 10 you will get stuck in a forever loop.
as in a previous lesson someone warned me about this, I should use “//” so it would return me a integer instead of a float number, making “n” to never become 1 and getting stuck in a endless loop

“However, when analyzing the runtime of a program, we only care about the slowest part of the program”

WHY?! That’s a pretty big thing to state without reasoning. If both parts of the function operate during a function call then they both add to the run time. why would we only care about the heavier part?

Big-O concerns itself with complexity and the prediction of worst case scenarios, or upper bound. The slowest part of the program is going to have to greatest time complexity. In this sense, it is not really time that we measure, but the number of operations. The same program will run in different times depending how powerful the computer is. Just because it appears fast, doesn’t necessarily mean it is not complex. That is where the upper bound is most telling.