What Math do You Use?

e_lehman asks: "I've been associated with MIT's introductory 'Mathematics for Computer Science' course for a number of years. The course has emphasized different topics in different years: logical foundations, proofs, probability, combinatorics, etc. But this is at the whim of instructors. What mathematical topics should we be teaching to budding computer scientists? What mathematics do you actually use or need, working in the computer industry? Here are some candidates: boolean logic, graphs, number theory, combinatorics, proofs, set theory, relations and functions, approximation methods, solving recurrences, generating functions, analysis of state machines, asymptotic analysis, and addition of small integers."

Comments

Re:Analysis

[KDan]

- Rows (pardon me if this is not the correct english word, something like Sum[v=0,eternity] of 1/v!).

Series (and summation of series)?

Daniel

A couple of things...

[Anonymous Coward]

...I've studied relatively little theoretical computer science to date (but am meaning to work through Art one of these days -- maybe when volume 4 (?) comes out), but there are two things that I have found extremely useful to me:
-- Formal logic, so that I'm more used to judging e.g. that a function always returns, and properly, or
-- O( calculation, so I know how slow my worst-case scenarios are.
Hope this helps.

Maths I Use?

[nathanh]

Statistics. I strongly wish I had a deeper grasp of statistics in almost everything I do. Finite state automata and directed acyclic graphs may be all the rage in compsci, but if I compreheneded confidence intervals and probability distributions I'd do much better work than I currently do.

Re:Jobs aren't the whole story

[Gerry Gleason]

While the theoretical core of CS is not typically of day-to-day value in most industry jobs, a solid background in the fundamentals is part of what makes you a professional and more than a hacker finding things out by trial and error. You don't have to be able to prove things about computability with Turing machines, but you'd better understand the implications of this stuff in terms of what can be computed in a reasonable time (or at all). The bottom line is, it depends on the specifics of your work (job); if you stick to programming and development vs. doing more systems and network engineering jobs, you are going to use a different knowledge set. Of course, the broader your foundation knowledge, the better you will be at the "big picture" stuff, and the more you will be able to function as a system designer and architect.

So, yes, all the "discrete stuff", as you say, but I view these more as the basic tool box for a programmer, and most people who are cut out for this work will pick up what they need in this area without a lot of formal training. The main reason to go deeper with this area is for a better understanding of cryptology and related stuff, and if you are getting into the "guts" of runtimes and garbage collectors, a more formal understanding of these ideas will be important, but I would say that the "Formal Languages" sutff is more important to programming work.

We create new "languages" all the time in the course of our work, so knowing what can be recognized and parsed with regular expressions (and the equiv. finite state automatons) vs. context free grammers helps when trying to specify something that is consistent and unambiguous.

I would also say that the math core (18.01-03 in my day, calculus through differential equations) isn't really essential to much, but probablity and statistics is a lot more important. I would also say that I didn't get much in my formal training that covered the topics important to analysing systems performance. I'm talking about the areas relating to latency vs bandwidth and throughput.

In retrospect, the "Computational Structures" course (6.032 in my day, which became 6.003 after I took it but before I graduated) lost it's relevance very quickly, or maybe I just forgot what I learned in this course. This was before the emergence of RISC architectures, and there has been enormous change in these areas since then, and I expect this to continue and maybe even intesify in the near future, so I would put more emphasis on these areas. IMHO, one of the main reasons that a lot of interesting new architectures fail (e.g. the connection machine) is that we don't have the basic mental and programming tools to deal with non-vonneuman architectures. Well, this really goes way beyond anything you can address with a course of study, but it would help.

Re:Jobs aren't the whole story

[sql*kitten]

That said, logic, sets, graphs, relations, discrete algebra - the "discrete stuff" so to say, is both what I like best and what I think is central to CS

Algebra, set theory (including relational algebra and relational calculus), Boolean algebra, statistics, matrix operations, linear programming.

I've never had to use PDEs, Tensor stuff or even induction since graduating. Of course it depends what sort of programming you want to do. Systems programmers don't it, but an applications programmer in the engineering industry might well do.