SIMulation vs EMulation

This question came up in the context of another topic, and I immediately envisioned an excellent interview question:

Explain the difference between simulation and emulation

As someone who has written thousands of simulations, this is how I would answer that question…

SIMulation

Simulation is a closed system where the state “S” contains all relevant variables and their values, and S(i) describes those values at a specific iteration within the simulation.

S = { V0..Vk }

S(i) = {V0,i; V1,i; .. Vk,i}

Based on the variable values in S(i) and a system of rules A{R0… Rm}, the simulation calculates a new state, S(i+1).

In the simulation, we have a starting state, S(0) and an eventual end-state S(n), which is created after n iterations of the simulation.  We start with S(0) and apply the rules of A{} in order to obtain S(1), and this continues until we reach S(n).

So explicitly, a simulation requires feedback from the current state in order to create a subsequent state, given a specific set of variable values and a specific set of rules that operate on those values.

EMulation

Emulation is a simulation whose rules are copied from another system.

Given a set of rules that describe system B: {R0..Rm}, if system A is an emulation of B then it simply contains the same rules:

A = B = {R0..Rm}

Given any state S(i) and a set of rules A{}, if we apply those rules to the current state, we get a new state S(i+1):

S(i+1) = A{} -> S(i)

Given the same state S(i) and another set of rules B{}, if we apply the rules in B{} to the current state S(i), we get S'(i+1), which is an “alternate-reality copy” of S(i+1):

S'(i+1) = B{} -> S(i)

If two different sets of rules A{} and B{} applied to any possible state S(i) produce the same next state, then:

S'(i+1) = S(i+1)

And therefore:

A is an emulation of B or vice-versa.

The important detail is that both systems A and B are equivalent, but they might not be implemented the same way – for example, the rules of B might be implemented in hardware, while A might be a software emulation of B.

Comparison

Emulation is a specific simulation that answers the question: “how would some other specific system respond, given a state of S”.

Conversely, in a simulation, you can have a set of independent rules that aren’t tied to any other system – the simulation is simply answering the question: “what would happen, if…”

I’ve seen definitions of both simulation and emulation that tie to copying something from the real world, but I disagree.   For example, I could easily write a simulation of a 4D solid traversing 3D space, which is a completely hypothetical model that has no tie to the real world.

Likewise, if you copy the rules of some arbitrary simulation over to another system, then you’ve emulated the original simulation, with no ties to the real world – for example, you could emulate our clearly-contrived 4D solid simulation by copying its rules from a state diagram or a set of software commands to some other equivalent logical system – for example, the logical rules within a game simulation.

Which brings us to a final point:  Simulations (and by extension, emulations) can contain other simulations.  For example, you could have a simulation of a digital pet within a simulation of a digital world.  The state logic and iteration of the digital pet could be driven inside the world simulation, or it could be driven externally and simply rendered based on its current state.  If the digital pet is driven inside the world simulation, it could be driven within the code of the simulation (created at compile time), or it could be implemented as part of the logical rules of the world – for example, as a script or state machine that’s created using in-world tools during runtime.