Great presentation. May seem a little basic at first to someone somewhat familiar with the topic, but everyone should appreciate how well he distills the concepts in such a short amount of time
Straight to the point. All in a nutshell. Thank you so much for clarity, briefness and of course precision and ease of grasping these concepts. Low Japanese bow of honor for you, my friend Ned
Great presentation. Big-O is an important topic and difficult to comprehend. I also read the Toxic experts' blog post. It is very well written. That is so true. Unfortunately, these toxic experts idealogy says, "either learn everything the way I know or do not even think about it." As long as they are commenting on your posts, "anonymously," we can say it is OK, and we can ignore them. However, sometimes they are in charge of your grades, or they are your manuscripts' reviewers. That is the sad part of the story.
A better way is to say how the speed of a process changes as the input size changes. Who said it only has to grow? For example, if your task was to quickly sort 1,048,576 numbers such as 3.1416, someone might say using an O(n^2) algorithm wont work in a reasonable amount of time, but that is not really true. For example, if you bust up those numbers into 1,024 groups of 1,024 numbers each, bubble sort each group, and then merge them together, you can get it to run in a reasonable amount of time. D&C (Divide and Conquer) is a wonderful thing. Not sure what the new big O would be but the runtime will for sure be MUCH better. Orders of magnitude better.
Python calculates a Hash for every element in the set. If by chance, the hashes for two elements are the same in the eyes of the hash algorithm, it takes longer to calculate them, because these "hash collisions" need to be resolved. And that takes O(N).
The word 'hash' (see "Hash_function" in Wikipedia) means that some numbers have the same hash. E.g., if you sum all digits of your birth date, you'll get a number. If I do the same with my birth date and get the same number, it will not mean that we were born the same day (it would be possible, but not for sure (an example of "hash collision") ).
if "..n is usually small" why the hell almost every company ask about it on the interview in addition asking to invert a binary tree, neglecting more important software engineering principles? :)
Nice talk. The part about small numbers though got me confused. If N is how much data you have, can you have less than 1. I think the N, the data or the iterations can be only non zero integers.
The graph there is a little confusing because the lines on it don't actually represent any real algorithms. An algorithm that does absolutely nothing is O(1), but runs in zero time. An algorithm that has one thousand consecutive copypasted lines of 'i++' is O(1), but does 1000 operations. On the other hand, an algorithm that takes a parameter "N" and then does 'i++' N times would be O(n), but only does N operations; this would make it run faster than the O(1) algorithm if your N is, say, 100 (as it would only perform 100 operations).
Great presentation. May seem a little basic at first to someone somewhat familiar with the topic, but everyone should appreciate how well he distills the concepts in such a short amount of time
Straight to the point. All in a nutshell. Thank you so much for clarity, briefness and of course precision and ease of grasping these concepts. Low Japanese bow of honor for you, my friend Ned
Great talk this made the concept a lot easier to understand, thanks !
one of the best presentations. thank you for such a nice talk.
I don't normally comment on RUclips videos but this is an excellent video. And I'm already familiar with big O too, he just says it so much better.
I love this presentation.
Really great talk Ned.
Really awesome presentation 👍 🐍
Great presentation. Big-O is an important topic and difficult to comprehend. I also read the Toxic experts' blog post. It is very well written. That is so true. Unfortunately, these toxic experts idealogy says, "either learn everything the way I know or do not even think about it." As long as they are commenting on your posts, "anonymously," we can say it is OK, and we can ignore them. However, sometimes they are in charge of your grades, or they are your manuscripts' reviewers. That is the sad part of the story.
Great presentation
Great talk
A better way is to say how the speed of a process changes as the input size changes. Who said it only has to grow? For example, if your task was to quickly sort 1,048,576 numbers such as 3.1416, someone might say using an O(n^2) algorithm wont work in a reasonable amount of time, but that is not really true. For example, if you bust up those numbers into 1,024 groups of 1,024 numbers each, bubble sort each group, and then merge them together, you can get it to run in a reasonable amount of time. D&C (Divide and Conquer) is a wonderful thing. Not sure what the new big O would be but the runtime will for sure be MUCH better. Orders of magnitude better.
13:16 does this mean we don’t care about accuracy? Why would we only look through half of the list? Thanks in advance.
Thank you! Could you please explain to me why 26:41 there is O(N) in the second example? Because we do multiplication and powering 2 to 61?
Python calculates a Hash for every element in the set. If by chance, the hashes for two elements are the same in the eyes of the hash algorithm, it takes longer to calculate them, because these "hash collisions" need to be resolved. And that takes O(N).
Great!
Why at 28:50 all the numbers i*(2**61-1) have the same hash. These numbers are different so should their hashes. I am a bit confused.
The word 'hash' (see "Hash_function" in Wikipedia) means that some numbers have the same hash. E.g., if you sum all digits of your birth date, you'll get a number. If I do the same with my birth date and get the same number, it will not mean that we were born the same day (it would be possible, but not for sure (an example of "hash collision") ).
Why is it O(N) when all the hashes are exactly the same ? @26:40
I couldn't find the slides if u could please drop the link to it
if "..n is usually small" why the hell almost every company ask about it on the interview in addition asking to invert a binary tree, neglecting more important software engineering principles? :)
Nice talk. The part about small numbers though got me confused. If N is how much data you have, can you have less than 1. I think the N, the data or the iterations can be only non zero integers.
The graph there is a little confusing because the lines on it don't actually represent any real algorithms. An algorithm that does absolutely nothing is O(1), but runs in zero time. An algorithm that has one thousand consecutive copypasted lines of 'i++' is O(1), but does 1000 operations. On the other hand, an algorithm that takes a parameter "N" and then does 'i++' N times would be O(n), but only does N operations; this would make it run faster than the O(1) algorithm if your N is, say, 100 (as it would only perform 100 operations).
pg was here (breadcrumbs)
Where are the slides?
You can look up in the description :)
Wow what brilliant insight 🙄