# How often do you have to solve pure mathematical or algorithmical problems? [closed]

How often when you're programming do you find yourself having to solve a purely mathematical or algorithmical problem? I mean problems such as "Find the shortest path between two points in a graph", "What's the derivative of a given function?", "Find the greatest common denomitor", "Find the most optimal solution from a given search tree", "What's the maximum global value of a given function?", etc.

-

## closed as not constructive by Mark Trapp Oct 1 '11 at 8:58

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

Never! I am in developing a enterprise web application for the past 4+ years and have not crossed any point where I need to solve any pure mathematical problems

-

Not often enough. In fact, the more often you have to do that, the better your job is, I'd say.

-

Almost every single day. I work with scientists and engineers to commercialize their ideas. Being scientists and engineers, they think in numbers. Having to come up with all sorts of edge cases, test them out, and store that information in as compact a representation in a database is why I have a job. Then again, I'm also doing a lot of geospatial work. It comes with the territory.

-
show 1 more comment

A few times a year - but I'm developing scientific software! I can imagine that most programmers will absolutely never need to solve such problems. And even when you do, it's usually just applying some well-known approach to a specific problem rather than actually solving a novel problem.

-

Rarely, and because of the lack of this during work, I sometimes launch "home projects" to keep my brain satisfied. However usually after solving the problem, the project dies with it :(

-

Out of work: All the time. I compete at TopCoder, CodeForces and similar sites for fun. I also work on some small projects of my own that are by choice algorithmic.

At work: Simple stuff: Not infrequent. I often have to think about the complexity of my code when working with large `List`s or other large chunks of data. In rare occasions I have had to model the situation as a graph and formulate my approach accordingly. But in all cases, the problem is usually simple - it would just take a person not thinking about this algorithmically longer rather than being totally stuck. Just the other day, I convinced my boss to change one of our database tables to avoid having to store all O(n^2) relationships between some entities.

Harder Stuff: Never. I've never had to use something like FFT or flow algorithms at work, but then again I work on simple CRUD apps most of the time.

Edit:

At the end of the day, it all comes down to what kind of work you do. I have friends who work in game development and they have to face all sorts of hard computationally intensive problems. OTOH, a lot of my friends and colleagues (and myself) work on "enterprise" system and spend their time coming up with "business logic", which are little more than simple CRUDs and glue code that goes in between the framework/library and the database. A lot of the heavy lifting is actually done by the database and framework, leaving the programmer to simply design the way they fit together.

-

I like to write games in my spare time, and you need to do it a fair bit with games (at least, certain aspects - particularly graphics, physics and AI - require solving purely mathematical problems).

But in my day job, it's very rare.

-

Perhaps not in the spirit of the question, I'd argue "every day."

Every time I use an if statement, write a loop, or (especially) design a "system" I am using math and logic. Any kind of optimization effort is an attempt at solving an algorithmic puzzle.

-
show 1 more comment

I work in commercial software, so, rarely. However, I will say this: knowing how to evaluate the performance of the simple algorithms you create on the fly can result in components that scale well without any particular effort. Knowing the difference between an algorithm that runs in O(n lg n) time vs. O(n^2) or even O(n!) (may Flying Spaghetti Monster have mercy on your soul) can do a lot to make sure you DON'T have algorithm-related problems that later need solving.

-

Very rarely....

This is actually one of those things which surprised me about programming. When studying Computer Science at uni, there was a lot of emphasis on maths. Like: we had to take some hardcore mathematics subjects, and we were told that programmers have to be very mathematically minded.

Now, almost a decade later, I have to say I could have gotten away with basic high school maths in almost all the work that I've done. There was only one gig (a CNC machine tool programming job) where "higher maths" came in handy. But for most everyday programming work, in most gigs, I've really needed nothing more than a basic feel for logic and algorithm design.

About the biggest issue that comes up on a regular basis is something like not using brute force iteration over a huge data set.

-

The last time I did run into this seriously I'm sorry to say I never actually figured out the solution. Years of web programming have, it seems, weakened me to the hard stuff. In my defence I was experimenting with 3D programming and basically it was lots of trigonometry, which I haven't studied for 15 years and then only worked with in two dimensions, and then lots of Quaternions which are very confusing indeed to use if you're not big on three ( four? ) dimensional geometry...

-

For standard enterprise or web development type apps it is very rare. In fact in the last 15 years of my professional development career the only time I can remember needing to was when developing an AutoCAD plugin that needed to do some serious maths.

-

At work: never (web development). The only problems I encounter are logic problems, which are straightforward enough once you get your head round them.

Outside of work, as with other answers, I start different projects to try out algorithms and so on.

-

Too few times. I would rather like my brain to stay in shape by doing any kind of math, but in database apps or such, that unfortunately never happens.

-

Much of my work is on something similar to CAD software, so I have to solve geometrical problems of varying complexity fairly frequently.

-

I work for a major backbone provider. Much, if not most of my work depends on analysing network data. To give a point of reference as to the scope, our network pushes about 23 petabytes of data per day, and that number keeps increasing. It has become clear that using statistical methods to find anomalies in the network has become increasingly more important as the sheer volume of data increases. It's to the point that I wish my math skills were better, and I'm looking at learning more so that I can better apply that knowledge.

-

These days, pretty much never - although the logical approach to problem solving is always applicable I never use any mathematics more complex than rearranging a simple (and I mean really, really simple like y = ax + b) and even that's rare.

That said even when I was working in an area that required maths skills (computer graphics) it was very much applying known algorithms. And even then, to be able to do that you only really need some basic knowledge of matrices and an appreciation of what various terms like 'normal', 'product' etc mean. Personally I think that's pretty basic stuff.

I suspect the number of people who really 'solve problems' with maths in their day-to-day jobs is tiny, it just isn't relevant in most business domains.

-

Almost never. I' working for embedded devices for 2 years, projects involving microcontroller coding. Sometimes I need to optimize my code to maintain performance level. But this doesn't involve mathematical/algorithmic solution.

-