**Lesson 1: Analytic solutions are the preferred ones.**

In the goats, wolves and lions case, as soon as we have deducted the importance of even and odd sums, we can obtain the solution within the blink of an eye, independent if the inital numbers are (17,55,6) or (1000017, 1000055, 1000006).

In finance, e.g., the Black-Scholes closed form solutions for options are certainly (within the Black Scholes world) to be preferred over binomial trees (other reasons why not to use trees are here ) or over finite elements numerical solutions. A more relevant example from finance: Pencil and paper work shows that Americal call options should not be exercised early when no discrete or continuous dividends occur. In this example, analysis removes the tedious work of treating American options.

**Lesson 1b: Caveat in the case of inverse problems.**

We have seen in the local volatility exanmple that analytic solutions for inverse problems may be dangerous in the presence of noisy data.

**Lesson 2: Brute force algorithms should be chosen carefully.**

We have presented two ways to solve the goats, wolves and lions problem by brute force: (1) either generate all possible meal sequences (leading to 3^77 words in the alphabet in the worst case) or (2) generate all possible states of animal populations (with 77^3 being an upper bound). Obviously (2) is the more efficient way.

Note that also Sascha's functional program implicitly contains both ways. It was essential for perfomance reasons to clean future states of forests from multiple identical states. This cleaning is possible due to the recombination of the meal trees.

In finance, we know that brute force American Monte Carlo (generate a new starting point of an MC simulation at every exercise date and every state then) leads to exploding computing times. Least squares Monte Carlo (the Longstaff -Schwartz style) is the preferred "soft brute force" algorithm.

**Lesson 3: Algorithms beat languages.**

Sascha and I obtained similar computation times around a second with his Wolfram code and my Fortran program and we would both have failed with algorithm (1) from Lesson 2. Of course, some languages are more equal than the others, but key are the underlying algoirthms.

**Lesson 4: Elegance produces enthusiasm.**

Nevertheless (and this is not an easy outing for a real Fortran programmer), Sascha's functional solution is much more elegant and readable than my Fortran DO loops and IF statements.

You don't have to be a programmer for using the UnRisk language and produce the results (values, risk figures) you need for a fit and proper risk management.