Explaining the Reverse-Time-Ordering of Light

 

Part 1 of 3: Introduction and Prerequisites of Digital Physics as demonstrated in introductory VB programming language

 

 

By Marty Wollner

 

mwollner@mi.rr.com

 

05-Jun-2016 (b)

 

 

 

 

(Light changing angles as it passes through transparent materials with different REFRACTIVE INDEXES)

 

 

 

HTML:

http://spikersystems.com/FlashNet_Pointer/www/projects/Martys_World/Quick_Explanation/Quick_Explanation_Digital_Light_Part1.htm

 

MSword:

http://spikersystems.com/FlashNet_Pointer/www/projects/Martys_World/Quick_Explanation/Quick_Explanation_Digital_Light_Part1.doc

 

 


 

 

 

Please note:

 

This explanation is NOT MAINSTREAM SCIENCE. However, it is 100% analytical, built upon the concept of an informational-based Universe that gets implemented by a very simple algorithm called the Theory Of Everything (T.O.E.). The explanation only requires simple integer arithmetic to understand. Several simple VB-code examples, charts and graphics are provided to help visualize the concepts. Actual VB-code snippets are provided for download and analysis.

 

Please be open-minded to these concepts, which are gaining more and more acceptance by mainstream science, every day. In any case, you can learn VB programming basics!!

 

Sanskrit leap:

 

 “Sanskrit” refers to the explanations of Virtual Reality (VR), Digital Physics, and finite automatons, for the un-informed. Even if you are familiar with these topics, first-time readers should continue on. For the brave,

 

Click HERE to leap directly to T.O.E. programming in VB.

 

 

 

 

 

 

 

 

 

16-Minute Prerequisite Mainstream-Science Background Video on the Physics of Light:

 

To help ease you into the physics elaborated upon in the 1-page abstract for this series of 3 papers, here is a YouTube video named:

 

Why is light slower in glass? – Sixty Symbols

16 minutes, 29 seconds

 

 

(Click HERE to see my comments to this video)

 

 

 

 

 

 


 

One-Page Abstract:

 

In this series of 3 papers, I will attempt to explain how light is optimized to take the fastest route from its emission to its absorption. This optimization is known in modern physics as the “Feynman path integral”.

 

A photon of light can potentially take many possible pathways on its route from emission to absorption, for example going through one or the other of two slits in a barrier in the infamous double-slit experiment. The selection of the actual route taken is optimized for the fastest completion time among all of the potential routes the light could take.

 

Therefore, the selection of the route that light actually takes occurs at the time of the absorption, after the decisions of potential pathways along the way have already been made!! We can thus conclude that light somehow operates in reverse-time-ordering.

 

In doing so, the operation of light appears to violate the principles of locality. Although this optimization is commonly observed in every-day life, the violation of locality is an unexplained mystery of mainstream science.

 

My NON-MAINSTREAM SCIENCE explanation for this mystery is:

 

  1. A very simple algorithm called the Theory Of Everything (T.O.E.) operates our Universe. The T.O.E. is based upon a finite-state-automaton.

 

  1. This optimization occurs whenever the light is presented with multiple pathways it can potentially take between the emission and the absorption.

 

  1. The reverse-time-ordering results from this optimization being performed at the time of absorption, as Feynman had surmised.

 

  1. The calculations for the optimization of photon routes occur “after the fact” in the sequential processing of light, in order to allow the Universe to deliver light in an optimal manner throughout the Universe. This allows the T.O.E. to “succeed”.

    The algorithmic processing of the optimization of light is graphically demonstrated in these papers.

 

  1. The algorithm works in the forward-only time-direction, by capturing a past-history of the potential pathways that photons can take, along the way, as they traverse their way towards the absorption target material.

 

What mainstream science calls “wave interference”, for example, in the infamous double-slit experiment, is NOT really interference at all! Instead, it is this optimization occurring for individual photons, when they are presented with the multiple pathways introduced in the experiment. The optimization patterns only LOOK like those calculated to be caused by wave-interference.

 


 

 

 

 

 

This page is left blank just to mess with you.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

 

Introduction:

 

 

I have a possible explanation for the way light operates in REVERSE-TIME-ORDERING. This explanation is NOT MAINSTREAM SCIENCE. However, it is 100% analytic, and the explanation will not require any math beyond simple integer arithmetic. The explanation is broken into three separate papers:

 

  1. Introduction and prerequisites of digital physics (this paper, 83 pages plus some lengthy appendixes)

 

  1. The digitized operation of light: The fish in the Ocean (graphically explains how the algorithm performs the optimization, 29 pages)

 

  1. Proof and consequences of the digitized operation of light (why the algorithm must operate such that we observe reverse-time ordering, a complete explanation for the observations of the double-slit experiment, and further implications, including a new meaning to the laws of conservation of matter and energy, 40 pages)

 

 

Most everyone can agree that:

 

 

 

 

 

 

 

This is all common knowledge and it all makes common sense. However, there is a lot about the common, every-day behavior of light that nobody in mainstream-science can explain. In fact, these behaviors are among the greatest unsolved mysteries of the Universe!!

 

 

 

 

 

Spear Fishing:

 

 

 

(A Sturgeon fish)

 

 

When you try spearing it, you need to aim a bit in-between yourself and the image of the fish you see on the surface of the water. Anyone who owns an aquarium knows why... the light is ANGLED when it hits the surface of the water.

 

But nobody knows how or why this happens!!

 

The 2nd paper in this series graphically describes this, as depicted in the following diagram:

 


 

 

20

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

EYE

19

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

18

A1

 

 

 

A2

 

 

 

A3

 

 

 

 

A4

 

 

 

 

A5

 

17

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

16

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

15

 

 

 

A6

 

 

 

A7

 

 

 

 

A8

 

 

 

 

A9

 

 

14

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

13

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

12

A10

 

 

 

A11

 

 

 

A12

 

 

 

 

A13

 

 

 

 

A14

 

11

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

10

S

S

S

S

S

S

S

S

S

S

S

S

S

S

S

S

S

S

S

S

9

 

W1

 

 

W2

 

 

 

 

W3

 

 

W4

 

 

W5

 

W6

 

 

8

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7

 

W7

 

W8

 

 

W9

 

W10

 

W11

 

 

W12

 

W13

 

 

W14

 

6

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5

W15

 

 

 

W16

 

 

 

 

W17

 

W18

 

 

W19

 

 

 

 

W20

4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3

 

 

 

W21

 

 

 

 

 

 

 

 

 

W22

 

 

 

 

W23

 

2

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1

W24

 

 

 

W25

 

 

 

 

FISH

 

 

 

 

W26

 

 

 

 

W27

 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

Legend:

 

 

 

 

 

 

 

 

 

Here is what transpires:

 

 

  1. The light from the FISH traverses through the water and then through the air on its way to the EYE.

 

  1. The straight-line pathway would break the surface of the water at location X = 15, Y = 10.

 

  1. But that’s not what happens in real life!! In real life, the light breaks the surface around location X = 12 or 13, Y = 10.

 

4.      It does so because it takes LONGER to traverse through water than through air. Somehow, the angle is optimized to provide the fastest route from the fish to your eyeball.

 

5.      Repeating myself again, nobody knows how or why this every-day observation happens.

 

 


 

 

So, what's the “great” mystery??:

 

 

 

 

 

 

 

The great unexplained mystery of physics is that this optimization means that the light must operate in reverse-time ordering.

 

Similarly, there are many other unexplained examples of reverse-time ordering observed in physics... the most famous is the DOUBLE-SLIT-EXPERIMENT, where light is being passed through a set of slits... how does opening up a second slit affect light ALREADY PASSED through the first slit??

 

 

 

Mainstream Science Explanation:

 

 

Nobody in mainstream science can explain exactly HOW this optimization happens, other than to assume that the light is somehow taking ALL possible pathways, concurrently, and then somehow selecting the optimal route ( resulting the fastest overall completion time) sometime before the absorption.

 

Here is a link to a paper that explains WHAT happens, in mainstream-science terminology. You don't need to understand the math! This is Feynman's explanation of SUM-OVER-HISTORIES. The explanation is based upon mathematics that has been refined over the past century. The mathematics assumes that discrete bits of matter move about an infinite continuum of space, over an infinite continuum of time.

 

Feynman allows for a route to be composed of several sub-pathways, each of which is given a “weight”. This is similar to determining the fastest route over various paths, like when you plan your daily commute to work... you take into account the speeds and distances for all of the possible paths. Then you “connect the dots” and pick the fastest route, which very well might not be the shortest by distance, for example, driving a few miles out of the way in order to get to an expressway.

 

In the case of light traversal, the speeds of the various pathways correlate to the density of the transparent materials being traversed... that’s what Feynman's “path weights” boil down to.

 

 

 

Unexplained questions:

 

  1. You can predict the fastest route to work because you already know what the path weights are expected to be, based upon prior knowledge of traffic flows. However, this begs to ask how does the Universe “already know” how to assign these path-weights as it is in the process of traversing through the transparent materials???

 

  1. This appears to violate the principles of locality and forward-time-ordering... does the Universe have prior knowledge of the “traffic flows” through the transparent materials?? If not, then how can it determine the optimal route to take???

 

  1. Of course the main question is, how does the Universe then optimize the pathway taken, at the time of the absorption, AFTER the light has somehow gone through and determined the weights of every potential path along the way???

 

  1. This is how light actually (and magically) operates, but nobody can explain WHY it is optimized for time vs. optimizing for distance between emission and absorption. Except for me.

 

 


 

 

My possible explanation for reverse-time ordering begins:

 

If we could explain this time-based optimization for one single photon, perhaps it will answer how light, in general works in reverse-time ordering. We will see below that what causes the optimization to take place are scenarios in which multiple possible pathways from the emission to the target are made available to the light for traversal!!

 

Next, since the double-slit experiment also behaves in reverse-time ordering when the second slit is opened... we ask could it possibly have something to do with the optimization that every INDIVIDUAL photon must process when multiple pathways are presented??

 

OF COURSE IT DOES!

 

The remainder of this set of documents attempts to do just that... explain how light really operates in reverse-time ordering by focusing upon the optimization of individual photons.

 

My explanation for the optimization of light is very simple, built upon my simple explanations for how the Universe operates. If you are already familiar with the work of Dr. John Conway and Dr. Stephen Wolfram, Digital Physics and Finite Automatons, then you already understand the basics.

 

I have a unique way of explaining how the Universe operates as an informational process, and it is very simple!

 

(The edge of the Universe)

 

 

Are you ready to dive in? My simple explanation of the Universe starts HERE…

 

 

 


 

How our DIGITAL Universe operates (in two pages):

 

 

Defining Matter, Space and Distance:

 

Let us start with a simple LIST OF INTEGER NUMBERS:

 

1) 2

2) 5

3) 7

 

We have just defined a 3-particle, one-dimensional DIGITAL UNIVERSE!

 

Each ENTRY in the list represents one PARTICLE. The numeric VALUE of each list entry functions as a POINTER the VIRTUAL LOCATION the particle is currently POSITIONED in.

 

We can VISUALIZE this Universe like this:

 

1-2-3-4-5-6-7-8-9---

--------------------

--1-----2---3-------

 

Particle #1 is positioned at location 2

Particle #2 is positioned at location 5

Particle #3 is positioned at location 7

 

Digital physics definitions we can derive from this tiny Universe:

 

  1. MATTER: The list of particles

 

  1. SPACE: The set of locations that particles can occupy

 

  1. OCCUPIED SPACE vs. EMPTY SPACE: If a particle is positioned at a given location, it is "Occupied", otherwise, it is "Empty"

 

  1. CO-OCCUPIED SPACE: When more than one particle is positioned at a location

 

  1. RELATIVE DISTANCE: The count of intervals between two locations is the relative distance; for example, particle 1 is "3 GRID LOCATIONS (GL)" away from particle 2, and 5 GL away from particle #3.

 

All that from a simple list of integer numbers! The list defines the STATIC STATE of this Universe at a given MOMENT IN TIME. Let us call the STATE of the Universe described in the list STATE_0:

 

STATE_0:

1) 2

2) 5

3) 7

 



THIS PAGE IS IMPORTANT!!!

 

Defining the Motion of Matter and Time:

 

By changing the value of any of these numbers, we change the location of the particles... we MOVE MATTER around from state to state!!!

 

SIMPLE INTEGER ARITHMETIC applied to the list of numbers accomplishes all of this. For example:

 

Algorithm #1: Add 1 to the odd numbered entries.

 

When we apply this set of instructions (known as an ALGORITHM) to the list of numbers, we get a new state (called STATE_1) for our simple 3-particle Universe:

 

STATE 1:

1) 3

2) 5

3) 8

 

(Particles 1 and 3 were "moved" one position to the right.) We can apply the algorithm to the list again, and come up with yet another state.

 

STATE 2:

1) 4

2) 5

3) 9

 

Here's what these state changes look like in our data visualization:

 

1-2-3-4-5-6-7-8-9---

 

--1-----2---3------- State 0

----1---2-----3----- State 1

------1-2-------3--- State 2

 

Can you visualize particles 1 and 3 hopping to the right in each STATE TRANSITION? This is Virtual Reality (VR) in is simplest form!!

 

Each state change is one application of the algorithm. And so, by continuously applying it in a successive series of applications, this is how the Universe implements the motion of matter through TIME!

 

This is how the Universe implements and tracks time... there is no “system clock”... the repeated, sequential execution of the algorithm itself provides the “tempo” of time!

 

 


 

 

 

 

The flow of time:

 

Please see the _Appendix_Elaborations_About_Time: (below)… to our conscious awareness, time seems to flow continuously, but really, it doesn’t… it skips from moment to moment as the algorithm transitions from state to state.

 

 

                                

 

(Big Ben ticking away, one discrete second at a time)

 

 

This appendix elaborates upon the creation of the Universe and our conscious perception of it, through a sequence of discrete moments of time. It categorizes our Universe as being a simple algorithm that has existed forever, and logically concludes that it must be able to run forever. In order for it to accomplish “running forever”, it must be COMPUTABLE!!

 

 


 

 

 

 

 

The bottom line goal of this paper is:

 

  1. The Universe is an algorithm called the Theory Of Everything (T.O.E.), and it must be able to run forever.

 

2.     We will design the T.O.E. starting from this one simple requirement of COMPUTABILITY. We will use the principles of Occum’s razor to do so… the simplest way to accomplish the functionality will be used.

 

3.     We will use this design to provide a live demo of the reverse-time operation of light, and it will graphically demonstrate how the “magical” optimization of individual photons works.

 

4.     It will further demonstrate scenarios where the optimization generates absorption patterns that resemble “wave interference”.

 

 

So, although this first of three papers is heavily focused upon PROGRAMMING, it will be very simple programming, in fact, you can learn VB programming just by reading it!

 

 

 

 


 

Designing the T.O.E. for NON-STOP COMPUTABILITY:

 

Our “Sanskrit leap” brings us here… we will now program the T.O.E. from scratch, and learn VB while doing so!!! REVIEW:

 

At a minimum, the algorithm is repeatedly manipulating a list of numbers, which emerges in our reality as matter moving through the passage of time.

 

That’s a good start for our T.O.E.:

 

 

Algorithm #1, rendition A:

 

 

While (True)

'' Repeat the algorithm for the age of the Universe

 

Call TOE  ''Apply the algorithm

   

End While '' Bottom of do forever

 

 

Note that this is actual Visual Basic code!! All code examples are available for download. Click HERE for an on-line directory of downloadable code modules.

 

The Universe must run forever. And that means that the algorithm must exhibit  "NON-STOP COMPUTABILITY", and I will explain this right now...

 

Let us assume that the algorithm needs to keep track of the number of state changes that have elapsed. A COUNTER is used for this purpose, and the T.O.E. can INCREMENT this counter every time it applies the algorithm. We will call this DATA STRUCTURE the Tick_Counter. We DECLARE this data structure with a VB dim statement, as follows:

 

 

Algorithm #1, rendition B:

 

 

Dim Tick_Counter As Integer    '' Declare the Tick_Counter

 

Sub Start_Universe()

 

Tick_Counter = 0         '' Initialize to zero

 

While (True)

'' Repeat the algorithm for the age of the Universe

 

Tick_Counter = Tick_Counter + 1   '' Increment the counter

 

Call TOE  ''Apply the algorithm

   

End While  '' bottom of do forever

 

End Sub

 

 

Note that I have enclosed the algorithm into a callable subroutine named Start_Universe.

 


 

 

Code for Algorithm #1, utilizing the Tick_Counter:

 

For our example 3-particle Universe, we'll need to DECLARE the data structures for the particle-list (like we did the Tick_Counter).

 

 

Algorithm #1, rendition C:

 

 

Dim Tick_Counter As Integer      '' Declare the Tick_Counter

Dim Particle_List(3) As Integer

'' Declare an array of integers to represent the list of particles

Dim PL_LOOP_Counter As Integer

'' Declare a counter used to process the particle list the Tick_Counter

 

Sub Start_Universe()

Call Init_TOE   ''One-time initialization

 

While (True)

'' Repeat the algorithm for the age of the Universe

Tick_Counter = Tick_Counter + 1   '' Increment the counter

 

Call TOE  ''Apply the algorithm

End While '' bottom of do forever

End Sub

 

 

Sub Init_TOE()

Tick_Counter = 0         '' Initialize to zero

 

Particle_List(1) = 2     '' Initialize to State_0 values

Particle_List(2) = 5

Particle_List(3) = 7

End Sub

 

 

Sub TOE ()

    Tick_Counter = Tick_Counter + 1  '' Increment the counter

 

    For PL_Loop_Counter = 1 To 3

    '' Loop through the list of particles

 

        If ((PL_Loop_Counter Mod 2) <> 0) Then

        '' if this is an odd numbered entry

 

            Particle_List(PL_Loop_Counter) = Particle_List(PL_Loop_Counter) + 1

            '' move it one location to the right

 

        End If  '' entry was odd

 

    Next PL_Loop_Counter  '' bottom of particle list loop

End Sub

 

 

Note: this algorithm can be copied into VB6 and it will run. You can download it and try it for yourself.

 

This algorithm will work to implement the functionality described in the visualization, BUT can it run forever?

 


 

 

Non-computable algorithms:

 

 

Obviously, if we just let this algorithm run forever, the Tick_Counter would get really, really big, and the locations of particles 1 and 3 would be very, very far from 0. If you execute the program, it will crash with an “Overflow Error”.

 

SO, IS THIS WHAT I MEAN WHEN I TALK ABOUT THE ALGORITHM BEING COMPUTABLE?? Yup.

 

If this really were a CGI video being rendered by a computer, could it display an infinite range of pixels? Even if the output weren't being displayed as a 2-d pixel image, even if just the simulacrum were allowed to be processed, could the computer process numbers that are infinitely large? Of course not... all computers deal with FINITE numbers. Limitations MUST BE applied to all of the computations being processed.

 

 

To demonstrate how attempting to violate these principles prevents the Universe from running forever, here's an example of a "NON-COMPUTABLE ALGORITHM":

 

 

Algorithm #2: Add 1 to the odd numbered entries; divide the even entries by the tick counter – 5;

 

BTW, this algorithm has multiple "rule sets" in it... the first "rule set" is "Add 1 to the odd numbered entries;" and the second is "divide the even entries by the tick counter – 5;”

 

 

 

 

 

Algorithm #2, rendition A:

 

 

Dim Tick_Counter As Integer      '' Declare the Tick_Counter

Dim Particle_List(3) As Integer

'' Declare an array of integers to represent the list of particles

Dim PL_LOOP_Counter As Integer

'' Declare a counter used to process the particle list the Tick_Counter

 

 

Sub Start_Universe()

 

    Call Init_TOE   ''One-time initialization

   

    While (True)

    '' Repeat the algorithm for the age of the Universe

        Tick_Counter = Tick_Counter + 1   '' Increment the counter

       

        Call TOE  ''Apply the algorithm

    End While '' bottom of do forever

End Sub

 

 

Sub Init_TOE()

 

    Tick_Counter = 0         '' Initialize to zero

   

    Particle_List(1) = 2     '' Initialize to State_0 values

    Particle_List(2) = 5

    Particle_List(3) = 7

End Sub

 

 

Sub TOE()

 

    For PL_LOOP_Counter = 1 To 3

    '' Loop through the list of particles

        If ((PL_LOOP_Counter Mod 2) <> 0) Then

        '' if this is an odd numbered entry

            Particle_List(PL_LOOP_Counter) = Particle_List(PL_LOOP_Counter) + 1

            '' apply the first rule set; move it one location to the right

        Else

        '' this is an even numbered entry

            Particle_List(PL_LOOP_Counter) = Particle_List(PL_LOOP_Counter) / (Tick_Counter - 5)

            '' apply the second rule set; divide by (Tick_Counter - 5)

        End If '' end else the entry was even

    Next PL_LOOP_Counter  '' bottom of particle list loop

End Sub

 

 

 

 

n the 5th tick of Universe time, the algorithm will try to divide by zero, and let us assume that the processor will hang forever whilst trying to compute this. Note that modern computers are designed to not explode or melt down when a divide by zero is attempted.

 

OK, so the computer might not melt down until hell freezes over, but the Tick_Counter will NEVER be incremented again... to the characters within the virtual reality, the Universe suddenly ceases. This is a bad thing.

 


 

 

THIS PAGE IS IMPORTANT!

 

Non-COMPUTABLE scenarios:

 

 

 

 

 

 

We could come up with an imaginary thought experiment to help explain the concept. Imagine that we have a computer of INFINITE CAPACITY and it also runs at INFINITELY FAST SPEED… any problem can be solved “instantly”. Theoretical computer experts call this imaginary device “THE ORACLE”.

 

In ALL of these scenarios, even if the Universe were being "processed" by the fastest computer possible… even if it was “The Oracle”, IT WILL STILL HANG FOREVER!!!

 

The 3rd paper in this series will explore the concepts of computability in more depth, including “the halting problem”, and how it applies to computable Universes. But by now, I hope everyone understands the basic idea of finite limits…this is a very important cornerstone of the design of the T.O.E.!

 

 

 

Finite-size, all-integer arithmetic is required:

 

So obviously, the values of any and all of the numbers being computed must be finite!!! Repeating myself (which I do a lot), infinity is impossible to compute, so the algorithm must take care to limit all of its computations to finite numbers, and since we are using all integers in our calculations, we can safely assume that the T.O.E. uses all finite integer arithmetic.

 

This can be likened to the WORD-SIZE of a computer, for example 16-bit computers can only process numbers 2**16 large... about 65,000. A 32 bit computer can process much larger numbers... 2**32, and 64-bit computers can process HUGE numbers, approaching the number of particles on Earth!!!

 

We will discuss the need for finite integer arithmetic further below, but for now, we need to make some modifications to our algorithm #2_A to assure it remains computable. Specifically, we need to limit the value of Loop_Counter and the number of locations in the Particle_List array to FINITE MAXIMUMS. And eliminating the possibility of division by zero is a good idea as well, ya think?

 

 

Algorithm #2. Rendition B:

Compare to previous version: Algorithm #2. Rendition A

 

 

Startup screen:

 

 

 

 

Instructions: Press the “Start the Universe” button.

 


 

 

'' Declarations section

 

Option Explicit

 

Const WordSize = 8

'' This defines the maximum size of the numbers processed by the algorithm as

'' 2 ** WordSize.

''

'' The entire algorithm is thus scaled by the range of numbers

'' that are considered to be COMPUTABLE.

Const TOE_Max_Tick = 2 ^ (WordSize - 2)

Const TOE_Max_Range = 2 ^ (WordSize - 4)

Const TOE_Count_PL = 2 ^ (WordSize - 6) - 1

 

Dim Tick_Counter As Integer      '' Declare the Tick_Counter

Dim Particle_List(TOE_Count_PL) As Integer

'' Declare an array of integers to represent the list of particles

 

 

 

'' Code section

 

Sub Start_Universe()

 

    Call Init_TOE   ''One-time initialization

   

    While (True)

    '' Repeat the algorithm for the age of the Universe

        Tick_Counter = Tick_Counter + 1   '' Increment the counter

        If (Tick_Counter >= TOE_Max_Tick) Then

        '' The Tick_Counter has grown too large to process

            Tick_Counter = 0  '' Reset it back to zero... the digital rollover

        End If

       

        Call TOE  ''Apply the algorithm

    End While '' bottom of do forever

End Sub

 

 

Sub Init_TOE()

 

    Tick_Counter = 0         '' Initialize to zero

   

    Particle_List(1) = 2     '' Initialize to State_0 values

    Particle_List(2) = 5

    Particle_List(3) = 7

End Sub

 


 

 

Sub TOE()

 

Dim PL_LOOP_Counter As Integer

'' Declare a counter used to process the particle list the Tick_Counter

   

    For PL_LOOP_Counter = 1 To TOE_Count_PL

    '' Loop through the list of particles

        If ((PL_LOOP_Counter Mod 2) <> 0) Then

        '' if this is an odd numbered entry

            Particle_List(PL_LOOP_Counter) = Particle_List(PL_LOOP_Counter) + 1

            '' apply the first rule set; move it one location to the right

            If (Particle_List(PL_LOOP_Counter) >= TOE_Max_Range) Then

'' The particle's location pointer has grown too large to process, in other

'' words, the particle has drifted past the edge of the computable Universe

                Particle_List(PL_LOOP_Counter) = 0

    '' Reset it back to zero... another digital rollover

            End If

        Else

        '' this is an even numbered entry

            If (Tick_Counter <> 5) Then

            '' This prevents division by zero

                Particle_List(PL_LOOP_Counter) = Particle_List(PL_LOOP_Counter) / (Tick_Counter - 5)

                '' apply the second rule set; divide by (Tick_Counter - 5)

            End If

        End If '' end else the entry was even

    Next PL_LOOP_Counter  '' bottom of particle list loop

End Sub

 

 

 

Runs forever and “the digital Rollover”:

 

The above rendition of algorithm #2 will work "as advertised", and it can run forever as well:

 

  1. When particles 1 or 3 get to the end of the allowable range of locations, they get re-positioned back to location 0.

 

  1. When the Tick_Counter is 5, the algorithm will NOT divide by zero!

 

  1. And, when the Tick_Counter gets too large, it gets reset as well, kind of like the counter at the 'ol butcher store... when it gets to 99, it gets reset back to 1.

 

I am calling this scenario "the digital ROLLOVER"; when a number gets to its maximum computable value, it gets rolled-over to zero.

 

 


 

Scalability:

 

In computing, SCALABILITY is the capability of a program to be used for a variable range of CAPACITY. For example, I can write an ADDRESS BOOK algorithm. If I write it to be NON-SCALABLE, it will have a FIXED capacity of names, addresses, etc. But if I write it with scalability in mind, then it could have the capacity to run on minimal hardware (and hold a minimal capacity) AND it could also run on huge data centers and super-computers, and have the capacity to know everyone in the world’s name, address, phone number, and a lot more. Can you say “C.I.A. and Google”?

 

The T.O.E. is solidly based upon the concept of fixed limitations, and the way it uses WordSize to base all of its capacities upon, makes it perfectly scalable. We can expect the T.O.E. to encounter no problems in any of its processing BECAUSE WE ARE LIMITING ALL OF IT TO OUR COMPUTATIONAL CAPACITY. Everything is under perfect control because of the way we are taking care to make this so, as demonstrated in this example.

 

 

I’m going to make you sick, repeating how Computability, Scalability, and WordSize drive the design of the T.O.E. Sorry.

 

These are the kind of considerations that we must take to assure our algorithm remains COMPUTABLE, forever and ever and ever. But this begs to ask, HOW CAN WE BE SURE our simulacrum won’t hang up or HALT?

 

 

 


 

 

 

Notes about Algorithm #2, rendition B , introducing THE HALTING PROBLEM:

 

 

 

 

 

 

 

 

In subsequent renditions we will also add a button to pause / resume the Universe, and features to CONTROL the speed of the execution of the loop, and to allow us to make single or groups of execution steps. Again, NONE OF THIS AFFECTS THE FUNCTIONALITY, so God can closely watch every detail of his creation, play it over and over as fast or as slow as he wants to, and not affect “his plan”, that is, if there really is a God. Another good thing.


 

Adding Bells and Whistles to Monitor and Control CELLULAR AUTOMATIONS:

 

I hope you’re following everything so far. Obviously, a major goal of this paper is to help you understand CELLULAR AUTOMATIONS. We are accomplishing this by writing the T.O.E. from scratch, from the inside out.

 

But we’re just starting to crawl; all we’ve done is make a program shell that keeps looping.

 

If you really want to see a sweet program that demonstrates MONITORING and CONTROL of cellular automatons, I strongly suggest you play around with a good ol’ one from 2005 called Mirek’s Cellebration. This program demonstrates Conway’s Game Of Life and many other “RULE SETS are demonstrated as well.

 

 

 

(Mireck’s Cellebration screen shot)

 

 

 


 

 

 

Classical Cellular Automatons vs. the T.O.E.:

 

Note that in most of these demos of “Classical” automatons, the rule sets are based upon RULES OF LOCALITY, for example, weather there are any adjacent cells (these are called NEIGHBORS) occupied or not.

 

Most of these have a fixed field of cells that always “persist”. Each cell may be “assigned” a STATE, which is an integer number from a small range of numbers. A range of 1 to 5 states, for example, can be visually displayed by 5 different COLORS, like red, green, etc. Mirek’s Cellebration calls the mapping of state numbers to colors “The Pallet”. In addition to a small range of states, an “EMPTY STATE” (usually the number 0) represents “EMPTY CELLS”.

 

These programs also have an initialization state, just like what we’re calling our “Pre-big-bang state”.

 

These states of all cells at a given instant is essentially a  “LOCATION_List” (vs. our “Particle_List”), and that is a major difference… we work from the inside out, mapping particles to virtual locations, They work from the outside in, mapping locations to virtual particles.

 

These programs also have RULES, just the rule sets we’re trying to develop.

 

These programs also have a very simple looping shell that executes the rules, exactly like our main loop. Their loop goes from the first to the last LOCATION, vs. our T.O.E. loop, which goes from he first to the last PARTICLE.

 

If you took their list of locations and selected those not in an empty-state, it would be just like our Particle_List. If we go through our Particle_List and look for all the ones that OCCUPY or CO-OCCUPY a location, this would be like their list of non-empty locations. So its almost 6 of 1 half-dozen of the other. BUT NOT QUITE, because I contend that:

 

Locality-based rules alone cannot simulate our observances of the time-reverse operation of light.

 

That’s why I’m writhing this paper... to show how a simple algorithm, working forward in time, CAN SIMULATE THE OPERATION OF LIGHT, EXACTLY THE WAY WE OBSERVE IT.

 

 


 

 

The RULES of locality In Conway’s Game Of Life:

 

 

Conway’s Game Of Life” best demonstrates a set of RULES of locality. Here are the rules, as defined in Wikipedia:

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

1.      Any live cell with fewer than two live neighbors dies, as if caused by under-population.

2.      Any live cell with two or three live neighbors lives on to the next generation.

3.      Any live cell with more than three live neighbors dies, as if by over-population.

4.      Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction.

The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.

 


 

 

 

The Unbelievable and Unpredictable POWER of Cellular Automaton Widgets:

 

 

These four dirt-simple rules of Conway’s Game Of Life yield ASTOUNDING results that surprised everyone.

 

Equally astounding is the idea that the 4 rules never change; what does change is the STATE of the Universe at any given time!!! In other words, the CONFIGURATION of cell states, alone is capable of self-generating patterns that function as powerful WIDGETS, and these can perform MAGIC!

 

Here is a link to a gallery of CELLULAR AUTOMATA widget demonstrations. I strongly suggest that you take the time to explore some of these widgets, especially if you’ve never seen them. YOU CAN WATCH THEM RUN as JAVA programs and as .gif animation files (F.Y.I, these are tiny automatons)!

 

You might also want to watch Wolfram’s YouTube video “A New Kind of Science”.

 

 

These simple widgets can accomplish a lot, especially when used in conjunction with one-another.

 

I’ve seen configurations where the motion of widgets simulates PHYSICAL MOVING OBJECTS like bombers, cranks, switches, and conveyors. These objects can be positioned on the layout such that they move and operate together, like the moving parts of a watch.

 

It’s just like using a simulator to create virtual gears and cogs, and running them together to simulate machinery in operation. An example of this is the simulation of the Antikythera mechanism as seen in this YouTube video.

 

In fact, some very creative people have “developed” widgets that “physically” simulate the LOGIC GATES of a computer, and have even successfully developed and executed “programs” using completely VIRTUAL computer!  The entire system was “programmed” ONLY BY THE CONFIGURATION OF CELLS and based only upon the 4 native rules of Conway’s game of Life!!!

 


 

 

It Goes WAY Beyond Games:

 

 

Cellular Automata demonstrate many concepts in mathematics, like CONVERGENCE, DIVERGENCE, and “Commonality of functionality” (the parallel evolution of common widgets).

 

They have also been used to simulate real-world scenarios with great success. The most well know are the simulations of gas laws and fluid motion, which proved to be 100% accurate.

 

One of my favorite demonstrations with automatons is to run one that displays perfect symmetry, for as long as the program is run, like a set of geometric shapes that fill the screen, all perfectly lined up from right to left and top to bottom, for example,

 

               

 

(The CROSS pattern, File: Cross.mcl, found in Mirek’ Cellebration V4.20.0.500)

 

 

And then CHANGE something in the layout… it suddenly starts to look like a cancer eating its way into the delicately tuned mechanism. It is very dramatic to watch. These scenarios are EXCELLENT demonstrations of CHAS THEORY! They show the spread of functional corruption through the populations of widgets, providing perfect simulations for the study of traffic flow, epidemics, weather patterns, etc.

 


 

Locality-Rules, ONLY to simulate the T.O.E.??:

 

 

 

Many believe that these dirt simple rules can simulate OUR real Universe!!! And some believe that our real Universe IS an automaton. For example, ME!!!

 

I am not alone! The list of people who believe the Universe is purely virtual (an INFORMATIONAL REALITY vs. a PHYSICAL reality, A.K.A. Quantum Realism) is growing by leaps and bounds every day as more and more evidence keeps piling in, all leading to this same conclusion.

 

The only thing I question is whether a strictly locality-based set of rules can do it or not??

 

 

 

(Moore’s neighborhood…. The 8 adjacent cells in a 2-d grid)

 

 


 

 

Non-Locality, Bell’s Inequality, and Einstein’s “Spooky Action at a Distance”:

 

 

A strictly locality-based rule set can simulate entangled photons as a two waves of localized activity spreading (A.K.A. moving or propagating, we’ve been calling it TRAVERSING) away from a point of origin. Their QUANTUM STATE INFORMATION can be encoded and conveyed from location to location by using “SPIN-PATTERNS”, for example, one widget spinning clock-wise, and it’s entangled twin spinning counter.

Here is another YouTube Video by a dude named Henry Miller. This video demonstrates an automaton doing this exact thing!  In it, Henry shows how the detection of a spin state in one location COULD (seemingly) WORK TO “INSTANTLY REVEAL” THE STATE OF THE ENTANGLED TWIN.

 

THIS APPEARS TO BE A “VIOLATION OF LOCALITY”! How can the state of particle-A INSTANTLY affect the state of particle-B? How can the quantum state information move INSTANTANEOUSLY between disparate locations?

 

Everyone knows what Einstein thought of this exact scenario… he wondered how could ANYTHING move faster than c?? (Instantaneous is faster than c). Einstein called this phenomenon “SPOOKY ACTION AT A DISTANCE”.

 

                        

 

(Albert Einstein, Casper the Friendly Ghost, and Henry Miller)

 

 

What Henry really shows is the coincidental observation of states in disparate locations, occurring at synchronized times because of a fixed rate of traversal through a fixed grid of location nodes.

 

 

So even though it is not mainstream science, Henry Miller is trying to prove that there really is an Aiether, and it is the grid of locations itself!! Sound familiar?

 


 

Locality-Only rules alone can’t do the job:

 

 

I TOTALLY agree with Henry’s assessment that the Universe must be composed of a digital grid. BRAVO! However:

 

I don’t believe that locality-only rules can process light the way we observe it in our real Universe!

 

It is precisely this magical optimization (the reverse-time-ordering I’m trying to explain) that precludes it from working by simple locality!!!

 

 

Make no mistake; the T.O.E. is a very simple automaton. However, our T.O.E. is not just based upon rules of locality! There is nothing preventing our T.O.E. from processing data all over the Virtual Universe in a single tick of time; if we want to say that two particles are entangled, we can just make a data link between the two records in our Particle_List, and we’re done.

 

In the case of this photon-pathway optimization, we will see that the rules of locality alone won’t be able to compute optimal routing in reverse-time-ordering, the same way that the Universe cannot instantaneously determine spin-states of disparate entangled particles.

 

Neither of these computations is possible using locality-only rules, but both are very simple to implement in a Universe that can extend its computations beyond its local neighborhood. Without even having to show how they’re programmed, isn’t this obvious by now?

 

 

 


 

Algorithm_3_A displays the Tick_Counter:

 

 

We will now turn our focus to programming Algorithm_3_A. Since the functionality is changed very little from V_2B, and the chapter focuses more on programming than the T.O.E., I moved it into Appendix: Programming the T.O.E. for Modularization. If you’re reading this paper to learn VB, this is a must-read appendix.

 

 

 

(After pressing the “Start the Universe” button the “Stop the Universe” button and the Tick_Counter display both appear.)

 

The program starts its looping execution, updating the Tick_Counter display each time it completes all of the computations in the T.O.E., on every particle (in all dimensions) and in-progress waveform, Universe-wide.

 

 

The Tick_Counter vs. the halting problem:

 

When we execute VB_Algorithm_3_a.exe we can now see that the Tick_Counter indeed IS being incremented. So we know that our T.O.E. is still running. You can watch it as long as you want to, it will keep on ticking! It hasn’t hung up in any infinite loops or division by zero, nor has it exceeded any maximums imposed by the WORD-SIZE of the computational process, in computing any of the states (thus far, at least).  A very good thing.

 

Watching the Tick_Counter transition doesn’t solve the halting problem, which is to ask, “Will there EVER be an end of time?” But at least we know we’re not frozen in time, which is a lot more important. In fact, we don’t ever need to know the answer to the halting problem in order for the Universe to proceed. We got the Universe up and running using all-integer computability, so now we can begin modeling our rules of motion into resembling the laws of nature.

 

The truth is, IT IS IMPOSSIBLE TO PREDICT FOR CERTAIN IF A PROGRAM WILL HALT OR NOT! That’s what Alan Turning concluded back in 1935 (and BTW, his proof for it is very imaginative). So let’s not lose any sleep worrying about the end of the Universe because even God (if there IS a God, that is) can’t answer this question, but just like us, he can take steps to make the design as solid as possible.

 


 

 

 

The laws of nature are implemented by rules of motion:

 

The only reason for rule #2 of algorithm #3_a is to demonstrate the concept of non-computable algorithms, and the need for error checking. We don’t need rule #2.

 

The reason that I changed rule #1 of this algorithm is that it will be used to demonstrate a LAW OF NATURE called MOMENTUM, and I don’t want this to be confused with the traversal of light; these are two separate things, but they ARE CLOSELY RELATED as we will discuss immediately below.

 

 

If you haven’t guessed it by now, each law of nature is coded up in individual rules of motion.

 

I suggest that these can roughly be equated to the set of Feynman diagrams that operate upon the fundamental particles in the standard model of physics.

 

 

 

(An example Feynman diagram)

 

 

 


 

 

 

The company payroll:

 

 

Before learning how MOMENTUM works, first let us talk about how a company payroll program works. What does this have to do with the motion of matter? Ah HA!!!

 

Suppose you have a company and you have a computer that performs the payroll every week. It runs like clockwork, computing everyone’s salaries right down to the penny and paying out checks. The sum of payouts is subtracted from the balance on hand, and it all works perfectly, week after week.

 

No problem, right?

 

OK, now, one week the power is out and you have t get in there and compute everyone’s salary using a battery powered hand calculator… still no problem, because you can still compute everything to the exact penny. Right?

 

OK, now, let’s say that you have to perform these calculations using an abacus… still no problem, again, we are using our INDIVISIBLE UNIT of value… the penny, which get counted on the abacus to the same precision as the company computer. Right?

 

In all of the above scenarios, the company could really run forever without any loss of the payroll balance… it can do so because these calculations are all exactly precise. I know this is obvious.

 

But now, what would happen if you had to use a SLIDE RULE to make the calculations?? The slide rule does not use all integer maths. It uses an approximation, which will lose precision if/when the numbers get big enough.

 

Can the company run forever if there is any possibility of losing the payroll balance? Of course not! Even if it loses only one penny at a time on very rare occasions, the company balance will decrease over time and become depleted.

 

THE COMPANY PAYROLL CAN ONLY GO ON FOREVER IF ALL OF THE CALCULATIONS ARE DONE WITH ALL-INTEGER ARITHMETIC.

 

 

 

All right, now, let us discuss the motion of matter…

 

 

 

 


 

 

Our first rule of motion to consider is called MOMENTUM OF MATTER:

 

This page is important!

 

For momentum to operate the way I envision it within the T.O.E.’s sequential looping execution, all PARTICLE motion is accomplished by moving no more than ONE GRID LOCATION in any given state transition. This allows LIGHT to traverse the grid at “FULL SPEED”, the speed of light, at a RATE of ONE GRID LOCATION EVERY TICK.

 

I changed rule #1 to move the particles at a rate of speed that is SLOWER THAN THE SPEED OF LIGHT, because I assume that particles can’t ever move as fast as light.

 

Please think about this for a minute; we are implementing the T.O.E. by following the simple, inside-out approach of sequential loping construction, using the counts of state transitions to act as TIME! In this context, there is no such a thing as “fluid time”!!

 

So, specifically, what IS “speed” in a digitized topology, and what speed can be can be considered to be slower than c?

 

The next slowest possible speed is to move every other tick, which is exactly what our upgraded rule #1 is doing. It waits one tick and then it hops, while light hops every tick; it is now moving at ½ c!!! If it waited for two ticks and then hopped, it would be moving at 1/3 c!!! Ya c what I’m sayin’?

 

 

The momentum of matter works as follows;

 

1.      Light traverses the digital grid at a rate of one grid location every tick.

 

2.      Matter moves by WAITING for a count of ticks, and then moving ONE GRID LOCATION!

 

3.      All motion is computed and implemented ONE DIMENSION AT A TIME!

We don’t have to compute distances between points with trigonometry; we can stick to “TAXICAB-GEOMETRY”. This allows pure integer arithmetic to be used in all of the calculations, even in multi-dimensional Universes, such as our own.

 

4.     Pure integer arithmetic then allows the T.O.E. to operate PRECISELY. There will never be a loss in resolution, allowing it to be able to run forever.

 

Once again, the primary goal of this design is forever computability. There you go!


 

 

Modifying the design of the Particle_List:

 

 

In our code examples thus far, we were able to convert our “State_0 list of numbers” …

 

STATE_0:

1) 2

2) 5

3) 7

 

into a VB array of integers…

 

Dim Particle_List(TOE_Count_PL) As Integer

'' Declare an array of integers to represent the list of particles

 

And we initialized them in the Init_TOE function call:

 

Particle_List(1) = 2     '' Initialize to State_0 values

Particle_List(2) = 5

Particle_List(3) = 7

 


 

A quick tutorial in Relational Databases:

 

 

Let us now be introduced to the science of relational databases; here is the “State_0 Particle_List TABLE”…

 

Particle_List  (State_0)

Index

Location

1

2

2

5

3

7

 

It looks very similar to our “State_0 list of numbers”. In RELATIONAL DATABASE terminology, this DATABASE TABLE has ROWS and COLUMNS.

 

Click HERE for an appendix that explains relational analysis, and elaborates upon a possible explanation for the 1/3-charge values that we observe in the standard model of particle physics.

 

 

 


 

 

Bits of matter sit for a count of ticks and then hop 1 GL.... how is this implemented by the T.O.E:

 

The Particle_List not only tracks the locations of particles, it also tracks their momentum, individually, and by individual dimension (and a lot more). Now that we know how to design databases, let’s modify the Particle_List TABLE

 

Here is an (admittedly, very poor) design of the Particle_List table for a Universe that has TWO DIMENSIONS and capable of tracking momentum:

 

Particle_List  (State_0)

Index

Loc_X

Speed_Level_X

Speed_Reset_X

Loc_Y

Speed_Level_Y

Speed_Reset_Y

1

2

15

1

0

0

0

2

5

0

0

0

0

0

3

7

15

1

0

0

0

 

Notes:

 

1.      We support multiple dimensions by breaking locations down into their dimensional components (location x, location y, etc.).

 

2.      For each dimension, we added two new attribute fields for tracking the relative speed counts:

 

·        The Speed_Level is how the T.O.E. designates “SPEED” as “the count of Universe ticks that elapse in-between hops”.

 

·        The Speed_Reset is how the T.O.E. will schedule the next hop, using the Universe_Tick_Counter to do so. So ya see, the Tick_Counter ain’t there just to let God know “His” creation is hung up in an infinite loop somewhere. That is, if there really IS a God.

 

Speed_Level is the relative speed at which a particle moves in relation to the grid itself, and therefore, also relative to other particles positioned in it. Just like MPH, the Speed_Level is a higher number for particles that move faster… in other words, they work in ASCENDING ORDER of increasing speed.

 

This seems obvious, however, the processing of Speed_Level in a digitized topology is NOT OBVIOUS. For example, you might wonder how I got a Speed_Level of 15 to represent one half c!!

 

I will explain this right now, and give you a heads up about the impact of using counts to track relative Speed_Levels:

 

It will lead us into some deep re-consideration of what we always thought about “SPEED” and the science of RELATIVITY. This is discussed in the 3rd paper in this series.

 


 

 

 

 

Digitized Speed Rates:

 

The bottom line is this:

 

SPEED IS NOT AN INFINITELY CONTINUOUS MEASUREMENT; IT MUST FALL INTO A FINITE SET OF “DIGITIZED SPEED RATES”.

 

You already know what I’m gonna be ranting about here. We aren’t in a continuum and so we can’t possibly have a continuum of speed levels!! We need to track everything using WHOLE INTEGER NUMBERS of the COUNT of TICKS that have elapsed since a previous Speed_Reset (since the last Tick of Time that we moved). Here’s how:

 

We count until it is time to move again, then we move 1 grid location and reset the counters.

 

Let’s keep this simple for now by only using one dimension, OK?  Let’s simplify our shitty 2-d design into this table, capable of tracking momentum in 1one dimension:

 

Particle_List  (State_0)

Index

Location

Speed_Level

Speed_Reset

1

2

15

1

2

5

0

0

3

7

15

1

 

I will explain why that 2-d table it was a shitty design, below.

 


 

Simplifying the explanation with an INVERTED speed scale:

 

 

In order to clearly explain this, let us start by using an INVERTED SPEED SCALE, where the FASTEST speed is 0, and the slower speeds are higher numbers. I’m designating the INVERTED scale speeds as I_Speed_Level. Ready?

 

Light moves at 1 GL per tick, and we agreed that matter couldn’t move as fast. So the fastest possible speed matter can move is ½ c, which is to wait one Tick in between each 1-GL hop (** I KNOW light can move faster than ½ c. See note below about speeds faster than ½ c).

 

So, 1/2 c is I_Speed_Level_1 (wait 1 tick), 1/3 c is I_Speed_Level_2 (wait 2 ticks), 1/4 c is I_Speed_Level_3 (wait 3 ticks), etc.:

 

 

Inverted Speed_Level

Ticks of Pause

Comment

0

0

Speed of light… not used for matter

1

1

1 / 2 c  (Fastest Speed_Level for matter)

2

2

1 / 3 c  (2nd fastest)

3

3

1 / 4 c  (3rd fastest)

4

4

1 / 5 c  (4th fastest)

 

Etc…

 

 

The general formula for Inverted Speed_Level is:

 

I_Speed_Level_n = c / (n  + 1)

 

Simple enough, right? We are able to track digitized rates of speed from the fastest (I_Speed_Level_1, which is ½ c) TOWARDS the slower I_Speed_Level_n speeeds (higher n numbers for more counts of waiting in-between ticks, resulting in slower motion).

 

 

 

 

 

 

**Note: I’m aware that the T.O.E. could use other methods to achieve speeds greater than ½ c, for example jumping more than 1 GL at a time. This is discussed in the 3rd paper in this series.

 

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

 

Is there a problem with inverted speeds:

 

 

 

(An angry Raccoon)

 

YES! There are a few:

 

1.      First off, nobody wants an inverted speed scale because the first thing they would have to do is somehow convert it in to an ASCENDING scale, like MPH or KPH is you live up in Canada, eh?

 

2.      Next big problem, we will call COURSE GRANULARITY. The difference between Speed_Level, from one to the next is always very abrupt… can you imagine having to accelerate between I_Speed_Level_3 and I_Speed_Level_2,  JUMPING from 1 / 4 c to 1 / 3 c, INSTANTANEOUSLY???

That is the price we always have to pay when we trade the time-space-continuum for the digitized grid.

More on course granularity will be discussed below, and yes, this is also part of the discussion we will have in the 3rd paper in this series on the real definition of SPEED, speeds past ½ c, and how this affects the science of RELATIVITY!

 

3.      There is a huge problem here: WHAT IS THE SLOWEST SPEED ALLOWABLE???

We are COUNTING ticks
that elapse until they reach a certain number, and then we hop one position and reset the counter. My burning question is: HOW BIG CAN THE COUNTER GET??? How LARGE of an integer number can we use for the purpose of counting???

 

 

 

 

 

 

Finite limits impact the processing of motion… Speed_Range:

 

AH-HAA!! So, once again, the concept of FINITE LIMITS is what will determine the design of the algorithm. I kept telling you how finite limits are an important cornerstone in designing the T.O.E.:

 

The T.O.E. must limit its range of allowable Speed_Levels to a finite integer number… a Speed_Range.

 

In the same way we limit (the Universe Tick_Counter to TOE_Max_Tick), (the maximum range a particle can be away from the center of the Universe to TOE_Max_Range), and (the count of records in the Particle_List to TOE_Count_PL), we must also limit (the count of ticks a particle can wait before it moves) to something we will call TOE_Speed_Range.

 

For example, if we said that we could wait, AT MOST, 256 ticks in-between hops, then the slowest Inverted Speed_Level allowed would be I_Speed_Level_256; we can’t use bigger numbers because we have to limit all of our calculations to numbers less than 256 (obviously).

 

I bet you can guess where we define TOE_Speed Range in the program code. If not, then you’re not following this paper!! It is (obviously) SCALED upon WORD-SIZE!!!

 

 

Let’s suppose that our WORD-SIZE is 8; as such, the biggest number we can compute is 2 ** 8 = 256. We’ll need all of that room to accumulate and manipulate our biggest integer numbers in the T.O.E. rules-of-motion calculations, WITHOUT OVERFLOWING.  Ya know, COMPUTABLE!

 

In order to accomplish overflow avoidance in hugely scaled Universes, we have been using RATIOS of the WORD-SIZE to determine our maximum limits…

 

Const WordSize = 8

'' This defines the maximum size of the numbers processed by the algorithm as 2 ** WordSize.

'' The entire algorithm is scaled by the range of numbers that are considered to be COMPUTABLE.

Const TOE_Max_Tick = 2 ^ ((WordSize * 3) / 4))

'' Oldest tick of Universe time allowed

Const TOE_Max_Range = 2 ^ (WordSize / 2)

'' Furtherst Grid Location from the center of the Universe allowed

Const TOE_Count_PL = (2 ^ (WordSize / 4)) – 1

'' Maximum count of records in the Particle_List allowed

 

So we just need to define Speed_Range right here, for example,

 

Const TOE_Speed_Range = 2 ^ ((WordSize / 4) + 2)

'' Number of Speed_Levels allowed


 

 

 

Now we can define Speed_Level as ascending with increasing speed:

 

 

We can now determine how many Tick counts the Universe can possibly wait for matter to move, or, in other words, we have determined the Universe Speed_Range. And so, now we can finally use an ascending scale for Speed_Level, from slow to fast, just like MPH. In general:

 

 

Speed_Level

Ticks of Pause

Comment

0

Forever

Frozen in the grid

1

Speed_Range - 1

Slowest moving Speed_Level

2

Speed_Range - 2

Second slowest

 

 

Speed_Range - 3

3

1 / 4 c

Speed_Range - 2

2

1 / 3 c (Second fastest)

Speed_Range - 1

1

1 / 2 c (Fastest Speed_Level)

 

 

The general formula for ascending Speed_Level is:

 

Speed_Level_n = c / (Speed_Range – n + 1)

 

Specifically, when using a WORD-SIZE of 8, we have Speed_Range = 2 **( (8 / 4) + 2)

 =  2 ** 4 = 16 allowable Speed_Levels:

 

 

Speed_Level

Ticks of Pause

Comment

0

Forever

Frozen in the grid

1

15

1 / 16 c (Slowest moving Speed_Level)

2

14

1 / 15 c (Second slowest)

3

13

1 / 14 c (3rd slowest)

4

12

 

5

11

 

6

10

 

7

9

 

8

8

 

9

7

 

10

6

 

11

5

 

12

4

1 / 5 c

13

3

1 / 4 c

14

2

1 / 3 c (Second fastest)

15

1

1 / 2 c (Fastest Speed_Level)

 

 

 

 

Speed_Level_15 was NOT obvious:

 

Remember that I wanted the odd numbered particles to move at 1 / 2 c?  That is the maximum allowable Speed_Level, and I came up with the number 15…here’s how:

 

Speed_Level_n = c / (Speed_Range – n + 1)

 

We need    c / (Speed_Range – n + 1)

 

To equal    c / 2            (that is 1/2 c)

 

So,

 

(Speed_Range – n + 1) = 2

 

(Speed_Range – n) = 1

 

So n = 15.

 

Proof:

Under Speed_Range_16, a Speed_Level of 15 waits for 1 tick of Universe time and then hops… it hops every other tick; 1/2c.

 

 

OK, so yes, Speed_Level 15 was correct, but we needed to determine our range of allowable Speed_Levels before it could be determined… we needed to take the scaling of the system into account and this got us back to the WORD-SIZE of computational capability of the system.

 


 

 

Processing MOMENTUM in the T.O.E.:

 

So now that we understand how Speed_Range and Speed_Level work, we can write the part of the rule set for the momentum of matter. We will process it for each and every particle, all separately and independent from each other, by making calls from the T.O.E. main loop, exactly like our previous examples:

 

 

For Pl_LOOP_Counter = 1 To TOE_Count_PL

'' Loop through the list of particles

 

If (Momentum_Eligible (Pl_LOOP_Counter)) Then

'' If the particle is eligible for motion by momentum

            Call Momentum (Pl_LOOP_Counter)

End IF

 

‘’ Etc… for the other rules of motion

 

Next Pl_LOOP_Counter  '' bottom of particle list loop

 

 

 

 

 

Sub Momentum (PL_Loop_Counter as integer)

 

If (pl_list(PL_Loop_Counter).Speed_Reset >= Tick_Counter) THEN

‘’ If it is time to move

 

pl_list(PL_Loop_Counter).Speed_Reset = Tick_Counter +

((pl_list(PL_Loop_Counter).Speed_Range –

 (pl_list(PL_Loop_Counter).Speed_Level)

‘’ re-schedule the next move

 

call Move_Particle ()

 

End if

 

 

End sub


 

 

In multiple dimensions, we need to modify our Particle_List as follows

 

 

 

We will process it for each and every particle, and within each and every dimension, all separately and independent from each other:

 

For Dim_Counter = 1 To n_Dims

'' Loop through each dimension

For Pl_LOOP_Counter = 1 To TOE_Count_PL

'' Loop through the list of particles

 

If (Momentum_Eligible (Pl_LOOP_Counter, Dim_Counter)) Then

'' If the particle is eligible for motion by momentum

            Call Momentum (Pl_LOOP_Counter, Dim_Counter)

End IF

 

‘’ Etc… for the other rules of motion

 

Next Pl_LOOP_Counter  '' bottom of particle list loop

Next Dim_ Counter  '' bottom of dimensions loop

 

 

Sub Momentum (PL_Loop_Counter as integer,

             Dim_Counter as integer)

 

If (pl_list(PL_Loop_Counter).Speed_Reset(Dim_counter) >= Tick_Counter) THEN

‘’ If it is time to move

 

pl_list(PL_Loop_Counter).Speed_Reset(Dim_counter) = Tick_Counter +

((pl_list(PL_Loop_Counter).Speed_Range(Dim_counter) –

 (pl_list(PL_Loop_Counter).Speed_Level(Dim_counter))

‘’ re-schedule the next move

 

call Move_Particle ()

 

End if

 

 

End sub

 

 

The above code is implemented in our next example VB program… Please obtain the source from the link for examination… look at the file named VB_Alogorthm_3_b.bas.


 

 

 

Algorithm #3, rendition B:

 

 

Rule: Perform MOMENTUM

 

(Modified from previous version: Algorithm #3, rendition A

 

 

When you run it, the first screen you see is:

 

 

Pressing the “Clear Display and Report Parameters” button lists the program’s run-time parameters…

 


 

 

 

 

 

 

When pressing the “Worst Case Speed Test” button, the Speed_Level of every particle in the Particle_List table set to the maximum allowed, which = the TOE_Speed_Range. The reason for this button is to assure us that we will be able to determine the average Speed_Level for all of the particles in the Universe.

 

When you press it, you get a message informing you of the largest number the T.O.E. had accumulated when summing up the Speed_Levels, for example:


 

 

 

If you get an “Overflow error” this means that the computational process is at risk, and so the code isn’t bulletproof. A bad thing. Success here insures that we cannot possibly overflow, even in the worst-case scenario.

 

Pressing the “Get Average Speed_Level” button performed the calculation, and outputted the /Ave_Speed_Level = 4096 message, informing us of the current (or LIVE) average for all of the particles in the Universe.

 

Pressing the “Reset Database to Pre Big-Bang State” button did just that, and outputted the /Init_TOE_DB = 1 message.

 

 

 

 

Pressing the “Start Universe” button starts execution, as in V_3_a, but improvements were made in controlling the program’s execution of the T.O.E.

 

So now when you press “Start Universe”, it brings up a “Pause/Resume” button, which toggles some flags in the T.O.E. main loop. The flags let the program

 

  1. Pause loop execution
  2. Resume execution
  3. Re-start the T.O.E. from the pre-big-bang state

 

 

 

 


 

 

Pressing the “Pause” button toggles the flags and pauses execution:

 

 

At this juncture, you can press either the “Resume Universe” or the “Restart Universe” button.

 

Another new feature added is the /TOE_Report_Interval, which reduces the updates to the Tick_Counter display, allowing the program, to execute as fast as possible.

 

 

 

 


 

Scaling up the computability of the T.O.E.:

 

 

Here is a solid example of how this approach will assure the T.O.E remains COMPUTABLE even if we scale it up to HUGE WORD-SIZE capacities…

 

Let us say that one of the computations needed in our T.O.E. is to determine the AVERAGE SPEED_LEVEL of all the particles in the Universe. This would be computed as such:

 

 

iSpeed_Sum = 0

For index = 1 to TOE_Count_PL

‘’ For every Particle in the Universe

 

iSpeed_Sum = iSpeed_Sum + abs (Particle_List(index).Speed_Level)

‘’ Accumulate the Speed_Level

 

Next index

 

iAve_Speed_Level = iSpeed_Sum / TOE_Count_PL

‘’ Compute average Speed_Level

 

 

 

Do you see how these numbers should always remain with the range of computability? If we increase WORD-SIZE, the count of particles increases along with maximum allowable Speed_Level, yes, BUT THE CAPACITY OF THE ALGORITHM TO COMPUTE THESE NUMBERS ALSO INCREASES PROPORTIONALLY!!

 

LET’S PROVE IT RIGHT HERE, RIGHT NOW!!

 

Const WordSize = 8

'' The maximum size of the numbers processed by the algorithm as 2 ** WordSize

Const TOE_Count_PL = (2 ^ (WordSize / 4)) - 1

'' Maximum count of records in the Particle_List allowed

Const TOE_Speed_Range = 2 ^ ((WordSize / 4) + 2)

'' Number of Speed_Levels allowed

 

 

At WORD-SIZE = 8, the maximum computable number is 2 ** 8 = 256, so as long as we never exceed the number 256 as we accumulate the Speed_Levels for all of the particles, we remain COMPUTABLE:

 

 

  1. At (2 ** (WORD-SIZE / 4)) - 1 for the TOE_Count_PL, we have no more than 3 particles in the Universe.

 

  1. At 2 ** ((WordSize / 4) + 2) for the TOE_Speed_Range, the fastest allowed Speed_Level by any particle is 16.

 

 

And so, the WORST CASE SCENARIO possible as we accumulate Speed_Level numbers is when every particle in the Universe is moving as fast as possible. That is

 

TOE_COUNT_PL * TOE_Speed_Range = 3 * 16 = 48

 

A lot less than 256! So we never ever have to worry that our accumulation will exceed the capacity of the algorithm to make this computation.

 

 

 


 

 

 

The capacity study:

 

 

If we try this using bigger and bigger WORD-SIZE, we get more and more excess capacity (our ratio of capacity to WORST-CASE COMPUTATION-SCENARIO GETS LESS AND LESS).

 

 

Click HERE for the capacity reporting results.

 

 

And so we conclude that:

 

When using this scaling strategy in the T.O.E., the average Speed_Level calculation for the entire Universe will always result in crash-proof code execution, regardless of how huge we wish to scale our Universe.  Another good thing!!!

 


 

 

 

Relating disparate quantities in the T.O.E.:

 

 

Do you see how DISPARATE quantities are RELATED to one another??

 

How the sequence of state changes (that we incorrectly perceive to be a fluid flow of TIME) relates the speed of light to the motion of matter when confining it to a digital topology? Do you see how FINITE LIMITATIONS set the stage for the construction of the T.O.E. algorithm?

 

Upon this “implicitly intuitive topology” deploying  “naturally occurring algorithmic constructions”, the QUANTITIES of Speed_Level and Speed_Range have emerged (pretty much) from obscurity!

 

Very soon, more of these “disparate quantities” will emerge (MASS, Heat_Level, etc.), and a web of relationships between them will also emerge. These relationships will also look similar to Feynman diagrams, exchanging various forms of “energy” for one-another. For example:

 

  1. A MASS is a collection of particles locked into a close proximity:

    The quantity “MASS” is the count of particles that entail the collection.

 

  1. A MASS can move according to the LAW OF MOMENTUM… when that happens, it has what we can call KINETIC ENERGY (or KE for short):

    The quantity “KE along vector w” = the MASS * the Speed_Level along the vector w.

 

  1. A MASS can collide with another MASS. When this happens, both of the colliding objects incur and exchange of KE (along each of their vectors). This is Newton’s 3rd law of motion.

 

  1. Collisions also GENERATE HEAT ENERGY (or HE for short) as well. “HEAT” is “stored” in masses, and the AMOUNT OF HEAT ENERGY is quantified into a range of integer Heat_Levels. There are Heat_Range distinct Heat_Levels that a mass can be heated to (exactly like Speed_Range of Speed_Level):|

    The quantity HE = Heat_Level * MASS

 

  1. Collisions exchange both their KE and their HE, and the formulas for this look like Newton’s laws of motion.

 

  1. Etc., etc., etc…

 

These exchanges will emerge into the laws of physics, however, if you really look, each of them is really a very simple calculation being performed. In other words, these “exchanges between disparate forms of energy” are simple numerical TRANSACTIONS being applied to lists of numbers and nothing more.


 

Designing the T.O.E. from obscurity:

 

Do you see how this is all pulling itself together? The T.O.E. designs itself from obscurity… it pretty much has to work as shown. And God, (if there is a God, that is), only needs to define TWO INTEGER NUMBER PARAMETERS for it to work. Anyone wanna guess what those are?

 

  1. The count of Dimensions used in “his” rendition of the T.O.E., which we know is 3 (or at least that’s all we can imagine without “Brain-Freeze”).

 

  1. The WORD-SIZE of the computational process, of course!

 

 And I believe this WORD-SIZE can be derived from observing our own real Universe. For example

 

  1. There are “NATURAL RATIOS”, like the ratio of electron mass to neutron mass (137 to 1).

 

  1. There are CONSTANTS, in particular the Planck’s DISTANCE UNIT and the Planck’s TIME UNIT.

 

  1. And of course there is the speed of light.

 

Remember I stated there is no such a thing as time (like about 20 times already by now)? If we actually believe the Universe operates as I’m suggesting, then I believe we can DIVIDE Planck’s distance unit by the Plank time unit to yield the COUNT OF STATE TRANSITIONS THAT WE OBSERVE PER SECOND. It comes to something like 299,972 Ticks per second.

 

 

We will discuss making these derivations along the way.

 

Isn’t this getting exciting?? Just you wait!!

 

 

In our next example VB program, the force of momentum is programmed, along with more bells and whistles. Please obtain the source from the link for examination… look at the file named VB_Alogorthm_3_c.bas.


 

 

 

Algorithm #3, rendition C:

 

 

Rule: Perform MOMENTUM

 

(Modified from previous version: Algorithm #3, rendition B

 

When you run it, the first screen you see is:

 

 


 

 

A new region for the Update Interval lets you set it, and just like the rest of the T.O.E., it is scaled to the system’s Word-Size because it has to process a number at least as large as the Tick_Counter. Shown below is what happens when you press the “Less Updates” button when it’s already at 1; it goes to “Never”, meaning no updates are performed. The maximum allowed for this is scaled up to the Tick_Counter –1, so it stops at 63 in this 8-bit, 1-d configuration example.

 

A new button “Clear Displayclears the display.

 

Pressing the “Report Parameters” button lists the program’s run-time parameters, as before, and now doesn’t also clear the display, because we have a button for that.

 

A new Button “Report Particle_List outputs:

 

/T:0|PL:1|D1 =  |Loc:2 |Last_Loc:0 |Sp_Lvl:0 |Sp_Rst:0

/T:0|PL:2|D1 =  |Loc:5 |Last_Loc:0 |Sp_Lvl:0 |Sp_Rst:0

/T:0|PL:3|D1 =  |Loc:7 |Last_Loc:0 |Sp_Lvl:15 |Sp_Rst:1

 

The output follows immediately after the parameters report. This is the Particle_List, as initialized in the Init_TOE subroutine. /T:0 is the Tick, |PL:1 is the Particle_List index, |D:1 is the Dimension. |Loc:2 is the Location in the |D: dimension, |Last_Loc is the previous location, |Sp_Lvl  is the Speed_Level, |Sp_Rst is the Speed_Reset.

 

You will notice that I have disabled the index #1 record from moving, so in this example, only the index #3 particle moves. Otherwise, the functionality is the same; particle #3 is SCHEDULED TO MOVE in tick #1, which makes it hop right away on the odd numbered tick counts. The Speed_Level of 15 makes it hop every other tick, as painfully described, above, this is due to our system’s scaling, based upon WORD-SIZE.

 

 

The “Worst Case Speed Test” button is unchanged: the Speed_Level of every particle in the Particle_List table set to the maximum allowed, which = the TOE_Speed_Range. The reason for this button was to assure us that we would be able to determine the average Speed_Level for all of the particles in the Universe.

 

The “Start Universe” button is now green color, but functionally, unchanged.

 

Brand new are the “Step” and “Step for Update Interval Ticks” buttons, both colored green to designate “GO”, like the “Start Universe” Button. These work exactly like in Mcell.  They let you perform ONE TICK of Universe time, or you can perform a series of (Update Interval) ticks.

 


 

 

 

 

We can now start-up the T.O.E. from the pre-big-bang state by using any of these green buttons. Follow these directions for an example of pressing the “Step” button to kick off the first tick of the T.O.E.:

 

Click “Clear Display”, then Click “”More Updates” once so the Update_Interval = 1, and then click “Step” 18 times…

 

 

 

 

 

 

Particle #3 started moving in the second click, when the Tick_Counter transitioned from 1 to 2, and it continuers to move every other tick (as our requirements specify).

 

New diagnostic messages are output whenever a particle moves:

 

/T2|Move_PL:3|D1 = 8  1

/T:2|PL:3|D1 =  |Loc:8 |Last_Loc:7 |Sp_Lvl:15 |Sp_Rst:3

 

When using these “Step-Modes”, and when you run, and then use the “Pause” button, the program falls into PAUSE mode, so just as before, you can re-start or resume the looping, and you can use these step buttons as well.


 

 

 

At this juncture, Algorithm #3, rendition C: is starting to look at lot like Mcell’s core features. The “hot” new feature of this rendition is the “Show Universe in Mcell” button. Pressing it brings up Mcell as a display screen for our T.O.E…. it simply outputs whatever is in our T.O.E. database…

 

 

 

(Mcell is shown with our program overlaid on top of it)

 

You can see our particles #1, 2 and 3 plotted out in Mcell as 3 red dots. And so now, we can watch animations of our T.O.E. on the Mcell display.

 

When you use the T.O.E. like this, do not shut down Mcell directly, just shut down our program and Mcell will also terminate.

 

Similarly, the Mcell controls won’t work backwards to run our T.O.E., so don’t bother (for now).

 

You will see that the Mcell updates slow our program down. You can “disconnect” from Mcell display by pressing the new button “Hide Mcell” (I’m still working on making it actually hide).

 


 

 

Watching Momentum working:

 

 

Now, please go ahead and re-start the program, and bring up the Mcell display and let it rip… Here is what happens…

 

 

Steps 1 – 18 move Particle #3 from location 7 towards the right end of the Universe, moving every other tick (1/2)c.

 

State 0 (Pre-big-bang)

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

 

#2

 

 

#3

 

 

 

 

 

 

State 1 (First tick)

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

 

#2

 

 

#3

 

 

 

 

 

 

State 2

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

 

#2

 

 

 

#3

 

 

 

 

 

 

State 17

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

 

#2

 

 

 

 

 

#3

 

 

 

 

On the 18t tick, particle #3 exceeds the POSITIVE range of this Universe, which is defined according to WORD-SIZE - 8 as +16, so we don’t allow anything past location 15, just to stay SAFE.

 

We have programmed our T.O.E. to not explode or melt down when this happens, so this rendition always maintains control, and won’t let things move to locations larger than it has the capacity to compute. 

 

We algorithmically move the particle back to the center of the Universe in these cases, so it gets moved to location 0, along with a set of messages:

 

/T18|Move_PL:3|D1 = 0  1

/T:18|Mov_PL:3|D1 = 0 OVERSHOT 1

/T:18|PL:3|D1 =  |Loc:0 |Last_Loc:16 |Sp_Lvl:15 |Sp_Rst:17

/T:18|PL:3|D1 =  |Loc:0 |Last_Loc:16 |Sp_Lvl:15 |Sp_Rst:17


 


And we don’t wait for it to crawl along at the speed of light to do so; it happens INSTANTANEOUSLY all in tick 18, just like quantum entanglement and “Spooky action at a distance” are theorized to accomplish.

 

State 18

-16

-15

-14

-3

-2

-1

0

1

2

3

14

15

16

 

 

 

 

 

 

 

#3

 

#1

 

 

 

 

 

 

And so now, the T.O.E. needs to keep going non-stop and bulletproof. This rendition doesn’t change the Speed_Level when it RE-CYCLES particles that have strayed outside of its bounds.

 

We will discuss “TYPES of UNIVERSE OPERATIONS” in more detail at a later time, but basically, this is what I call a FOUNTAIN model… particles that go over the edge get re-cycled back to the center. If you want to read my verbose thoughts on this matter, please see Appendix: Types of Universe Operations, included below. It is a rant!

 

 

 

So continuing to process particle #3 (because that’s the only particle in motion, for now), WHAT DO YOU THINK WILL HAPPEN NEXT? I would guess the particle would just start moving forward again, every other tick. But that’s not what happens; it starts moving BACKWARDS into NEGATIVE territory!

 

State 20

-16

-15

-14

-3

-2

-1

0

1

2

3

14

15

16

 

 

 

 

 

 

#3

 

 

#1

 

 

 

 

 

 

State 22

-16

-15

-14

-3

-2

-1

0

1

2

3

14

15

16

 

 

 

 

 

#3

 

 

 

#1

 

 

 

 

 

 

Etc…

 

Here is why:

 

We are tracking our DIRECTION OF MOTION simply by remembering the previous position we were in at all times. Our algorithm then compares the previous location to the present to know the direction it is heading in.

 

In this rare case of “NON-STEPWISE LINEAR MOTION”, in tick 18, the LastLocation was 16 and our current Location was 0. That makes it negative direction of travel.

 


 

 

Going Negative:

 

Particle #3 will now move all the way until it hits the end of he NEGATIVE SIDE of the Universe, stop, and output another OVERSHOT message. This occurs at tick 48 because it took 18 ticks to get to the center, and we go 15 locations backwards from there at a rate of ½ c. It takes 30 ticks to move the 15 GLs from location 0 to location –15.

 

 

State 46

-16

-15

-14

-3

-2

-1

0

1

2

3

14

15

16

 

#3

 

 

 

 

 

 

 

#1

 

 

 

 

 

 

State 48

-16

-15

-14

-3

-2

-1

0

1

2

3

14

15

16

 

 

 

 

 

 

 

#3

 

#1

 

 

 

 

 

 

 

So, once again particle #3 will go forward, moving towards the positive end of the Universe. As it does so, for the very first time, our algorithm will encounter a COLLISION….

 

State 50

0

1

2

3

4

5

6

7

8

14

15

16

 

#3

#1

 

#2

 

 

 

 

 

 

 

 

 

 

State 52 COLLISION between particle #3 and particle #1

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

 

#2

 

 

 

 

 

 

 

 

 

 

#3

 

 

 

 

 

 

 

 

 

 

 

This is how I’m showing a CO-OCCUPATION of particles #1 and #3 both in location 2.

 

 

State 54 Momentum of particle #3 sends it through to location 3.

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

#3

#2

 

 

 

 

 

 

 

 

 

 

State 56 COLLISION between particle #3 and particle #1

0

1

2

3

4

5

6

7

8

14

15

16

 

 

#1

 

#2

 

 

 

 

 

 

 

 

 

 

 

 

#3

 

 

 

 

 

 

 

 

 

 

The program HANGS UP at this point. The reason is clear… we are OVERWRITING the intermediate results if computing particle #3 over the record space for m particle #3.

 

We need a way around this… MULTIPLE DATA SETS … coming up next….

 

 

Algorithm #3, rendition D:

 

Rule: Perform MOMENTUM using double buffering.

 

 

(Modified from previous version: Algorithm #3, rendition C

 

The program entry screen shows only a very few COSMETIC changes:

 

 

 


 

 

Two new sections were added: Pause Between Loops (milliseconds), and Diagnostic Verbose Level. The pause is obviously a “must-have bell-and-whistle”; we really can’t work without it.  The idea of the Verbose Level is to output more and more detailed messages, the higher the level number is. The code has many places in which the output of these messages is very informative, for example, when we move a particle, when we have a collision, etc. The ability to control these by level helps prevent the output log from flooding with too much detail.

 

This version has significant changes, but these are mostly INTERNAL (the functionality isn’t changed, but the implementation is). Most important are the changes made to the program’s DATABASE, as specified in the DECLARATIONS section:

 

 

Const TOE_DataSet_Count = 2

'' The count of copies of the runtime data within each T.O.E. database... each is called a DataSet.

'' These are needed to prevent the T.O.E. from overwriting intermediate results.

'' We make all of our calculations as usual, but we write the results into a separate scratch-pad called the NextSet.

'' When we finish all of our updates within a given tick of time, we then switch the Current set to the Next set,

'' in other words, we make the scratchpad DataSet the live Dataset.

Const TOE_DataBase_Count = 2

'' The count of copies of the T.O.E. database... each is called a DataBase

'' These are only used for the purpose of testing out future possible states

'' for the purpose of trying to make the T.O.E. perform a function, like "Make Pyramid shaped objects".

'' See TheTruth-machine.com, chapters 8 and 9 for details of LOOKING AHEAD by using RECURSION.

'' These are called Recursive-Look-Aheads.

 

 

The new TOE_DataSet_Count parameter lets the T.O.E. process multiple copies of the Particle_List. The primary reason for this is to prevent the Universe from overwriting intermediate results, as shown in the previous example.  This new version no longer hangs up at step 57; it can run “forever” (as long as the electric bill is paid).



 

The new TOE_DataBase_Count parameter lets the T.O.E. process multiple copies of the entire database.  This allows the algorithm to make a copy of the present state, and process it as though it were the real deal, but only for the purpose of allowing us look forward into the future, to see what WOULD HAVE resulted, had we taken a certain course of action.

 

Please see Appendix: Using RECURSION to look-ahead into the future… INTELLIGENT DESIGN:.  This appendix is a lengthy discussion about how the Universe might have been created, and no, it does NOT necessarily imply that a God provides the “intelligence”. This feature allows the Universe to converge upon a desired functionality by trying out a plethora of possibilities, honing in upon ones that are “successful”.

 

 

 

 

 

 

 

Program VB_Algorithm_3_e:

 

'' Algorithm #3_e:

''

'' Rule: Move by MOMENTUM,

'' Accept external parameters,

'' Modularize the TOE functions,

'' Allow a scan from Mcell

''

 

Compare to previous: VB_Algorithm_3_d

 

 

This version has many internal as well as cosmetic changes.

 

When you run it without supplying it any parameters, you get:

 

 

 

(The bottom of the window is truncated… the text area is blank)

 

You can press the new “Open More Report Windows” button to provide additional monitoring windows. It comes up displaying the system parameters:

 

 


 

 

 

(The first reporting window also has the Eon Loop Testing buttons + Eon Counter Display. The above example is showing 511 particles because the TOE_WordSize of the system is now defined as 20.)

 

Our example then overrides this with 3 particles upon initialization. The CAPACITY for 511 particles is there, if we need it, but this rendition allows us to use less.

 

If you press the “Open More Report Windows” (on the main form) again, you get another reporting window, without the Eon Testing region. Right now that’s all that is allowed, however, we can easily add additional reporting windows if needed in future renditions.

 

Users can now bring up these multiple windows and get “live” reports of various data structures, like the Particle_List (working), the Photon_Queue (future rendition), etc. We will also add a “Live reports” button and display the data as such in future renditions, so the users can watch the details as they unfold.

 

 

 

 

 

 


 

 

When you start the program up, you can now supply optional RUNTIME parameters. Since we will be using a boatload of parameters, in order to keep the command line manageable, we put all of our parameters into a file, in CLI format. See the example files for descriptions of the parameter format.

 

Here is a link to the example parameter file:

 

http://spikersystems.com/FlashNet_Pointer/www/projects/Martys_World/Quick_Explanation/Code/VB_Algorithm_3_e/VB_Algorithm_3_e_Input_Params_1.txt

 

Here is a link to the example command procedure used to start the program up:

 

http://spikersystems.com/FlashNet_Pointer/www/projects/Martys_World/Quick_Explanation/Code/VB_Algorithm_3_e/AAA_Start.bat

 

My “environment” is currently:

 

C:\Quick_Explanation\Code\VB_Algorithm_3_e\

 

Here is AAA_Start.bat:

 

 

start C:\Quick_Explanation\Code\VB_Algorithm_3_e\VB_Algorithm_3_e.exe " " "/@ = C:\Quick_Explanation\Code\VB_Algorithm_3_e\VB_Algorithm_3_e_Input_Params_1.txt /x = y"

 

 

For testing from within VB, place the following line in the “Project” – “Project1” – “Make” tab, in the field “Command Line Arguments”:

 

/@=VB_Algorithm_3_e_Input_Params_1.txt

 

Executing AAA_Start.bat from my environment (or via VB with the above command line argument) brings up the program, and it becomes loaded with the parameters defined in the parameter file. Two windows appear:

 


 

 

 

(The Main form, started with parameters)

 

 

 

 


 

 

(The first reporting form includes the Eon Loop Testing area.)

 

 

 

 


 

You can press the “Open More Report Windows” button on the main form to provide a third monitoring window. It comes up displaying the system parameters, but you can then press, for example, the “Clear Display” then “Show Particle List” buttons:

 

 

 

(The second report window doesn’t have the Eon Loop Testing buttons or Verbiage control buttons.)

 

 

Only 3 particles are listed because that is what we defined in our “State_0 initialization”, even though this rendition was built using a Word-Size of 20, allowing it to have up to 511 particles, if needed.

 

 

 

 


 

The program has been modularized: The “core” TOE functions are now kept in module TOE_VB_Algorithm_3_e.bas. TOE_Utilities_VB_Algorithm_3_e.bas now has the handy T.O.E. functions, such as Copy_Particle_List(). The main module, VB_Algorithm_3_e.bas now has only the outer loop testing construct,; it calls the “pure TOE simulacrum” as a single function named TOE():

 

Function TOE(Cur_DataBase As Integer, Cur_DataSet As Integer) As Boolean

 

'' This is the function that repeatedly gets called; the SIMULACRUM for the Theory Of Everything.

 

'' Each time this is called the Universe completes one more sequential tick of Universe time.

 

Dim PL_Loop_Counter As Long

Dim Dim_Counter As Integer

Dim bSomething_Moved As Boolean

 

    bSomething_Moved = False

   

    For PL_Loop_Counter = 1 To TOE_Count_PL

    '' Loop through the list of particles

        For Dim_Counter = 1 To TOE_Dims

        '' loop through the dimensions

            If (TOE_Momentum_Eligible(Cur_DataBase, Cur_DataSet, _

                                      PL_Loop_Counter, Dim_Counter)) Then

'' The particle is scheduled to move

 

                Call TOE_Momentum(Cur_DataBase, Cur_DataSet, _

                                  PL_Loop_Counter, Dim_Counter)

'' Move particle by momentum

                bSomething_Moved = True

 

            End If

 

'' (Remaining rule sets go here…)

 

        Next Dim_Counter

   

    Next PL_Loop_Counter    '' bottom of particle list loop

   

    TOE = bSomething_Moved  '' Return true if anything moved

 

End Function

 

Many changes were made to the calling parameters of many of the functions within the T.O.E., allowing it to support multiple DataSets and DataBases (described in the previous rendition), and for modularization. The TOE() function now returns TRUE if any particle was moved, and accepts the Cur_DataBase and Cur_DataBase parameters, but it maintains the Tick_Counter inside of a global testing structure declared as:

 

Public TOE_RT_Param(TOE_MAX_Param_Count) As tTOE_Runtime_Parameters_Rec

 


 

 

Copy Mcell Layout functions:

 

 

This rendition can now get snapshots of the Mcell screen layout.

 

 

 

(Mcell with VB_Algorithm_3_e overlaid upon it, showing State_0.)

 

 

The above is showing the Mcell layout of our 3-particles Universe, as it comes up when pressing the “Show Universe via Mcell” button (on the main form).

 

Pressing the “Copy Mcell Layout” button now prompts you for confirmation to perform the scan, but before we do that, let’s get Mcell to display a layout we want…

 

 

 

 

 

 


 

 

(A layout selected in Mcell that we want to scan into our T.O.E.)

 

 

OK, now pressing the “Copy Mcell Layout” button prompts for confirmation:

 

 


 

You press, “Yes”, and it performs the scan. On a “standard” 400 x 400 Mcell layout, it takes about a minute to complete. You can monitor the progress by watching the Main-form’s text window. If you need more detail, turn up the Verbose Level and you can now see messages generated for individual particles as they are scanned:

 

 

 

(Mcell is being scanned. The ROW NUMBER of cells being scanned is displayed in the main form, and individual particles are listed in the Form_2 reporting screen)

 

 

Mcell row numbers range from –200 to 200:

 

 

/Scanning the MCell layout Row #-123 (last row to scan = +200)...

 

 

Because the program controls should be unavailable to users while a Mcell layout is being scanned, the Main form is disabled, so that the buttons won’t work. In order to allow users to change the VERBOSE LEVEL in the meanwhile, the Form_2 screen is enabled and it now has buttons to adjust the verbose level just like on the Main form.

 

 

When the Mcell layout scan completes, the user is prompted for confirmation to save the scan into the “Pre-Big-Bang State”. Answering “Yes” copies the DataSet from Database_2, DataSet _1 to Database_3, DataSet 1 for safe keeping:

 


 

 

(Prompting for permission to save the layout into the “Pre-Big-Bang State”)

 

 

 

Note that once this is done, if the user subsequently presses the “Reset T.O.E. DataBase to Pre-Big-Bang State” button, it will copy to Database_3, DataSet 1 over the starting configuration. This allows the user to work with Mcell layouts more easily:

 

 

 

Next, the user is prompted for confirmation to save the scan into the “Pre-Big-Bang State”:

 

 


 

 

 

(Prompting for permission to copy the layout into the current DataBase and DataSet)

 

 

The program outputs informational messages and also interactively informs the user:

 

 

 

 

/Scanning the MCell layout Row #200 (last row to scan = +200)...

/All_Done_Scanning /Msg = 407 particles scanned + loaded into DataBase  #2

/DataSet_Copied_From = |DB #2 |DS #1 / DataSet_Copied_To_Pre_Big_Bang_State = |DB #3 |DS #1 /PL_Count = 3

 

/DataSet_Copied_From = |DB #2 |DS #1 / DataSet_Copied_To = |DB #1 |DS #1 /PL_Count = 407

 


 

 

At this juncture, you can get a report of the T.O.E. database and it will include the particles scanned in from the Mcell layout:

 

 

(A Particle_List report showing particles scanned in from the Mcell layout)

 

 


 

 

And now, the Main form also shows the yellow Pause/Resume Button. This is done to allow the users to start the T.O.E. and run forever (if pressed, the green “Start The Universe” button would re-initialize it from the boot-up state).

 

By pressing any of the other green buttons, or pressing the yellow Pause/Resume button, the T.O.E. now takes off, and it is running on the layout scanned in from Mcell:

 

 

 

 

 

 

(Running the Algorithm #3, you can see particle #1 on the right of the fish scanned in from Mcell)

 

 

 

 

 

 


 

 

 

 

 

Program VB_Algorithm_4_a:

 

'' Algorithm #4_a:

''

'' Rule: Move by MOMENTUM,

'' Accept external parameters,

'' Modularize the TOE functions,

'' Allow a scan from Mcell

''

 

Compare to previous: VB_Algorithm_3_e

 

Version 4_a is more of the same, providing even more parameters that allow you to read the layout in from a file and automatically start the Mcell display. Here is an example parameter file:

 

!!

!! VB_Algorithm_4_a_Input_Params_1.txt

!!

!! This is a parameter file in CLI format.

!! See ..\..\SpikerSystems_Common\CLI_Lib for format and use.

!!

/Test_Verbose_Level = 3

!! Outputs more or less detailed status messages

!!

/PL:1 =  |Tmp:11 |Dcy:1

/PL:1|D:1 = |Loc:2

/PL:2 =  |Tmp:12 |Dcy:2

/PL:2|D:1 =  |Loc:5

/PL:3 =  |Tmp:13 |Dcy:3

/PL:3|D:1 =  |Loc:7 |Last_Loc:0 |Sp_Lvl:254 |Sp_Rst:1

!! These are "local testing definitions" for the initial configuration.

!! These can also be overwritten by using the /Use_State_0_At_Startup parameter

!!

!!!/Use_State_0_At_Startup = VB_Algorithm_4_a_State_0_Defs_FISH.txt

!! Reads the initial configuration from the file

!!

!!!/Scan_Mcell_Layout_At_Startup = True

!! If defined as True, the Mcell layout will be added to the Particle_List

!! definitions

!!

/Show_Mcell_At_Startup = True

!! If defined as True, the program will automatically display Mcell after it is

!! initialized

!!

/AutoRun_At_Startup = True

!! If defined as True, the program will automatically startup after it is

!! initialized

!!

/TOE_Report_Interval = 1

!! Reports status every /TOE_Report_Interval Ticks (Mcell calls Ticks GENERATIONS)

!!

/TOE_Loop_Pause_ms = 15

!! Pause after each Tick

 

 

 

Describing LIGHT??? We're almost there:

 

It may seem that we've strayed off from our “simple explanation” of light. But everything discuss thus far is required for understanding the explanation. Hey, at least it's 100% analytic... no spirit forces or vague explanations will be provided, only solid answers to the greatest mystery of physics!

 

But the RULE OF MOTION demonstrated in Algorithm #3_a already serves as an example of how MOMENTUM of matter works, in general.

 

So we already know almost enough to begin discussing how the digital Universe can process light:

 

  1. We still need to know how matter can be heated... one way for this to happen is when a particle collides with another. Now that we understand the basics of momentum, we can simulate a collision and have it “generate some heat”. We'll need to know how to track the heat levels of matter by making modifications to the Particle_List.

 

  1. Next, we can discuss how matter can cool off... when matter cools, it emits light, so that's all we'll need to know about the T.O.E. to begin talking about light.

 

 

Heating and cooling are both described in less than 2 pages:

 

 

Heating matter:

 

Continuing our example Algorithm #2:

 

Recall, we were in state 2 of our example...

 

1-2-3-4-5-6-7-8-9---

 

--1-----2---3------- State 0

----1---2-----3----- State 1

------1-2-------3--- State 2

 

In the next tick of Universe time, particle 1 will COLLIDE with particle 2 (at location 5), and let's just assume that this somehow generates some HEAT.

 

Let us have the Universe track HEAT LEVEL in the Particle_List like this:

 

 

Particle_List  (State_2)

Index

Location_X

Speed_Level_X

Speed_Reset_X

Heat_Level

1

4

16**

3

0

2

5

0

0

0

3

9

16**

3

0

 

**(The Speed_Level shows 16, which is not allowed because it IS the speed of light in a system with Speed_Range 16. It is shown here as 16 to continue example algorithm #2, where particles 1 and 3 are somehow moving at c. Note how the Speed_Reset is scheduled for the next tick of Universe time.)

 

 

Particle_List  (State_3)

Index

Location_X

Speed_Level_X

Speed_Reset_X

Heat_Level

1

5

16**

4

1

2

5

0

0

1

3

10

16**

4

0

 

This is a modified Particle_List, showing the Heat_Level increases when particles 1 and 2 collided in State_3. Both of these particles went from Heat_Level=0 to Heat_Level=1. The Heat_Level of particle 3 (not in a collision) remained at 0.

 

 


 

 

Cooling matter:

 

In the next tick of Universe time, the algorithm can process this heat energy into a photon... for any given particle in the Universe, this is how an emission is processed...

 

 

IF (Given_Particle.Heat_Level > 0) THEN // If there is any heat to shed

 

(Create a PHOTON);                // (explained in paper #2)

 

Given_Particle.Heat_Level = Given_Particle.Heat_Level – 1;

     // The heat was converted into a photon of light

 

END IF

 

 

Notice the CONDITIONAL application of this RULE OF MOTION. The rule will not be ENACTED unless the conditional test allows it to be enacted. In this case, the Universe is testing if the particle has any heat to shed before it goes ahead and lets it try doing the impossible. The obvious reason for conditional testing is to keep the algorithm COMPUTABLE, just like checking for division by zero helps keep algorithm #2 running forever.

 

All of the rules of motion require this kind of CONDITIONAL PROCESSING, and there are some major implications to this as well, as described in the 3rd paper in this series.

 

 

 

 

Modifications to the Particle_List:

 

Please see the declarations for the Particle_List and the Photon_Queue in our latest rendition to see how this is implemented in VB.

 

We modified it above to accommodate tracking Heat_Level. Note that it also needs to be modified to track the motion of matter at various relative Speed_Levels, and to accommodate more than one dimension. Here is the “generic” DATA RECORD STRUCTURE for the Particle_List for a Universe that has N_Dims dimensions:

 

Index

Location(N_Dims)

Previous_Location(N_Dims)

Speed_Level(N_Dims)

Speed_Reset(N_Dims)

Heat_Level

Mass

Decay_Counter

 

 

The Photon_Queue:

 

A new data structure is required to track the photons that get emitted from matter as it cools down. This can be referred to as the list of PHOTONS.

 

Note that although the Particle_List has a fixed number of records in it (3 in the above examples), the list of photons is actually a QUEUE that holds a variable number of records in it. For this reason, we call this “list” the PHOTON_QUEUE... it is the list of all of the “in-progress” photons in the Universe.

 

Here is the “generic” DATA RECORD STRUCTURE for the Photon_Queue:

 

Index

Emission_Location(N_Dims)

Emission_Time

Frequency

Intensity

Linked_From_Index

Link_Traversal_Interval

Link_Traversal_Interval_Accumulation

 

 

OK, when a particle creates a photon, it is really creating a new record that gets inserted into the photon queue. The T.O.E. checks each and every photon in the Universe-wide queue of them, very much like the way it checks each and every particle in the Universe-wide Particle_List, in each and every tick of Universe time.


 

 

 

Ready, steady GO??

 

 

All right, we are finally ready to discuss the processing of light and how and explain how and why it operates in reverse-time ordering.

 

Click here for the 2nd paper.

 

 

 

 

 

 


 

 

 

Table of Appendixes:

 

Appendix_Elaborations_About_Time: 90

Appendix: Programming the T.O.E. for modularization: 97

Appendix: A quick tutorial in Relational Databases: 105

Appendix: Using the Particle_List.Index field: 107

Appendix: Relative Capacity Study Reports: 111

Appendix: Using RECURSION to look-ahead into the future… “INTELLIGENT DESIGN”: 118

Appendix: My comments to the YouTube Video “Why is light slower in glass? – Sixty Symbols”: 137

Appendix: Types of Universe Operations: 142


 

 

Appendix_Elaborations_About_Time:

 

 

 

 

Some things about time are non-obvious...

 

If you think about it, "time" is really the SEQUENCE of these state changes because it really doesn't matter how long it takes to compute each one of them, what matters to the characters within the VR is MOTION, and that only occurs relative to the sequential ordering of the these changes.

 

In-between each state change, it's like the Universe is frozen... more accurately, it is as if time doesn't exist.... which it really doesn't. In other words, THERE IS NO SUCH A THING AS TIME. Each individual moment is independent from the next, UNIVERSE-WIDE!!!

 

 

Proof there is no conscious perception of time:

 

This MUST BE TRUE, at least from our consciousness's point of view. Let me explain this...

 

The human brain is connected to the outside world through millions of NEURONS. Each neuron is eventually connected to some kind of sensing device, like an eyeball or an eardrum. But here's the thing... all neural signals are DIGITIZED!!! That's how they operate; by digitally switching on and off.

 

From this, we can conclude that even if the Universe were analog, our consciousness perception only sees digital.

 

What makes it appear to be realistic and to seemingly flow from the past into the future is the resolution our Universe operates on. How many frames per second does our real Universe operate upon?   The derivation for this is discussed below. Our Universe operates at about 1.855e+43 frames per second... amazingly fast... so fast that it's impossible for us to tell that time itself is DIGITIZED.

 

I liken our perception of our Universe to the frames in a CGI movie... it doesn't matter how long it takes to compute each successive frame... nor does it matter if there are pauses in between the recording of the frames. Upon playback, although it appears that time is flowing smoothly, in reality, it is the sequence of frames that create this perceived tempo of time. The video can be paused and continued, and the characters within the movie (within the VR of the CGI) are none the wiser... each frame is a separate state, frozen in time, just like our mini-Universe examples.

 

 

 

 

The questions of creation vs. the goals of this paper:

 

If the Universe runs by an algorithm that repeatedly manipulates a list of numbers (which is what I'm saying), then one might ask "who programmed the algorithm, who makes it run, where is the computer, and what happens if they have a power failure???" These are fair questions; I liken them to asking "is there a God?"

 

This paper is 100% analytic, so we won't approach it from the standpoint of a "SIMULATION", as if there is a physical computer somewhere and its crunching out our reality.

 

Instead, we will use the definition of a SIMULACRUM... an algorithm in and of itself.  As it applies to us, this is a T.O.E. that we can try to design without getting God or religion involved, because we don't need to ask who wrote it or who runs it.

 

In this paper, we try to design the algorithm itself as "the simplest possible way to accomplish the functionality". We will call this the "Occam's Razor approach to designing the T.O.E.".

 

 

 

 

Static vs. dynamic algorithm?:

 

Unlike a CGI movie, I believe that our Universe is “running' on a simple algorithm that never ever changes... it runs the Universe FOREVER. My reasons for this:

 

  1. Firstly, our observations of the Universe don't appear that is has been running “Willy-Nelly”... it appears as though the same laws of physics have been in place FOREVER (See Brian Whitworth's paper).

 

  1. More importantly, if the laws of physics do change, then I think that the entire science of physics would be worthless... if you study up on this stuff, right now mainstream science is considering the possibility. These suppositions come from “slightly Willy-Nelly” observations that as of yet are unexplained.

    However, physics itself has not detected any changes, at least since it has been studied and used for solving real-world problems. The suppositions of “different physics” go way back to various developmental phases of the Universe, according to big-bang theory. But if these suppositions were true, they why can't someone argue that perhaps the laws of physics not only change over time, but maybe they also change by location... you know, different rules for different galaxies, or maybe for different positions relative to the center of the Universe.

    Again I disagree with these theories as they tread too fine a line between interpreting physics by excessive complexity vs. revealing that they really don't understand what they're looking at.

 

  1. Most importantly, from a standpoint of COMPUTING, this equates to changing algorithm in the middle of execution, which really does not compute (at least not without God intervening, but that doesn't jive with our Occum’s razor approach to the design).

    In computing, the algorithm itself defines the Universe!

    Please see the definitions of COMPUTATIONAL REDUCTION from Dr. Steven Wolfram. In this context, every “possible” algorithm can be reduced to a basic form... this is like the collection of all possible geometric shapes, or the collection of all possible knots. The collection of all possible basic algorithmic forms is “the list of all possible unique algorithms”, which brings us to the next topic: MULTI-VERSES.

 

 

 

 

 

Multi-Verses... Multiple Possible Universes:

 

 

First off, my definition of “MULTI-VERSE” is from a computational approach, which is a lot different from the version that Dr. Brain Green is describing on Nova. The way they (quantum theory researchers) explain it, one single Universe PROLIFERATES into multiple instances as it encounters scenarios in which DECISIONS are made.

 

For example, as a molecule approaches another, it might deflect to the left or to the right. These guys suggest that this scenario results in TWO Universes to become instantiated, one in which the molecule went left, the other where it went to the right. When asked how can there be so much capacity to instantiate a GA-zillion new Universes in each an every of the GA-zillion state changes occurring a GA-zillion times a second (in each and every instance), they just smile and say “that's the power of infinity”.

 

From a computational approach I have major problem with this in a multi-verse of ways!!! These guys toss infinity around like a baggage handler at the Hilbert hotel!!

 

From a computational approach, the definition of a multi-verse is simply that different algorithms instantiate different Universes.  Dr. Wolfram's computational reduction clearly categorizes each and every possible one of them.

 

But here's the thing! Each of these Universes is continuously and infinitely instantiating every moment it comprises!!! At least it emerges that way to the characters within the VR. Again, this is because there is no such a thing as time!!  Every movement in every instantaneous moment throughout the history of the Universe has already been pre-determined and frozen in time. Each instant is separate and captured forever, simply by virtue of the algorithm existing!!

 

Note that the question of DETERMINISM is discussed in depth in the 3rd paper in this series, along with a definition of RANDOM, as these both relate to “computable algorithms”. One thing it definitely is not is a continuum… that conflicts with all notions of computability because infinite precision is not computable, as described below.

 

In a computable Universe, the COUNT of individual movements over a given span of time, is a finite number!! It has to be, in order for the algorithm to be computable, also as explained below. So, a Universe is kind of like a set of pictures that is finite in count and discrete in content.

 

This brings us to the next topic: how old is the algorithm that runs our Universe? The only thing really infinite is the age of the algorithm, which also equates to the age of the Universe... a finite set of pictures that have existed FOREVER!!!

 



 

 

 

 

 

 

 

 

The age of the Universe:

 

I liken the simulacrum of our Universe to a simple math formula...

 

Y = X squared, for x = 1 to 100, in whole integer units

 

For those who are math challenged, this looks like a parabola, when plotted on a 2-dimensional graph.

 

If X = 1, then Y = 1.

If X = 2, then Y = 4.

If X = 3, then Y = 9.

If X = 4, then Y = 16.

If X = 5, then Y = 25…

 

 

 

 

 

 

 

 

25

 

 

 

 

x

 

 

24

 

 

 

 

 

 

 

23

 

 

 

 

 

 

 

22

 

 

 

 

 

 

 

21

 

 

 

 

 

 

 

20

 

 

 

 

 

 

 

19

 

 

 

 

 

 

 

18

 

 

 

 

 

 

 

17

 

 

 

 

 

 

 

16

 

 

 

x

 

 

 

15

 

 

 

 

 

 

 

14

 

 

 

 

 

 

 

13

 

 

 

 

 

 

 

12

 

 

 

 

 

 

 

11

 

 

 

 

 

 

 

10