**Temporal
Notation**

See also:

The
Mathematical Analysis,

What is time? We have developed the concept of time based upon our experience that things seem to change and dynamics seem to flow in one direction and not another. Underlying this phenomenon of change is the phenomenon of information and computation.

To be precise, I do not here imply the common uses of 'information' and 'computation'. See this glossary for the more general and metaphysical meanings of information and computation that I am implying here. However the common meanings do provide a useful analogy.

It is through successive iterations of a computational process
that information is transformed and is thereby experienced (by
virtual systems) as dynamical change within an empirical universe.
Hence *iteration* underlies *time* and there may be
successive computational processes within processes (to some
potentially large but finite nesting depth) that form cycles within
cycles (see __Cyclic
Computation__), so there are multiple nested temporal contexts
or worlds within worlds.

As a simple tangible example of nested temporal contexts, consider a VR game, which is running on a Java virtual machine, which is running on a Windows operating system, which is running on a virtual computer (such as VirtualBox), which is running on a Linux operating system, which is running on a virtual private server (VPS), which is running on a physical computer … I'll stop there to keep this example simple.

The processes operating in each of the those nested contexts are functioning within separate but related temporal contexts.

In our later analysis we will be dealing with large numbers of nested computational processes and information spaces, hence we will need a notation to keep track of which temporal context we are in and also within which context the units are expressed. We will also need a table of conversion factors between each of the time frames.

Hence this notation was developed to facilitate accurate analysis of nested temporal contexts and thereby facilitate the analysis and discussion of various issues that span multiple temporal contexts. This can be developed for and used within physical, computational, quantum mechanical and metaphysical contexts. Below I describe a particular set of nested contexts that are used in later quantum mechanical and metaphysical analyses.

Firstly I describe some notation for a set of nested contexts and then use this to generate a table of conversion equations, from any time frame to any time frame.

The first temporal context is *external time* **t**_{e}
defined within the context within which the __transcendent
process__ (TP) operates (i.e. **t**_{e} is
physical time for an electronic computer), this is the (e)context (e
for External). This time is required when considering a general
computer embedded “in the world”. In a metaphysical analysis the
TP does not exist within any *world* or if it does we cannot
directly know about it. This holds true for any perspective embedded
within an information space; it can only apprehend information that
flows within that space.

Next there is the *computational time* **t**_{c}
which is the number of computational moments within the transcendent
context (TC). This is the “time variable” with which we can
refer to particular computational moments.

Finally, **T**_{c} is the duration of one
computational moment and is
the computational frequency.

In the context of electronic computers is the duration of one computational moment expressed in terms of external seconds and is the CPU clock frequency. This quantifies the computational capacity that is provided by the TP.

In the context of our universe, at the quantum level, is
the Planck time 5.38x10^{-44} seconds and is
the Planck frequency 1.859x10^{43} Hertz. These correspond to
the duration of a single 'primitive' moment of classical existence
and the number of 'primitive' computational cycles within this
moment. This quantifies the computational capacity that is provided
by the quantum field.

Next there is the *program time* **t**_{0}
which is the number of primitive computational *iterations* of
the Simulator
or the number of primitive empirical moments or simulation steps,
this context is referred to as the (0)context. In the case of an SMN
based simulation, this is the number of matrix multiplications
performed.

is the period of one iteration expressed in terms of a number of computational moments and is expressed in external seconds.

are the initial TP and Simulator times. can be arbitrarily chosen and is the initial iteration number. Now one can express one time in terms of the other; and

Note: the following few paragraphs use some “finite discrete
notation”. It is not essential to understand this here, but for
details see __here__.

The smallest time step within the (0)context is .

Within metaphysical systems the Simulator iterations give rise to
cyclic phenomena that underlie the simple harmonic properties of the
quanta that permeate the empirical information space. So **t**_{0}
is related to the fundamental period (or frequency and energy) of the
empirical quanta.

Next there is the *space time* **t**_{n},
this is only required by the Cyclic
Computational Model used in relation to metaphysical analysis; it
represents the time within a computational context derived from
multiple primitive (0)cycles . This is referred to as the (n)context
and it contains **n** distinct (n)cycles or temporal contexts that
form an ordered sequence with .
Elsewhere
we see that the (n)contexts produces something remarkably like a
macroscopic relativistic space-time, which contains varying frequency
photons and particles that have mass and also velocity less than the
speed of light. In this way virtual phenomena with material
properties 'condense' out of the nested cyclic computations.

The smallest time step within the (n)context is

Each (n)cycle takes (n - 1)cycles to complete and is the period of one (n)cycle in terms of external time.

The fastest (n)cycle is in fact the underlying (0)cycle; the
primitive (0)context is considered separately however the two
contexts are unified at this point. The (0)context is the *ceiling*
or the vacuum of the relativistic space-time. The slowest (n)cycle is
the (**L**_{n})cycle, there can be no slower cycles
due to energy quantisation and quantisation
entropy, so the energy of the (**L**_{n})cycle
is equal to **dE**.

Next there is the *simulation time* (sim time) **t**_{s}
which is the time within the virtual universe, i.e. what we call the
physical universe. In this context time is measured in *seconds*,
this is referred to as the (s)context and it is the time within the
empirical context
(EC). The unit of seconds is defined by beings within the simulation
universe (e.g. ourselves), so the exact duration of a second can be
arbitrarily defined using any reliable standard; for example, the SI
unit of seconds as defined in 1967 was “the duration of
9,192,631,770 periods of the radiation corresponding to the
transitions between the two hyperfine levels of the ground state of
the cesium-133 atom”. This sounds quite arbitrary, but it gives us
a 24/60/60 quantisation scheme with which to break up our circadian
cycle into discrete units of seconds that have a particular numerical
relation to other fundamental constants. One may also define the
simulation time based upon the fundamental
properties of the cyclic computational process and it seems that
both the fundamental unit and our *arbitrary* unit are identical
(this is very intriguing). But for now the time 'units' are left
undefined.

**In summary**: we have (**t**_{e}, external
moment), (**t**_{c}, computational moment), (**t**_{0},
one iteration of the simulator), (**t**_{n}, one
(n)cycle) and (**t**_{s}, one iteration of the
simulation – i.e. one moment of virtual existence).

Let be the initial sim time, which can be arbitrarily chosen e.g. if one is simulating the growth of a city one may choose to begin the simulation on a particular date – one could choose the moment of the hypothetical “Big Bang”. Now we can express simulation time and program time in terms of each other; and .

Now that all the contexts have been defined their inter-relations can be considered. First assume that the initial external time is for simplicity. Then we'll insert some place-holding variables that represent actual but yet to be defined values.

We use a sub-script to indicate the temporal context that is being
converted and a super-script to indicate the context that we are
converting to. For example, sSuppose that it takes **t**_{e}**'**
external seconds to complete one primitive iteration, so .

Note: I will neglect **t**_{c} here for
simplicity because it is not needed in the later analysis (it has
been subsumed within **t**_{e}').

Suppose also that _{ }
is the period of one (0)cycle in terms of sim-seconds; this is also
the smallest measurable time period in sim-seconds, as measured or
inferred by the occupants within the simulation space.

For our physical universe **T**_{p} is the
Planck Time (5.38 x 10^{-44} sec); this is analogous to the
frame duration of a movie which is approximately **1 / 25 = 0.04**
seconds. So this physical universe has a very high temporal
resolution., with a frame rate of **R**_{t}** = 1
/ dt = 1 / t**_{p}** = 1.86 x 10**^{43}
frames per second.

Suppose also that is the period of the slowest (n)cycle. Each of these time variables may be expressed in terms of each other as shown in the following matrix.

Each of these above terms may be used to convert between temporal contexts. For example;

where ;
with this one can transform any time **t**^{( 0 )}
expressed in iterations into a time **t**^{( s )}
expressed in sim-seconds, simply by multiplying **t**^{( 0 )}
by .

And with
one can transform any time **t**^{( e )} expressed
in e-seconds into a time **t**^{( s )} expressed in
sim-seconds, and so forth.

Note that for any two contexts **r**
and **p**,
transforms
any **t**^{( r )} into the corresponding **t**^{(
p )}. These various quantities will come in handy later when
we come to analyse these contexts in detail.

The above calculations assume that the iteration or cycle period is constant, which is reasonable for finite state automata, which occur in the metaphysical analysis. However for the general case of varying iteration periods (which occurs when one utilises Energy Flow Processing or for general computing applications), if one wished to maintain detailed synchronisation between an internally simulated model and an external system then the varying computational load of each iteration must be taken into account. In SMN this is relatively simple. From above we have for constant periods. However if the computational load for each iteration varies then varies with each iteration so the simulation time step must also vary with each iteration in order to maintain synchronisation between the inner simulation model and the outer external environment.

In the case of energy flow processing in SMN the iteration doesn't process the entire matrix with each iteration. There is a list of state variables that have changed during the last iteration and only systems that take that state variable as an input need to be processed; the rest would not change even if they were processed so they are left as they are. So at the beginning of each iteration we take the list of changed states, from this we identify which systems need to be processed.

For example, say that only the nth state variable in the state
vector has changed, one then looks at the nth column of the matrix
and any systems with a non-zero interface element must be processed.
Say there are **m** non-zero elements so we know that we are to
process **m** systems. This involves **m** inner products of a
matrix row with the state vector. When very large matrices are being
used we also utilise *sparse matrix methods* so one also
determines the number of non-zero elements in each row that is to be
processed. Now we know the total number of non-zero elements involved
in this iteration and for each such element there is a uniform
computational process involving a simple multiplication of the matrix
element with a state vector element hence we have estimated the total
computational load of that iteration and
therefore we can adjust the simulation time step appropriately
and thereby maintain synchronisation.

One can also utilise a synchronisation signal in more complex cases such as Non-Linear SMN or when there are multiple levels of nested system matrices or for arbitrary computational simulations. This is a simple timing signal from the environment that the simulation program can use to determine whether the inner model and the outer system are synchronised.