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 te defined within the context within which the transcendent process (TP) operates (i.e. te 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 tc 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, Tc 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.859x1043 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 t0 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 t0 is related to the fundamental period (or frequency and energy) of the empirical quanta.
Next there is the space time tn, 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 (Ln)cycle, there can be no slower cycles due to energy quantisation and quantisation entropy, so the energy of the (Ln)cycle is equal to dE.
Next there is the simulation time (sim time) ts 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 (te, external moment), (tc, computational moment), (t0, one iteration of the simulator), (tn, one (n)cycle) and (ts, 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 te' external seconds to complete one primitive iteration, so .
Note: I will neglect tc here for simplicity because it is not needed in the later analysis (it has been subsumed within te').
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 Tp 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 Rt = 1 / dt = 1 / tp = 1.86 x 1043 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.