"For CS students at college, they have to learn different types of Big-O notation (Big O, Big Theta, Big Omega)."
This is a false statement. Theta, Big Omega, Little Omega, Little O et al. are NOT types of Big O notation they are different types of notation used in the analysis of algorithms to estimate their complexity asymtotically. Big O is ONE such notation as is theta notation etc. Big O is a subset of asymtotic analysis not the set from which the other forms of notation are derived.
Also I think your article title is contradictory when you say "non-cs perspective", Big O notation is a mathematical concept that is at the heart of computer science.
Thats like saying we will discuss medieval history from a non-history perspective. You could have said non-technical or a web programmer's perspective or standpoint?
Applications of asymptotic analysis includes the use of a subset which is Big O notation in web and mobile development, however it dosen't mean all CS is supposed to be applied in one particular industry or else its not useful, which is the perspective that is being pit across to me.
Computability, complexity and algorithmic analysis techniques form part of CS theory, they ARE CS.
Automata theory for example, we can take FSMs and CFGs which aren't encountered too often in web development but along with Markov models is rampant in AI and robotics. We also get cellular automaton from computational complexity theory which can be applied to entirely different fields altogether not just CS.
Also you can't say 'software engineering technical interviews', since in embedded software engineering, space complexity is a real concern in those memory constraint systems. Maybe phrase it as 'web and mobile programming ("engineering") technical interviews?
Your understanding of Big O is confusing. Look at Big Omega, Little Omega, Big O, Little O and Theta and asymptotic analysis in general a little more.
I think it's great what you are doing, but when you say:
"But for the sake of software engineering technical interviews, all we care about is the best and worst case scenarios."
It seems to me you are saying that other stuff is not necessary which is not true, not to mention Big O measures asymtotic upper bounds since it bounds the growth of the running time from the top.
You need to understand all forms of asymtotic notation for understanding algorithmic complexity. Computation, computability and complexity are all important so you can have a much larger toolbox to understand what your algorithm is doing and perform analysis on it, the most used dosen't mean it is the best in all scenarios.
"CS students in college" learn all of these because not all of them end up being web or mobile developers, some of them end up writing embedded systems software, designing compilers and eventually into academic research positions or R and D in industry and need to analyse their algorithms from differing performance metrics. Even a web developer can benefit from analysing how their algorithm performs from varying standpoints not just upper bound.
Great article by the way and I think its great that programmers can learn this kind of stuff from such a great community!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This was a great read! Good work!
When you state:
"For CS students at college, they have to learn different types of Big-O notation (Big O, Big Theta, Big Omega)."
This is a false statement. Theta, Big Omega, Little Omega, Little O et al. are NOT types of Big O notation they are different types of notation used in the analysis of algorithms to estimate their complexity asymtotically. Big O is ONE such notation as is theta notation etc. Big O is a subset of asymtotic analysis not the set from which the other forms of notation are derived.
Also I think your article title is contradictory when you say "non-cs perspective", Big O notation is a mathematical concept that is at the heart of computer science.
Thats like saying we will discuss medieval history from a non-history perspective. You could have said non-technical or a web programmer's perspective or standpoint?
Applications of asymptotic analysis includes the use of a subset which is Big O notation in web and mobile development, however it dosen't mean all CS is supposed to be applied in one particular industry or else its not useful, which is the perspective that is being pit across to me.
Computability, complexity and algorithmic analysis techniques form part of CS theory, they ARE CS.
Automata theory for example, we can take FSMs and CFGs which aren't encountered too often in web development but along with Markov models is rampant in AI and robotics. We also get cellular automaton from computational complexity theory which can be applied to entirely different fields altogether not just CS.
Also you can't say 'software engineering technical interviews', since in embedded software engineering, space complexity is a real concern in those memory constraint systems. Maybe phrase it as 'web and mobile programming ("engineering") technical interviews?
Your understanding of Big O is confusing. Look at Big Omega, Little Omega, Big O, Little O and Theta and asymptotic analysis in general a little more.
I think it's great what you are doing, but when you say:
"But for the sake of software engineering technical interviews, all we care about is the best and worst case scenarios."
It seems to me you are saying that other stuff is not necessary which is not true, not to mention Big O measures asymtotic upper bounds since it bounds the growth of the running time from the top.
You need to understand all forms of asymtotic notation for understanding algorithmic complexity. Computation, computability and complexity are all important so you can have a much larger toolbox to understand what your algorithm is doing and perform analysis on it, the most used dosen't mean it is the best in all scenarios.
"CS students in college" learn all of these because not all of them end up being web or mobile developers, some of them end up writing embedded systems software, designing compilers and eventually into academic research positions or R and D in industry and need to analyse their algorithms from differing performance metrics. Even a web developer can benefit from analysing how their algorithm performs from varying standpoints not just upper bound.
Great article by the way and I think its great that programmers can learn this kind of stuff from such a great community!