What is the maths you really need in Data Science?
Highly debatable subject, especially because the job title “Data Scientist” is still fluid and it means different things to different people. Now, assume the term ‘Data’ fits everybody, the addition of ‘Scientist’ leads to a number of ideas about what a scientist is/should be and does/should do.
If we stick to the notion that a scientist investigates the unknown and contributes original and novel insights, then she needs a few more skills, maybe, in addition to the job specifications of the Data Analyst. So, yes, there’s a risk of being seen as the ‘jack of all trades’.
Let’s be non-parametric and skip questions like “does a Data Scientist need a PhD/MSc?” and let the data speak (my data — yours may differ, and that’s perfectly fine).
The list may grow as you touch upon more exotic subjects (Random Walks, Markov Chains, Boltzmann Machines…) but this is what I think I am using in my work, beyond the obvious grasp of statistics:
- Computational cost
- System Theory
- Signal analysis
- Design of Experiments
1. Computational Cost
Or perhaps ‘just’ evaluation of the algorithms in terms of performance against resources, typically memory, CPU time, etc. To do this you need to know basic algebra and specifically elementary combinatorics (sometimes under the umbrella of discrete mathematics). Basically you need to be able to count: go through the loops if there are any, and estimate the number of lines of code which will actually be executed. This is often difficult, so you estimate an ‘order of magnitude’ — Big O notation. So quite literally, you need to know your limits (yes, that’s calculus).
2. System Theory
This is perhaps a far shot. What I mean here is the ability to look at an algorithm as a ‘system’ you know nothing about. Why? Because it will soon become complex and/or deal with a large amount of data and/or with a number of variables (100 – 1,000 – 1M features?). So you will need to relate input parameters to outputs and do so in a systematic way, formalizing what your black box does, even if you do not know how. This is the situation not only in software engineering (e.g. black-box testing) but also in some ML algorithms like Random Forest and Neural Networks — nobody fully knows why some of these marvels work.
3. Signal Analysis
Or is it just about “functions”? As your ‘code’ is a system, you may want to see what it does (response) when you feed in some input (data and parameters). This is the typical situation of a regression, linear or not, but also when you deal with Neural Networks or Deep Learning. People have been switching from the sigmoid (early days) to more modern and efficient activation functions like ReLU. So you need to know your basics on functions and more generally what a graphed function is telling you.
4. Design of Experiments
To do the above, you need Design of Experiments (DOE) to design a suitable set of “experiments” to test your hypothesis. You may ask questions like “how many experiments do I need to run with parameter x1 fixed and parameters x2…xk varying?” Or: “shall I change one element at a time, keeping all the rest constant?” (incidentally, you may find this is not the ideal thing to do). This is a statistically sound way of optimizing your tests, based on the fact that you have finite time and finite resources.
Is that all? I am not sure. And besides, these elements may not be used all at once in all of your work.
Finally, an open-ended question for you: do you have examples of other maths elements deployed in your analysis?