Re: simulation as a causal/inferential "chimera"

To restate my response to Steve in more formal terms might be useful (or, might not). Here goes...

Let us begin with a modelling relation between some natural system NS and some formal (mathematical) model of it:

(NS) <==(encode/decode)==> F(a,b,x,y,z)

In this example, using an arbitrary abstract model, the description "F(a,b,x,y,z)" leaves it unclear as to what the roles and causal categories are of each of the arguments a,b,x,y,z, which would be more readily apparent in a concrete example of a model. For the sake of this discussion, let us use some more elaborate description to make the idea of structure-preserving in modelling relations, and the lack of it in simulations, a little more apparent. (For the following rewritings of functions into mappings I use the methods in Rosen's Theoretical Biology and Complexity, ch 3. sec.VIII.)

Let us stipulate that a,b are parameters and x,y,z are variables. F operates on those variables, and therefore takes the role of efficient cause. The role of parameters is in the category of formal cause. We can describe this relationship between function F and parameters a,b in the notation "F_ab".

Some of the variables may be of the environment, and some are of the system - which and how many of each will depend upon the particular system in question. Let us say that x,y are environment variables and z is a system variable; that is, as the environment of the system changes, as described by changes in x,y, there will be corresponding changes in the system, as described by changes in z, in accordance with the function F and the parameters a,b of F. (The variable z, then, is phenotype and the parameters are genotype.) In that case, we can rewrite the equation as:

F_ab: (x,y) --> (z)

So, we have somewhat clarified the roles of the various symbols as compared with the original description "F(a,b,x,y,z)". (We can also show the role of initial state in a state-based model as material cause by a further rewriting F_ab(x,y): (z₀) --> (z) but we will not need this for the discussion.)

Our modelling relation now appears as:

(NS) <==(encode/decode)==> [F_ab: (x,y) --> (z)]

Now, let us say we want to create a simulation of our formal model F_ab: (x,y) --> (z). This means that we are now going to employ a Turing machine (TM) as "hardware" which will process some "software", the latter into which our formal model will be mapped. A TM is simply a kind of formal processor, which we typically realize as a physical mechanical device, like a desktop computer. For our purposes, we only need to consider the formal apparatus. We shall designate this by T(s), where T is the Turing machine function and s is the software input - the tape - on which it operates. Clearly, in T(s), T is an efficient cause and s is a material cause.

Our next job is to create s, the software for the simulation. This means we must convert our formal model into software code; in other words, create a map C which puts the model F_ab: (x,y) --> (z) into a form suitable for processing by T, as some initial input to T:

C: [F_ab: (x,y) --> (z)] --> s₀

It is immediately evident that all the structure in the model that we took care to distinguish is now apparently lost. It appears that it has been collapsed entirely. But since s₀ is actually a set (that is, it is a finite set of discrete entries on the tape for the TM), we do have the possibility that, at least in some cases, we might be able to create some kind of auxiliary mapping which will tell us how to go from s₀ back to specific elements of our model, in such a way that we can resurrect the original structure of the relationships. However, we rarely, if ever, explicitly create such auxiliary mappings; rather, we typically rely upon mental or other inexact notes to recall what each subset of s₀ is supposed to be mapped to in the formal model. So, often, we do not know explicitly whether such auxiliary mappings are valid or even possible.

The end result is that the right-hand side of the modelling relation has become something quite different. We have gone from a structure-preserving model to a simulation:

[F_ab: (x,y) --> (z)] ~~> T(s)

where "~~> T(s)" signifies our turning the formal model into a simulation. But s₀, our software, is created by our mapping C. Therefore, we rewrite the above more completely as:

[F_ab: (x,y) --> (z)] ~~> T(C: [F_ab: (x,y) --> (z)] --> s₀)

So, we are now led to consider our central question: under what circumstances can T(C: [F_ab: (x,y) --> (z)] --> s₀) act as a substitute for [F_ab: (x,y) --> (z)]? That is, when can the simulation be a substitute for our formal model in a commuting modelling relation with our natural system NS? Strictly speaking, never. This is because instead of the original modelling relation:

(NS) <==(encode/decode)==> [F_ab: (x,y) --> (z)]

the tentative modelling relation would look like:

(NS) <==(encode?/decode?)==> T(C: [F_ab: (x,y) --> (z)] --> s₀)

But clearly, T, C, s₀, and the relationships they impose, are entirely extraneous, and have nothing to do with any entailment structures occurring in NS. Also, every causal structure in the model has now become a material cause of T. Therefore, a simulation of a model can never truly be in a modeling relation with the same system for which the model was intended.

As I said before, if we are careful, we can in some cases recover structure in the model that is lost in s. We need to keep track of the mapping C along with some auxiliary mapping to recover that structure. If we can do that, then we can at least use that recovered structure to verify that our simulation is being faithful to the structure of entailments in the model (and by extension, if the model is faithful to the NS, then we know the recovered structures in the simulation are faithful to the ones in the NS).

We can now ask: when will the recovery of these structures be even theoretically possible? First of all, we have to note that the structure, the entailment relations, are not converted by the mapping C directly into symbols on squares on the tape. Instead, the relations are converted into relations between symbols on the squares of the tape. And in a Turing machine the relationships established between squares on the tape are the predicative, algorithmic relations embodied by the function T. That is, the only kind of relation that C could possibly encode into s are predicative ones. Therefore, if the model has only predicative relations and C maps these relations to s carefully, then it is at least possible that they might be recovered, and it is at least possible that they might be faithful to the original system. (But this is a very different statement than saying that the simulation is in a modelling relation with the original system.)

On the other hand, if the model has impredicative relations, then C cannot map them to s, such that those relations are preserved, simply because the function T cannot perform such relations, and so cannot enact such relations between symbols on the tape squares. Therefore, in such cases our mappings C must employ an alternate strategy (i.e., map from an impredicative structure in the model to some predicative algorithm which at least exhibits the desired output behavior). This now means that our simulation no longer has a structure which is recoverable that will be faithful to the model's. (Because, just as breaking apart an impredicativity creates an infinitely long predicative sentence, it equally would take an infinitely long predicative sentence to map back to an impredicativity.)

Finally, as to the use of models versus simulations as a way to answer "why?" questions. If we ask why? of the model [F_ab: (x,y) --> (z)] we can get answers which should relate to corresponding answers for the NS of which it is a model. If we ask why? of the simulation [T(C: [F_ab: (x,y) --> (z)] --> s₀)] we can get no such useful answers. (Try asking "why z?" of both the model and the simulation to see the difference.) At best, if we can establish the auxiliary mapping then we might be able to answer why?, but effectively then we are asking why? of the recovered model, not of the simulation.

> >
> > I agree with you on this. Still, suppose we
> > successfully established a congruence between the
> > relationships among the observables of a plane and the
> > relationships among images in a software simulation.
> > We 're successfully encoding/decoding thus the MR
> > commutes. Clearly, this is possible - it's done all
> > the time in engineering.
>
>
> TG: Good question. I hope I have a good answer. :) This is where
> we have to
> be careful. Essentially, we can't directly establish a congruence of
> entailments between the object system and the simulation. This is
> because in
> the simulation, all the entailments are material cause (i.e., all
> inputs to
> the hardware), and so in mapping from the object system to the simulation,
> we are mapping both material and efficient causes of the object system to
> entirely material causes in the simulation. As Rosen says about this,
> "Nothing could more starkly illustrate the anomolous characer of
> simulation
> and the mischief that can arise through its confusion of causal
> categories."[LI 234]
>
> If we are very careful in writing our programs, and keep track of these
> mappings, then we can avoid any "mischief" and we can map back to
> the object
> system, unraveling the collapsed causal structure back to its original
> character. Often, though, once something is coded into a
> simulation, and it
> is indistinct as to causal categories, we can easily lose our
> ability to map
> back. The phrase "its all just software" can fool us into
> rewriting code in
> ways that destroy the original mappings. Also, in simulations the
> concern is
> often with the output values, so once the encoding of entailments is done,
> the focus is on the output values, and the correctness of the
> output values
> can appear as if they are a proxy for the correctness of the
> mappings back.
> But values are only one aspect of decoding, the other is the entailments.
> Hence, one concern with "mischief".
>
> Along these same lines, it is not only the distinct categories of
> the causal
> structure that is an issue, but the type of causal structure involved.
> Specifically, causal loops cannot map into predicative steps. Instead, we
> use algorithms which numerically (or otherwise) approximate the behavior
> resulting from those loops. But such algorithms, useful as they
> are, cannot
> map back to the causal loops in the object system. So there is no
> congruence of entailments in such a case.
>
> The notion of 'simulable model' (or 'computable model') avoids the
> "mischief" because it mandates that the predicative entailment of the
> hardware (i.e., at the read head of the Turing machine it
> realizes) must be
> congruent with some entailment in the object system. Therefore, the causal
> categories remain distinct rather than being coalesced into material cause
> as all software.
>
> Regards,
> Tim