When discussing large-scale economics or politics from a rational standpoint, the notion of "the world wants to ..." makes perfect sense. It's just the means to make better use of our physical and mathematical intuition to reason better.
Consider a claim such as "gravity is the force that makes local changes to the system in order to minimize its potential energy". Or, simply put, "water tends to find a way to get down there". We may call it a simplification, but it is nowhere near to being a "conspiracy of gravity", or "conspiracy of water". Moreover, we are happy to use such simplifications in everyday life, for educational purposes, to articulate our points better, and overall to have a higher-quality and more enjoyable conversations.
Now, since the notion of "the world wants to ..." can be plausibly established, and since technological progress does appear to be an inevitable part of our civilization for the past few millennia at least, we may well pose a simple question: does "the world" "want" to slow it down or to speed it up?
Well, if anything, what "the world" "wants" is extremely reactive. The lag between some innovation happening and between "the will of the world" beginning to make the appropriate adjustments can be dozens of years.
Therefore, for most people who are pro technological progress, "the world" would appear to be very conservative. Pretty much no new invention is just unanimously accepted. Rather, it's a slow and painful process, and the adoption of even the very best ideas generally lasts for generations; for a lot longer than what each individual human would take to internalize the value of certain invention. Besides cell phones and the printing press, penicillin comes to mind as a good example.
At the same time, there surely are people among us for whom "the world" appears to "want" innovations to be accepted too quickly. Even taking the abovementioned lag into consideration, progress does indeed happen, and, slowly as it moves on, this very process does make some people unhappy. Those people are the ones who believe "the world" would be better off if its default state would be to resist innovation even stronger than it presently does.
Still, the progress does happen, and we have to conclude that the force that is making it happen is continuously stronger than the force that is making it slow down. On this axis of being "pro accelerated progress" (rather "pro fewer barriers to progress", of course) and being "pro more force to slow down the progress", we could then define progressives, conservatives, and centrists.
It is temping to define centrists as the people who are about indifferent to whether we should strive for fewer or for more barriers to progress. But such a definition would be remarkably inaccurate because the distribution is extremely skewed.
It's a lot more plausible to define "centrists" in a more democratic way: as the median of the distribution.
And I would then be the first to argue that a modern "technology centrist" is a rather progressive person.
Moreover, since the acceleration of progress is generally assumed to be exponential, it is only reasonable to assume that the "median centrist" along this axis would become increasingly more pro progress.
To rephrase this statement: the person who is indifferent to whether we should put more or fewer barriers on the way of progress would fall into a percentile that is lower and lower.
On the one hand, it makes sense, as the derivative of an exponential function is also an exponential function. On the other hand, it sounds too optimistic to be true.
Consider a claim such as "gravity is the force that makes local changes to the system in order to minimize its potential energy". Or, simply put, "water tends to find a way to get down there". We may call it a simplification, but it is nowhere near to being a "conspiracy of gravity", or "conspiracy of water". Moreover, we are happy to use such simplifications in everyday life, for educational purposes, to articulate our points better, and overall to have a higher-quality and more enjoyable conversations.
Now, since the notion of "the world wants to ..." can be plausibly established, and since technological progress does appear to be an inevitable part of our civilization for the past few millennia at least, we may well pose a simple question: does "the world" "want" to slow it down or to speed it up?
Well, if anything, what "the world" "wants" is extremely reactive. The lag between some innovation happening and between "the will of the world" beginning to make the appropriate adjustments can be dozens of years.
Therefore, for most people who are pro technological progress, "the world" would appear to be very conservative. Pretty much no new invention is just unanimously accepted. Rather, it's a slow and painful process, and the adoption of even the very best ideas generally lasts for generations; for a lot longer than what each individual human would take to internalize the value of certain invention. Besides cell phones and the printing press, penicillin comes to mind as a good example.
At the same time, there surely are people among us for whom "the world" appears to "want" innovations to be accepted too quickly. Even taking the abovementioned lag into consideration, progress does indeed happen, and, slowly as it moves on, this very process does make some people unhappy. Those people are the ones who believe "the world" would be better off if its default state would be to resist innovation even stronger than it presently does.
Still, the progress does happen, and we have to conclude that the force that is making it happen is continuously stronger than the force that is making it slow down. On this axis of being "pro accelerated progress" (rather "pro fewer barriers to progress", of course) and being "pro more force to slow down the progress", we could then define progressives, conservatives, and centrists.
It is temping to define centrists as the people who are about indifferent to whether we should strive for fewer or for more barriers to progress. But such a definition would be remarkably inaccurate because the distribution is extremely skewed.
It's a lot more plausible to define "centrists" in a more democratic way: as the median of the distribution.
And I would then be the first to argue that a modern "technology centrist" is a rather progressive person.
Moreover, since the acceleration of progress is generally assumed to be exponential, it is only reasonable to assume that the "median centrist" along this axis would become increasingly more pro progress.
To rephrase this statement: the person who is indifferent to whether we should put more or fewer barriers on the way of progress would fall into a percentile that is lower and lower.
On the one hand, it makes sense, as the derivative of an exponential function is also an exponential function. On the other hand, it sounds too optimistic to be true.
How should I prepare for statistics questions for a data science interview?
A candidate who really impresses me would be knowledgeable in:
• Statistics: Confidence intervals, parameter estimation, p-value, hypothesis testing.
• Common metrics: Engagement / retention rate, conversion, similar products / duplicates matching, how to measure them.
• Useful cost functions: Log-loss, other entopy-based, DCG/NDCG, etc.
• Basic machine learning: Classification / regression / ranking problems, overfitting, convex optimization, trees, ensembles, boosting, collaborative filtering, etc.
• Tools: R / Python / Mathematica, Weka & similar. Code up something yourself would help too, Kaggle is very useful.
• Mathematics and complexities: Eigenvectors, singular values, PCA, LDA, Gibbs Sampling, Information Bottleneck et. al.
• Real-life numbers and intuition: Expected user behavior, reasonable ranges for user signup / retention rate, session length / count, registered / unregistered users, deep / top-level engagement, spam rate, complaint rate, ads efficiency.
A candidate who really impresses me would be knowledgeable in:
• Statistics: Confidence intervals, parameter estimation, p-value, hypothesis testing.
• Common metrics: Engagement / retention rate, conversion, similar products / duplicates matching, how to measure them.
• Useful cost functions: Log-loss, other entopy-based, DCG/NDCG, etc.
• Basic machine learning: Classification / regression / ranking problems, overfitting, convex optimization, trees, ensembles, boosting, collaborative filtering, etc.
• Tools: R / Python / Mathematica, Weka & similar. Code up something yourself would help too, Kaggle is very useful.
• Mathematics and complexities: Eigenvectors, singular values, PCA, LDA, Gibbs Sampling, Information Bottleneck et. al.
• Real-life numbers and intuition: Expected user behavior, reasonable ranges for user signup / retention rate, session length / count, registered / unregistered users, deep / top-level engagement, spam rate, complaint rate, ads efficiency.
My C++ code has a special index type, say,
It is easy to be confused with an index from a different universe, so instead of defining it as
A few extra casts here and there, but strong typing FTW, and it has already spared me from digging through tons of code to find a few nontrivial bugs.
Actually, the underlying type is
Now, the conversion from an object to its internal
In the unit test, the checks then are
And everything was perfect until a thought crossed my mind: hey, why
So I made the change. So that the test now is a "simple"
Except you know what? There are death tests, because some instances of
The death test used to be:
Guess what? The above line causes a compiler warning:
So, to suppress the warning, my code now reads
Actually, because we, engineers, copy-paste stuff -- hey, that's what unit tests are for! -- the code as of now actually is:
MyIndex.It is easy to be confused with an index from a different universe, so instead of defining it as
using MyIndex = size_t; the code is `enum class MyIndex : size_t {};A few extra casts here and there, but strong typing FTW, and it has already spared me from digging through tons of code to find a few nontrivial bugs.
Actually, the underlying type is
enum class MyIndex : size_t { Invalid = static_cast<size_t>(-1); }, but this bit is not important for the main story.Now, the conversion from an object to its internal
MyIndex used to be done via a member function: my_object.GetMyIndex().In the unit test, the checks then are
EXPECT_EQ(42u, static_cast<size_t>(my_object.GetMyIndex())).And everything was perfect until a thought crossed my mind: hey, why
.GetMyIndex() if it can just define operator MyIndex()? After all, it's a no-op, just a cast, so why not.So I made the change. So that the test now is a "simple"
EXPECT_EQ(42u, static_cast<size_t>(static_cast<MyIndex>(my_object)));.Except you know what? There are death tests, because some instances of
MyObject do not have the corresponding MyIndex-es.The death test used to be:
ASSERT_THROW(my_object.GetMyIndex(), IllegalGetMyIndexException). Now it is ASSERT_THROW(static_cast<MyIndex>(my_object), IllegalGetMyIndexException).Guess what? The above line causes a compiler warning:
unused result. Because googletest folks (and I've recently updated it) didn't take care of this weird case.So, to suppress the warning, my code now reads
ASSERT_THROW(static_cast<void>(static_cast<MyIndex>(my_object)), IllegalGetMyIndexException).Actually, because we, engineers, copy-paste stuff -- hey, that's what unit tests are for! -- the code as of now actually is:
ASSERT_THROW(static_cast<void>(static_cast<size_t>(static_cast<MyIndex>(my_object))), IllegalGetMyIndexException);Sometimes the price for only paying for what you use is extra verbosity.