Big-O Notation in 100 Seconds 

same

Keep this 100s project, it's amazing! 👏

That's how i feel if someone asks me if my code is efficient.

@@Fireship haha.. the best way to respond to a junior dev is senior saying he doesn't understand either

Same here

same here

99 sec.

@@mohanbarman5982 right

It is 100 seconds because it has O(n^2) with n=10 and a one second delay in the inner for loop since the bubble sort is executing on a Commodore 64.

Yeye. I basically learnt basic js without a course. All I did was watch fireship vids.

@@ACodingWoof wow that's amazing...

@@vaisakhkm783 yup ikr

Watching One hour fireship video >> Learning one semester

@@justwaterweight ==

I'm just asking here, but if you were to have code with the complexity of O(1/n), would that mean the program works less efficiently with fewer inputs than with greater? Also, I doubt it's pragmatic, but is it possible to have an algorithm with the complexity of O(1/n)

@@arhamaneeq3685 I think that O(1/n) is not possible since the number of computations grows as the size grows.. We might use memoization to store some recurring intermediate results in cache but even then, there is still slight addition to the computational time... Also, O(1) is the fastest time any possible computational operation can take... Having an algorithm that has a Big O of 1/n would mean that it's faster than O(1) which is an impossible task to achieve...

@@MsSuyash1995 maybe when quantum computing has general availability ;0)

@@MsSuyash1995 this seems kinda like O(1/n) to me: the problem: your inputs are an array, you are supposed to return an element from that array with index greater than 500. the algorithm to do it: pick a random element from the array. Check if it is at index 500 or greater. If it is, return in, otherwise, try again. Is this O(1/n) on average? Or given what you said about being faster than O(1), maybe it's O(1 + 1/n)?

@@mthf5839 No. Random number generation and array lookup based on index are both O(1) time complexity. Also this algorithm will loop forever for arrays shorter than 500, so there is no average time complexity. Getting the index of an array element based on its value is on average O(n) time. Also I don't get why you would bother getting an item from an array, when you could just check if the number is above 500 right after you generated it.

Nice! I'll have to check that out

He'd probably sum it up in less than 100 seconds, just saying lol

Awesome!

Because it's a real life application of the same thing.

And have you ever had to use Big O in you daily job? Ever?

@@winkbrace no not ever in 20+ years of programming, it just a tech interview question to weed out candidates

O(log n) one of the most efficient algorithms have it like quick sort. Others like merge sort or heap or tim sort (tim sort is used in javascript v8 engine used in node and chrome) have O(n log n)

@@lord12790 Sorry, quicksort is O(n log n) too in the average case, even O(n²) in the worst case. It is just preferred over the others because those have larger coefficients hidden in the O.

can you recommend others? I can't find more programming channels that cover angular/firebase , go fast enough and are not Indians (just don't like the hard to understand accents, I'm not native English) ...

Coding train, thenewboston cant think from the top of my head but this 2 r pretty good