How much Math do you REALLY do in your job?

Solution 1:

I've spent the past twelve years as a professor. However, for five months last spring I spent part of a sabbatical working in the long-term forecasting group of an investment firm. I used a lot of math in those five months. (Admittedly, it was mostly a research-type position, and I gravitated toward the math-heavy problems.) Here are some problems I tackled on this job that required me to use math.

  1. We have huge gaps in our set of stock prices because countries change currencies or come into existence or cease to exist or stocks move in and out of major indexes or name your reason. We need to know how these stocks rise and fall (or don't) with each other. How do you calculate a covariance matrix in the presence of missing data? The best solution often results in the matrix becoming singular. This is a big problem because your model requires you to invert it. Do you try one of the other solutions to avoid the singular matrix problem and accept the resulting drawbacks, or do you try to "fix" your matrix somehow? If the latter, what are the best ways to do that? Answering this question required a great deal of understanding of (well, to be honest, learning about) numerical issues in linear algebra.

  2. We have a model that we're happy with that makes short-term predictions, and we have a model that we're happy with that makes long-term predictions. How about the medium term? How do we smooth our short-term predictions into our long-term predictions? To answer this question for us I had to, among other things, solve a couple of differential equations that resulted from trying variations on the logistic curve as models.

  3. Our model is giving weird, erratic results. Why? Does it have some fundamental economic flaw? It takes me a couple of days to determine that the answer to this one has to do with the eigenvalues of the covariance matrix at the core of the model. Linear algebra once again.
  4. I'm analyzing a set of economic indicators to determine their predictive value. Are they random walks of some sort, or do recent values have something to do with slightly less recent values? This requires time series analysis.
  5. The woman sitting next to me is having trouble with her linear regression. I can't remember now exactly what the difficulty was, but I needed some statistics to solve the problem for her.

The job wasn't all math; I spent more time coding than anything else. But I did use linear algebra, numerical methods, optimization, statistics, differential equations, and even some calculus on this job.

So don't give up hope yet. Maybe they are in the research arm of a company, or maybe they require an advanced degree, but there are some jobs out there that require a good deal of math.

Solution 2:

I've tried to put it into words, but I guess the following picture is much better (of course, please alter the text in your mind so that it fits the current context).

Calamities of Nature, strip 323.

Solution 3:

In my job as a (thus far) applied computer science researcher, I can sympathize with you in that I am not utilizing as much math directly from my courses into my job. Sure, I have to know some basic probability, but much of my job consists of reading research papers where most math consists of the standard operations along with some tricky, but not difficult, summations and integrals. I am a math major, but I could easily perform my research if I had never taken abstract algebra or real analysis. If I ever did need knowledge from abstract algebra, the fact that I took the class makes it much easier for me to "re-understand" concepts again.

But one thing that may be misleading is that, no matter what you major in, you're unlikely to use a significant fraction of whatever you study in your everyday job. In my opinion, it's far more likely that you've encountered a small topic in one course that you end up working on in depth, as deep knowledge of one subject trumps general breadth.

Regardless, I still take math courses as they are among my favorites. And the point of university isn't solely to provide preparation for specific jobs; that's why people do internships. Experience can also trump coursework.

Solution 4:

A bit of background first: my area is Computer Science, and I've been a student as well as a professional software engineer. As such, my answer is tailored to this profession. As a CS student I'd learnt a fair amount of mathematics : discrete maths, logic, plus the standard engineering stuff: ODE, PDE, Transforms, Operations Research. I've also picked up quite a bit of undergraduate pure maths by myself.

As a software engineer, the most mathematics I had to do was in the form of sanity checks and unit tests for my software. Arguably, the calculations hardly went beyond basic arithmetic, and sometimes involved a certain amount of algebra.No calculus, ODEs, Transforms, etc. Hardly have I "sat down to do maths"!

In the software industry, the core product development does take a substantial knowledge of relevant mathematics concepts, but the work of a typical engineer may not involve any of this. For example, one of my friends at a database firm told me that their core database team knew a great deal of logic and set theory , which is the maths that gets heavily used in databases. But the typical engineer was involved in the peripheral parts, e.g. designing the GUI, and this involved relatively little mathematics. A company is not necessarily interested in what amount of maths is used, but rather what brings in the maximum revenue.

Also, I've often encountered "maths heavy" (or otherwise arcane) software code wrapped up in easy-to-use programming libraries, e.g. image processing. In such a case, I'm the user , not the designer, and have to know relatively little maths. Such "packaging" saves the programmer from thorny implementation details and having to reinvent the wheel.

I totally agree with Peter Sheldrick's comment on your question. But it's important to point out that some of the benefits you gain by taking maths-heavy courses may be quite abstract. For example, almost every aspect of Software Engineering involves substantial abstraction( I dare say beyond algebraic geometry!) ; debugging is sometimes like finding an error in a proof. Mathematics courses encourage you to do both.

I also strongly recommend Keith Devlin's article on whether a software engineer needs maths, and suggest you ponder over this. HTH, and sorry for the long post!