Consider the development from a single fertilized egg cell (a zygote) to a complete human baby. That baby has a complex three-dimensional shape and physical composition including a variety of complex internal structures such as: the different organs and the internal structure of each organ, and how these organs are placed and connected in the body; the skeleton and all its bones, joints, muscles, and tendons; the nervous system including the brain; the circulatory system including the lymphatic system. The complete human baby has trillions of cells and their cell-controlling bions, and all this three-dimensional complexity during the development of that baby’s physical body implies the existence in those cell-controlling bions of a means by which a cell-controlling bion can determine its 3D spatial relationship with various other cell-controlling bions in that body.
To allow a cell-controlling bion to determine its location relative to certain other cell-controlling bions in the same developing body, let’s make a few assumptions:
Assume that on our planet Earth, for a cell-controlling bion whose cell is a part of a multicellular body, the learned programs that have evolved on our planet for controlling these cells, make use of the cell-controlling bion’s user-settable identifiers block in the following way:
The first integer (denote as USID_1), gives the most recent status of the bion’s cell. The following five values are defined:
MY_CELL_IS_ACTIVE: This would be the normal setting for the cells composing our physical bodies.
MY_CELL_IS_READY_TO_DIVIDE: A bion changes its USID_1 value from MY_CELL_IS_ACTIVE to MY_CELL_IS_READY_TO_DIVIDE if that bion is ready to start the cell-division process but that bion needs another bion to occupy and control what will be the newly formed cell after the cell division process has completed. In effect, changing its USID_1 value from MY_CELL_IS_ACTIVE to MY_CELL_IS_READY_TO_DIVIDE is a form of advertising to other cell-controlling bions that have as their current USID_1 value HAVE_NO_CELL (see below).
After another bion has been found to occupy and control what will be the newly formed cell after the cell division process has completed, and that other bion is in close proximity to this bion that is ready to divide, and both bions are ready to bring about the cell division, then this bion changes its USID_1 value from MY_CELL_IS_READY_TO_DIVIDE to MY_CELL_IS_DIVIDING.
MY_CELL_IS_DIVIDING: see the above description of MY_CELL_IS_READY_TO_DIVIDE which explains when MY_CELL_IS_DIVIDING is set.
MY_CELL_IS_IN_STASIS: This is set when the bion’s cell is still intact, but the cell’s environment has changed in a way that the bion no longer has from its environment what it needs to do its normal activities with its cell. When MY_CELL_IS_IN_STASIS is set, a bion stops its normal activities for its cell and awaits developments.
Assuming one has a typical death where one’s physical body is intact but first one’s breathing has stopped and then a few minutes later one’s heart stops, then probably within five minutes after one’s heart has stopped, a majority of the awake cell-controlling bions of the cells composing one’s physical body, will have changed their cell’s status in USID_1 to MY_CELL_IS_IN_STASIS.
Besides the situation for us humans and other animals whose cells depend on circulating oxygenated blood, a non-death example of cell-controlling bions changing their cell’s status to MY_CELL_IS_IN_STASIS are the cells in a completed plant seed, which can be kept in dry storage for many years and still germinate when planted and watered. Another non-death example where MY_CELL_IS_IN_STASIS would be set are the tiny multicellular animals called tardigrades (aka water bears; their adult bodies have about 10,000 cells) which can be dried out and then last many years in this desiccated state, and then after water is added they come back to life.
HAVE_NO_CELL: If a bion has copied all the learned programs needed to be a cell-controlling bion but has not yet had a cell, then this is that bion’s initial value for its USID_1 (perhaps only cell-controlling bions that have had a cell and currently have their USID_1 set to HAVE_NO_CELL will make themselves available to be copied by other bions, which would include copying all the bion’s learned programs and also its user-settable identifiers block). Otherwise, assuming the bion had a cell, then HAVE_NO_CELL is set if the bion’s cell suffered sufficient physical damage or destruction, or if it is time for the cell to die because of what is known as programmed cell death (aka apoptosis). It would also be set if USID_1 is MY_CELL_IS_IN_STASIS and too much time has elapsed since MY_CELL_IS_IN_STASIS was set. Regarding how much time is “too much time”, it apparently varies depending on what that bion’s cell is a part of: in the two examples above of plant seeds and tardigrades, “too much time” for plant seeds is more than the centuries that many plant seeds have lasted dry and then germinated after planting and watering, and for tardigrades “too much time” is more than the 30 years that tardigrades have been kept desiccated and then brought back to life after adding water. In the case of human sex cells, egg cells and sperm cells have each been frozen and then unfrozen years later, regaining their activity and capability as sex cells. Thus, in the case of human sex cells, the stasis period can last years. From this, it seems likely that “too much time” for human cells in general is measured in years.
When a bion—referred to in this paragraph as this bion to distinguish it from the other bion—has HAVE_NO_CELL as its USID_1 value, then this bion will soon run its learned program for communicating with bions that are ready to divide their cells but need another bion to occupy and control what will be the newly formed cell. The sent message to communicate with bions that are ready to divide their cells, would have for the user_settable_identifiers_block parameter of the send() statement a USID_1 value of MY_CELL_IS_READY_TO_DIVIDE, and the other integers in this parameter are set to null unless a specific cell type for the dividing cell is wanted, in which case USID_6 (see below) would also be set to a non-null value. After successfully finding a bion whose cell is ready to divide, and, in effect, agreeing with that bion to occupy the newly formed cell, this bion would then locate that other bion and move itself to where that other bion is, so that this bion can occupy and control the newly formed cell (and probably also help in the cell-division process): locating that other bion can be done using the learned-program statement get_relative_location_of_bion_uid() (detailed in subsection 5.2.1), and then moving to where that other bion is at can be done by using the learned-program statement move_this_bion() which is detailed later in this subsection.
The second integer (denote as USID_2), in effect, says whether or not the bion is currently with its cell in the same location as its cell. Let these two values be denoted as WITH_MY_CELL and NOT_WITH_MY_CELL.
Note that when a bion is asleep, none of its learned programs are running (section 9.3). In general, a sleeping bion is useless while it is asleep, and, for example, the events of multicellular development only happen with bions that are currently awake and able to run their learned programs. This general uselessness when asleep is the reason why in the above code for the examine_a_message_instance() routine, there is no replying to a GET_LOCATIONS_OF_BIONS request if the recipient bion is asleep, because that sleeping bion is not currently available to interact in any way with whatever awake bion called the learned-program statement get_relative_locations_of_bions() that sent that GET_LOCATIONS_OF_BIONS request.
The third integer (denote as USID_3), gives further detail regarding current status, that supplements the current setting, either WITH_MY_CELL or NOT_WITH_MY_CELL, of USID_2. For the WITH_MY_CELL setting of USID_2, and given what else is currently in this book, I am not defining any specific values for USID_3. But for the NOT_WITH_MY_CELL setting of USID_2, and given the whole subject of bion-body projections covered in chapter 5, and also the detailed procedure given in subsection 5.2.3, I’m defining the following two values for USID_3 when USID_2 is NOT_WITH_MY_CELL:
AWAY_FROM_MY_CELL: The bion is currently away from its cell.
RETURNING_TO_MY_CELL: The bion is not currently with its cell, but is in the process of returning to its cell.
The fourth integer (denote as USID_4) is, in effect, a unique identifier for that multicellular body. The value of this unique identifier is set by the controlling bion of whatever cell was the first cell of that multicellular body, such as a fertilized egg cell. Before it begins dividing, that cell-controlling bion for that first cell, as per one of its learned programs, calls a learned-program statement to get a large random number and then a different learned-program statement to set its USID_4 to the value of that large random number.
Also, the learned programs that handle cell division for a multicellular body, for a cell-controlling bion that will control the new cell that results from a cell division, that bion will copy into its USID_4 the same unique identifier for that multicellular body that the parent cell’s bion has, with the end result that every bion controlling a cell in that multicellular body whose origin traces back to that first cell of that multicellular body, has the same USID_4 value.
The fifth integer (denote as USID_5), in effect, identifies the large-scale structure that bion’s cell will be a part of. I would suppose that each of the bones in a skeleton gets its own structure identifier, and each of the many different muscles that are in different locations in the body and attach at different places, that all these each get its own structure identifier, and likewise for similar situations regarding a structure that occurs more than once in the body. This would also include structures that occur in the body just twice, due to bilateral symmetry, such as two lungs and two eyes. Thus, for example, each of the two eyes has its own structure identifier, so that, in effect, the left eye can always be distinguished from the right eye, whenever needed.
The sixth integer (denote as USID_6), in effect, identifies the type of cell that bion’s cell either currently is, or will shortly be if that cell is currently changing into that cell type. In a human body there are, I suppose, hundreds of different cell types.
The assumption of one bion per cell may be correct for most cell types, but nerve cells with axons may be an exception. Also, as was mentioned in Section 3.1, neurons with a clearly defined axon can transmit a signal in only one direction. To support development involving such neurons, if each such neuron is, in effect, subdivided into three zones: the cell’s signal-start end, the axon length, and the cell’s signal-end end. And each of these three zones has its own cell type that the bion occupying and controlling that zone has as its USID_6 value. In the case of long axons (the axons running down our spines can be several feet long) there may be many bions for that axon along its length.
The seventh integer (denote as USID_7), is used in subsection 6.3.2 to make the initial connections between a mind and a brain. See subsection 6.3.2 for further details.
And let’s also assume that there is a learned-program statement get_relative_locations_of_bions(). In general, this get_relative_locations_of_bions() routine lets a bion learn about other bions in its environment, and where those other bions are in 3D space relative to itself. More specifically, and assuming the user-settable identifiers block detailed immediately above, a cell-controlling bion whose cell is a part of a multicellular body can call get_relative_locations_of_bions() to learn about other cells in that multicellular body, and where those other cells are in 3D space relative to that bion and its cell—assuming that bion is with its cell when it called get_relative_locations_of_bions(). The examine_a_message_instance() routine detailed in subsection 3.8.5 includes calling two routines, reply_to_this_location_request_bions() and process_a_location_reply_from_a_bion(), that are there to support get_relative_locations_of_bions().
The detail of the reply_to_this_location_request_bions() routine follows (note that this routine is called by the examine_a_message_instance() routine that is detailed in subsection 3.8.5):
Note: The parameter requester’s_message_instance is the location request that this routine is replying to. The value of requester’s_message_instance.special_handling_locate is GET_LOCATIONS_OF_BIONS.
Set the message text of this reply, which has three components:
set reply_mt.XYZ to this_CE’s_XYZ /* Note that in this context, this_CE’s_XYZ is the XYZ coordinate of the computing element that currently holds the recipient bion that is, in effect, replying to the location request. */
set reply_mt.transfer_count_to_location to message_instance.transfer_count /* In effect, this is how far message_instance traveled from the sender’s location (a computing element) when it sent this message, to this recipient bion’s location (a computing element). */
set reply_mt.requester’s_instance_identifier to the value of requester’s_message_instance.instance_identifier
/* set other items */
set message_instance.special_handling_locate to LOCATION_REPLY_FROM_BION
set message_instance.send_distance to requester’s_message_instance.send_distance /* Set the reply message to have the same send_distance as the request message. */
The intended recipient of this LOCATION_REPLY_FROM_BION message is the bion that made the location request that resulted in this reply, and that bion’s unique identifier is contained in the requester’s_message_instance parameter. So, extract it from there and set it in the message_instance as the sole recipient of this LOCATION_REPLY_FROM_BION message.
Complete and send this LOCATION_REPLY_FROM_BION message.
Assume that any items defined as being in this message_instance but not explicitly set above are set as stated in subsection 3.8.4 (for example, transfer_count is set to 0). Then, to send this LOCATION_REPLY_FROM_BION message_instance into 3D space, use the same code the send() statement uses to offer a message_instance to the adjacent computing elements.
return /* exit this routine */
The detail of the learned-program statement get_relative_locations_of_bions() follows:
Only a single call of this get_relative_locations_of_bions() routine can be ongoing at any one time, so assume that calling this get_relative_locations_of_bions() routine is protected by a semaphore.
This get_relative_locations_of_bions() routine defines a group of global variables that are visible to the process_a_location_reply_from_a_bion() routine. Access to these globals is protected by a semaphore named grl_globals_exclusive_access.
The get_relative_locations_of_bions() routine, which is a learned-program statement, has three parameters:
The user_settable_identifiers_block parameter identifies the intended bion recipients of the GET_LOCATIONS_OF_BIONS message that will be sent out. The following rule for the send() statement applies: The user_settable_identifiers_block has to have at least one of its values non-null, and the recipient bion(s) of the sent message will be those bions whose user-settable identifiers block has the same non-null values in the same locations as in this user_settable_identifiers_block parameter.
The get_details_for_this_many_nearest_recipients parameter is an integer that specifies how many of the nearest recipients to the bion that is calling this get_relative_locations_of_bions() routine, will have their details returned to the caller by this routine. The returned details are the recipient bion’s identifier block, the recipient bion’s relative location to the calling bion, and the distance between the recipient bion and the calling bion when that recipient bion’s reply was received by the calling bion.
The value of get_details_for_this_many_nearest_recipients can be zero, and if either get_details_for_this_many_nearest_recipients is zero or the number of replies is zero, then the returned ret_nearest_recipients_count will be zero. Otherwise, the returned ret_pointer_to_nearest_recipients_list will point at the first element in the returned nearest-recipients list, and the returned ret_nearest_recipients_count will be the number of elements in that nearest-recipients list (this number will be less than get_details_for_this_many_nearest_recipients if the total number of replies is less than get_details_for_this_many_nearest_recipients). Also, the returned nearest-recipients list will be in ascending distance order (the nearest replying bion will be first in that list, the next-nearest replying bion will be second in that list, and so on).
Given the sphere-filling message-transmission algorithm in subsection 3.8.5, note that the replies received first by process_a_location_reply_from_a_bion() will not necessarily be replies from the nearest replying bions. In fact, including the “roundtrip” consideration described in the next paragraph, the computed distance for each of two different replies received at nearly the same time by process_a_location_reply_from_a_bion(), can vary by as large a factor as 3.46410. For example, if the reply with the smaller computed distance has a computed distance of d, then the distance of the other reply that was received at nearly the same time can be as large as (3.46410 × d).
In the case of get_relative_locations_of_bions() and the replies that result from its sent query message, there is a roundtrip factor of 2, because, before a bion can send its reply message giving its current location, it first has to receive that sent query message. Thus, regarding the total time between sending the query message and receiving back a reply, the time needed for that roundtrip, for two different replying bions that are each at the same distance d from the bion that sent the query message, this roundtrip time can vary between those two replying bions by a factor of as much as (2 × SQUARE_ROOT_OF_3) which is 3.46410 (accurate to 5 decimal places). The actual degree of variance will depend on the XYZ coordinates of those two replying bions and the XYZ coordinate of the bion that sent the query message which is the bion that called get_relative_locations_of_bions(). See subsection 3.8.5 for more explanation, including an explanation of the SQUARE_ROOT_OF_3 factor.
Because the replies are unlikely to be received in ascending distance order, that is the reason for the “insertion sort” that is done in process_a_location_reply_from_a_bion() when inserting a reply into the nearest-recipients list. However, given the linear-time cost of doing this insertion (see the discussion in the comment regarding “insertion sort” in process_a_location_reply_from_a_bion()), that is the reason for a presumed limit on how big the value of get_details_for_this_many_nearest_recipients can be. I don’t have a good basis for guessing this limit, because, among other things, the actual processing speed of a computing element is unknown (even though lower bounds can be estimated for its processing speed). Although it is only a guess, I think the maximum value allowed for get_details_for_this_many_nearest_recipients is somewhere above 100.
The use_this_send_distance parameter is an integer used to set the send_distance value for the constructed GET_LOCATIONS_OF_BIONS message. The maximum value accepted for this parameter is MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_BIONS which I guess is less than 10 feet (about 3 meters). Regarding the needs of multicellular development, it is probably very safe to say that for any two cells that are more than 10 feet apart, their occupying bions are not going to have any need at any time to know where the other of those two cells is in 3D space relative to itself.
As an example of how the first two of the above three parameters would be set, assume the caller is a cell-controlling bion in our world that is already a part of a multicellular body and is currently occupying its cell, and that bion, in its learned program, wants to know the details of the nearest 100 bions that are also cell-controlling bions currently occupying their cells and they are also a part of that multicellular body. In this example, get_details_for_this_many_nearest_recipients is set to 100 and the integers in user_settable_identifiers_block are set as follows: the USID_2 value is set to WITH_MY_CELL, and the USID_4 value is set to the unique identifier for that multicellular body, and the remaining integers in user_settable_identifiers_block are set to null.
get_relative_locations_of_bions(user_settable_identifiers_block, get_details_for_this_many_nearest_recipients, use_this_send_distance)
Prepare the message_instance for the GET_LOCATIONS_OF_BIONS message to be sent. Note that there is no message text for a GET_LOCATIONS_OF_BIONS message.
Although the code for this editing is not shown, before use_this_send_distance is assigned below to message_instance.send_distance, it is first edited to make sure that its value is not less than 1 and not more than MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_BIONS. One can also assume, if one wants, that if use_this_send_distance is null, then its edited value is some default value appropriate for the get_relative_locations_of_bions() statement.
set message_instance.special_handling_locate to GET_LOCATIONS_OF_BIONS
set message_instance.send_distance to the edited value of use_this_send_distance
set message_instance.instance_identifier to (generate a random number; cannot be null)
The parameter user_settable_identifiers_block identifies the recipient bions, so copy it into the message_instance in the same place that the send() statement would put it.
To make the average transfer time from one computing element to the next be the same for both GET_LOCATIONS_OF_BIONS messages and LOCATION_REPLY_FROM_BION messages, two things are done: 1) the macro M_determine_which_of_these_two_ifs_executes()—in the pass_this_message_along() routine in subsection 3.8.5—eliminates directional bias regarding the execution time needed to move a message_instance along an axis in a positive direction (the value of that axis coordinate is increasing) compared to moving that message_instance along that axis in a negative direction (the value of that axis coordinate is decreasing); and 2) both the GET_LOCATIONS_OF_BIONS message_instance and the LOCATION_REPLY_FROM_BION message_instance will have the same size:
In the process_a_location_reply_from_a_bion() routine detailed further below, the transfer_count to and from each recipient bion is used, in effect, as a precise timer with the implication that the average transfer time from one computing element to the next will be the same for both the GET_LOCATIONS_OF_BIONS message sent out to the specified recipients, and for the LOCATION_REPLY_FROM_BION messages sent back by those recipients. To make this average transfer time sufficiently the same for both these two message types, the size of the GET_LOCATIONS_OF_BIONS message_instance is made the same size as the size of the LOCATION_REPLY_FROM_BION message_instance (by “same size” is meant the same number of bytes or whatever unit of memory is used by computing elements).
Comparing the message_instance sizes, each LOCATION_REPLY_FROM_BION message_instance has as its message text the fixed-format fixed-size reply_mt (defined in the reply_to_this_location_request_bions() routine above), whereas the GET_LOCATIONS_OF_BIONS message_instance has no message text. Let AA be the size of reply_mt. Also, the LOCATION_REPLY_FROM_BION message_instance has only a single bion as its recipient, which is identified by a bion’s fixed-format fixed-size unique identifier (let BB be the size of a bion’s unique identifier), whereas the GET_LOCATIONS_OF_BIONS message_instance has a fixed-format fixed-size user_settable_identifiers_block to identify its recipients (let CC be the size of a user_settable_identifiers_block). Note that I’m assuming CC > BB, and AA > (CC − BB). Thus, to make the two message_instance sizes the same, add dummy padding in the amount of (AA − (CC − BB)) to increase the size of the GET_LOCATIONS_OF_BIONS message_instance so that it will be the same size as each LOCATION_REPLY_FROM_BION message_instance.
At this point in this routine assume the message_instance to be sent is complete and ready to be offered to the adjacent computing elements.
Now initialize global variables that will be visible to the process_a_location_reply_from_a_bion() routine which is detailed further below.
set match_this_instance_identifier to the value of message_instance.instance_identifier
set to zero: sum_all_relative_X, sum_all_relative_Y, sum_all_relative_Z, total_replies, nearest_recipients_count
set requested_nearest_count to the value of the get_details_for_this_many_nearest_recipients parameter
allocate enough memory for a list that can hold as many elements as specified by requested_nearest_count. Each element in this list has three components: the replying bion’s identifier block; the replier’s_XYZ_relative_to_000 that is computed in the process_a_location_reply_from_a_bion() routine; and the computed distance between (0, 0, 0) and replier’s_XYZ_relative_to_000.
set pointer_to_nearest_recipients_list to point at the location in memory of the just-allocated list
Note: The execution of the following short block of code—that begins immediately below with setting XYZ_start and ends immediately after the GET_LOCATIONS_OF_BIONS message is sent—should be executed with the same high priority as used for message transmission.
set XYZ_start to this_CE’s_XYZ
Initialization of globals is complete.
Complete and send the GET_LOCATIONS_OF_BIONS message.
Assume that any items defined as being in this message_instance but not explicitly set above are set as stated in subsection 3.8.4 (for example, transfer_count is set to 0). Then, to send this GET_LOCATIONS_OF_BIONS message_instance into 3D space, use the same code the send() statement uses to offer a message_instance to the adjacent computing elements.
At this point the GET_LOCATIONS_OF_BIONS message has been sent out, and this routine will now wait for the replies to come in. The replies are processed by the process_a_location_reply_from_a_bion() routine. While waiting for the replies to come in, this_CE can execute other threads of execution depending on priorities.
The reason for the below multiplier (2 × SQUARE_ROOT_OF_3), which has the value 3.46410 (accurate to 5 decimal places), is explained above in the remarks regarding the get_details_for_this_many_nearest_recipients parameter.
set estimated_time_to_wait to ((2 × SQUARE_ROOT_OF_3) × (the edited value of use_this_send_distance) × (an estimated average time for transferring the message_instance from a computing element to an adjacent computing element))
halt execution of this thread and wait estimated_time_to_wait, during which time other threads of execution can run.
At this point all replies, in the time allowed, have been received.
set match_this_instance_identifier to null /* no more replies to the sent message accepted */
Compute the centroid for all the replying bions. The centroid is easy to compute and can be useful in the case of multicellular development. Note that centroid_XYZ_relative_to_000 is a local variable, not a global variable.
set centroid_XYZ_relative_to_000.X to (sum_all_relative_X ÷ total_replies)
set centroid_XYZ_relative_to_000.Y to (sum_all_relative_Y ÷ total_replies)
set centroid_XYZ_relative_to_000.Z to (sum_all_relative_Z ÷ total_replies)
For those globals whose current values will be returned, copy those values from those global variables to local variables, and then return these local variables.
set ret_total_replies to total_replies
set ret_nearest_recipients_count to nearest_recipients_count
set ret_pointer_to_nearest_recipients_list to pointer_to_nearest_recipients_list
set pointer_to_nearest_recipients_list to null /* this global no longer has access to that list */
return the results
return ret_total_replies, centroid_XYZ_relative_to_000, ret_nearest_recipients_count, ret_pointer_to_nearest_recipients_list /* exit this routine */
The detail of the process_a_location_reply_from_a_bion() routine follows (note that this routine is called by the examine_a_message_instance() routine that is detailed in subsection 3.8.5):
Note: The parameter message_instance is a reply to a location request made by this_bion. The value of message_instance.special_handling_locate is LOCATION_REPLY_FROM_BION.
set XYZ_stop to this_CE’s_XYZ
if message_instance.reply_mt.requester’s_instance_identifier is not the same as match_this_instance_identifier
return /* ignore this message_instance and exit this routine */
The purpose of the next three labeled steps is for the computed value in replier’s_XYZ_relative_to_000 to be the replying bion’s XYZ location relative to this_bion’s computed XYZ location when that replying bion’s XYZ location—the value in message_instance.reply_mt.XYZ—was set in the reply_to_this_location_request_bions() routine.
The idea of step 1 is that we want to know how far along on the vector from XYZ_start to XYZ_stop was this_bion when the replying bion copied its XYZ location into message_instance.reply_mt.XYZ. As stated in the code for the above get_relative_locations_of_bions() routine, the average transfer time from one computing element to the next is the same for the two message types involved (a GET_LOCATIONS_OF_BIONS message_instance and a LOCATION_REPLY_FROM_BION message_instance), and this means that the transfer_count_to which came from a GET_LOCATIONS_OF_BIONS message_instance, and the transfer_count_from which came from this LOCATION_REPLY_FROM_BION message_instance being processed by this routine, have the same unit of time. Thus, ((transfer_count_to + transfer_count_from) × that average transfer time from one computing element to the next) is the total time that this_bion took to go from XYZ_start to XYZ_stop, and dividing (transfer_count_to + transfer_count_from) into transfer_count_to gives how far along on that (XYZ_start, XYZ_stop) vector this_bion was when the replying bion copied its XYZ location into message_instance.reply_mt.XYZ.
Regarding the value of vector_fraction computed in step 1, in our world the value will be at or close to ½ (0.5), assuming that messages move thru 3D space much, much faster than our Earthly biosphere is moving thru 3D space. In general, the greatest deviation of the computed vector_fraction from being ½ will be when the replying bion lies on the line that runs thru XYZ_start and XYZ_stop, and the least deviation of the computed vector_fraction from being ½ will be when the line that runs thru this_bion and the replying bion is at a right angle to the line that runs thru XYZ_start and XYZ_stop.
Step 2 computes the location of this_bion when the replying bion’s message_instance.reply_mt.XYZ value was set. Note that this computation assumes that this_bion moved thru 3D space in a straight line from XYZ_start to XYZ_stop, when in actuality on our Earth, this_bion moved along a curve because of the rotation of our Earth and the effect of gravity on our Earth. This error is considered separately after the following three steps are given.
Step 3 simply subtracts step 2’s this_bion’s_XYZ from message_instance.reply_mt.XYZ, giving replier’s_XYZ_relative_to_000, which is, in effect, the replying bion’s location relative to this_bion’s_XYZ being relocated to XYZ coordinate (0, 0, 0). Note that the actual math is to subtract this_bion’s_XYZ from both this_bion’s_XYZ (which gives (0, 0, 0)) and from message_instance.reply_mt.XYZ (which gives replier’s_XYZ_relative_to_000).
For steps 2 and 3, the arithmetic is signed. Also, any computed .X, .Y, or .Z value for this_bion’s_XYZ in step 2 that is not an integer is rounded to the nearest integer before assignment to that .X, .Y, or .Z. For example, if vector_fraction is 0.5, and XYZ_start.X is 9, and XYZ_stop.X is 5, and message_instance.reply_mt.XYZ.X is 6, then this_bion’s_XYZ.X is (9 + (0.5 × –4)) which is 7, and replier’s_XYZ_relative_to_000.X is (6 − 7) which is –1. In this same example, if instead vector_fraction is 0.498, then this_bion’s_XYZ.X is (9 + (0.498 × –4)) which is (9 + –1.992) which is 7.008 which rounds to 7, thus this_bion’s_XYZ.X is set to 7.
/* step 1: */
set transfer_count_to to message_instance.reply_mt.transfer_count_to_location
set transfer_count_from to message_instance.transfer_count
set vector_fraction to (transfer_count_to ÷ (transfer_count_to + transfer_count_from))
/* step 2: */
set this_bion’s_XYZ.X to (XYZ_start.X + (vector_fraction × (XYZ_stop.X − XYZ_start.X)))
set this_bion’s_XYZ.Y to (XYZ_start.Y + (vector_fraction × (XYZ_stop.Y − XYZ_start.Y)))
set this_bion’s_XYZ.Z to (XYZ_start.Z + (vector_fraction × (XYZ_stop.Z − XYZ_start.Z)))
/* step 3: */
set replier’s_XYZ_relative_to_000.X to (message_instance.reply_mt.XYZ.X − this_bion’s_XYZ.X)
set replier’s_XYZ_relative_to_000.Y to (message_instance.reply_mt.XYZ.Y − this_bion’s_XYZ.Y)
set replier’s_XYZ_relative_to_000.Z to (message_instance.reply_mt.XYZ.Z − this_bion’s_XYZ.Z)
At this point we have in replier’s_XYZ_relative_to_000 the replying bion’s XYZ coordinate relative to this_bion being at coordinate (0, 0, 0). Let’s now consider in the attached footnote the error that results in the above step 2 where this_bion’s_XYZ is computed, because the physical biosphere on our Earth is not moving thru space in a perfectly straight line, but instead is moving along a curve (note that the size of this error in step 2 carries over into step 3 which subtracts this_bion’s_XYZ from the replying bion’s XYZ). As shown in the footnote, the error is insignificant in the case of the real-world needs of multicellular development.
increment total_replies /* add 1 to it */
Note: sum_all_relative_X, sum_all_relative_Y, and sum_all_relative_Z will be used in the get_relative_locations_of_bions() routine, after all replies have been received, to compute the centroid for all the replying bion’s.
set sum_all_relative_X to (sum_all_relative_X + replier’s_XYZ_relative_to_000.X)
set sum_all_relative_Y to (sum_all_relative_Y + replier’s_XYZ_relative_to_000.Y)
set sum_all_relative_Z to (sum_all_relative_Z + replier’s_XYZ_relative_to_000.Z)
If conditions are met, insert the reply—more specifically, insert together three relevant details regarding the replying bion—into the current nearest-recipients list.
if requested_nearest_count is greater than 0
set distance to (use the distance formula to compute the distance between (0, 0, 0) and replier’s_XYZ_relative_to_000)
Regarding the nearest-recipients list, assume that pointer_to_nearest_recipients_list is the first element in that list, pointer_to_nearest_recipients_list is the second element in that list, and so on. The nearest_recipients_count is the current number of nearest-recipients in this nearest-recipients list.
Without showing the code to do an “insertion sort”, assume that an insertion sort is done here. For a description of the insertion sort, see, for example, Insertion sort at https://en.wikipedia.org/wiki/Insertion_sort.
At the end of the code that goes here (not shown), the reply—its relevant details; see the allocate statement in get_relative_locations_of_bions() for a description of the three components in each pointer_to_nearest_recipients_list element—has either been inserted into the nearest-recipients list or not. As long as nearest_recipients_count is less than requested_nearest_count, then the reply is inserted into the nearest-recipients list and the nearest_recipients_count is incremented by 1. But if nearest_recipients_count already equals requested_nearest_count, then, to be inserted into the nearest-recipients list, the reply’s distance, computed above, has to be less than the distance of the last element in the nearest-recipients list, which is pointer_to_nearest_recipients_list[nearest_recipients_count].distance, and, if so, then the reply is inserted into the nearest-recipients list and this insertion will, in effect, push what was the last element in the nearest-recipients list, out of that list (deleting it from that list), and the nearest_recipients_count will still be equal to requested_nearest_count.
If the reply was inserted, then at the end of this insertion, the elements currently in the nearest-recipients list will always be in ascending distance order. More specifically, if nearest_recipients_count is greater than 1, then for all values of n between 1 and (nearest_recipients_count − 1) inclusive, the following will always be true: the value of pointer_to_nearest_recipients_list[n].distance is less than or equal to the value of pointer_to_nearest_recipients_list[n + 1].distance.
For those familiar with time complexity for an algorithm, inserting a reply into this nearest-recipients list will have linear-time cost, and this linear-time cost to do an insertion will be proportional to the current value of nearest_recipients_count, which will have the value of the get_details_for_this_many_nearest_recipients parameter as soon as that many replies have been received. Because of this linear-time cost, but at the same time there is a need to process the replies quickly so that the reply messages, in effect, do not pile up in a big way, awaiting processing by this bion: one can assume that the computing-element program imposes a limit on how large the value of the get_details_for_this_many_nearest_recipients parameter can be. For a guess of what this limit is, see the description of the get_details_for_this_many_nearest_recipients parameter.
return /* exit this routine */
Among other things, the detailed data structures and routines presented above in section 3.8 provide a firm foundation for the observed multicellular development that happens in our world, and shows that it is possible to explain something as mysterious as multicellular development by assuming an underlying computation layer (the computing elements) and programming (the computing-element program and learned programs). Of course, regarding all this complexity—a computation layer and a lot of programming in the computing-element program—why should all this underlying complexity exist? To this kind of question I am reminded of the answer my dad gave me when I was very young and I asked him a philosophical question—I no longer remember exactly what I asked, but his reply has stayed with me: Why should anything exist? he answered. But a lot obviously does exist, and an underlying computation layer along with a lot of programming is the best way to explain the more complex objects in existence, such as ourselves.
Regarding the Particle Details returned by the various get_relative_location…() learned-program statements described in this Book
This book names and describes a total of eight different learned-program statements that each compute the relative location—the replier’s_XYZ_relative_to_000—of each replying particle. These eight learned-program statements are:
For each of these eight learned-program statements, whenever the detail of one or more replying particles is returned by a call of that learned-program statement, the returned detail of a replying particle always has three components:
Non-location info about that particle. If the replying particle is a bion, then this returned info is the sender’s_identifier_block. If the replying particle is an atom, then this returned info includes that atom’s unique identifier and whatever additional non-location info is specified for that learned-program statement.
The replier’s_XYZ_relative_to_000, which is computed as shown in process_a_location_reply_from_a_bion(). This is the location of the replying particle, relative to the location of the calling bion, when that calling bion’s location is normalized to point (0, 0, 0).
The reason to normalize the calling bion’s location to point (0, 0, 0), is because doing so simplifies a few things, including some of the math. This normalization also avoids allowing learned programs to deal with the actual XYZ coordinates of particles. Instead, only relative coordinates, relative to the calling bion, are allowed.
The distance between the calling bion and the replying particle, which is simply the distance between the point (0, 0, 0) and the point replier’s_XYZ_relative_to_000. This distance is computed using the distance formula, which in this case, with one of the two points being (0, 0, 0), simplifies to:
distance = square_root_of((replier’s_XYZ_relative_to_000.X)2 + (replier’s_XYZ_relative_to_000.Y)2 + (replier’s_XYZ_relative_to_000.Z)2)
A typical use by the calling bion of a replying particle’s replier’s_XYZ_relative_to_000, is if that calling bion, in effect, decides to move closer to that particle. In general, a bion has to be able to move in 3D space. To move itself, assume there is a move_this_bion() learned-program statement. At the very least, any call of move_this_bion() must specify as a parameter the wanted direction of movement (additional parameters probably include how far to move and how fast to move, and perhaps also whether to move in the opposite direction (see below)).
To be consistent with replier’s_XYZ_relative_to_000, assume that move_this_bion()’s direction-to-move parameter (denote as XYZ_head) is an XYZ coordinate relative to point (0, 0, 0). In effect, (0, 0, 0) is the tail-point and XYZ_head is the head-point of this direction-to-move vector. Then, the first thing the code in move_this_bion() would do is translate this direction-to-move vector (translating a vector moves the vector without changing its orientation and length) so that that vector’s tail-point is the current location of the bion that is calling move_this_bion():
/* Translate the direction-to-move vector. */
set dtm_tail_XYZ.X to this_CE’s_XYZ.X
set dtm_tail_XYZ.Y to this_CE’s_XYZ.Y
set dtm_tail_XYZ.Z to this_CE’s_XYZ.Z
set dtm_head_XYZ.X to (XYZ_head.X + this_CE’s_XYZ.X)
set dtm_head_XYZ.Y to (XYZ_head.Y + this_CE’s_XYZ.Y)
set dtm_head_XYZ.Z to (XYZ_head.Z + this_CE’s_XYZ.Z)
As an example of using move_this_bion(): If a bion calls get_relative_location_of_one_physical_atom() and then wants to move closer to that atom, that bion can then call move_this_bion() after setting the XYZ_head parameter to the value of that atom’s replier’s_XYZ_relative_to_000. If, for some reason, that bion wants to instead move in the opposite direction to that atom, that bion, after setting the XYZ_head parameter to the value of that atom’s replier’s_XYZ_relative_to_000, can then set another move_this_bion() parameter, that, in effect, tells move_this_bion() to move in the opposite direction of the given direction-to-move vector, in which case move_this_bion() will reverse the signs of the X, Y, and Z components of the XYZ_head parameter before doing the above vector translation. For example, if the value of XYZ_head is (−13, 8, 17), then after the sign reversals its value would be (13, −8, −17).
When I first thought about how to get the relative locations of bions, I realized I needed an absolute coordinate system for 3D space, rooted in the computing elements, and that is why I assume that for any specific computing element, it will have a unique XYZ coordinate that cannot be changed. If one grants the existence of the computing elements, then it is a small step and not unreasonable to also grant that a computing element’s state information includes an XYZ coordinate, that, in effect, gives that computing element’s location within the great number of computing elements that, in effect, comprise the 3D space of our universe.
Also, when I was thinking about how to get the relative locations of bions, I realized that if one assumed that each computing element had a precise time clock, and all the computing elements had the same time on their precise time clocks, then I could make a simplification to my solution (given above in subsections 3.8.5 and 3.8.6) for getting the relative locations of bions, because making both the GET_LOCATIONS_OF_BIONS message and the LOCATION_REPLY_FROM_BION messages have the same average transfer time from one computing element to the next, was only necessary because of how I compute vector_fraction. If instead, all the computing elements have the same time on their precise time clocks, then each LOCATION_REPLY_FROM_BION message could include a timestamp of when the message_instance.reply_mt.XYZ value was set, and vector_fraction can then be computed as (((that timestamp time) − (the time when start_XYZ was set)) ÷ ((the time when stop_XYZ was set) − (the time when start_XYZ was set))).
However, the reason I rejected the all-clocks-have-the-same-time approach, is because it seemed too unreasonable, because either one assumes something like each computing element has a perfect high-precision time clock with zero time drift, and whenever a specific computing element came into existence its time clock started with whatever the current time was on the time clocks of all the other computing elements, if any, already in existence; or, even more unreasonable, one assumes something like instead of each computing element having its own high-precision time clock, there is a single high-precision time clock that is separate from the computing elements but somehow the current time on that clock can be read instantly at any time by any computing element.
That a computing element has a time clock is reasonable, but that all computing elements have the exact same time on their time clocks is unreasonable. There are clock-synchronization algorithms already in use in our world of physical computers, so that computers that are widely separated geographically can have the same or nearly the same clock time, depending on how accurate the clocks are supposed to be. However, in the case of the computing elements, even if one assumes that the most efficient clock-synchronization algorithm possible is being run by the computing-element program to keep computing-element clocks synchronized, it seems to me like a big cost—in terms of the ongoing computing needed at every computing element running that clock-synchronization algorithm—for the small gain of being able to mix in certain algorithms timestamps that came from different computing elements.
In the above code for get_relative_locations_of_bions() is the line “halt execution of this thread and wait estimated_time_to_wait, during which time other threads of execution can run.” Keeping track of elapsed time would be easy if one could always refer to the same accurate clock, but all the bions on our Earth are moving thru 3D space at roughly 1/245th of lightspeed (see the footnote in this subsection), which means that the computing element that a specific bion on Earth was in a second ago, is now more than 1.22 million meters distant from the computing element that bion is in one second later (1.22 million meters is about 758 miles). How can the above-quoted “wait estimated_time_to_wait” be done without assuming that widely separated computing elements have the same time on their clocks, because, as stated above, I reject the idea that every computing element has the same time on its clock? Although I’m allowing computing-element clocks to have different times on their clocks when compared to each other, I’m assuming—regarding the solution given in the next paragraph—that all computing-element clocks are ticking at very close to the same rate, and this assumption is reasonable.
A basic solution is to assume that a bion’s state information includes a big integer named this_bion’s_accumulated_clock_ticks, which was initialized to zero when that bion was created. And, in the computing-element program, is code that does the following: As already stated in section 1.6, a particle is moved from a computing element (denote as CE1) to an adjacent computing element (denote as CE2) by “simply copying that particle’s information block from the computing element that currently holds that particle, to an adjacent computing element that becomes the new holder of that particle, and then at the computing element that no longer holds that particle: in effect, delete that particle’s information block from that computing element’s memory.” In the case of moving a bion, immediately before starting that copying of that bion’s information block from CE1 to CE2, the following is done at basically the same time in CE1 and CE2: in CE2, a big integer in CE2’s memory, named time_this_CE_got_this_bion, is set to the current time on CE2’s internal clock; in CE1, add to the bion’s current this_bion’s_accumulated_clock_ticks value the number of clock ticks that this computing element has held that bion, which is, for the purpose of this calculation, defined as ((current time on CE1’s internal clock) − (CE1’s time_this_CE_got_this_bion)).
With each bion having its own this_bion’s_accumulated_clock_ticks, which is maintained by the computing-element program as detailed in the previous paragraph, it is easy for each bion to keep track of elapsed time. For example, assume there is a learned-program statement wait_this_long() that has one parameter named total_clock_ticks_to_wait which is an integer whose value is set to the number of clock ticks to wait. Then, for a bion, the computing-element program does the following to execute wait_this_long(): it halts execution of the thread that called wait_this_long(), and saves in that bion’s memory regarding this execution thread a big integer named when_to_resume_execution that is set to (total_clock_ticks_to_wait + this_bion’s_accumulated_clock_ticks). And, regarding how and when the end of the wait time is determined: If the bion is not currently asleep, then, immediately after the bion’s information block has been copied to CE2 (see the previous paragraph) and CE2’s computing-element program is ready to resume running the bion’s current execution threads, CE2’s computing-element program does the following check for each of the bion’s current execution threads, if any, that have when_to_resume_execution set: if this_bion’s_accumulated_clock_ticks is greater than the thread’s when_to_resume_execution value, then end that wait and resume execution of that thread; otherwise, that execution thread remains waiting and won’t be checked again until a different computing element holds this bion and this bion is not asleep.
The following is an example of using wait_this_long() to impose a delay of three months between doing action A and doing action B:
do action A.
do action B if all other requirements for doing action B, if any, are met.
In procedures and learned programs given later in this book, where it is said to wait a specific amount of time—instead of waiting for a specific event to happen, such as waiting to receive a specific message—in these cases, one can assume that the learned-program statement wait_this_long() is used to wait that specific amount of time. For example, in step 5 of the first “basic procedure” given in subsection 5.2.1, it says: “Given the returned distance and how fast one’s awareness/mind is moving towards that bion, compute the estimated time to reach that bion. Then wait a fraction of that estimated time—a fraction close to, but less than 1 (for example, 97/100ths would be good)—before doing step 6”. In this example, the time to wait, in terms of clock ticks, is first computed, and then wait_this_long() is called with that computed time to wait as its parameter.
In addition to the learned-program statement wait_this_long(), also assume there is a learned-program statement get_this_bion’s_accumulated_clock_ticks() that returns the current value of this_bion’s_accumulated_clock_ticks. This learned-program statement, get_this_bion’s_accumulated_clock_ticks(), can be used to time or delay an event that involves more than a single execution thread and/or learned program. And, get_this_bion’s_accumulated_clock_ticks() also gives a bion’s learned programs a way to timestamp data when that data is stored in that bion’s memory, by storing along with that data a timestamp set to the value returned by get_this_bion’s_accumulated_clock_ticks(). Then, the current age of that stored data can be determined whenever that stored data is accessed at a later time by any of that bion’s learned programs: the current age of that stored data is simply the elapsed time computed as (get_this_bion’s_accumulated_clock_ticks() − (that stored data’s timestamp)).
In one’s human mind, it should be obvious that many of one’s memories are, in effect, timestamped, such as one’s personal memories of events in one’s life, so that one can consciously know when a given remembered event happened. Also, by timestamping memories, one’s mind can delete old memories to make room for new memories. Besides one’s various memories being timestamped, each entry in one’s soliton directory (subsection 5.1.1) has at least two timestamps: one timestamp set to get_this_bion’s_accumulated_clock_ticks() when that entry was added to one’s soliton directory (this timestamp allows the age of that entry to be computed); and a different timestamp set to get_this_bion’s_accumulated_clock_ticks() each time that entry’s total_relationship_score is changed by a significant amount (this timestamp allows the age of the last significant update to that score to be computed). These two ages would be computed and used by the algorithm that determines which entry in the soliton directory to delete when room is needed for adding a new entry.
 Regarding how our world is moving thru 3D space, let’s use the following numbers (from the 2010 article by Marshall Brain (an apparent pseudonym), titled Good question – How fast are you moving through the universe right now? at http://www.brainstuffshow.com/blog/good-question-how-fast-are-you-moving-through-the-universe-right-now/):
The Earth makes one complete rotation in 24 hours: from this rotation, the Earth’s surface at the equator is moving at about 1,037 MPH (miles per hour). The Earth’s diameter is about 7,920 miles.
The Earth makes one complete orbit around the sun in 365 days: the Earth is moving in its orbit at about 66,666 MPH. The Earth is about 93 million miles distant from the sun.
Our solar system is in the Milky Way galaxy and orbits the gravitational center of our galaxy at a speed of about 420,000 MPH: we are about 25,000 light years away from that gravitational center and it takes us about 250 million years to make one complete orbit around that gravitational center.
Our Milky Way galaxy as a whole is also moving thru space. The article gives different numbers and concludes with a rough estimate of our galaxy moving at 1,000 kilometers per second (2,237,000 MPH). The article does not suggest any orbit for our galaxy, and checking elsewhere on the internet confirms no well-founded claims of orbiting for our galaxy.
Note that the article, to compute an upper bound for the maximum speed that we are moving thru 3D space, adds up the above four numbers: 1,037 MPH + 66,666 MPH + 420,000 MPH + 2,237,000 MPH = 2,724,703 MPH (this is about 1/245th of lightspeed).
To estimate the error in replier’s_XYZ_relative_to_000 that results from the combination of our Earth’s rotation, our Earth’s orbit around the sun, and our solar system’s orbit around our galaxy’s gravitational center, an upper bound for each of these three errors is computed separately below, and then all three of these upper bounds are added together to get a composite upper bound on the error. Also, regarding multicellular development, note that, in general, the closer two cells are to each other, the more important to have a precise location of the other cell, and conversely, the further away two cells are from each other, the less important to have a precise location of the other cell. However, the closer that two cells are to each other, the quicker messages will travel between their occupying bions because of the shorter distance between them, which means less time for the three errors under consideration to accumulate and become significant. So, to give these three errors more of a chance to appear significant, assume a large separation distance of 3 inches (7.62 centimeters).
To compute the error, we have to make an assumption about how fast the messages (the sent GET_LOCATIONS_OF_BIONS message, and the replying LOCATION_REPLY_FROM_BION messages) are moving thru 3D space. First we compute the error assuming these messages are moving at lightspeed, and then we compute the error assuming these messages are moving at half the speed of gravity messages:
For a message moving at lightspeed, its speed is 186,282 miles per second × 5,280 feet in a mile × 12 inches in a foot = 11,802,827,520 inches per second. For the message to go 3 inches takes 3 ÷ 11,802,827,520 = 0.000000000254 seconds (rounded to 3 significant digits). The roundtrip—the message from this_bion to the replying bion and the replying bion’s message back to this_bion—covers 6 inches and takes 0.000000000508 seconds.
(In this paragraph, to use the same orbit terminology, consider the rotation of the Earth at its surface on the Equator as an orbit:) To compute for each of the three cases—the Earth’s rotation, the Earth’s orbit around the sun, and our solar system’s orbit around our galaxy’s gravitational center—an upper bound for the error in replier’s_XYZ_relative_to_000 that is caused by that case, a good upper bound—good in the sense of not being too far above the smallest upper bound that can be proven—can be computed as follows: Given the diameter of the orbit, divide that diameter by the time needed to complete half that orbit, to get the speed that this_bion is moving in the direction of the orbited center. Let S be this speed in inches per second, and let Derr be the wanted upper bound of the error resulting from this case. Then, given 3 inches as the separation distance between this_bion and the replying bion, Derr is simply S × the time needed for the 6-inch roundtrip which is 0.000000000508 seconds. Computation of this upper bound for the three cases follows:
Case 1, rotation of the Earth: S = (7,920 miles × 5,280 feet in a mile × 12 inches in a foot) ÷ ((24 hours ÷ 2) × 3,600 seconds in an hour) = 501,811,200 inches ÷ 43,200 seconds = 11,616 inches per second
Derr = 11,616 inches per second × 0.000000000508 seconds = 0.0000059 inches
Case 2, the Earth orbiting the sun: S = ((93,000,000 miles × 2) × 5,280 feet in a mile × 12 inches in a foot) ÷ ((365 days ÷ 2) × 24 hours in a day × 3,600 seconds in an hour) = 11,785,000,000,000 inches ÷ 15,768,000 seconds = 747,400 inches per second
Derr = 747,400 inches per second × 0.000000000508 seconds = 0.00038 inches
Case 3, our solar system orbiting the gravitational center of our Milky Way galaxy: S = (((25,000 light years × 2) × 5,878,500,000,000 miles in a light year) × 5,280 feet in a mile × 12 inches in a foot) ÷ ((250,000,000 years ÷ 2) × 365 days in a year × 24 hours in a day × 3,600 seconds in an hour) = 18,623,000,000,000,000,000,000 inches ÷ 3,942,000,000,000,000 seconds = 4,724,300 inches per second
Derr = 4,724,300 inches per second × 0.000000000508 seconds = 0.0024 inches
Adding together the above three Derr values gives us:
0.0000059 inches + 0.00038 inches + 0.0024 inches = 0.0028 inches (0.0071 centimeters)
So, in the case of multicellular development, and two bions (and their cells) that are 3 inches apart from each other, the error—assuming that the messages are moving at lightspeed—for either bion using the get_relative_locations_of_bions() routine to get the other bion’s location is at worst about 0.0028 inches, which means that replier’s_XYZ_relative_to_000, which is the computed point in 3D space for that other bion’s location relative to this_bion being at point (0, 0, 0), may be as much as 0.0028 inches distant, in some unknown direction, from the actual location of that other bion in 3D space relative to this_bion being at point (0, 0, 0). Also note that the error is linear with the separation distance between the two bions: for example, if the separation distance is doubled to 6 inches, the error is doubled to 0.0056 inches; if the separation distance is halved to 1.5 inches, the error is halved to 0.0014 inches. It seems reasonable to conclude that the error is small enough that multicellular development will not be negatively affected by it, and there is no need for a more precise algorithm for computing replier’s_XYZ_relative_to_000 than the one I give in this book.
Instead of the assumption in the previous paragraph that the messages are moving at lightspeed, assume that the messages are moving at half the speed of gravity messages. As stated in section 1.1, the actual speed of gravity—which I assume involves the transmission of gravity messages—has been computed by astronomer Tom Van Flandern as being not less than 20 billion times the speed of light (2×1010c). Thus, moving at half the speed of gravity messages is moving at least as fast as (1010 × lightspeed), and the above computed error of 0.0028 inches must be divided by 1010 assuming this faster speed for transmission thru 3D space of the GET_LOCATIONS_OF_BIONS and LOCATION_REPLY_FROM_BION messages, which gives an estimated relative-location error of 0.00000000000028 inches instead of 0.0028 inches, for the two bions (and their cells) separated by 3 inches.
3.8.7 The Learned-Program Statements for Seeing and Manipulating Physical Matter have a very Short Range
By physical matter is meant physical atoms and molecules. The purpose of this subsection is to give the reasons for concluding that the learned-program statements for directly seeing and manipulating physical matter have a very short range, in terms of the maximum distance allowed between an atom and a bion that calls a learned-program statement to see or manipulate that atom (an exception to this short range is getting the relative location of a single physical atom identified by its unique identifier, described in subsection 3.8.9). I estimate that this short range is less than one-tenth of a millimeter (less than 1/250th of an inch).
Calling the learned-program statement get_relative_locations_of_physical_atoms(), which is detailed in subsection 3.8.8, is how a bion can directly see the physical matter in its surrounding environment. This learned-program statement returns a count of the replying atoms and their centroid relative to the calling bion, and can also return in a sorted list, details about the nearest replying atoms, including the replying atom’s location in 3D space relative to the calling bion (see the description of the get_details_for_this_many_nearest_recipients parameter in subsection 3.8.6; the returned list is in ascending distance order—the distance between that replying atom and the calling bion). The furthest away that an atom can be from that calling bion and still be seen by that call is MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS whose value I estimate as being less than one-tenth of a millimeter (less than 1/250th of an inch).
Before proceeding further, note the following common-sense rule, because a bion should not be able to directly manipulate a physical atom that lies outside of that bion’s surrounding environment in which that bion can directly see any physical matter in that surrounding environment:
The distance at which a bion can directly manipulate one or more physical atoms by calling a learned-program statement, cannot exceed the maximum distance at which that bion can directly see any and all of the physical atoms surrounding that bion by calling the get_relative_locations_of_physical_atoms() learned-program statement.
Thus, the distance limit for get_relative_locations_of_physical_atoms(), which is MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS, is also the distance limit for any learned-program statement that directly manipulates physical atoms. Besides learned-program statements that, in effect, move physical atoms and/or affect chemical bonds, directly manipulating physical atoms would also include any learned-program statements that transmute physical atoms or materialize physical atoms, if any such learned-program statements exist.
The following three reasons each argue for a short range for directly seeing and manipulating physical matter:
Given the above rule that the distance limit for directly seeing physical matter is also the distance limit for directly manipulating physical matter, it is only necessary to argue for a short range for directly seeing physical matter:
The reason for such a short range for directly seeing physical atoms is to keep the computation cost of calling get_relative_locations_of_physical_atoms() reasonable: In our reality, it appears that physical atoms greatly outnumber intelligent particles. For example, an adult human body has about 50 trillion cells, and if one assumes one cell-controlling bion per cell, that’s about 50 trillion bions, or 5 × 1013 bions. In comparison, an adult human body weighing 70 kilograms (154 pounds) is estimated to have 7 × 1027 atoms (see How many atoms are in the human body? at http://education.jlab.org/qa/mathatom_04.html). Generalizing for a multicellular organism: there are about 1014 atoms per cell, and assuming one cell-controlling bion per cell, about 1014 atoms (100 trillion atoms) for every cell-controlling bion in that multicellular organism.
The computation cost for a bion calling get_relative_locations_of_physical_atoms() is proportional to the number of atoms whose reply messages are received by that bion during that call. Because there can be so many atoms in such a tiny volume, reducing the volume of space that can be examined by a call of get_relative_locations_of_physical_atoms() is the most direct way to limit the computation cost of that call, and this means a short distance for MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS.
Regarding get_relative_locations_of_physical_atoms(), another consideration is the possibility of too many reply messages in too short a time for the calling bion—the bion that called get_relative_locations_of_physical_atoms() which sent the GET_LOCATIONS_OF_PHYSICAL_ATOMS message—to process all those replies. Let x be the transfer_count of the received GET_LOCATIONS_OF_PHYSICAL_ATOMS message_instance at a replying atom, and let y be the transfer_count of that atom’s reply message_instance when it is received by the calling bion. If the sum (x + y) for replying atom A is the same or nearly the same sum as the sum (x + y) for replying atom B, then atom A’s reply and atom B’s reply will both be received at the calling bion at nearly the same time (note: assuming that a computing element can only have copied to it one message_instance at a time, then it’s not possible for the calling bion to receive both atom A’s reply and atom B’s reply at the exact same time).
For the math given in this paragraph, assume the same uniform distribution of replying atoms in the sphere filled by the GET_LOCATIONS_OF_PHYSICAL_ATOMS message, regardless of the send_distance value. In this paragraph, also assume that “nearly the same time” is a very short time interval of fixed size t, and “maximum number of reply messages received by the calling bion at nearly the same time” means the largest number of replies received during time interval t anywhere in the timeframe that is inclusively bounded by the first reply message received by the calling bion and the last reply message received by the calling bion. The maximum number of reply messages received by the calling bion at nearly the same time, will increase with the square of the send_distance used to send the GET_LOCATIONS_OF_PHYSICAL_ATOMS message. If at a send_distance of d the maximum number of reply messages received by the calling bion at nearly the same time is j, then, if the send_distance is increased by a factor of m (m > 1), the send_distance becomes (m × d) and a close approximation of the maximum number of reply messages that will be received by the calling bion at nearly the same time is (m2 × j). For example, if send_distance is 10,000 and the maximum number of reply messages received by the calling bion at nearly the same time is 13, then if send_distance were 30,000 instead of 10,000 (m is 3), a close approximation of the maximum number of reply messages that will be received by the calling bion at nearly the same time is (32 × 13) which is 117. The maximum allowed value for send_distance for get_relative_locations_of_physical_atoms() is MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS. Considering the huge number of physical atoms in a single cell in one’s physical body, a short distance for MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS makes the possibility of overwhelming the calling bion with too many reply messages at nearly the same time, much less likely.
The mere fact that our physical world is so filled with multicellular life, where the cells are very tiny, points to a very limited range for those learned-program statements that can manipulate physical matter. If hypothetically, any bion had available to it learned-program statements that gave it the ability to see and manipulate physical matter at a maximum distance from that bion of, say, an inch (about 2.5 centimeters), then why, for example, wouldn’t we see microscopic pond life (both single-celled pond life and multi-celled pond life) using that long range of an inch to see and then move food particles toward itself to feed on those food particles instead of what we actually see which is that both single-celled and multi-celled pond life only consumes food that comes into contact with the surface of that pond life, and that the only two feeding strategies for cellular pond life is to either anchor and wait for the food to contact its surface or to actively swim about in the pond water so as to increase its chances of running into food that it can then consume. Given what is seen with how pond life actually feeds, it is reasonable to conclude a very short range for those learned-program statements that can manipulate physical matter. Also, why would learned programs for multicellular life evolve and develop at all in the first place, when, with that hypothetical one-inch range, it would be possible to evolve and develop instead learned programs for manipulating physical matter on a much larger scale than what is done with physical cells which are very tiny.
Thus, the fact that multicellular life is so abundant on our Earth, and given the idea of survival of the fittest in this world, which, given the learning algorithms in section 3.6, would also apply to the evolution of learned programs that can manipulate physical matter, it is reasonable to conclude that the multicellular life we see is the fittest, and that the learned-program statements that can manipulate physical matter have a very short range for a bion to directly see and manipulate physical matter, and this very short range is probably less than one-tenth of a millimeter (less than 1/250th of an inch). Note that most of the cells in our human bodies are less than one-tenth of a millimeter in diameter.
Another reason to believe that the learned-program statements for directly seeing and manipulating physical matter have a very short range, or at least a range that is too short to be useful to our human minds in our physical human bodies, is the absence of any mental ability to directly see and manipulate physical matter with our minds alone. The learned-program statements for manipulating physical matter are too limited in what they can do, to have become a part of our minds. In addition to we humans, none of the other higher animals in our physical world show any psychokinetic ability.
In this subsection, learned-program statements are presented that allow a bion to see and manipulate physical atoms and molecules.
The physical structure of a cell is composed of many different kinds of molecules (atoms are bonded together with other atoms forming molecules). For a bion to be able to control a cell, it needs a way to see atoms and how those atoms are bonded to other atoms (chemical bonds). And a bion also needs a way to move an atom (and if that atom is a part of a molecule, and chemical bonds are preserved, then moving that atom will also move that molecule).
There are more than 100 different kinds of atoms in our world (reference the Periodic table of the chemical elements; three examples of atoms are hydrogen, oxygen, and carbon atoms). An atom is known to have subatomic structure, being composed of electrons, protons, and neutrons, and those protons and neutrons in turn are composed of quarks. However, for simplicity, let’s assume that in our everyday world—not the world of, for example, particle accelerators doing high-energy collisions of atoms—an individual atom at any point in time only occupies a single computing element, and all the state information for that atom is stored in that computing element’s memory. This state information has all the relevant information for that atom, including a large random number that serves as a unique identifier for that atom. Also, the state information for any atom A includes info about the other atoms, if any, that are currently chemically bonded to atom A (this info would include for each of these other atoms, the other atom’s unique identifier, and also that other atom’s kind—which chemical element it is).
For a bion to see an atom, assume there is a learned-program statement get_relative_locations_of_physical_atoms(). This routine and its supporting routines and code can be designed in the same way as was done for the get_relative_locations_of_bions() routine and its supporting routines and code, with only a small number of changes: For example, corresponding to GET_LOCATIONS_OF_BIONS and LOCATION_REPLY_FROM_BION there would be two new values for special_handling_locate, GET_LOCATIONS_OF_PHYSICAL_ATOMS and LOCATION_REPLY_FROM_PHYSICAL_ATOM, and there would be new code inserted near the end of the examine_a_message_instance() routine (a comment in the examine_a_message_instance() routine shows where the following code would be placed):
if message_instance.special_handling_locate is GET_LOCATIONS_OF_PHYSICAL_ATOMS
and this_CE is currently holding an atom
The reply_to_this_location_request_atoms() routine has the same design as the reply_to_this_location_request_bions() routine, but with atom details in the message text to be sent, instead of bion details.
reply_to_this_location_request_atoms(message_instance) /* The detail of this routine is not given. */
return /* exit this routine */
if message_instance.special_handling_locate is LOCATION_REPLY_FROM_PHYSICAL_ATOM
and this_CE is currently holding a bion that is not asleep
and that bion qualifies as a recipient of the message /* Examine the message_instance and also that bion’s identifier block to determine this. */
The process_a_location_reply_from_an_atom() routine has the same design as the process_a_location_reply_from_a_bion() routine, but with atom details in the received message text instead of bion details.
process_a_location_reply_from_an_atom(message_instance) /* The detail of this routine is not given. */
return /* exit this routine */
For the reply_to_this_location_request_atoms() routine, the message text of the reply will have the current XYZ location of the atom, along with other info about that atom including that atom’s unique identifier and that atom’s type, and whether that atom is chemically bonded to one or more other atoms and if so then for each of those other atoms what is its unique identifier and its type. The process_a_location_reply_from_an_atom() routine will save details of those atoms that are nearest to the bion that called get_relative_locations_of_physical_atoms(), in the same way that process_a_location_reply_from_a_bion() saves certain details of those bions that are nearest to the bion that called get_relative_locations_of_bions(). Also, get_relative_locations_of_physical_atoms() has the same get_details_for_this_many_nearest_recipients parameter that get_relative_locations_of_bions() has.
For get_relative_locations_of_physical_atoms(), the maximum value allowed for its use_this_send_distance parameter is MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS, and my estimate is that this maximum value is less than one-tenth of a millimeter (less than 1/250th of an inch). The reasons for such a short maximum distance for locating atoms are given in subsection 3.8.7, which also gives an important rule stated as follows:
The distance at which a bion can directly manipulate one or more physical atoms by calling a learned-program statement, cannot exceed the maximum distance at which that bion can directly see any and all of the physical atoms surrounding that bion by calling the get_relative_locations_of_physical_atoms() learned-program statement.
Applying the above rule: The value of MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS also becomes the maximum transfer distance allowed for any learned-program statement that, in effect when its sent message is received and acted upon, moves and/or otherwise manipulates one or more atoms. Two such learned-program statements are given below in this subsection: move_a_physical_atom() and push_against_physical_matter(), and for each the maximum allowed value for its use_this_send_distance parameter is MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS.
The get_relative_locations_of_physical_atoms() routine can be made more useful by assuming it has the option to be given parameters that specify the kinds of atoms—including an option to specify chemical bonds for those atoms—that the bion calling get_relative_locations_of_physical_atoms() wants replies from. For example, if these parameters were set to only want replies from carbon atoms that are chemically bonded to two hydrogen atoms, then only those computing elements holding a carbon atom that is chemically bonded to two hydrogen atoms would reply back by calling reply_to_this_location_request_atoms().
In effect, the learned-program statement get_relative_locations_of_physical_atoms() allows a bion to see the atoms and molecules that are nearby, and know where in 3D space relative to itself those atoms and molecules are. Besides being able to see atoms and molecules, to control a cell a bion needs a way to move itself around in 3D space (the move_this_bion() learned-program statement provides this capability), and also a way to move atoms and molecules in 3D space.
For a bion to move an atom in 3D space, assume there is a move_a_physical_atom() learned-program statement. Calling move_a_physical_atom() results in sending a message whose special_handling_non_locate is set to MOVE_PHYSICAL_ATOM. With regard to this sent message, the recipient computing element (denoted below as recipient-CE) is whichever computing element is holding the specified atom to be moved, when the message instance is offered to that computing element. The move_a_physical_atom() routine has the following four parameters in addition to its use_this_send_distance parameter:
The unique identifier of the atom to be moved (denote this atom as atom M). Presumably this unique identifier, and also the chemical-bonds info for parameters 3 and 4 below, was gotten from a previous call of get_relative_locations_of_physical_atoms().
If specified, a vector that gives the wanted direction of movement for atom M in 3D space.
If atom M is currently part of a molecule, then this parameter is a list of zero or more unique identifiers, each of which is the unique identifier of an atom that is currently bonded to atom M. For each of these listed atoms, its chemical bond with atom M will be preserved during the move of atom M.
If atom M is currently part of a molecule, then this parameter is a list of zero or more unique identifiers, each of which is the unique identifier of an atom that is currently bonded to atom M. For each of these listed atoms, its chemical bond with atom M is to be broken as a result of the move of atom M.
Although one might imagine a parameter that specifies how far to move the atom (and perhaps there is such a parameter, albeit with limitations), in the case of an atom that is part of a molecule, it may be better to assume that the computing-element program which has all the code for implementing a move_a_physical_atom() request, will only move atom M a very short distance, enough to satisfy preserving and breaking bonds as was specified by parameters 3 and 4 when move_a_physical_atom() was called. Note that moving atom M will involve, in effect, the state information of atom M transiting across some number of computing elements beginning at recipient-CE (this state information will be updated during the move process as needed to reflect changes, if any, in atom M’s chemical bonds). Also, let’s assume that when the final outcome of the move request is known, then whichever computing element ends up holding atom M will send a reply message to the bion that called move_a_physical_atom() giving the result of that move request, either success or failure, and if failure then some additional detail as to why the move request wasn’t doable as specified (for this reply message, its send_distance can be set to MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS, or set to a lesser value if it can be calculated from the available information).
Chemistry is a subject that I know very little about, and I know nothing about the strength of chemical bonds and what that strength depends on. Because of my ignorance, there may well be a better overall design for move_a_physical_atom() and its parameters than what I’ve given above. Also, besides move_a_physical_atom(), there may be other learned-program statements for manipulating physical matter in a way that can alter chemical bonds, but given my ignorance I’ll leave to others any further consideration of move_a_physical_atom() and any other learned-program statements that involve chemical bonds.
Besides learned-program statements that can directly work with individual atoms and their chemical bonds, there is a need for a learned-program statement that can “push” against physical matter (any atoms and/or molecules encountered by this pushing force) with a specified force in a specified direction. Assume there is a learned-program statement push_against_physical_matter(). The push_against_physical_matter() routine has the following four parameters, in addition to its use_this_send_distance parameter:
The radius of a right circular cylinder, denoted RCCradius. Regarding what the allowed range of values is for this radius, my guess is that the smallest value is the size of an atom (assuming as already stated above, that in our everyday world an individual atom at any point in time only occupies a single computing element, then the size of an atom is the side-width of a computing element, which has distance value 1), and the largest allowed value would be (½ × use_this_send_distance).
The length of a right circular cylinder, denoted RCClength. This length is the distance between the two end-caps of the cylinder, as measured from the center of each circular end-cap. Regarding what the allowed range of values is for this length, the smallest allowed value would be 1, and the largest allowed value would be use_this_send_distance.
A vector V that gives the wanted direction of the push in 3D space. Denote the two endpoints of vector V as A and B, with the direction of the vector being from point A to point B.
An integer F specifying how much force to apply pushing against each atom that will be pushed against as a result of this push_against_physical_matter() call.
The two parameters RCCradius and RCClength define a right circular cylinder, and the push_against_physical_matter() routine will compute the location of this right circular cylinder in 3D space, such that the center of one of the circular end-caps is at the current location in 3D space of this_bion, and the line that runs thru the center of those two end-caps will be parallel to vector V having the same orientation in 3D space.
After computing the location of that right circular cylinder in 3D space, a message is then sent with the relevant details. For any computing element that gets the sent message and is currently holding an atom, and that computing element’s location in 3D space is within the bounds of that right circular cylinder, then that computing element (more specifically, the computing-element program that it runs) will apply force F against that atom in the direction that is parallel to vector V. In other words, the volume of space defined by that right circular cylinder, that is within message-reach for the given use_this_send_distance value, is where the force F will be applied against any atom currently in that volume of space, and the direction of that applied force is parallel to vector V.
The detail of the push_against_physical_matter() routine follows:
push_against_physical_matter(RCCradius, RCClength, V, F, use_this_send_distance)
Define a new vector (A_endcap_center, B_temp) that translates vector V so that instead of beginning at point A, it begins at point A_endcap_center.
For computing the three coordinates (X, Y, and Z) of B_temp, the arithmetic is signed.
set A_endcap_center to this_CE’s_XYZ /* the current location of this_bion */
set B_temp.X to (B.X + (A_endcap_center.X − A.X))
set B_temp.Y to (B.Y + (A_endcap_center.Y − A.Y))
set B_temp.Z to (B.Z + (A_endcap_center.Z − A.Z))
At this point the vector (A_endcap_center, B_temp) has the same length as vector V, and is parallel to vector V, and points in the same direction as vector V, but for the line that passes thru points A_endcap_center and B_temp) we want to find the point B_endcap_center on that line that is RCClength distant from point A_endcap_center such that the vector (A_endcap_center, B_endcap_center) points in the same direction as vector V.
set V_length to the distance between points A and B /* Use the distance formula for computing the distance between two points in 3D space. */
set ratio to (RCClength ÷ V_length)
set B_endcap_center.X to (A_endcap_center.X + (ratio × (B_temp.X − A_endcap_center.X)))
set B_endcap_center.Y to (A_endcap_center.Y + (ratio × (B_temp.Y − A_endcap_center.Y)))
set B_endcap_center.Z to (A_endcap_center.Z + (ratio × (B_temp.Z − A_endcap_center.Z)))
Prepare the message to be sent, and send it.
/* set the message text */
set message_instance.mt.rcc.radius to RCCradius
set message_instance.mt.rcc.length RCClength
set message_instance.mt.rcc.A_endcap_center to A_endcap_center
set message_instance.mt.rcc.B_endcap_center to B_endcap_center
set message_instance.mt.V to V
set message_instance.mt.F to F
/* set other items */
set message_instance.special_handling_non_locate to PUSH_PHYSICAL_MATTER
set message_instance.send_distance to use_this_send_distance
Note that the intended recipients of this PUSH_PHYSICAL_MATTER message are computing elements holding physical atoms. Complete and send this message.
Assume that any items defined as being in this message_instance but not explicitly set above are set as stated in subsection 3.8.4 (for example, transfer_count is set to 0). Then, to send this PUSH_PHYSICAL_MATTER message_instance into 3D space, use the same code the send() statement uses to offer a message_instance to the adjacent computing elements.
return /* exit this routine */
For the two values of special_handling_non_locate given in this subsection, MOVE_PHYSICAL_ATOM and PUSH_PHYSICAL_MATTER, there would be new code inserted near the end of the examine_a_message_instance() routine (a comment in the examine_a_message_instance() routine shows where the following code would be placed):
if message_instance.special_handling_non_locate is MOVE_PHYSICAL_ATOM
and this_CE is currently holding the specified atom /* The unique identifier of the atom to be moved is in the message_instance. */
process_a_move_atom_request(message_instance) /* The detail of this routine is not given. */
return /* exit this routine */
if message_instance.special_handling_non_locate is PUSH_PHYSICAL_MATTER
and this_CE is currently holding an atom /* any physical atom */
The is_point_within_right_circular_cylinder() routine returns “yes” if the given point lies within the given right circular cylinder; otherwise it returns “no”. Although the detail of this routine is not given in this book, the math needed to answer this question can be found, for example, in Determining if a given point is inside a right circular cylinder at https://www.physicsforums.com/threads/determining-if-a-given-point-is-inside-a-right-circular-cylinder.200082/
set this_atom_XYZ to this_CE’s_XYZ /* the location of the atom held by this_CE */
returned_value = is_point_within_right_circular_cylinder(this_atom_XYZ, message_instance.mt.rcc) /* The detail of this routine is not given. */
if (returned_value is “yes”)
A and B are the two points in vector V (in message_instance.mt.V), and the direction of the vector is from point A to point B.
Define a new vector (this_atom_XYZ, B_temp) that translates vector V so that instead of beginning at point A, it begins at point this_atom_XYZ. Note that this new vector will be parallel to vector V and point in the same direction as vector V, and this is the direction in which the held atom is to be pushed with force message_instance.mt.F
For computing the three coordinates (X, Y, and Z) of B_temp, the arithmetic is signed.
set B_temp.X to (B.X + (this_atom_XYZ.X − A.X))
set B_temp.Y to (B.Y + (this_atom_XYZ.Y − A.Y))
set B_temp.Z to (B.Z + (this_atom_XYZ.Z − A.Z))
process_a_push_atom_request(this_atom_XYZ, B_temp, message_instance.mt.F) /* The detail of this routine is not given. */
return /* exit this routine */
Regarding physical matter, Newton’s third law of motion states: “For every action there is an equal and opposite reaction.” However, this law applies to physical matter interacting with itself, and does not apply to an intelligent particle that is, in effect, moving or pushing physical matter by calling a learned-program statement. Thus, when a bion, in effect, pushes against some physical matter, there is no push-back against that bion, and there is no movement of that bion as a result of, in effect, pushing against some physical matter.
Aside from gravity which affects both intelligent particles and common particles, physical cells are subject to physical forces that do not affect intelligent particles. In particular, a cell can be moved about by physical forces that do not move the bions controlling those cells. The question then becomes, how does a cell-controlling bion stay with its cell when that cell is moved in 3D space by one or more physical forces that do not also move its cell-controlling bion?
There are many different kinds of moving forces from many different sources that a physical cell can undergo in a large multicellular organism, including for us humans such things as: all the voluntary movements we can make with our limbs and other parts of our body, including, for example, moving every cell in our body by walking; breathing which moves a lot of cells in our upper body; the beating of our heart and the pulsing of major blood vessels also moves a lot of cells in addition to the blood cells themselves that move with the circulating blood; other involuntary muscle movements such as movements in our digestive tract including movements by our stomach processing a meal; all the ways a physical body and its cells can be moved or buffeted about by external physical forces, including such things as floating in water or being a passenger in a vehicle, such as being in a car or jet aircraft. In all such movement cases, a cell-controlling bion needs a way to stay with its cell.
Because the earliest cells in our world billions of years ago presumably existed as single cells in watery solutions, subject to being moved about by movements of the surrounding water, a learned program to keep cell-controlling bions with their cells would have evolved in the earliest stage of organic life.
Because each physical atom has a unique identifier, and cells are collections of physical atoms, the easiest solution is to, in effect, keep a cell-controlling bion close to a specific atom in its cell, identifying that specific atom by its unique identifier. Name this learned program that all cell-controlling bions in our world have, LP_keep_this_bion_close_to_this_physical_atom (LP is short for learned program). This learned program has two inputs:
The unique identifier of a physical atom: This identifies the atom to stay close to. One can assume that whichever learned program in a cell-controlling bion selects this atom to stay close to, that this atom is part of a large molecule in its cell that will stay in its cell, such as an atom in a large protein molecule or a DNA molecule.
A distance stay_within_this_distance: If this bion is more than this distance away from that physical atom, then this bion is moved towards that physical atom until it is less than this distance away from that physical atom.
Regarding the detail of this learned program, assume there is a learned-program statement get_relative_location_of_one_physical_atom(), and besides having the use_this_send_distance parameter, its other parameter is the unique identifier of a physical atom. As already explained in subsection 3.8.7, get_relative_locations_of_physical_atoms() has a very short range, and its MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ATOMS is estimated as less than one-tenth of a millimeter (less than 1/250th of an inch). The root reason for its very short range is the potentially enormous number of recipient atoms for the sent message when a bion calls get_relative_locations_of_physical_atoms(). However, calling get_relative_location_of_one_physical_atom() has only a single recipient atom, and its MAX_SEND_DISTANCE_ALLOWED_FOR_LOCATING_ONE_ATOM can easily be a distance of thousands of miles (1.6 kilometers per mile), and I assume this is its maximum range.
Given get_relative_location_of_one_physical_atom(), the learned program LP_keep_this_bion_close_to_this_physical_atom can work as follows: Many times per second get_relative_location_of_one_physical_atom() is called (for efficiency, assume the use_this_send_distance parameter is initially set to stay_within_this_distance, and use_this_send_distance is increased in steps as needed if no reply is received back from the specified atom in the time allowed for that reply, then when a reply is received and the bion moves closer to that atom, use_this_send_distance can be decreased accordingly). Assuming a reply from the atom, the info returned by that call of get_relative_location_of_one_physical_atom() includes the distance to that atom and the replier’s_XYZ_relative_to_000 for that atom, and, if that distance is further away than stay_within_this_distance, then move_this_bion() is called, with its direction-to-move parameter set to the value of that atom’s replier’s_XYZ_relative_to_000, so that this call of move_this_bion() will move the bion in the direction to that atom. Thus, when a cell-controlling bion is running its learned program LP_keep_this_bion_close_to_this_physical_atom, many times per second that bion checks the location of that atom relative to itself, and will move closer to that atom as needed so as to keep within the stay_within_this_distance (for a typical cell, stay_within_this_distance is probably typically set to a value that is short enough to keep that cell-controlling bion either mostly or completely within the confines of its cell).
When a cell-controlling bion is within its cell, its learned program LP_keep_this_bion_close_to_this_physical_atom is probably always running, with possible changes as needed, while it is running, to its two inputs, as that bion moves around in its cell manipulating atoms and molecules as needed to keep that cell alive and functioning. A cell-controlling bion will stop running its learned program LP_keep_this_bion_close_to_this_physical_atom if that bion is leaving its cell either temporarily or permanently. An example of temporarily leaving its cell is if that cell-controlling bion becomes a part of a projected bion-body (see the description of bion-body projections in chapter 5); at the end of a bion-body projection, to get back to their cells, each cell-controlling bion in that projected bion-body resumes running its learned program LP_keep_this_bion_close_to_this_physical_atom. An example of a cell-controlling bion permanently leaving its cell is if that cell is no longer physically viable because either that cell itself was destroyed by some poison, or some external physical force, or that cell is a part of a larger multicellular body that has died and is no longer maintaining the physical environment that cell needs, such as circulating oxygenated blood (such as when we humans physically die and our heart stops beating and we stop breathing).
How does a Sleeping Cell-Controlling Bion stay with its Cell, and how does a Sleeping Bion in a Bion-Body stay with that Bion-Body
When a bion is asleep, none of its learned programs are running (section 9.3). In the case of a cell-controlling bion that is currently with its cell because its learned program LP_keep_this_bion_close_to_this_physical_atom is currently running, when that cell-controlling bion falls asleep, how does that bion stay with its cell if that cell moves away from that bion during that bion’s sleep?
A similar problem is how does a bion that is currently a part of a bion-body, such as a part of one’s afterlife bion-body (section 6.3) or a part of a Caretaker’s bion-body (section 7.6), stay with that bion-body if that bion-body moves when that bion is asleep? The answer to both these problems is to assume the following code in the computing-element program:
If this_bion is not owned by a soliton, then assume the following code is executed by the computing-element program for this_bion when the computing-element program is about to put this_bion to sleep:
if this_bion very recently called get_relative_location_of_one_physical_atom()
and this_bion is currently near whatever atom was specified by this_bion’s most recent call of get_relative_location_of_one_physical_atom()
For the duration of this_bion being asleep, keep this_bion close to that specified atom.
else if this_bion is currently close to one or more other bions
Select one of those nearby bions, and for the duration of this_bion being asleep, keep this_bion close to that selected bion.
This chapter considers psychic phenomena and the related subject of meditation. The chapter sections are:
Unlike the mathematics-only reality model, the computing-element reality model is tolerant of human experience, because much more is possible in a universe with intelligent particles. For example, the learned-program send() statement allows direct communication between two or more minds, and this communication does not use the physical senses nor physical substance to carry the messages that are sent from one mind to one or more other minds. Thus, ESP (extrasensory perception) is possible using the send() statement, and not only possible but it happens a lot in the human world. Given what was said in section 3.8, the owned bions of one’s soliton (awareness) are one’s mind, and a soliton can only send messages to, and receive messages from, its owned bions (its mind) and not to or from any other mind. The end result is that for humanity as a whole, probably the majority of all the send()-statement messaging between different human minds is not brought to the awareness of any of the humans involved (they remain unconscious of it). However, for some people in some cases one’s mind might give one’s awareness (one’s soliton) a thought or feeling of some sort about some specific communication with one or more other minds.,,
In contrast to the computing-element reality model, the mathematics-only reality model cannot accommodate ESP. With only common particles to work with, ESP cannot be explained, and the mathematics-only reality model states that ESP does not exist.
Besides ESP, there are many other human experiences that are denied by the mathematics-only reality model. However, these experiences are explained by the computing-element reality model. For example, out-of-body experiences, an afterlife, and communication with the dead are all allowed by the computing-element reality model. An afterlife is possible, because a soliton and its owned bions, and also the cell-controlling bions in one’s physical body, are elementary particles. In general, the breakdown of a structure leaves intact the elementary particles composing that structure. Because one’s human memories are located somewhere in the collective memory of those bions—the owned bions of one’s soliton—that collectively form one’s mind, one’s memories can also survive the death and destruction of one’s physical body. For the same reason, because intelligent particles have an existence separate from physical matter and are not dependent on physical matter, out-of-body experiences are possible. And also, because of the afterlife and the learned-program send() statement, communication with the dead is possible.
One psychic power that we don’t have, although popular in fiction, is a psychokinetic power that would allow one to move physical objects at a substantial distance from oneself, just by using one’s mind. The range of the learned-program statements that can manipulate physical matter is very short (estimated to be less than one-tenth of a millimeter), which means that distant movements of physical matter by one’s mind is impossible (see subsection 3.8.7).
 Broadly, ESP (extrasensory perception) is perception by psychic means. Most often, ESP refers to the ability to feel what other people are thinking or doing. An example of ESP is the commonly reported experience of feeling when one is being stared at by a stranger: upon turning around and looking, the feeling is confirmed.
Precognition is a consequence of ESP. The most likely explanation for successful instances of precognition is non-physical messaging between minds using the learned-program send() statement. For example, when a person feels that the phone is about to ring, and the phone rings. When this happens, typically the caller and callee are already known to each other, being, for example, relatives or friends. The most likely explanation is that the two minds involved in the call, unconsciously communicated between themselves that the call would happen, and the callee’s mind gave the callee’s awareness a feeling that the phone was about to ring.
Synchronicity or coincidence is another consequence of ESP. Because our minds can communicate with other minds by using the learned-program send() statement, without us having any conscious awareness of this communication, meaningful coincidences can be arranged with one or more other minds. For example, the minds of two persons can arrange between themselves a meeting without either person having any conscious knowledge that their two minds are going to bring them together. Depending on the detail of how the meeting is brought about, one or both persons may later see their meeting as extraordinary and/or very unlikely, and then explain it as destiny, or the will of God (actually, the will of their two minds).
Claims of time travel by psychic means—viewing alleged past or future events—are sometimes made, but are necessarily erroneous. The computing-element reality model does not allow time travel. In general, the passage of time is due to the continued processing by the underlying network of computing elements that fill the universe. Because all particles are just a consequence of that processing—and not its cause—there is nothing any particle or group of particles can do to alter the underlying network’s processing order (corresponding to the direction of time) and processing rate (corresponding to the flow of time). Thus, there is nothing we or any machine we might build can do, in a real and not an imaginary sense, to move forward or backward in time relative to the current processing order and processing rate of the underlying computing-element network that fills the universe.
 I believe the following is an example of ESP from my own experience: During my late thirties I once went to a psychic fair offering readings by professional psychics (I had seen an ad for this in the local newspaper). Interested in a personal demonstration, I selected one of the available psychics. To avoid helping her during the reading, I did not ask questions, give personal information, comment on her reading’s accuracy, or even look at her. Nevertheless, the reading she gave me was a personally convincing demonstration of direct communication between minds, where the communications were brought to awareness in the mind of the psychic.
After the reading was over, the psychic remarked that I was very easy to read, and that sometimes she gets very little or nothing from the person being read. The explanation follows: During a reading, bions in the psychic’s mind are receiving information communicated (sent) by bions in the mind of the person being read. If that person’s mind refuses to communicate, or is unable to, then that psychic draws a blank, and must either admit defeat, or rely on some secondary means, such as interpreting tarot cards according to fixed rules, and/or making guesses based on whatever clues are available such as a person’s age and appearance. Thus, a skeptic who wants “proof” that a psychic is fake, can get “proof,” by unconsciously refusing to communicate, or by unconsciously communicating false information.
Psychic readings, when genuine, provide a means to consciously learn about hidden plans and/or expectations in one’s own mind, circumventing the normal paths to awareness which are restricted and heavily filtered. Channeling, when the source is not merely the channel’s own mind, is a closely related talent which many psychics have. When a psychic channels communications from another mind, such as from the mind of a dead person, the same direct communication between minds is taking place. For some psychics, channeling and doing a psychic reading are the same thing, in which the mind of a dead person acts as an intermediary who telepathically talks to the psychic and provides information about the person being read; the psychic then repeats more or less what the intermediary says.
Regarding the various props that psychics use, such as tarot cards, tea leaves, crystal balls, astrological charts, personal effects held by the psychic (psychometry), and such, working psychics have commented as follows: “I read tarot cards for people one-on-one, in person, or over the phone. They’re just a point of concentration. I could use a crystal ball or goat innards, but tarot cards are lighter than a ball and less messy than the goat innards!” (Cooper, Paulette, and Paul Noble. The 100 Top Psychics in America. Pocket Books, New York, 1996. p. 266), and, “Sometimes I use cards because then the person doesn’t become preoccupied with ‘Where the hell is she coming up with this stuff from?’ It’s easier to blame it on the cards.” (Ibid., p. 250). Regarding what is brought to awareness in the mind of the psychic, this depends on the psychic and the circumstances—or, more specifically, the received communications and the way those communications are processed in the mind of the psychic and then sent to that psychic’s awareness—but, in general, “pictures, sounds, and symbols that the psychic verbalizes” (Ibid., p. 297).
 Despite the apparent usefulness of ESP in general, overt displays of ESP are not widespread in human society, and it appears that different evolutionary forces are at work to suppress such psychic phenomena. For example, social forces are at work. In Europe during the Middle Ages, women who were overtly psychic were murdered as witches by the religious establishment.
Another factor, perhaps the dominating factor, that limits the conscious display of ESP including conscious direct communication with another mind, is that having these capabilities, without perceptual confusion regarding the source of the perception, has a cost in terms of requiring an allocation of awareness-particle input channels (section 9.6). More specifically, for the awareness to have extra-sensory perceptions and simultaneously know they are extra-sensory perceptions, then either a separate allocation is needed for carrying these extra-sensory perceptions to the awareness, or, if the same allocation is used to carry both extra-sensory and sensory perceptions, such as, for example, telepathic hearing and normal hearing carried by the same allocation, then a separate allocation is needed for carrying a feeling—sent to the awareness at the same time as the extra-sensory perception—that alerts the awareness that the current perception has an extra-sensory origin.
Experimentation is an important part of the scientific method. Because bions are particles, one might expect to observe bions directly with some kind of physical instrument. However, observing bions with an instrument made of common particles is unlikely, because bions are selective about how they interact with common particles. For example, if a bion, in effect, chooses to ignore a man-made detection instrument, then that detection instrument will not detect that bion.
Being partly composed of bions, it is possible for a man to be his own instrument to observe bions. However, because of the fragility of the physical body and its overriding needs, most people cannot directly observe bions without some kind of assistance, such as by meditation.
 Of course, the computing-element program decides all particle interactions (the only exception is the soliton, which has an agency of its own)—either directly in the case of common particles, or indirectly thru learned programs in the case of intelligent particles—and all particles are blocks of information manipulated by the computing elements that run the computing-element program. However, as a literary convenience, intelligent particles will sometimes be spoken of as having their own volition. This avoids excessive repetition of the details of the computing-element reality model.
 Regarding computation, note that ignoring other particles and not interacting with them is always easiest, because interaction requires computation, whereas non-interaction requires nothing in terms of computation. Thus, for example, bions passing thru a wall is computationally easier for those bions than being repelled by that wall. And bions remaining invisible to ordinary sight is computationally easier for those bions than having and running a learned program to reflect and/or absorb and/or emit light, and thereby be seen.
The ancient books of Hinduism are collectively known as the Vedas. It is not known with any certainty when the Vedas were written, but typical estimates are that the oldest books were written 3,000 years ago.
Among the Vedas are the Upanishads, a collection of ancient writings which embody the philosophy of Hinduism. The Upanishads speak clearly about a means to experience psychic phenomena. It is an amazingly simple method: mentally repeat, over and over, the sound Om (rhymes with the words Rome and home). The o sound is short and the m sound is typically drawn out. Robert Hume, in his book The Thirteen Principal Upanishads, translates from the original Sanskrit:
The word which all the Vedas rehearse,
And which all austerities proclaim,
Desiring which men live the life of religious studentship—
That word to thee I briefly declare.
That is Om!
That syllable, truly, indeed, is Brahma!
That syllable indeed is the supreme!
Knowing that syllable, truly, indeed,
Whatever one desires is his!
That is the best support.
That is the supreme support.
Knowing that support,
One becomes happy in the Brahma-world.
The above verse is from the Katha Upanishad. In this verse, praises are heaped upon Om. There is also a promise of desires fulfilled and happiness attained. The word Brahma is a technical term which occurs frequently in the Upanishads, and often refers to the experiences one can have as a result of using Om.
Taking as a bow the great weapon of the Upanishad,
One should put upon it an arrow sharpened by meditation.
Stretching it with a thought directed to the essence of That,
Penetrate that Imperishable as the mark, my friend.
The mystic syllable Om is the bow. The arrow is the soul.
Brahma is said to be the mark.
By the undistracted man is It to be penetrated.
One should come to be in It, as the arrow [in the mark].
The above verse is from the Mundaka Upanishad. The syllable Om is identified as a bow in the fifth line, and in the first line the bow is called the great weapon. By this bow-and-arrow analogy, the power of Om is expressed. A straightforward interpretation of this verse is that the use of Om can launch the awareness into an out-of-body experience.
As the material form of fire when latent in its source
Is not perceived—and yet there is no evanishment of its subtle form—
But may be caught again by means of the drill in its source,
So, verily, both are in the body by the use of Om.
By making one’s own body the lower friction-stick
And the syllable Om the upper friction-stick,
By practicing the friction of meditation,
One may see the God who is hidden, as it were.
The above verse is from the Svetasvatara Upanishad. It uses an outdated analogy, as did the previous verse. Before matches and lighters, man started fires by such means as rapidly spinning a stick of wood called a drill, the pointed end of which—surrounded by kindling—is pressed against a wooden block; the heat from the friction then ignites the kindling. The beginning of the verse is scientifically inaccurate; it is saying that fire exists in wood in some subtle form. This mistake is excusable, given that the Upanishads are prescientific writings.
The meaning of this verse starts with the fourth line. The first three lines make the claim that fire has both a visible form and a subtle hidden form. The remaining lines make the claim that there is something similarly hidden in the body. Normally, this something is hidden, as the writer of the verse supposed that fire is hidden in the stick. But by using Om, one can draw out this hidden something, and make it known to one’s own awareness. Referring to the computing-element reality model, this hidden something is the population of bions inhabiting the cells of the physical body.
Whereas one thus joins breath and the syllable Om
And all the manifold world—
Or perhaps they are joined!—
Therefore it has been declared to be Yoga.
The above verse, from the Maitri Upanishad, defines yoga as involving the use of Om.
 Hume, Robert. The Thirteen Principal Upanishads, 2nd ed. Oxford University Press, London, 1934. pp. 348–349.
 Ibid., p. 372. (The bracketed note on the last line is by the translator, Robert Hume.)
 Ibid., p. 396.
 Ibid., p. 439.
If one wants to meditate using Om, and risk the injury described in the next section, then the typical procedure seems to be the following: Lie down comfortably on a bed—preferably at night before sleeping. The room should be quiet. Then, close your eyes and mentally repeat the sound Om over and over, at whatever seems like a normal pace; do not say the sound aloud. Avoid stray thoughts, and try not to feel the body. Movement should be avoided, but move if it will correct any physical discomfort. During the meditation, the attention has to settle somewhere, and a good place to focus the attention is the center of the forehead.
There is no guarantee that the use of Om will produce results. The results of Om meditation have a high threshold. A single sounding of Om is useless. Instead, it must be repeated many times. Many hours of using Om, spread over many days, may be necessary before there are any results. The following are some of the effects that may result from Om meditation:
Upon waking from sleep, there is an enhanced clarity and frequency of dream remembrance.
During sleep, there is lucid dreaming. A lucid dream is when one is conscious within what appears to be a surrounding dream world, and in that dream world one can freely move about. Chapter 5 explains lucid dreams as out-of-body experiences.
During sleep, there is an onset of consciousness and a direct perception of a nonphysical body. Often, this bion-body, which is a body composed solely of bions, is either coming out of, or reentering, one’s physical body. This nonphysical body—which is capable of movement independent of the physical body—convinces those who experience it that they are truly exterior to their physical body.
Something is felt in the body during the Om meditation. This may be a vibration, or a loss of sensation in the limbs, or a shrinking feeling.
If one is going to have an out-of-body experience, the best time for it is when one is asleep, because during sleep one’s physical body has the lowest need for the control provided by one’s awareness/mind (defined in chapter 5). Thus, if one’s awareness/mind were to wander off and leave the physical body alone during sleep, then most likely the physical body will remain safe without it.
Although Om meditation has the potential to promote unusual experiences, it also has the potential to cause a very painful injury. Om meditation, and meditation in general, can, after long use, cause the devastating injury known as kundalini. This injury, which appears to be nonphysical, happens during the actual meditation. Briefly, the cause of the injury is too much meditation. More specifically, a possible explanation is that excessive meditation can cause a neuron-inhabiting bion in the lower spine to self-program, causing an alteration or corruption in one of its learned programs; and the ultimate consequence of this reprogramming is the burning pain of the kundalini injury.
The details of the kundalini injury are as follows: At some point during meditation, and without any warning, there is a strong sensation at the spine in the lower back, near the end of the spine. There is then a sensation of something pushing up the spine from the point of the original sensation. How far this sensation moves up the spine is variable. Also, it depends on what the person does. He should immediately get up, move around, and forswear future meditation. Doing so can stop the copying of the learned-program corruption, if that is what the felt movement up the spine is: a side effect of the corruption-originating bion copying to neighboring neuron-inhabiting bions, and those neighbors copying to their neighbors, and so on up the spine.
The onset of the pain is variable, but it seems to follow the kundalini injury quickly—within a day or two. Typically, the pain of the kundalini injury is a burning sensation across the back—or at least a burning sensation along the lower spine—and the pain may also cover other parts of the body, such as the head. The pain is sometimes intense. It may come and go during a period of months or years and eventually fade away, or it may burn incessantly for years without relief.
The common reaction by the sufferer to the kundalini injury is bewilderment. Continued meditation seems to aggravate the kundalini injury, so the typical sufferer develops a strong aversion to meditation.
The Indian, Gopi Krishna, suffered the kundalini injury in December 1937 at the age of 34. He had a habit of meditating for about three hours every morning, and he did this for seventeen years. Apparently, he did not practice Om meditation. Instead, he just concentrated on a spot centered on his forehead. In his case the sensation rose all the way up his spine and into his head. The pain he suffered lasted several decades.
The Indian, Krishnamurti, who had been groomed as the World Teacher of the Theosophical Society, suffered the kundalini injury in August 1922 at the age of 27. He had been meditating. His suffering lasted several years, and the pain would come and go. In one of his letters of 1925, Krishnamurti wrote, “I suppose it will stop some day but at present it is rather awful. I can’t do any work etc. It goes on all day & all night now.” Such are the hazards of meditation.
 Lutyens, Mary. Krishnamurti: The Years of Awakening. Avon Books, New York, 1983. p. 216.