I was just wondering what Nixers thought of the relation between Math and Programming. The reason I ask this is because right now in my college life I am great at programming concepts and design. But am really struggling with pretty basic mathematical skills. (I never really exposed myself much to the maths in highschool, I kinda avoided it like the black plauge). Also I didn't really know where to post it, so if there is a better place to be please put it there. I felt that this question needed some Nixer input.

Programming is all about maths deep down the line.
Algorithms are part of maths, inference (recursion) is part of maths.
On a more general basis, algebra is used the most in programming.
Other aspects of maths can be used to solve your computing problems like physics engines and the likes.

I too have sometimes struggled with maths, but to be honest so far the only area it's really hit me is game programming, and I still do that so it's clearly not too much of an issue. This is from the viewpoint of a first year University student mind, I've no clue about the professional world.

"most" programming is based on algebra. and like calculus, knowing how to setup the equation is far more import than solving it. if you can setup the problem the computer will solve it. but you have to know enough maths to get everything setup... TLDR pretty important.

On a somewhat unrelated note, I'm interested to know if anyone here as much experience with Haskell? I did notice the python/perl/ruby section also surprisingly has haskell in it, but after a quick peek through I see that most topics are on python.

I'm certainly not familiar with it though and haven't written anything in it either, but I just started learning it (like beginner level) and I'm really liking it. And I think it has to do with what xero said sort of. Like because it's (100%?) pure in a fp sense, it's almost as if you layout the rules and the program figures out the rest as opposed to directly telling the program what to do like in imperative languages. But you have to be good with currying and the pure fp style and all that... which is probably why math-people like it? (I guess you can tell I'm not a programmer if that made no sense.)

I might also just be liking it because, as opposed to goPhir, math was my favourite subject in highschool, although that's the highest level at which I have pursued the discipline.

(30-11-2014, 10:15 AM)rwzy Wrote: On a somewhat unrelated note, I'm interested to know if anyone here as much experience with Haskell? I did notice the python/perl/ruby section also surprisingly has haskell in it, but after a quick peek through I see that most topics are on python.

I'm certainly not familiar with it though and haven't written anything in it either, but I just started learning it (like beginner level) and I'm really liking it. And I think it has to do with what xero said sort of. Like because it's (100%?) pure in a fp sense, it's almost as if you layout the rules and the program figures out the rest as opposed to directly telling the program what to do like in imperative languages. But you have to be good with currying and the pure fp style and all that... which is probably why math-people like it? (I guess you can tell I'm not a programmer if that made no sense.)

I might also just be liking it because, as opposed to goPhir, math was my favourite subject in highschool, although that's the highest level at which I have pursued the discipline.

I like Haskell and functional programming but there isn't that big of a niche to start a section here.

As a person suffering from dyscalculia, I think the importance of math in programming is severely overrated.

It really depends on what you are programming, I'm a University student and I've the best grades from my class in programming and also one of the worst students at math, I've failed at calculus.

Like @xero said, being able to setup the equation is more important, but if you know how to setup the equation, then you know the steps needed to solve the problem in the first place (you're just slower than a calculator/computer). So in that sense, math is important, at least up to college level algebra (university level for you Europeans).

I've worked in a few different areas of Software Engineering, and here I'll list roughly the amount of math needed in each. Keep in mind, this is based on my experience, so others may furnish different weights for the same areas:

* Web Development (Sites, "apps", APIs, etc): Rarely used math save for a few times where I needed to implement some GIS formulas into an API to validate GPS points and guess their distances, then write the tests that verified the formulas were implemented correctly.

* (Systems) Integration: Induction / inductive reasoning are really important when working in integration, because you have to be able to prove consistent behavior for many cases, especially for low-level integrations and those integrations that need to be able to expect variable input. This is mostly an issue in CRM and ERP integrations where you could end up with accounting data similar to quantities of work due to one of the applications having a bug that pulls from the wrong table because the original writer didn't account for latin-1 characters when the client bought the CRM system... (I'm still butthurt about that bug!)

* Embedded Development (GPS and WiFi devices): Most of the math I used here was simple arithmetic (for WiFi, IP address and latency related calculations), GPS devices required more algebra, trig, and geometry. The devices needed to be able to guess where they would end up given speed, angle of approach, current position, past position, etc. Interesting problems to solve, understanding how to apply various formulas helped out a lot.

All of that said, my coworkers in each of those areas had different ways of solving the same types of problems. Some of them used more math than me, others avoided math like the plague and still ended up with great production code. The phrase "There's more than one way to skin a cat" comes to mind.

There is definitely a mathy aspect in programming.

Take regular expressions as an example: they provide a way to interact with finite state machines.
Or the lambda calculus-it was a purely mathematical model and is now the second most important programming model
in the world (after the turing machine).

So there is definitely a mathematical background, however, this background is not needed to understand programming.
You can totally learn regular expression without knowing about the theory, or use haskell without really understanding
the theoretical foundation of the lambda calculus.

I can't do math for shit, and I'm good at programming. I don't think I could do something like 3D game programming though.

One mathematical thing that is important in programming is algorithm complexity.

You can pick it up intuitively though, it doesn't require lots of algebra and symbols like you think of "math" normally being:
* linear time if the program just works through each element one at a time.
* quadratic time if it tests each thing against each other thing.
* exponential time if it's completely brute force.
and then 'log n' comes up when you deal with binary.

I think everyone who has been programming for a while has a good hands on understanding of these and how fast they are.

(19-04-2016, 09:21 AM)rain1 Wrote: ...
* exponential time if it's completely brute force.
...

Brute force does not mean exponential time. When you use a brute force algorithm, it just means you aren't taking advantage of the nature of the problem to avoid checking some solutions. For instance, a naive password cracking algorithm would be brute force; it would enumerate all possible passwords and check them one at a time. But that algorithm has linear complexity.

An example of exploiting the nature of the problem to avoid checking all solutions is binary search. Say you have a sorted list and want to know if the list contains a certain element. You can do this by brute force in O(n), linear, time by starting at the beginning of the list and checking each one. Or you can exploit the nature of a sorted list and use binary search, which runs in O(logn) time.

The takeaway is brute force has nothing to do with exponential time.

---

I agree with rain1, algorithms complexity is probably the most useful math to know when it comes to being a programmer. But often just knowledge of how to find the big-oh notation of your program isn't good enough. You need to know lots of ways to solve lots of different problems in order to fix your code when it's taking too long to run. So I'd propose data structures as being important math to know as a programmer.

The reason is that data structures tie heavily into the complexity and therefore the runtime of your program. One example I ran into recently is finding the longest common substring of two strings. If you take a brute force approach, you are stuck with an exponential time algorithm :( But it turns out there's a totally cool data structure that will reduce the complexity significantly. Store the strings in a suffix tree, and you get O(n) time and space once the tree is constructed. [1]

I mention this last because it could be specific to the domains I've been exposed to recently, but numerical analysis and probability are great tools to have in your toolbelt. Numerical analysis comes into play when you are curve fitting, for example. Being able to map the probability of events that apply to your problem at hand can guide you in the design of your solution. I may write some posts on this stuff :)


[1] https://www.cs.helsinki.fi/u/ukkonen/Suf...thFigs.pdf