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