Thank you for the video! I love quick little algorithm comparison showcases. A quick note: on my machine, my own version of the trial division algorithm (up to 1 million) took 12 seconds to run while printing the numbers and just over one second without printing the numbers. This is because system calls (which are required to print to the terminal) are around a thousand times (or more!) slower to run than typical math operations, depending on the language and environment. This also explains why the sieve and trial division algorithms took about the same time for the first million primes, they both spent most of the time printing instead of actually doing math. It's worth keeping this in mind for future comparisons. Again, thank you for the video; I would love to see more naive vs. advanced algorithm implementation comparisons!
Hi! Really glad to hear that you enjoyed the video😊 I’ve also tried the algorithm without printing and realised they were quicker, however I felt like it would be a little more visually interesting if the prime numbers were printed out in the video 😅
Hello, mathematician here. Your method is awesome, but you only need to check for divisors up to the floor of sqrt(p), what i mean is, if you wanna check if one thousand is prime, you only need to check if 1000 is divisible by the numbers 2 to 31 (square root of 1000). Hope this helps, this makes it a lot faster.
The algorithm explanation is genuinely super easy. Great job as always :D Also a quick question; if we use a faster compiling language than python will the time change be noticeable or same?
Thanks!🙏🏻 Yes the time difference if we use a faster language (e.g C/C++) should be noticeable! I just used python because it’s the language I am most familiar with 😁
I think, the main problem with faster algorithms here is results output. Most of the time this code would spend printing the results. If it is true, the way of working with i/o is more important (in terms of performance) than programming language choice
Yes, I actually did this a while back with 3 languages and this sieve. Nodejs, C++, and Python Also, a quick note, these tests were automated back to back, mixing the order. along with that I did not have each number printed into the console because printing, especially on Windows, is slow. On going to 1m, and averaged over 5 times, the times were: Python: 1797.4 ms Node: 149.8 ms (12x faster) C++: 46.7 ms (38.4x faster) then for 10m, again averaged over 5 times: Python: 23752.1 ms Node: 1214.1 ms (19.6x faster) C++: 699.8 ms (33.9x faster) Also, here are the peak ram usages going from the 1m run, then 10m run, were Python: 86.7 mb, 772.9 mb Node: 36.6 mb, 119.7 mb C++: 4.9 mb, 15.6 mb C++ is so much better here btw because I used bit arrays (std::vector), basically each number bool takes up a single bit in the array. (this is how the sieve works btw)
Question: Does the respective script exclude numbers ending in 0, 2, 4, 5, 6, 8? Because these are certainly not prime numbers. Where can I get the scripts?
Good catch, this was actually an oversight when I made the video. The trial division algorithm actually had the square root as the limit, I just forgot to explain it during the video. Hope that answers your question!
We be obtaining security keys used by big internet security firms with this one 🗣️🗣️🗣️🔥🔥🔥🔥💯💯💯
ok..
primes are in P
Thank you for the video! I love quick little algorithm comparison showcases. A quick note: on my machine, my own version of the trial division algorithm (up to 1 million) took 12 seconds to run while printing the numbers and just over one second without printing the numbers. This is because system calls (which are required to print to the terminal) are around a thousand times (or more!) slower to run than typical math operations, depending on the language and environment. This also explains why the sieve and trial division algorithms took about the same time for the first million primes, they both spent most of the time printing instead of actually doing math. It's worth keeping this in mind for future comparisons. Again, thank you for the video; I would love to see more naive vs. advanced algorithm implementation comparisons!
Hi! Really glad to hear that you enjoyed the video😊 I’ve also tried the algorithm without printing and realised they were quicker, however I felt like it would be a little more visually interesting if the prime numbers were printed out in the video 😅
Hello, mathematician here. Your method is awesome, but you only need to check for divisors up to the floor of sqrt(p), what i mean is, if you wanna check if one thousand is prime, you only need to check if 1000 is divisible by the numbers 2 to 31 (square root of 1000). Hope this helps, this makes it a lot faster.
If you check the code, this was already implemented, just not mentioned verbally
Thanks for the feedback! But yes I did implement this, just not for the first algorithm 😁
I mean I really would like to see more of the code, but other than that, it's very easy to understand
Thank you! I’ll keep that in mind 🙏🏻
Really good video, however the voice goes straight through me.
Thanks for the feedback! Very much appreciated 🙏🏻
Great video as always, i really enjoy watching your videos. Keep the great work up!
Thank you for your support!
The algorithm explanation is genuinely super easy. Great job as always :D
Also a quick question; if we use a faster compiling language than python will the time change be noticeable or same?
Thanks!🙏🏻 Yes the time difference if we use a faster language (e.g C/C++) should be noticeable! I just used python because it’s the language I am most familiar with 😁
@@MarshySyntax ah I see. Thanks for answering. Cause I am studying programming so these kinda videos and questions help :D
I think, the main problem with faster algorithms here is results output. Most of the time this code would spend printing the results. If it is true, the way of working with i/o is more important (in terms of performance) than programming language choice
It's probably around 10x the speed
Yes, I actually did this a while back with 3 languages and this sieve.
Nodejs, C++, and Python
Also, a quick note, these tests were automated back to back, mixing the order.
along with that I did not have each number printed into the console because printing, especially on Windows, is slow.
On going to 1m, and averaged over 5 times, the times were:
Python: 1797.4 ms
Node: 149.8 ms (12x faster)
C++: 46.7 ms (38.4x faster)
then for 10m, again averaged over 5 times:
Python: 23752.1 ms
Node: 1214.1 ms (19.6x faster)
C++: 699.8 ms (33.9x faster)
Also, here are the peak ram usages going from the 1m run, then 10m run, were
Python: 86.7 mb, 772.9 mb
Node: 36.6 mb, 119.7 mb
C++: 4.9 mb, 15.6 mb
C++ is so much better here btw because I used bit arrays (std::vector), basically each number bool takes up a single bit in the array. (this is how the sieve works btw)
it would be great if the voice was a little lower in pitch, but otherwise this is a great video!👍
Thank you for the feedback! 😁
underrated channed. this video is so good. Would you like to do more number algorithms showcase like this. I'd love to watch!
Thank you! ☺️
I thought this is a channel with a million subscribers, really high quality video ,l like it
Thank you! I try my best to make as good videos I can 😊
Nice video! I like your explanations because they are really simple and easy to understand!
Thank you!
Super easy to understand, would love to see more complex subjects
Thanks! I’ll try to keep them coming!
I was late but great video again
😆 Thank you as always!
The voice is paintful to listen to, but good video
Thank you for that feedback! 😊
@@MarshySyntax no problem
Question: Does the respective script exclude numbers ending in 0, 2, 4, 5, 6, 8? Because these are certainly not prime numbers. Where can I get the scripts?
Nope! It does not explicitly exclude those numbers. But when the script is run it’ll naturally figure out that these aren’t primes
@@MarshySyntax The script can be faster. It don't need time for checking 0, 2, 4, 5, 6, 8 if the number has millions of digits.
Hi, just a quick question for trial division algorithm why you had calculated square root as limit
Good catch, this was actually an oversight when I made the video. The trial division algorithm actually had the square root as the limit, I just forgot to explain it during the video. Hope that answers your question!
@@MarshySyntax Thanks for the solution!! Btw, very good video!!
Thank you!
wtf is this voice
Great content just change the voice
Thanks for the feedback!