In ProgrammerMathSkills, it is lamented that many programmers lack training (or have forgotten all about it as part of the usual MindWipe that occurs shortly after graduation). This page, which contains some material ReFactored from that page, lists the math skills that programmers ought to have. Or so the collective we think....
Things suggested: Discussion below.
You do bring up a good point though; Perhaps this direction of discussion is more fruitful. I expect that a professional programmer would have an elementary understanding of the following areas of mathematics:
I am sure to have missed some points in haste. Comments are appreciated!
How about Boolean algebra and predicate logic? This is usually in the beginning CS/CE/EE curriculum and helps greatly when analysing and refactoring conditionals. Personally, I think the second list is more widely applicable than the first. I consider items in the first list knowledge required to solve particular domain problems rather than general programming problems.
The math skills I use every day are arithmetic, regular algebra, and Boolean algebra. The CS math skills I have used to fix bugs and solve performance issues are complexity analysis, simulation, and the ScientificMethod. For particular problems at specific jobs, I have had to dip into numerical analysis, trigonometry, and linear algebra. However, it was just as important in those cases that I know where to go to refresh my skills as it was to have those skills in the first place. -- IanOsgood
Let's not forget numerical analysis. After all, the floating point number system is not the real number system, but just an approximation. Sometimes programmers don't understand this, and sometimes their managers don't understand this.
Sure, the problems with floating point operation are well known, if not well understood by the average programmer. However, many programmers rarely use FP. Above, I mentioned numerical analysis (methods) as one of the special cases that needs more background.
For example, consider the quadratic equation ax^2 + bx + c = 0. I'll assume the discriminant is positive, so as to avoid any domain problems. The standard way to solve this (in pseudo-code) is:
discriminant := b*b - 4*a*c discr_root := sqrt(discriminant) r1 := (-b + discr_root) / (2*a) r2 := (-b - discr_root) / (2*a) return (r1, r2)This is not the correct method, because when b*b is much bigger than 4*a*c, discr_root is very close to abs(b), and the calculation of either r1 or r2 will result in catastrophic round-off error. (See ReadLikeMath)
However, some programmers for NASA in the 1980s tried to rewrite their quadratic solver to do it the correct way, but their managers refused to allow that. They remembered the quadratic formula from their high school days, and by G-d they would use it. Is this documented?
The correct method is, by the way:
discriminant := b*b - 4*a*c discr_root := sqrt(discriminant) factor := - b - sign(b)*discr_root r1 := factor / (2*a) r2 := (2*c) / factor return (r1, r2)This converts the nasty subtraction to a benign addition and division. -- EricJablow
And here I was despairing because my skills in such things as the LambdaCalculus, FirstOrderLogic, and other such and sundry are a bit weak...
In many schools, a math minor is made a computer science major requirement. Ironically, the same is not true of electrical engineering. I imagine this is done to pad the degree and bring in more money for the school. I can't say that it is to help the computer science student, as most math classes skip over (or barely touch) the things important to computer science like 3d graphics, set theory, automata, etc.
What's ironic about that? You can't understand the EE curriculum without some moderately serious math background. If you can't handle Fourier Transforms and Laplace Transforms, then you're not going to get an EE degree. Conversely, the areas of math that are essential to EE are rarely critical to most areas of CS, and vice-versa. An EE cares about finite state automata, but usually only trivial ones, he doesn't need to know about the equivalence with the Chomsky hierarchy of grammars.
That's for sure, yep yep, definitely agree.
Challenged:
Reasons to learn DifferentialCalculus?, IntegralCalculus?, and the OrdinaryDifferentialEquations? used to solve the ReynoldsTransportTheorem or any of its special cases (such as KirchoffsCurrentLaw?, KirchoffsVoltageLaw?, et cetera):
If you do programming for business, calculus comes up often for optimization, cost and margin analysis, queueing theory. Differential equations (part of calculus) also apply to many fields - physics, biology, chemistry as well as economics and business. Calculus is useful for some kinds of programming. There is such a thing as applied mathematics, not just pure mathematics.
[Most of these uses of DifferentialEquations? are special cases of the ReynoldsTransportTheorem. It is easier to learn these various differential equations if one is aware that they all follow the same pattern.]
Though GeneralSystems?, ControlTheory? concepts and patterns may help, there is no way you are going to learn DifferentialEquations without calculus.
Unless you're programming calculus, you're unlikely to need calculus to understand anything you're doing in programming.
That's like saying English is necessary because everyone should document. It's not hard to find reasons for every other subject, too. So, we all believe in a well-rounded education, and its future value, yes. Does that make it a core subject for programming? Certainly not.
You work for a telecom company (a not uncommon vocation for programmers). Your PointyHairedBoss wants you to write a program to help him manage prices and capacity. He has come up with a formula for 3 distinct demands for the company's service:
Weekends: Q1=a1-b1*P1 Holidays: Q2=a2-b2*P2 Nights: Q3=a3-b3*P3TC=j+k*Q where Q=Q1+Q2+Q3 and TC is TotalCost?, P is Price, Q is quantity of minutes demanded by subscribers. a,b,j,k are constants they determine by data mining. What formula will your program use for the button that says "Show Profit Maximizing Output" and the one that says "Show Profit Maximizing Price"? (He expects you to come up with that formula).
Domain Issue
Isn't this a domain issue? Different domains will require different math skills, some very few. Rather than try to load up on a bunch of different kinds of math when we are young and hope to remember it for a long time without use, some kind of JustInTime training would perhaps be more effective.
Most of this discussion seems to be missing the point. Math for programmers is like progressive weight training for athletes. Not every athlete is going to be a weight-lifter - virtually none of them are - and yet virtually all athletes do progressive weight training. Why? Because it gives them one component of a well-rounded athlete. Sport specific training is then added to this fundamentally sound basis.
Mathematics does the same thing for your mind. It gives you some knowledge, yes, but much more important is the skills that come with it. Analysis, abstraction, manipulation, attention to detail while retaining the whole picture, are all skills acquired and hone by doing mathematics.
But there are other ways and topics to expand one's mind. In my opinion, the best way to expand yourself is force yourself to do what you least like or are the least good at. For many geeks, this is improving social and diplomacy skills.
Maybe it's not the only way, but the best programmers I've worked with and for have all had strong mathematical backgrounds. I don't believe that to be one way. I believe that further study in mathematics will make you a better programmer, provided it's used as an enhancement of domain specific skills.
Perhaps, but what I find is that what the boss rewards and what personally impresses me of other's work often differs greatly. Perhaps we should make a distinction between personal enlightenment and keeping our wallets happy.
Moved from BadStuffWeLearnInSchool
Re: Math and science are overemphasized
Hey, if that was true I wouldn't have met so many incompetent programmers, you wouldn't complain so much about H1Bs and L1s (those seem to be on another level altogether than the average US born programmer) and >50% of graduate tech students being foreigners. Blaming it all on globalization when there are many more deep causes is handwaving. From my private perspective, the intelligent kids receive an utterly incompetent training in Math. Somebody with A's all over the place could not derive for me ln x, a year after getting A in calculus. I landed here in 2000, the then gov of California declared that the "strategic goal" to have all high-school graduates be able to write read and do basic math (mostly arithmetic, that is, because otherwise I already saw two shop attendants who had problems calculating in their head a 10% discount). To argue for further de-emphasizing of science and math is pure unadulterated idiocy.
Students are ignoring math because in the US, math does not pay. The high-end of the field has almost always been filled with foreigners because, first, it is more socially acceptable to be a math nerd in other countries, and second, it is easier for foreigners to learn math than other subjects due to language and cultural barriers. Thus, they gravitate that way, pushing down the US value of such a skill relative to other skills. If the US government wants more citizen math whizzes, it would probably have to subsidize the field to compete with these factors. Also, in the business domains, high-end math is not used that often at all. It is hard to know which domain one will end up in when in school. Business domains are probably growing faster than other domains due to offshoring of manufacturing and physical research. The laws of nature are constant across the globe, but the laws of business are not.
Some obvious comments:
My highly opinionated two cents...
I think the most important reason for programmers to learn (a least a bit more) mathematics is for a more general skill: reasoning skills.
We are bestowed with brains that work in some way. Never mind if they are always right or not: it is what we have, and what we are bound by. We have some intuitive notions of what makes sense and what doesn't, and we often find that we agree with others about what those things are.
Logic is simply an abstraction of our common and agreed ways of reasoning. It provides us with a way of formalising and communicating our intuitive reasoning. We don't know if it is absolutely reliable, but we have been using it a while now and it seems to serve well. If, someday, we find a part of logic that doesn't fit the real world very well, then we will probably dump it. Hence, I would say that logic is the science of human reasoning.
The way I look at mathematics is that it is an application of logic to things we can measure (or quantify, whatever). And it just so happens that a lot of real-world phenomena, and a lot of other things we would like to analyse, tend to be measurable. And a whole bunch of people have tried to formalise the things we commonly measure as different fields of mathematics.
So, which fields of maths you study depends on what real-world phenomena are important to you. For example, if you concern yourself with chance, then probability is dead handy. If you concern yourself with finding patterns and trends in seemingly random data, then statistics is worth a look. If you want to build things in the real world that involve taking up space (architecture, landscape design, all sorts) then geometry is a must-have. If you are interested in how changing one measurable thing can affect another measurable thing, the differential calculus is a lot of help. (Okay, I think you probably see my point.)
If you concern yourself with software development... well, I suppose it depends on what you are developing!
I am no great mathematician; in fact, I don't have any qualifications at all. But the above is how maths has helped me. So maybe it could help a bunch of other people too.
See also: WhatEveryDeveloperShouldKnow, http://steve-yegge.blogspot.com/2006/03/math-for-programmers.html