Looking for examples where knowledge of discrete mathematics is helpful [closed]

Question

Inspired after watching Michael Feather's SCNA talk "Self-Education and the Craftsman", I am interested to hear about practical examples in software development where discrete mathematics have proved helpful.

Answer 1

Discrete math has touched every aspect of software development, as software development is based on computer science at its core.

http://en.wikipedia.org/wiki/Discrete_math

Read that link. You will see that there are numerous practical applications, although this wikipedia entry speaks mainly in theoretical terms.

Answer 2

Techniques I learned in my discrete math course from university helped me quite a bit with the Professor Layton games.

That counts as helpful... right?

There are a lot of real-life examples where map coloring algorithms are helpful, besides just for coloring maps. The question on my final exam had to do with traffic light programming on a six-way intersection.

Answer 3

As San Jacinto indicates, the fundamentals of programming are very much bound up in discrete mathematics. Moreover, 'discrete mathematics' is a very broad term. These things perhaps make it harder to pick out particular examples. I can come up with a handful, but there are many, many others.

Compiler implementation is a good source of examples: obviously there's automata / formal language theory in there; register allocation can be expressed in terms of graph colouring; the classic data flow analyses used in optimizing compilers can be expressed in terms of functions on lattice-like algebraic structures.

A simple example the use of directed graphs is in a build system that takes the dependencies involved in individual tasks by performing a topological sort. I suspect that if you tried to solve this problem without having the concept of a directed graph then you'd probably end up trying to track the dependencies all the way through the build with fiddly book-keeping code (and then finding that your handling of cyclic dependencies was less than elegant).

Clearly most programmers don't write their own optimizing compilers or build systems, so I'll pick an example from my own experience. There is a company that provides road data for satnav systems. They wanted automatic integrity checks on their data, one of which was that the network should all be connected up, i.e. it should be possible to get to anywhere from any starting point. Checking the data by trying to find routes between all pairs of positions would be impractical. However, it is possible to derive a directed graph from the road network data (in such a way as it encodes stuff like turning restrictions, etc) such that the problem is reduced to finding the strongly connected components of the graph - a standard graph-theoretic concept which is solved by an efficient algorithm.

Answer 4

I've been taking a course on software testing, and 3 of the lectures were dedicated to reviewing discrete mathematics, in relation to testing. Thinking about test plans in those terms seems to really help make testing more effective.

Understanding of set theory in particular is especially important for database development.

I'm sure there are numerous other applications, but those are two that come to mind here.

Answer 5

Just example of one of many many...

In build systems it's popular to use topological sorting of jobs to do.

By build system I mean any system where we have to manage jobs with dependency relation.

It can be compiling program, generating document, building building, organizing conference - so there is application in task management tools, collaboration tools etc.

Answer 6

I believe testing itself properly procedes from modus tollens, a concept of propositional logic (and hence discrete math), modus tollens being:

P=>Q. !Q, therefore !P.

If you plug in "If the feature is working properly, the test will pass" for P=>Q, and then take !Q as given ("the test did not pass"), then, if all these statements are factually correct, you have a valid, sound basis for returning the feature for a fix. By contrast, many, maybe most testers operate by the principle:

"If the program is working properly, the test will pass. The test passed, therefore the program is working properly."

This can be written as: P=>Q. Q, therefore P.

But this is the fallacy of "affirming the consequent" and does not show what the tester believes it shows. That is, they mistakenly believe that the feature has been "validated" and can be shipped. When Q is given, P may in fact either be true or it may be untrue for P=>Q, and this can be shown with a truth table.

Modus tollens is core to Karl Popper's notion of science as falsification, and testing should proceed in much the same way. We're attempting to falsify the claim that the feature always works under every explicit and implicit circumstance, rather than attempting to verify that it works in the narrow sense that it can work in some proscribed way.