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?"
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.
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!
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.
Pharmacists arent Chemists
In the UK they are called that.
...the future crusty old bastards are already drinking the Kool-Aid.