Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don't really agree.

There are a number of things that "computer science" can be:

- The study of algorithms. Mathy.

- Numerical analysis. Mathy.

- Compilers, computational reasoning, automated proofs. Mathy.

- Data mining and AI. Mathy.

- Systems, especially performance testing. Needs some statistics, but it's not hardcore math. No more than psychology or economics.

- Systems architecture. Not at all mathy. More like the biology of computer systems.

- Best practices. Software engineering. Not really mathy. Not really science either.

- OOP. Theology?

Of course, if you are good at math, then the most mathematical parts of computer science may be the ones that catch your eye. So you equate computer science with math + a bit of fluff. But there are things to study that aren't just math, even in the field of computer science.



"the study of algorithms"

Well, can do what Knuth did in TACP. There he did a lot with combinatorial formulas. To make much more progress, will have to get serious about math. E.g., the leading question in algorithms is just P versus NP, and that is now darned serious math. Don't attack that or even parts of it without a good background in math.

Other new and challenging questions in algorithms promise to need math for progress.

As I look at algorithms in 'advanced computer science', commonly they want to treat optimization. Tilt! Optimization is a huge field from applied math, operations research, and electrical engineering. There is deterministic and stochastic optimal control, Kalman filtering, integer linear programming, and much more. It's darned good applied math, and the math background I outlined is needed.

"numerical analysis"

That's a field of applied math. E.g., quickly get into advanced parts of matrix theory. E.g., consider R. Horn's books. E.g., quasi Newton quickly becomes an exercise in matrix norm theory. Long one of the more important tools in numerical analysis has been functional analysis. Likely the leading reason to pursue numerical analysis is just to get solutions to partial differential equations, and don't go there without a good background in math and likely the corresponding mathematical physics.

"compilers, computational reasoning, automated proofs"

For the last two, they are just fields of applied math.

"Data mining and AI"

The way computer science pursues these two, they are nonsense fields. The first should be just mathematical statistics, and for that the background I gave in probability is crucial. E.g., will want to know sufficient statistics, and that is based on the Radon-Nikodym theorem, and that is graduate pure math.

For AI, if someone can write a computer program that really has 'intelligence', fine. If all they use are intuitive ideas, good for them. But so far, the field of AI is very far from this goal in spite of decades of DARPA funding.

For now, if want a system that solves a problem well enough to look 'intelligent', then just engineer the system with the usual role for applied math. I gave a paper at an AAAI IAAI conference with the "25 best applications of AI in the world", and the best applications, really, were just good engineering.

"Systems, especially performance testing. Needs some statistics, but it's not hardcore math. No more than psychology or economics."

For some simple applications, yes, can just borrow statistics from the social sciences.

But for progress, it's back to "hardcore math": E.g., I published a paper on 'performance monitoring', that is, zero day anomaly detection in server farms and networks, and the math was based on some of the more advanced parts of the texts I listed. Basically I found a collection of multivariate, distribution free hypothesis tests. The social sciences have been using univariate distribution free hypothesis tests for over 60 years; my work was apparently the first good progress to multivariate distribution free tests. Multivariate tests are just crucial for analyzing performance data. I used a finite group (from abstract algebra) of measure preserving transformations something like in ergodic theory. My work was similar to some of what Diaconis at Stanford has done with exchangeability in distribution free statistics. This material needs all the background I outlined and more.

"Systems architecture"

For the future, before we build a large system, we will want the 'architecture' to have some known properties. We do this for bridges, buildings, dams, ships, airplanes, etc. So, we will want to do it for systems. We will want to know about reliability and security, at least. And we may want to 'optimize', that is, get what we need at minimum price.

E.g., consider part of the core of the Internet: Suppose we are given nodes and flows at the nodes. Then our mission, should we decide to accept it, is to connect the nodes at minimum cost to provide desired capacity, performance, and reliability.

Dean of Engineering at MIT T. Magnanti gave a Goldman lecture at Johns Hopkins on this problem; first-cut it's a super tough problem in integer linear programming. Actually, it was such problems in network design, and integer linear programming, that got Bell Labs going on the work that resulted in

Michael R. Garey and David S. Johnson, 'Computers and Intractability: A Guide to the Theory of NP-Completeness', ISBN 0-7167-1045-5, W. H. Freeman, San Francisco, 1979.

which is one of the key books early in the problem P versus NP.

It is common now to throw together a system, have various intuitive approaches to parallelism and redundancy, and then get a problem and see the whole server farm go south. Recall that this is just what happened at Amazon a few weeks ago.

Maybe some people, say, in national security, finance, or air traffic control would like such things not to happen?

A common situation is parallelism that is not more reliable but worse: E.g., there was a parallel transaction processing system. The load balancing sent the next transaction to the least busy computer. Then one day, one of the computers got a little sick, started throwing all its work into the bit bucket, was not very busy, was getting nearly all the transactions, and, thus, killed the whole 'cluster'. Bummer.

Something similar happened with Google's e-mail servers.

Instead, we need some theory with some theorems and proofs that provide some guarantees that we are getting the performance and reliability we need. That work will be mathematical; without a good background in math, don't try. And, yes, likely the work will need probability such as I discussed.

"Best practices. Software engineering. Not really mathy. Not really science either."

Not really computer science research either.

"OOP. Theology?"

There have been some connections with category theory, but I'm reluctant to take those seriously.

Mostly OOP in practice is simple and works well for some simple things. Otherwise OOP is not well thought out. And long OOP was a 'theology'.

My old view of programming languages is that they should be designed so that they 'admit' some source code transformations that have some useful properties. E.g., suppose we have such a language with such properties and have two pieces of code. Can we use the transformations to check if the two pieces of code are equivalent? So, right, we will have 'equivalence classes' of code. Some of these will do better on processor time, main memory usage, exploitation of multiple cores, etc. than others. So, with some code and these transformations, we have an optimization problem: Transform the code to equivalent code with the 'resource' properties we need. Sounds like math to me.

"But there are things to study that aren't just math, even in the field of computer science."

The problems are from computer science. But the good solutions are necessarily applied math because our civilization knows no other way to proceed. This situation is much that same as in all fields that have been 'mathematized', especially theoretical physics.


I feel like you may be ignoring special functions, although you did mention NP completeness. The un-mathematized areas of CS make liberal use of intuitive formulations of feedback systems, and are more or less unassailable to analysis. Computer Engineering can tackle some of these, but there is a lot of pressure to swap these intuitively good solutions to worse, but more tractable ones.

CS can and has the taken head-on a large number of problems mathematics cannot handle. These are hard to sciencify, which is why the prominent direction of CS seems to instead be expressiveness. You can't take engineering out of computing, and CS seems to be yet another attempt at systems study.


Some progress can only be made using advanced math. But that doesn't mean that no progress can be made without advanced math. That said, I wouldn't recommend a PhD in computer science to anyone afraid of mathematics.

Either way, I think that more advanced math needs to be taught earlier. Otherwise you get big cargo cult disciples with their own re-invented wheels and funny terminology, and no interest in math from other fields. Economics in particular.


"But that doesn't mean that no progress can be made without advanced math."

Right. But, it's tough to make good progress on tough problems without the most powerful tools!

E.g., for AI, it needs a lot of 'non-math' ideas before it gets to some math, if it ever does.


We tell our 251 students that the class should be called "Some Theoretical Ideas for Computer Science." Last semester, the professor and six of eight TAs had math majors. We definitely don't disagree with you. You're barking up the wrong tree.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: