It's also good to keep in mind that there is nothing special about n.
Saying an algorithm is O(n) without defining n is a little misleading, even though it is traditionally taken to be the size of the input.
In the example with all the if statements, if we define n to be the number of if statements, then the algorithm is in fact O(n). But n is just a constant, so it's really O(1).
yea i got you now. on your example since arrayOfLengthN is just being compared then run time would always be constant unless n is being run by or evaluated by other method such as forEach. In other words compare instruction is O(1) regardless of how many are being chained.
In the example with all the if statements, if we define n to be > the number of if statements, then the algorithm is in fact O(n). > But n is just a constant, so it's really O(1).
Im guessing the author is talking about n as number of ifs thats how I was understanding it. Thats why he had to create a hash for a constant look up.
It's also good to keep in mind that there is nothing special about
n.Saying an algorithm is
O(n)without definingnis a little misleading, even though it is traditionally taken to be the size of the input.In the example with all the if statements, if we define
nto be the number of if statements, then the algorithm is in factO(n). Butnis just a constant, so it's really O(1).yea i got you now. on your example since
arrayOfLengthNis just being compared then run time would always be constant unlessnis being run by or evaluated by other method such asforEach. In other words compare instruction isO(1)regardless of how many are being chained.Im guessing the author is talking about
nas number ofifsthats how I was understanding it. Thats why he had to create a hash for a constant look up.Exactly, unless they're doing something with the input data that would scale with the input size.
gotcha. much love sir. thanks.