Slashdot Mirror
Which Math For Programmers?
An anonymous reader writes "It is no news that the greatest computer scientists and programmers are/were mathematicians. As a kid 'hacking' if-else programs, I was not aware of the importance of math in programming, but few years later, when I read Engines of Logic by Martin Davis I started becoming increasingly more convinced of this. Unfortunately, math doesn't return my love, and prefers me to struggle with it. Now, as the end of the semester approaches, I am faced with a dilemma: What math subject to choose next? I have two choices: 'Discreet structures with graph theory' (discrete math; proofs, sets, algorithms and graphs) on one side, and 'Selected math chapters' (math analysis; vectors, euclidean space, differentials) on the other. I'm scared of the second one because it's said to be harder. But contrary to my own opinion, one assistant told me that it would be more useful for a programmer compared to the first subject. Then again, he's not a programmer. That's why I turn to you for help, fellow slashdotters — any advice?"
If you're just worried about the programming (coding and maybe some design) side of things, then the math you need is going to be the math that applies to what you're coding (calculus for physics engines, algebra for accounting packages, statistics for reporting ,etc...).
On the other hand, if you think it will benefit you to know more about what underlies the code (it does me, but we may think in different ways), then I would say absolutely that you should take the Discrete. Computer Science is 95% applied Discrete Mathematics. Computer Science is also a lot of theory which, truth be told, tends to be very specialized in usage to developers unless they're going to the very low levels. After taking DM for my degree, I found that my code has improved, but I also admit that it is anecdotal.
As a programmer, I've found statistics to be another useful branch of mathematics. It can be more functional when collaborating with others to do number crunching and can having varying degrees of difficulty from drop-dead-easy to omgwtfbbq. Also, probability and statistics in general, are often incorporated in machine learning to make the computer handle non-deterministic problems; good for programming AIs and such. Personally, I always liked learning the 'harder' thing as that might expose my brain to concepts or ways of thinking that I wasn't already familiar with. But regardless, math isn't too bad if you take the time and effort to understand it.
Take the Discrete Math stuff first since you are just beginning to learn Computer Science and it will fit better with those courses. You should then take Numerical Analysis to totally break your concepts that computers are precise. Finally, take the classical Calculus & Differential Equations track just so you can take Partial Differential Equations, at which point the math will start becoming useful for real world Engineering problems.
Proofs, proofs, then more proofs.
Programming is all about isolating the smallest part of a problem and simplifying it out. Doing proofs is effectively the basis for programming.
Understanding trig and calc is handy for specific projects, but for every single program we write we have to be able to see the problem, to isolate components of the problem, and to simplify them.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Discrete maths are more useful because you can prove the operation of your program. The other crap is useful for you to write scientific applications, physics simulators, and clones of Quake-- in which case, you need to be able to understand your own complex logic flow to make sure your program is executing those complex mathematical computations correctly, on the correct data, with the correct output.
Support my political activism on Patreon.
[...] The second is going to give you practical skills in programming -- a wide array of practical skills. The first is most likely going to give you some automata theory for computers but unless you're going into theoretical research, the second is the obvious answer. Graphics and games are all vectors, the web is becoming even more so with new browser rendering technologies. Rendering is all euclidean space transposed onto a two dimensional plane (screen) using points (pixels). Differentials are huge in the vision and image processing world and again, in graphics. This is your obvious selection[...]
I couldn't disagree more. There is no "obvious selection," because the OP didn't mention what type of programming interests him. If you're going to specialize in graphics or scientific computing, yes, the analysis course would be helpful. However, I find that branch of mathematics completely useless for the programming work that I do.
In more systems-oriented programming (e.g., OS, compilers, networking, databases), a strong background in algorithms, data structures, and graph theory is absolutely essential. If you start moving into security and cryptography, you need to understand modern algreba topics like number theory and group theory; having a solid foundation in set theory is a prerequisite for any of those topics.
[...] although I challenge you to take both [emph. added]. Also, look for courses on classes that blur the lines between stats/math and computer science. Like courses on error correcting codes or computer language design and theory.
On this point, we agree.
I think you're confusing the art of programming with the engineering of software systems. The minds that are good at one are generally not good at the other, and training for one often comes at the expense of the other. Very few are good at both, though I have worked with such people. The former requires an intimate understanding of the science and mathematics underlying problems to be solved, whether they are actuarial algorithms for life insurance or physical engines for FPS video games. Physics and math are the foundation upon which the necessary intuitive, creative leaps can be made to solve problems in a robust, elegant manner. Turning the crank on an existing process isn't good enough. The latter is fundamentally systems engineering: identifying and quantifying assumptions, risks, and resource limits; chunking problems and deriving requirements; and lots and lots of bookkeeping and documentation. The bookkeeping and documentation parts are the kinds of things that many physicists and electrical engineers have to be cajoled and browbeaten into. Software engineering can seem very, very tedious to a creative mind. Now, which did the GP mean? I think the former. But I think you are talking about the latter, and you are both correct.
I can see the fnords!
It's quite shocking isn't it? And not just a "this code isn't very pretty" problem either, but the instability of the thing is remarkable.
Remarkable? Its legendary! ROOT has the dubious distinction of including the worst piece of programming I have ever seen. When adding some extract I/O objects in separate header files to a program, generating dictionaries etc. I suddenly had the linker complaining about duplicate symbols. After spending just over a day trying to figure out why and getting more and more confused I finally demonstrated that ADDING A COMMENT to the code fixed the problem!
Staggered that ROOT was somehow breaking the C++ standard in ways I had not even contemplated I spent another day tracking this down to an automatically named function which used the C preprocessor line number directive as the only variable part of its name. So, if you happened to have the classdef (IIRC) macro on the same line in two header files ROOT would generate identically named symbols. The result was that something as simple as adding or removing a comment could fix or cause a duplicate symbol problem!
Far, far worse than all that though was that when I submitted a nice bug report illustrating the problem and pointing out the macro which was at fault they claimed that this was NOT A BUG and did not need fixing! ARGH! I only ever use ROOT through the Python interface now since it shields you from so much of the pain....just not all of it unfortunately!