On 4/13/13 3:29 PM, Nicholas Thompson wrote:
Now that that is behind us, what did the message mean?
Iteration is a special case of recursion, namely tail recursion.
Specifically, Glen's description of memory in the behavior of an oil
filter can be handled by passing and returning an oil filter state
object to the recursive functions. It's true that with imperative
programming languages like C that it is all too easy to get memory
effects -- a progressively more dirty filter -- because in absence of
any extra thinking or effort, there's all of the heap memory that can be
mutated without any bulletproof mechanism to control its lifetime or
scope. Purely functional programming languages force use of control
mechanisms over scope and lifetime.
As for the question of what constitutes an explanation for dirty oil,
the engine or the absence of filtering, I'd say that's a topic not
related to iteration or recursion. There's nothing wrong with saying
that "The oil is clean because it is filtered," or "The oil becomes
dirty become of the activity of the engine," or in a deep-dive to a
first-principle physical explanation of oil fluid dynamics, combustion,
friction, etc.
One way to reason about these propositions is using types.
For example, in Haskell, types like..
type Oil = Either DirtyOil PrettyCleanOil
filterOil :: Oil -> FilterState -> (PrettyCleanOil,FilterState)
cycleEngine :: PrettyCleanOil -> Oil
..place constraints on how to put together a car. System-level
composition of these functions which fails to respect these types,
simply cannot be compiled, i.e. it's proven to be internally inconsistent.
It's also possible, using a dependently typed language like ATS or Agda
to define PrettyCleanOil in terms of values; it is possible for a
certain, type-constrained function (certain inputs together with a set
of operations) to be proven ahead of time as being able (or not) to
cause a transition from PrettyCleanOil to DirtyOil. For example, one
could imagine a program that iterated `cycleEngine' a million times as
compiling but a billion would not. The reason being that a physical
simulation could show that combustion and friction effects could at most
produce a maximum amount of oil-dirtying per cycle. A dependently-typed
program could, for example, force the modeler to include a maintenance
intervention in the simulation in order to replace the filter in order
to compile. In this way, a lot of needless simulation could be avoided.
Marcus
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
