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?"
This is the fundamental math for computer science. The other is useful for other subjects, some of which will need software... but if you want powerful fundamentals, it's in discrete structures.
and pretty much the only math I use on a daily basis (when writing code and designing software) is the discrete math. (I did take both classes when I was in school, and lots more besides) so, in my experience the first course would be much more useful.
In Soviet Russia jokes are formulaic and decidedly non-humorous.
if you don't have a good understanding of algebra and geometry, computer graphics coding is going to suck for you. You will not only find the work daunting, but your coworkers will be very frustrated with the duct tape work-arounds you will need to employ in order to compensate. My advice would be to work your butt off to grok both classes. It will only make your quality of work life more enjoyable later on. Trust me, math hated me as much as I hated it and I've had to go back and do it over.
boycott slashdot February 10th - 17th check out: altSlashdot.org
I'm not directly familiar with either course (and the one-word summaries are a bit limited for providing informed advice!) but it sounds to me like the first one would be generally useful and you should take it regardless of what programming you intend to do - it sounds like it covers sort of the "mathematical fundamentals of programming". The second sounds more like it's useful for certain *types* of programming - perhaps 3d or game programming. Unlikely to be terribly useful for writing database-backed web applications, for example.
The former will be really useful if you decide to work on database-related things. Not just "using SQL to get my work done" but actually crafting the internals of a database. Similarly useful for compilers - both of them have optimizers, and that's just one big graph traversal. Too big to do in a useful amount of time, so all kinds of heuristics are used for graph pruning. Go for it.
The latter is a good foundation for numerical analysis, a field occupied by a lot of engineers and fairly few CS type people. It's a nice differentiator (pardon the absurdly weak pun). You'd much, much rather try to find simulation work than, say, writing yet another inventory management application these days.
True not all fields require math, but just to answer the question. Yes, choose what you like:
If you want to do algorithms and language theory, you need discrete math, graph theory, etc.
If you want to do graphics and signal processing, you need calculus (also called math analysis), geometry and differential.
If you want to do human computer interface, you don't need math (or a brain).
If you want to kick ass, you need all the introductory math you put your hands on (advanced university level math is too theoretical though and only useful for quantum physics and math majors).
I 100% disagree with this post.
Almost *any* complex algorithmic task (programming) comes in the end, down to solving *some* graph theory problem. The first one most definitely sounds more useful to a programmer. This has applications in coming up with algorithms, understanding type systems, proving to some degree that your program works, understanding the logic involved in your program. Sets and graphs are about the most important structures you will ever come across in programming.
The latter is pretty much only useful for people building 3D tools, to which the former is also applicable.
I don't know about that - the CS degree I did (starting in '83) was in a Computer Science department that was opened in '67. While I think that was one of the first in the UK I don't think it was that exceptional.
This is actually quite simple. The trick is to recognize gains as soon as possible, while waiting as long as possible to write off losses. This is the motivation behind FASB's rule change at the beginning of April 2009 (at the kind...er, suggestion...of the large banks) that allowed any asset marked as "held to maturity" to be valued at whatever they want (so long as it doesn't exceed the maturity value). That means that if 50% of your loan portfolio is delinquent and has no chance of ever accruing, you can put a label on it that says you'll hold it to maturity, and you don't have to recognize a 50% loss in your loan portfolio until 30 years down the road (so long as you don't foreclose on the debtors, of course). By simply waiting on the foreclosures, you can make billions off of free money from the Fed discount window (heck, you can even borrow that money from the Fed at 0%, and loan it right back to the federal government at 3%!), and rake in billions in "profits" (and bonus payouts). And then when your bills come rolling in, it doesn't matter that you have no income and all your assets are worth less than a Pontiac Silverdome... you've already cashed in your stock options. As they say, patience is a virtue!
Then you've never sat down and thought about what it takes to make a 3D environment and get perspectives right.
Dude, if there's three kinds of people on earth that make terrible software engineers, they're mathematicians, physicists and electrical engineers.
While they may write incredibly smart and efficient computer programs that solve incredibly difficult problems, that doesn't make them good software engineers. The libraries and API's I've used that have the worst documentation, the worst programmning interfaces and the most convoluted and non-extendable architecture are invariably libraries and API's written by (and often for) mathematicians, physicists and electrical engineers. Common 'good software engineering practices' don't appear to apply to people from these fields, which isn't bad if they'd stick with solving the problem and prototyping a solution, then hand over their work to skilled software engineers that are qualified to turn it into good software. Using stuff like LAPACK, BLAS, CSparse, Matlab-type code etc is pure masochism for software engineers like myself.
Ontopic for the submitter:
Both sound useful to me, but many of the topics from the 'selected math chapters' are probably only interesting to get a basic understanding of what is what, and improve abstract thinking. If you're ever going to have to write software that does differential calculations or linear algebra all depends on the kind of problems you will work on. There's lots of stuff you don't need to know anything about applied mathematics like that for. Graph theory, data structures and algorithms on the other hand, are almost a fundamental part of any CS or software engineering education. While you can write quality software without any knowledge of linear algebra, I really doubt you'll be able to write quality software without knowledge of algorithms, complexity theory, graph algorithms and advanced data structures. They're the cornerstone of software that doesn't suck.
As a physicist turned software engineer I think you should take both math classes. Alternatively, take physics classes instead -- if you go far enough you will have to learn and apply almost all of those maths, plus others (linear algebra, series decomposition, approximation methods, and derivation skills, and general problem solving).
Religion is poison to rationality, and we lose sight of that at our own peril. -- Lurker2288
I'd also recommend taking a look at Ars Digita University's old Computer Science materials at http://aduni.org/.
The discrete math course has nice videos of the lectures, so it could be a nice way to augment whatever course someone takes live. Plus there are additional problems (some with answers). And the book for the course, being 10 years old, can be picked up for under $10.
http://www.aduni.org/courses/discrete/
Second this.
User interfaces are terrible because of attitudes like the GP has because, at the surface, they *seem* simple so many people ignore them thinking that they'll just "slap on an interface" at the end. However, if you ever try doing some user interface design, it is a nightmare of a problem. To add to the list of courses needed, I would also throw in (non-math) courses on psychology - specifically cognitive, social, and visual psychology.
I took both discrete structures and vector calculus classes.
I have used the discrete structures, graphs, algorithms far more than I ever use calculus. The only time I would have had a need to use 3d space mapped to a map (IE doing a map) there were plenty of examples for the specific task on the internet.
That isnt, in of itself, an excuse but for the rarity of the need it was useful.
I avoided video game programming because I realized that it is not a lot of "fun" it is mostly managing vectors and such, which is nice for those that want to do it, and I passed the classes required for it, but it simply was not for me.
If you don't vote, you don't matter, so don't waste your time telling me your opinion
Well, if he takes calculus and vectors he'll also learn how to find his own solutions to an array of problems, just different ones. The thing is that the kinds of problems that you can solve with one of them are invariable either impossible or intractable with the other. The questions he should ask himself are things like "what do I want to do with my life - games or crypto?" and "what is easier for me to do on the side later in professional life if it turns out I needed it after all?" and "can I do them both?" and "do I really need either of them?" Most programmers don't touch maths any more these days. Most programming is either monkey work where someone else did the maths for you or design work where you build complex systems out of pre-existant parts that already contain all the algorithms you'll ever need and probably more efficient than you could ever hope to implement them yourself.
P.S. Good courses dealing with vector calculus targeted at programmers will deal with tractability, precision, performance, data storage and other issues, and will learn you many a great lesson on doing for example matrix math efficiently, including the most important one: there are good matrix maths libraries out there, use them - people have devoted large chunks of time to small parts of them and you can't hope to outdo them. Avoid doing such low-level things yourself unless you genuinely have special needs.
Pharmacists arent Chemists
In the UK they are called that.
...the future crusty old bastards are already drinking the Kool-Aid.