by Kurt Johmann
Copyright © 2023
October 31, 2023: I, Kurt Johmann, the author and copyright owner, hereby place in the public domain the entire text of An addendum for the 12th and revised 12th editions of my book, regarding copying a soliton/mind’s mind to replace the mind of a different soliton.
1. Familiarity with my book is helpful
2. The problem in my book that this addendum corrects
3. Two integer constants, Q and Z, used in this addendum
4. For an optimal mind-copying algorithm, how the unique identifier for an owned bion is defined
5. Some considerations before giving an efficient mind-copying algorithm
5.1 My estimates for those two integer constants Q and Z6. An efficient mind-copying algorithm; The starting point of the mind-copying process (steps 1, 2, and 3)
5.2 Messaging in 3D space, and the limit on the size of the message text
5.3 The message-flood problem
5.4 The state information of an owned bion includes three constants that were set when that owned bion was created, that cannot be changed, and are unaffected by the mind-copying process
5.5 The definition of the unsigned-integer unique identifier of an owned bion, allows a range of message recipients to be specified
5.5.1 An unexpected side benefit: simultaneously within a gigantic number of owned bions, search thru all memories, or erase all memories5.6 Improving the usability of copied learned programs
5.7 Revised preconditions for doing a mind copying
7. Different ways to deal with the message-flood problem, and avoid having any lost messages between each copy-from owned bion and its same-numbered copy-to owned bion
8. Estimating the computational burden of message transmission for this mind-copying process
8.1 My book’s algorithm for message transmission9. The third-way code: divide the message senders into smaller groups and send their messages at different times without overlap
8.2 To make message transmission faster, eliminate the square root by squaring both sides, and do that math comparison at most only once, instead of an average of three times
8.3 A rough estimate of how many machine instructions are needed to do my improved message-transmission algorithm
10. The last two steps of the mind-copying process (steps 4 and 5)
11. Postscript
Note: Other than eight external links between the BEGIN and END below, all the other links in this addendum are internal links that only jump within this addendum.
This addendum is an addition to my book, and it would be helpful if the reader is already familiar with my book, either the 12th edition or the revised 12th edition. The following quote from the revised 12th edition of my book may be helpful understanding the terminology used in this addendum:
For convenience, because they are always kept together regardless of where they are, an awareness (implicitly and uniquely identified by the soliton associated with that awareness) and its mind (that soliton’s owned bions) will often be referred to simply as awareness/mind or soliton/mind. A conscious being is here defined as a specific soliton and its associated awareness, along with that soliton’s owned bions which, taken as a whole, is the mind of that conscious being. For each conscious being, regardless of where that conscious being is located in this gigantic universe of ours, the awareness/mind phrase implicitly emphasizes more its soliton as the seat of its awareness, and the soliton/mind phrase implicitly emphasizes more that the seat of its awareness (its soliton) is itself an intelligent particle.
Regarding the phrase “message text” that I use in this addendum, I say in my book that the data being sent to the intended recipient(s) of a message, is often referred to as the “message text”. For convenience in this addendum, I often speak of a message as being received, and more specifically I mean that the particle that received that message, either a soliton or owned bion, was—within the message itself—a specified recipient of that message.
Note: In my book, I often refer to the “unique identifiers” of other particles without any qualification, because in my book I’ve already defined those unique identifiers as always being big-random-number unique identifiers. However, in this addendum I define an additional kind of unique identifier for owned bions, which is an unsigned-integer unique identifier (see 4. For an optimal mind-copying algorithm, how the unique identifier for an owned bion is defined). Thus, to be clear what kind of unique identifier I’m referring to in this addendum, especially when referring to an owned bion, I’ll often use the phrase “big-random-number unique identifier” or “unsigned-integer unique identifier”.
In my book, I defined the unique identifier of each owned bion to be a big random number, constructed so that it’s very unlikely that two owned bions in the same solar system will have the same unique identifier. However, this definition in my book causes a big problem for any mind-copying algorithm, requiring a mind-copying algorithm (not given in this addendum) that is both less time-efficient and also much less memory-usage-efficient—if I understand things correctly regarding learned programs, in the worst case a gigantic translation table, beyond the available memory in a single intelligent particle, is needed, translating copy-from big-random-number unique identifiers to copy-to big-random-number unique identifiers—than the optimal (or nearly optimal) mind-copying algorithm that I give further below. I first realized this problem, while thinking about my book, May 12, 2023 (I wrote the date down so I wouldn’t forget it), and I began work on this addendum a few days later.
As it turns out, the best solution for the unique identifier of an owned bion, is for each owned bion to have two different unique identifiers, one being the big random number already described in my book, and the other described here: 4. For an optimal mind-copying algorithm, how the unique identifier for an owned bion is defined.
Although I talk about mind copying in my book, albeit without using the “mind copying” or “mind-copying” phrases that I use in this addendum, I don’t give any mind-copying algorithm in my book.
A soliton/mind’s mind is composed of the owned bions of that soliton. In my book, I say that each soliton/mind has the same number of owned bions, and the reason I say this is because I know that this is a necessary condition for mind copying. Each soliton in the universe has the same number of owned bions, which is an integer constant denoted in this addendum as Q.
Also, for each computing element in the universe, if it is currently holding a bion, the computing-element program always reserves Z bytes of that computing element’s memory, reserving it to hold whatever data that held bion currently has (its data will include its state information, and zero or more learned programs and/or other data). Z is an integer constant, and has the same value for every bion in the universe.
For convenience in this addendum, this reserved memory of size Z bytes, will often be referred to as “Z memory”. Also, for convenience in this addendum, I’m using the word “bytes”, instead of using this phrase from my book, “bytes or whatever unit of memory is used by computing elements”.
For an optimal mind-copying algorithm, for all Q owned bions of a soliton, the unique identifier for each owned bion will be an unsigned integer with a value somewhere between integer 1 and integer Q inclusive, such that the value of each owned-bion’s unsigned-integer unique identifier is unique among those Q owned bions, which means that each unsigned-integer value between integer 1 and integer Q inclusive—a total of Q different unsigned-integer values—is assigned to only a single owned bion among those Q owned bions.
Said another way, during the creation process of a soliton, when all the owned bions of that soliton are also created and initialized, which includes assigning the unsigned-integer unique identifier of each bion owned by that soliton, one can imagine that each owned bion is created sequentially, and that unsigned-integer unique-identifier value is simply assigned in sequential order from integer 1 to integer Q, in the order that those owned bions are created for that soliton, giving a total of Q owned bions for that soliton.
Regarding the mind-copying process, there are two parties involved, the copy-from awareness/mind (aka soliton/mind) and the copy-to awareness/mind (aka soliton/mind).
In this addendum, the phrase “same-numbered” means that for the two owned bions referred to—a copy-from soliton’s owned bion and a copy-to soliton’s owned bion—each has the same unsigned-integer value as its unique identifier.
To make mind-copying possible, that’s why the value of Z must be the same for every bion. Briefly, you cannot copy M bytes of data into N bytes of memory if M > N. Hence the need for sameness.
Regarding the value of Z, which is the number of bytes of Z memory, I think an estimate of a billion bytes (109 bytes) is reasonable, based on my rough understanding of how much information a billion bytes can encode, and my rough understanding of what a cell-controlling bion will need in terms of its learned programs.
For the value of Q, which is the number of owned bions that each soliton has, see the range—and the justification for it—that I give in my book’s footnote 162, which is a low of 2×1023 owned bions, and a high of 2×1031 owned bions. So, I think the value of Q is much greater than the value of Z, and even that low number of 2×1023 owned bions is still a gigantic number of owned bions. And, as I say in that footnote 162, “I think it likely that the great majority of the bions composing one’s mind are used for memory storage.”
To copy my above estimate of a billion bytes of Z memory, from a copy-from owned bion to a same-numbered copy-to owned bion, I’m assuming the routines involved with mind copying in the computing-element program use the equivalent of my book’s send() statement (see my book’s section 3.8 Identifier Blocks, the send() Statement, and Multicellular Development).
Regarding the send() statement and the message it sends, the code for message transmission in my book will copy that message into a 3D spherical space composed of computing elements, of radius send_distance, centered on the computing element from which that message was sent.
In my book, I said a lot about a computing element’s use of its memory to store particle data. However, I don’t think I said anything directly about how its memory might be allocated (divided up) for use when a computing element is holding a particle, and in particular holding an intelligent particle. For example, running learned programs, depending what they do, may need some amount of so-called scratchpad memory, and my book does mention the ability of an intelligent particle to save in memory, in a message queue, recently received messages until each received message can be processed and then deleted from that message queue. So, both scratchpad memory and memory for saving any messages that that particle was a recent recipient of but has yet to fully process, can perhaps share the same part of memory. However, the Z memory for an owned bion’s data, is meant, in general, for data of a more long-lasting kind, such as state information, learned programs, and, for example, memories in a human mind.
In my book, I do say: “Also, because more time is needed to copy a larger message, the computing-element program imposes a limit on the maximum size of a message, so that message transfer is always a fast process.” However, if I recall correctly, I didn’t give any estimate limiting the size of a message or the size of a message’s message text. However, in this addendum there is a need to copy Z memory, which I think is about a billion bytes, by messaging, so I’ll discuss the idea of messages and size limits, and give my estimate of how big the message text can be, in the next two paragraphs:
In general, the bigger the size of the message text, the bigger the total size of the message, and the slower that message can be moved thru 3D space composed of the computing elements, because more computer time is needed to copy that larger message from one computing element to the next. Thus, to keep messaging fast, and also to avoid wasting too much of limited memory storing recently received messages until they can be processed, there is, presumably, a size limit imposed by the computing-element program on how big the message text can be, and I think one can assume that that limit is much less than my estimate for Z which is a billion bytes (109 bytes).
Also, regarding that size limit on how big the message text can be, I want to make a few personal comments: During my roughly 400 lucid dreams, I had many telepathic talks with other persons, but I never had an instance of receiving from another person, or sending to another person, an image or sequence of images. This suggests to me that the size limit on how big the message text can be, is at most a few thousand bytes (or maybe less than a thousand bytes), and not millions of bytes. Thus, to copy a billion bytes of Z memory, that might need a sequence of roughly a million messages.
On the Internet, the messaging protocols used to reliably transfer billions of bytes of data across the Internet, typically make use of checksums to verify the received data, because the Internet’s physical electronic computers and communication networks have the potential to corrupt the transmitted data, which can be detected by using checksums, resulting in retransmission requests as needed, of any detected corrupted data. However, for the computing elements, I don’t think that a sent message—during its transmission filling a 3D spherical space composed of computing elements, of radius send_distance, centered on the computing element from which that message was sent—can be corrupted, such as, for example, a bit flipping (changing from 0 to 1, or 1 to 0) somewhere in the message or message text, because, presumably, the computing elements don’t make mistakes like that during message transmission. Thus, I don’t think there is any need for the use of checksums, either during messaging or at the end of messaging, to guarantee that the Z memory received by a copy-to owned bion is the same Z memory sent in a sequence of messages by the same-numbered copy-from owned bion.
In my book’s section 1.3 Components of the Model, I say, “Regarding computing-element processing speed, it’s possible to compute lower-bounds by making a few assumptions: … so the MIPS rating of each computing element is at least 1024 MIPS (millions of instructions per second)”. That’s 1030 instructions per second.
Given my low estimate of Q above, which is 2×1023 owned bions: Can the computed reality described in my book, handle 2×1023 messages filling the same 3D space at the same time without, in effect, losing any messages? Are the computing elements fast enough to not lose any messages?
Thinking about the value of Q, which is a gigantic number, probably somewhere between 2×1023 owned bions and 2×1031 owned bions, and thinking about a possible need to do the mind copying—copying the Z memory of each copy-from owned bion to the same-numbered copy-to owned bion, by sending a sequence of messages—for all Q owned bions: That is a task so big—if all Q copying actions are supposed to happen at the same time in the same 3D space—that I don’t want to just assume that it can be done without losing any messages.
Because, if some messages are lost, then, in the worst case, either the copied mind received by the copy-to soliton will be corrupt compared to the copy-from soliton’s mind that was sent by messaging, because of lost messages not received (this is the do-not-resend-a-presumed-lost-message scenario), or that mind-copying process might not be able to finish in whatever time is allowed for it to finish, if the routines in the computing-element program that will do the actual mind copying, check for presumed-lost messages, such that each copy-from owned bion has to resend a message if too much time goes by without that copy-from owned bion receiving a reply message from the same-numbered copy-to owned bion that was sent that message, acknowledging receiving that sent message (in this resend-a-presumed-lost-message scenario, the message-flood can grow worse over time if the volume of messaging grows substantially with resent messages).
To be more clear, during the mind-copying process, regarding the message senders and the number of messages sent, given the two scenarios in the previous paragraph: In the do-not-resend-a-presumed-lost-message scenario, the message sending is only one way, going from the copy-from owned bion to the same-numbered copy-to owned bion, with no replies or any other messages being sent by the same-numbered copy-to owned bion. In the resend-a-presumed-lost-message scenario, compared to the do-not-resend-a-presumed-lost-message scenario, there are twice as many message senders, and twice as many messages being sent in the best case of no lost messages, because each message successfully sent by the copy-from owned bion to the same-numbered copy-to owned bion, results in a reply message.
Two of these three constants are already defined in my book: They are, for an owned bion, the big-random-number unique identifier of the soliton that owns that owned bion, and the big-random-number unique identifier of that owned bion. And the third constant of an owned bion is the unsigned-integer unique identifier of that owned bion, described here: 4. For an optimal mind-copying algorithm, how the unique identifier for an owned bion is defined.
Also, as I say in my book, given the quality of the big-random-number generator, which is a routine in the computing-element program, it’s very unlikely that two particles of the same type in the same solar system, will have the same value for its big-random-number unique identifier.
In my book’s subsection 3.8.2 The Learned-Program send() Statement: Parameters, see the discussion of “within-the-mind communication” and the call parameter within-the-mind-or-not.
So, I’m saying in this addendum that an owned bion has two different unique identifiers that it can use to identify itself, and which one is used depends on the usage context. For within-the-mind messaging—which is messaging where both the message sender and all message recipients are members of the same soliton/mind—and also for the mind-copying process, use the unsigned-integer unique identifier of an owned bion. However, for usage of the big-random-number unique identifier of an owned bion, my book’s subsection 6.3.2 How a Mind Connects with a Brain before Birth is a perfect example of that usage. In general, and as a rule, with at least one exception to this rule being the mind-copying process, if an owned bion is sending a message to one or more particles that are not owned by the soliton that owns that owned bion that is sending that message, then the big-random-number unique identifier of that owned-bion message sender, and not its unsigned-integer unique identifier, should be used in that message to identify that owned bion as the message sender to the message recipient(s).
When I say above in the heading, that these three constants in the state information of an owned bion are unaffected by the mind-copying process, I mean that if I were to say something later in this addendum like “then copy the Z memory of that copy-from owned bion to the same-numbered copy-to owned bion’s Z memory, replacing whatever Z memory was there before”, I mean for that copy-to owned bion to do that replacement without replacing the values of its own three constants in its state information which is a part of its Z memory.
I say in my book’s subsection 3.8.2 The Learned-Program send() Statement: Parameters, that the “size of list_of_bions is presumed to be limited to a small number of unique identifiers in the list. I estimate this limit at about ten unique identifiers”. However, the unsigned-integer unique identifier of an owned bion offers something new with regard to specifying message recipients, which is specifying a range of owned bions as the message recipients, from the low unsigned-integer given in the range, to the high unsigned-integer given in the range, inclusive. For example, the small range of 3 thru 7 specifies 5 owned bions: those with the unsigned-integer unique identifiers of 3, 4, 5, 6, and 7. Of course, a much larger range can also be specified:
As already stated above, and referring to my book’s footnote 162, the value of Q, which is the number of owned bions that each soliton has, has an estimated low value of 2×1023 owned bions, and an estimated high value of 2×1031 owned bions.
In my book, although I give both a low estimate and a high estimate for Q’s value, I don’t give any suggestions of how this big number of owned bions might be divided into different groups with regard to usage. However, for the purpose of improving overall efficiency in the computing-element program, and also, during the mind-copying process, to reduce the total number of message senders and thereby avoid having lost messages (see 7. Different ways to deal with the message-flood problem, and avoid having any lost messages between each copy-from owned bion and its same-numbered copy-to owned bion), I’m going to assume that the computing-element program divides Q into three separate contiguous groups of owned bions, named the soliton-directory group, the everything-else group, and the storage-of-memories group:
soliton-directory group: For any soliton, this soliton-directory group includes all of its owned bions whose unsigned-integer unique identifier is anywhere in the range of 1 thru 100 inclusive.
This soliton-directory group is where the soliton directory is stored, which is described in my book’s subsection 5.1.1 The Soliton Directory.
Given my above estimate of Z memory being a billion bytes, and also my estimate in my book that the soliton directory can hold thousands of entries, I think a single owned bion is probably enough to store the soliton directory and its thousands of entries. However, I’m choosing 100 owned bions for storing the soliton directory, primarily to allow room for more entries in the soliton directory.
Regarding the soliton-directory group’s involvement in the mind-copying process: If the mind-copying happens, then only the copy-from soliton’s everything-else group will be copied to the copy-to soliton’s everything-else group, and the copy-to soliton’s soliton-directory group and also its storage-of-memories group will both be erased, because they were both created by the old mind which is being replaced.
Note: Because the soliton-directory group is so small compared to the storage-of-memories group, it would be easy to store all of the entries in the soliton-directory group in the storage-of-memories group, and thereby eliminate the soliton-directory group. However, the reason I’m keeping these two groups separate, is because, in my book, I assume that the soliton directory is retained indefinitely across many lives, whereas for at least most of us if not all of us, our past memories at the start of a new life—or soon before its start or soon after its start—are erased.
everything-else group: For any soliton, this everything-else group includes all of its owned bions whose unsigned-integer unique identifier is anywhere in the range of 101 thru 2×1020 inclusive.
On this Earth, as far as I know, we humans are the most intelligent physically embodied conscious beings, and the Caretakers are the most intelligent bion-body-embodied conscious beings. This everything-else group is where all the learned programs in the mind are kept, including but not limited to those learned programs for intelligence, emotions, one’s senses, and also for interacting with one’s body.
Almost 2×1020 owned bions, times my above estimate of each owned bion’s Z memory being a billion bytes (109 bytes), is a total of about 2×1029 bytes to store all the learned programs in one’s mind. Is this enough memory for both humans and Caretakers to be as intelligent as they are, and also for them to be able to live in and control their respective bodies, and also have the emotions and the senses that they have? In my opinion, it is more than enough memory, by a wide margin.
storage-of-memories group: For any soliton, this storage-of-memories group includes all of its owned bions whose unsigned-integer unique identifier is anywhere in the range of (1 + (2×1020)) thru Q inclusive.
If one assumes the low estimate for the value of Q, which is 2×1023 owned bions, then this storage-of-memories group is one thousand times bigger than the everything-else group. If one assumes the high estimate for the value of Q, which is 2×1031 owned bions, then this storage-of-memories group is one hundred billion (1011) times bigger than the everything-else group.
The word “memories” for this storage-of-memories group, means all kinds of memories, whether short-term or long-term, visual or textual, factual or fictional, personal experience or not, something seen or heard or felt by touch, or smelled or tasted, or something just thought of consciously, or something learned from a book or classroom or teacher, or some emotion felt, or a body movement or sequence of body movements made, or a remembered dream, or the memory of an out-of-body experience, or whatever else you, the reader, think is missing from this list of different kinds of memories.
I’m assuming that the computing-element program has a specific purpose for this storage-of-memories group, which is the storage of all kinds of memories, and therefore it is reasonable to also assume that the computing-element program predefines all the routines that can be called in this storage-of-memories group (note: this same reasoning also applies to the other two groups). Also, the code of each of these predefined routines is in the computing-element program, and is called there using whatever call parameters, if any, are given in the received message text (see the next paragraph). In this addendum, I’m only interested in two of these predefined routines for this storage-of-memories group, which I’m naming search_for() and erase_all(), and I’ll use each routine in its own following paragraph to show its use.
To simultaneously search thru the entirety of all the stored memories currently in one’s mind, do the following: From a learned program in the everything-else group of owned bions, construct and send a message which specifies as its recipients the above range of owned bions in the storage-of-memories group, which is (1 + (2×1020)) thru Q inclusive. Also, the message text will specify both the search_for() routine to be called by each message recipient, and the search parameter(s) to be searched for using that called search_for() routine. And this called search_for() routine will only send a reply message to the message sender if the search parameter(s) to be searched for are found in that owned bion’s memory where memories are stored (presumably, most of the Z memory in each owned bion in this storage-of-memories group will be used for storing memories). Also presumably, the searching thru the stored memories that is done by the search_for() routine, will be a simple linear search that will examine each of the stored memories in that owned bion, for a match with the search parameter(s). And also, in that owned bion, because the memory to be searched is only about (my estimate) a billion bytes (109 bytes), and the computing element that currently holds that owned bion has an estimated minimum processing speed of 1030 instructions per second, the call of that search_for() routine will likely finish in much less than a nanosecond (one billionth of a second). And because this same search is happening at nearly the same time in all the other owned bions in the storage-of-memories group, any searching thru the entirety of all the stored memories in anyone’s mind will likely take much less than a nanosecond. Also, because the number of owned bions in the storage-of-memories group is so gigantic, presumably the search_for() routine imposes some minimal edits on the search parameter(s), so that there won’t be a huge number of reply messages being sent because the search parameter(s) were so simple and commonplace among stored memories (like, for example, searching for the letter “a” in my book).
Note: My main focus in this addendum is mind copying, and my main goal is to make the mind-copying process as efficient and fast and error-free as possible. Thus, it strikes me as serendipitous that while working on my main goal, I was able to create and thereby discover a truly beautiful algorithm, given in the previous paragraph, to simultaneously search thru the entirety of all the stored memories currently in one’s mind. And because this search algorithm is so fast and efficient, I think it’s optimal. Also, searching thru stored memories is a commonplace and widespread thing in the human mind, often happening without any conscious awareness of it happening, but it had to have been happening whenever one consciously thinks of or uses some recalled memory (an example of using a recalled memory or using a sequence of recalled memories is a gymnast repeating his exercise routine on the parallel bars).
Unlike the search_for() routine, the erase_all() routine is very destructive, and I’m going to assume that the erase_all() routine cannot be called in a learned program, but instead, can only be called in certain routines in the computing-element program, and one of those allowed routines is routine1 (see the beginning of step5 below).
In an allowed routine, allowed to simultaneously erase the entirety of all the stored memories currently in a specific soliton’s mind (in the case of the mind-copying process, this will be the copy-to soliton running routine1), construct and send a message which specifies as its recipients the above range of owned bions in the storage-of-memories group, which is (1 + (2×1020)) thru Q inclusive. Also, the message text will specify the erase_all() routine to be called by each message recipient, and this erase_all() routine has no call parameters, and sends no reply message. The code for this erase_all() routine, located in the computing-element program, will depend on how memories are stored by the computing-element program in an owned bion in the storage-of-memories group. For example, if memories are stored in a doubly linked list, then the only thing the erase_all() routine has to do, to, in effect, erase whatever stored memories are in that owned bion, is to put a null value (all zeroes) in the pointer that points to the first item in that doubly linked list.
In my book’s section 6.3 The Afterlife, in the part titled Transitioning from one Animal Type to a different Animal Type, I say, “this [mind] copying would not include any copying of personal memories, which means that a soliton with a freshly copied new mind will start with zero personal memories”. Yes, when copying a mind to a different soliton/mind, don’t include in the copying any personal memories. However, given the storage-of-memories group that I’ve defined above, I believe—and this will also simplify the mind-copying process—that nothing in the storage-of-memories group, none of those memories, regardless of whether they are personal memories or not, should be copied from one conscious being to another, and I can’t think of any good arguments for doing such copying of memories, and the argument against such copying of memories is that those memories were produced by someone else’s existence, not the copy-to conscious being’s existence.
Very Important: During the mind-copying process, only the copy-from soliton’s everything-else group of owned bions will be copied to, and completely replace, the current content of the copy-to soliton’s everything-else group of owned bions. And when that copying of the copy-from soliton’s everything-else group is either about to happen or is already underway, the mind-copying process will, in effect, have the copy-to soliton send a message as shown above, to simultaneously erase the entirety of all the stored memories currently in that copy-to soliton’s storage-of-memories group of owned bions, and also, that copy-to soliton will send a similar erase message, specifying 1 thru 100 inclusive as the range of the message recipients, to erase the contents of the copy-to soliton’s soliton-directory group of owned bions.
Note: Regarding the two erasures in the previous paragraph, the reason for those two erasures is that both those memories and the contents of that soliton directory are a product of the old mind in that copy-to soliton/mind, which is being replaced by a new mind copied from the copy-from soliton/mind. Those erasures are also a good reason why the mind-copying process will not be allowed to happen if the copy-to conscious being (soliton/mind) is currently embodied, because of the danger those erasures would have for its current embodiment, especially if it’s a physical embodiment.
Two rules are given below for learned programs that will make learned programs that were copied from the copy-from soliton/mind more practically useful to the copy-to soliton/mind. The basic idea of both of these rules is that the value of a big-random-number unique identifier of a particle cannot appear directly in a learned program.
And what, exactly, do I mean by saying that the value of a big-random-number unique identifier of a particle cannot appear directly in a learned program? First, I’m going to make an educated guess about the size of a big-random-number unique identifier of a particle: 35 bytes times 8 bits per byte, gives 25635 which my calculator says has about 1.943×1084 different values; and, I remember from decades ago reading that the universe has an estimated 1090 physical particles in it, so I think 1084 will be much larger than the number of physical particles in the most massive solar system. Then, to directly appear in a learned program, somewhere in that learned program you would see a particle-type mark (indicating the type of that particle) next to that particle’s 35-byte big-random-number unique identifier.
So, I’m excluding the value of a big-random-number unique identifier of a particle from appearing directly in a learned program, and why am I doing this? I’m doing this exclusion because that big-random-number unique identifier of a particle is supposed to be unique for that particle type in that solar system, and its value should not be copied from the copy-from soliton/mind to the copy-to soliton/mind. However, for the unsigned-integer unique identifier of each owned bion in a soliton/mind, that unique identifier among those unsigned-integer values, only applies within that mind, and not outside of it, because the exact same unsigned-integer numbering scheme is used for every soliton/mind’s mind (see 4. For an optimal mind-copying algorithm, how the unique identifier for an owned bion is defined), everywhere in the universe. And that’s why my mind-copying algorithm further below works so beautifully, because that exact same unsigned-integer numbering scheme is used for every soliton/mind’s mind, and it allows my mind-copying algorithm to preserve without any changes every usage of the value of an unsigned-integer unique identifier of an owned bion, including but not limited to appearing directly in a learned program. And I’m sure that the computing-element program uses the unsigned-integer unique identifier of an owned bion for all within-the-mind communication, instead of using the big-random-number unique identifier of an owned bion. Also, even if Q has the high estimate of owned bions, which is 2×1031, that only requires 13 bytes times 8 bits per byte, giving 25613 which my calculator says has about 2.028×1031 different values, and using 13 bytes (the unsigned-integer unique identifier) to uniquely identify an owned bion is obviously more memory-usage-efficient than using 35 bytes (the big-random-number unique identifier).
Regarding 5.4 The state information of an owned bion includes three constants that were set when that owned bion was created, that cannot be changed, and are unaffected by the mind-copying process: All three of those constants are stored in that owned bion’s state information. Specifically, the big-random-number unique identifier of the soliton that owns that owned bion, the big-random-number unique identifier of that owned bion, and the unsigned-integer unique identifier of that owned bion. So, I’m assuming the computing-element program defines three keywords in the programming language for learned programs, to represent those three constants, represented here by the keywords C1 (representing the big-random-number unique identifier of the soliton that owns that owned bion), C2 (representing the big-random-number unique identifier of that owned bion), and C3 (representing the unsigned-integer unique identifier of that owned bion). Then, assume it’s a rule in the computing-element program, that to represent any of those three constants in a learned program, the keyword must be used, and not the actual value of that constant.
To make a different point, consider two examples of learned programs in my book: Subsection 3.8.9 How Cell-Controlling Bions Stay with their Cells, has a learned program using an atom’s big-random-number unique identifier as a call parameter that is set by a different learned program, to get a cell-controlling bion back to its cell. Another example in my book is subsection 5.2.1 Out-of-Body Movement during a Lucid Dream, which has a learned program that uses one’s soliton directory to get the big-random-number unique identifier of an owned bion in another person’s mind, and if that other person (soliton/mind) is awake and can be visited in that lucid dream, and one wants that visit to happen, then one’s soliton/mind is moved close to where that other person is in 3D space, and then, apparently, with that closeness in 3D space, one can then talk telepathically with that other person, and then, when that interaction with that other person ends, one can repeat that process if one wants, finding another person in one’s soliton directory to visit in that lucid dream, and so on, and then, at the end, when it’s time to go back to one’s physical body, a routine is called to get the relative location of a bion, which in this case is one of the body’s brain bions (identified by its big-random-number unique identifier), and that location info is then used to guide one’s soliton/mind back to its physical body.
Regarding the two examples from my book that are described in the previous paragraph, is there any need to directly encode anywhere in a learned program the value of a big-random-number unique identifier of a particle: In that second example, which describes a learned program for moving around in a lucid dream and meeting with other persons, the big-random-number unique identifier of an owned bion in another person’s mind is a value extracted from the soliton directory and is then presumably stored in a local variable for use in that learned program until it is no longer needed, and the value of that big-random-number unique identifier of an owned bion in another person’s mind is not directly encoded in that learned program. Also, regarding that first example, that big-random-number unique identifier of an atom, in my book I’m already assuming that a different learned program determines that atom to stay close to, which means that the value of that big-random-number unique identifier of that atom can be kept in a global variable that is then passed as a call parameter when that other learned program is called to move that cell-controlling bion back to its cell. Thus, there is no need to directly encode in the learned program of that first example the value of that big-random-number unique identifier of that atom. And likewise for that second example where the big-random-number unique identifier of a brain bion is used to guide that soliton/mind back to its physical body, I say in my book, “for simplicity, this can be the same brain bion that was the most recent input for the learned program LP_maintain_AM_position_close_to_one_bion when one was awake in one’s physical body”, and also one can presume that a different learned program determines the big-random-number unique identifier of that brain bion, and whether the current value of that big-random-number unique identifier of that brain bion is copied from that learned program LP_maintain_AM_position_close_to_one_bion or some other learned program, the value of that big-random-number unique identifier of that brain bion will presumably always be stored in a variable, whether a global variable or a local variable or a call parameter, in the learned programs mentioned, and will never be directly encoded anywhere in any of those learned programs.
Note: Regarding learned programs, a global variable only has visibility within that bion where it is defined, and not outside of it. Thus, if two owned bions have the same owning soliton, and each of those two owned bions defines a global variable with the same name, that is okay, because those are two separate global variables with no connection between them.
Thus, referring to the second paragraph above this one, and the above goal to make learned programs that were copied from the copy-from soliton/mind more practically useful to the copy-to soliton/mind, assume the following rule: The computing-element program does not allow any learned program to directly encode anywhere in that learned program the value of a big-random-number unique identifier of a particle. Instead, in any learned program, to use the value of a big-random-number unique identifier of a particle, that value must be stored in either a call-parameter variable or local variable or global variable and that variable must be referenced using that variable’s name in that learned program, to make use of the value of that big-random-number unique identifier of a particle in that learned program.
My book has another example to consider, which is the group of learned programs in the mind that interface with the brain (see subsection 6.3.2 How a Mind Connects with a Brain before Birth). In this example, there isn’t just one atom or one brain bion. Instead, there are roughly one million points of color data just for the human visual field for one eye, and there are two eyes, and there are other parts of the cerebral cortex that have a lot of different types of information regarding the physical body and its senses. And also, there’s a lot of control over the voluntary muscles by the motor cortex, which is a part of the cerebral cortex. This interface between one’s mind and what I’ll guess is roughly three or four million of the cell-controlling bions in one’s cerebral cortex, is what makes us human with a physical body. Note that, in general, cerebral-cortex nerves are supposed to last a lifetime, and thus, each cerebral-cortex nerve’s cell-controlling bion’s big-random-number unique identifier will also last a lifetime.
So, regarding the previous paragraph, what can be done with this last example from my book? Nothing really. According to the rule I made in the second paragraph above this one, the computing-element program does not allow any learned program to directly encode anywhere in that learned program the value of a big-random-number unique identifier of a particle. Okay, so that means the big-random-number unique identifier of a cell-controlling bion in the mind/brain interface, is saved in the same owned-bion’s Z memory where the referencing learned program is also stored, and that learned program can then access that saved big-random-number unique identifier of a cell-controlling bion, by using a global variable.
In my book’s footnote 19, and also in my book’s Transitioning from one Animal Type to a different Animal Type, I imagined the mind copying going from a mother to her to-be child if that awareness/mind who will be her child doesn’t already have the mind needed to live as that animal type. However, while working on this addendum, I’ve changed my mind about this, because there is a safer time to do the mind-copying process than during embodiment.
Important: I think it best to assume that a requirement for the mind-copying process, in the computing-element program, is that neither the copy-from soliton/mind nor the copy-to soliton/mind can have a body, neither a bion body (like a Caretaker) nor a physical body (like a human, and all the other physically embodied animals that also have a soliton/mind). This means, for those conscious beings whose life cycle alternates between having a body and not, that both parties involved in the mind-copying process, must both be in the lucid-dream stage of the afterlife, not the embodiment stage nor the afterlife bion-body stage. This requirement excluding embodiment of either mind-copying party will avoid the possibility of problems of any kind with regard to either party’s embodiment, which could be caused by the mind-copying process having too much priority and/or taking too much time to finish. (Regarding the earlier mention in this paragraph of the afterlife bion-body stage: I think this afterlife bion-body stage is only for a conscious being that has physical embodiment in its life cycle, because having an afterlife bion-body is contradictory for a conscious being whose only embodiment in its life cycle is a bion-body, which might be most of the conscious beings in this universe, unless most of the conscious beings in this universe just exist in the lucid-dream stage and their life cycle has no embodiment stage.)
In our world, in a typical case of mind-copying, before the mind-copying process actually happens, I think it likely that there has already been a lot of interaction, even if only in the lucid-dream stage of the afterlife, between the two parties involved (those who will ultimately be the copy-from awareness/mind and the copy-to awareness/mind). Important: And, I guess, that interaction, along with current circumstances, has reached a point where there are changes in the state information of each of the two solitons such that, in effect, they both indicate that they want the mind copying to happen, and the role each has (as the copy-from soliton or the copy-to soliton), and they each identify the other (I think a soliton’s state information includes a few variables regarding mind-copying, including a variable to store the unique identifier of the other soliton in the currently wanted mind-copying process between them).
Regarding sleep, I say in my book’s section 9.3 The Need for Sleep:
When an intelligent particle is asleep, none of its learned programs are running (any of its learned programs that were running immediately before sleep, have been stopped by the computing-element program in preparation for this sleep time). Then, during sleep, the learning algorithms of the computing-element program (section 3.6) are running for that intelligent particle, with the possibility of making changes to that intelligent particle’s learned programs. Thus, any changes to an intelligent particle’s learned programs (including any additions or deletions of learned programs) can only happen when that intelligent particle is asleep.
In my book’s Transitioning from one Animal Type to a different Animal Type, I assume both solitons need to be asleep before the mind-copying can happen. However, I now assume that the copy-from soliton needs to be awake instead of asleep during the mind-copying process. Important: I don’t want the copy-from soliton’s mind, which is the mind to be copied, to possibly be in the middle of the computing-element program’s learning algorithms making one or more changes to that mind’s learned programs because that soliton is currently asleep, so, for that reason, I’m assuming a requirement that the copy-from soliton must be awake during the mind-copying process. (I’m also assuming, for those conscious beings whose life cycle includes embodiment, that during the lucid-dream stage of the afterlife when the mind-copying process can happen, that, in general, if a soliton is awake, then all of its mind is also awake, and if a soliton is asleep, then all of its mind is also asleep. However, when a mind is asleep, it is not necessarily using all of its time asleep just running the learning algorithms, because I know from my own experience that when I’m awake and consciously working with my mind on a problem, but I’m dissatisfied with the result that I’m getting, that when asleep my mind will often continue working on that same problem, and if my mind can then get a better result or solution than when I was awake, my mind will present my awareness with that better result or solution soon after I awake from that sleep. Besides experiencing this when I was working on my book, I’ve also experienced this more than a few times while working on this addendum.)
Each step in the mind-copying process will be labeled in boldface text and bracketed as step1 … end_step1_description, step2 … end_step2_description, step3 … end_step3_description, and so on, until the last step which is step5.
Also, for the mind-copying process, I’m defining five routines in the computing-element program, routine1, routine2, routine3, routine4, and routine5. Each of these routines will run with a high priority, but this priority will be lower than the priority of message transmission (regarding message transmission, see my book’s subsection 3.8.5 The Learned-Program send() Statement: Algorithmic Details, and The Sphere-Filling Message-Transmission Algorithm).
In this code, sometimes a message is sent from one particle to another, and a reply message is expected; alternatively, in this code, sometimes the code expects to receive a message that isn’t a reply message. An example of expecting a reply message is in step1 below, when routine1, running for the copy-to soliton, sends a message to the copy-from soliton, and then implicitly waits for a reply. However, what if a reply never comes, and this is possible if the copy-from soliton was too far away, beyond the reach of the send_distance used for that sent message (and the send_distance itself has a limit; it can’t just be anything). The solution assumed here, for the code that expects to receive a message (either a reply message or a non-reply message), is to wait in a timed loop that will only exit that timed loop if either the expected message is received, or too much time has elapsed after entering that timed loop. However, this addendum is already wordy enough, without adding this explanation of a timed loop for any expected message to be received. So, in the following steps and routines for the mind-copying process, just assume there is a timed loop where needed, if not already there, along with reasonable error handling, assuming there is a real chance that the expected message won’t be received. (Note: The computing-element program is assumed to have no bugs, and each computing element is assumed to run without error.)
step1: In the computing-element program, in its code which it runs for any sleeping soliton, assume at the very beginning of that code, before the computing-element program runs any learning algorithms for that soliton or any of its mind, run routine1, which will examine that soliton’s state information to see if it currently meets all the above requirements for being a copy-to soliton, and if it does, then that copy-to soliton’s routine1 will send a message to the copy-from soliton—the copy-from soliton’s unique identifier should be in the copy-to soliton’s state information regarding mind-copying; see 5.7 Revised preconditions for doing a mind copying—and upon receiving that message, the copy-from soliton will start routine2 running, which will examine that soliton’s state information to see if that soliton currently meets all the above requirements for being a copy-from soliton for that copy-to soliton, and if yes, then that copy-from soliton’s routine2 replies back positively to the copy-to soliton with a message saying that it also currently meets all the above requirements for being a copy-from soliton for that copy-to soliton, and then after receiving that positive reply message, that copy-to soliton’s routine1 sends a reply message to that copy-from soliton telling it to prepare for the mind-copying process, and it will do the same.
If the copy-to soliton doesn’t currently meet all requirements for the mind-copying process, then routine1 will exit. However, if routine1 sent the message to the copy-from soliton which started routine2, and routine2 determined that that copy-from soliton doesn’t currently meet all requirements for the mind-copying process, then that routine2 will first send a reply to the copy-to soliton telling it of this failure, and then routine2 will exit, and when the copy-to soliton gets this failure message, routine1 will also exit. When routine1 exits without reaching the “prepare for the mind-copying process” point, then, because that soliton was at the very start of the sleep process before running routine1, which, in effect, failed, and no mind-copying will happen, then resumption of the normal sleep process for that soliton will happen. end_step1_description
At this point, with the copy-to soliton having just sent a reply message to that copy-from soliton, telling it to prepare for the mind-copying process, this is the current status of the two mind-copying parties: the copy-from soliton/mind is awake, and the copy-to soliton/mind was at the start of the sleep process but is about to get its mind replaced. Also, neither party has an embodiment, neither a physical embodiment nor a bion-body embodiment.
step2: This is the “prepare for the mind-copying process” mentioned in step1. As a part of this “prepare for the mind-copying process”, both solitons, the copy-from soliton and the copy-to soliton, represented by routine2 and routine1 respectively, which are both still running, will each send a single message—named here the prepare-the-everything-else-group-for-mind-copying message—to all of the owned bions in that soliton’s everything-else group of owned bions (to identify in that one sent message, all of the message recipients, using their unsigned-integer unique identifiers, the range to specify is 101 thru 2×1020 inclusive (see here); this group has all of the mind’s learned programs), telling all those message recipients, to, in effect, prepare for the mind-copying process.
In the prepare-the-everything-else-group-for-mind-copying message sent by the copy-from soliton, its message text will identify routine3 as the routine to be called by each message recipient, and its message text will also include the unique identifier of the copy-to soliton, which will be the value of routine3’s one call parameter when routine3 is called by each message recipient.
This one call parameter of routine3—its value is the unique identifier of the copy-to soliton—will be used in step4 below, when routine3 is sending messages to the same-numbered copy-to owned bion. To uniquely identify that copy-to owned-bion recipient in each sent message, that copy-from owned bion running routine3 copies into that message to identify the message recipient, both its own unsigned-integer unique identifier (because of same-numbered), along with the value of routine3’s one call parameter, which is the unique identifier of the copy-to soliton.
In the copy-from soliton’s everything-else group of owned bions, each copy-from owned bion that receives the prepare-the-everything-else-group-for-mind-copying message, as stated in a previous paragraph, will call routine3 with the unique identifier of the copy-to soliton as the value of its one call parameter, and the first thing routine3 will do is to stop any learned programs in that owned bion that are running, and also prevent any other learned programs in that owned bion, if any, from running. Among other things, this will stop all output from its mind to the awareness associated with that copy-from soliton, putting that awareness in a solitonic-projection state (see my book’s section 6.2 Solitonic Projections). However, the reason to do this stoppage of all learned programs in the copy-from soliton’s everything-else group of owned bions, is to leave more compute time available for each of those owned bions, for the mind-copying messaging that is about to happen, and also, most important in my opinion, prevent the possibility of the copy-from awareness/mind, which is still awake, willfully moving about in 3D space, when, at the same time, the copy-to soliton/mind is about to get very close to, and then stay very close to, the copy-from soliton/mind (see step3 below). Also, until routine3, which is running for that copy-from owned bion, exits, any messages in that owned-bion’s message queue, that are received and awaiting processing, that are not related to the mind-copying process, are deleted.
In the prepare-the-everything-else-group-for-mind-copying message sent by the copy-to soliton, its message text will identify routine4 as the routine to be called by each message recipient, and its message text will also include the unique identifier of the copy-from soliton, which will be the value of routine4’s one call parameter when routine4 is called by each message recipient.
This one call parameter of routine4—its value is the unique identifier of the copy-from soliton—will be used in step4 below, when routine4 is receiving messages sent to the copy-to owned bion running routine4: each such message received, to be accepted and processed, has to identify the message sender as being an owned bion with the same unsigned-integer unique identifier (because of same-numbered) as that receiving copy-to owned bion running routine4, and the unique identifier of the soliton that owns the owned bion that sent that received message, has to be the same value as routine4’s call-parameter value, which is the unique identifier of the copy-from soliton.
In the copy-to soliton’s everything-else group of owned bions, each copy-to owned bion that receives the prepare-the-everything-else-group-for-mind-copying message will, as stated in a previous paragraph, call routine4 with the unique identifier of the copy-from soliton as the value of its one call parameter, and the first thing routine4 will do (the same as routine3 does), is to stop any learned programs in that owned bion that are running, and also prevent any other learned programs in that owned bion, if any, from running. Any learned programs in the copy-to soliton’s everything-else group of owned bions belong to the old mind that is about to be replaced, so, that is one reason to stop any learned programs from running, and another reason (same as for routine3) is to leave more compute time available for the mind-copying messaging that is about to happen. Also (like routine3), until routine4, which is running for that copy-to owned bion, exits, any messages in that owned-bion’s message queue, that are received and awaiting processing, that are not related to the mind-copying process, are deleted.
After doing the above in this step2, each instance of routine3 and routine4 will simply wait in a loop until: Each instance of routine3, which is running for a copy-from owned bion in the everything-else group, will wait to receive the message sent to it in the “third-way code” below, telling it to copy the Z memory in that copy-from owned bion to the same-numbered copy-to owned bion. And, each instance of routine4, which is running for a copy-to owned bion in the everything-else group, will wait to receive the last Z-memory message that the same-numbered copy-from owned bion will send to it (presumably, after the same-numbered copy-from owned bion, running routine3, has sent the last Z-memory message, then that is either indicated in that last Z-memory message’s message text, or routine3 will send a final message telling that same-numbered copy-to owned bion that there are no more Z-memory messages). end_step2_description
Before describing step3 which is next, recall that each soliton is surrounded by a spherical shell (as perceived by my awareness during the two solitonic projections that I had), and, I assume that perceived surrounding spherical shell is composed of the Q bions owned by that soliton, and, as I say in footnote 162 in my book, “My estimate of the diameter of that spherical shell is one inch (2.54 centimeters)”, based on the second of my two solitonic projections that I had (see my book’s subsection 10.1.2 My Two Solitonic Projections).
step3: The copy-to soliton’s routine1 has already sent the prepare-the-everything-else-group-for-mind-copying message in step2. routine1 will next start routine5 running in its own separate execution thread. Once routine5 starts running, it will remain running until routine1 cancels routine5’s separate execution thread.
Because mind-copying will require a lot of messaging, routine5 will move the copy-to soliton very close to the copy-from soliton (less than one-tenth of a millimeter between them should be easy to do, I think), and then make an ongoing effort to stay that close for as long as routine5 is still running. Doing this will reduce the send_distance of each message sent between a copy-from owned bion and the same-numbered copy-to owned bion to about 1.1 times the diameter of the spherical shell—the 0.1 in the 1.1 multiplier is a reasonable 10% margin of safety so that each sent message can reach its destination—since both spherical shells will occupy almost the same 3D space. (In my book’s subsection 5.2.1 Out-of-Body Movement during a Lucid Dream, there’s code for moving a soliton/mind close to a different soliton/mind, but not as close as what’s wanted here.)
Once the copy-to soliton is very close to the copy-from soliton, routine5 should wait a short time, say one second, to allow more than enough time for the stop-the-learned-programs part of step2 to complete, and then routine5 will send a message to the copy-from soliton, saying that the copy-from soliton can start doing the mind copying. end_step3_description
To avoid having any lost messages between each copy-from owned bion and its same-numbered copy-to owned bion, there are three ways to lessen lost messages:
Reduce the total number of message senders (sending reply messages included).
Before sending any Z-memory messages, first reduce the distance (and the corresponding message send_distance) between each copy-from owned bion and its same-numbered copy-to owned bion. However, if the owned bions in each spherical shell are randomly distributed in that shell with regard to the unsigned-integer unique identifier of each owned bion (this is most likely, I think), then reducing this send_distance to a practical minimum (less than one-tenth of a millimeter, I think, should be easy to do) and staying within this close distance during the Z-memory message sending—which includes any “final message” (see step2’s last paragraph)—is going to require its own messaging so that each copy-to owned bion can repeatedly query its same-numbered copy-from owned bion as to the location of that same-numbered copy-from owned bion, and then move towards it.
In the previous paragraph, there’s a need for back and forth messaging between each copy-to owned bion and its same-numbered copy-from owned bion, so that the copy-to owned bion can move very close to, and then stay very close to, that same-numbered copy-from owned bion, so that the Z-memory messages can then be sent using a very short-range send_distance. However, a message flood is still possible with that back and forth messaging at the start, so that each copy-to owned bion can move very close to that same-numbered copy-from owned bion, so the suggestion in the previous paragraph is not very useful. However, to make better use of this idea of bringing the copy-to owned bion and its same-numbered copy-from owned bion very close together, one can assume that the computing-element program actively prevents a random distribution in a spherical shell of owned bions with regard to the unsigned-integer unique identifier of each owned bion in that shell. See the next paragraph.
It did occur to me that if, when the computing-element program creates a soliton and all Q of its owned bions, what if that computing-element program, in effect, will create a long, continuous string of owned bions, in unsigned-integer unique identifier order, while wrapping this string of owned bions around an imaginary sphere centered on the soliton, beginning with the number 1 owned bion at the top of the spherical shell to be created, and ending with the number Q owned bion at the bottom, opposite pole, of that spherical shell just created. This assumes that the computing-element program has code that it periodically runs for each owned bion, to maintain this “string of owned bions”, that will move that owned bion as needed to keep it close to its nearest numeric neighbor(s). For example, for the two owned bions numbered 1 and Q, each has only a single neighbor in this string, being the two owned bions numbered 2 and (Q − 1) respectively, and that code will keep the two owned bions numbered 1 and Q close to the single neighbor each has, but in addition, because the two owned bions numbered 1 and Q are the begin and endpoint respectively on that spherical shell, that code will also make sure that the two owned bions numbered 1 and Q are kept the diameter-of-the-spherical-shell distant from each other. For all the owned bions numbered 2 thru (Q − 1) inclusive, those owned bions each have two neighbors on the string of owned bions, and that code will keep each of those owned bions close to its two neighbors. For example, the owned bion number 287 will be kept close on one side to owned bion number 286, and be kept close on the other side to owned bion number 288. Also, if this code to maintain the string of owned bions actually exists, then it should also include code to also keep that owned bion at radius-of-the-spherical-shell distance from the soliton that owns that owned bion. (This paragraph, in effect, describes two different programs, the wrap-around-the-sphere program and the maintain program, which can both be replaced with a single maintain program that can deal with the initial random locations in the spherical shell of the owned bions with regard to their unsigned-integer unique identifiers, after all Q owned bions have been created at radius-of-the-spherical-shell distance from the owning soliton.)
If the code description in the previous paragraph will form the well-ordered spherical shell that I imagine, then, to align the two spherical shells (the copy-from and the copy-to) so that each copy-from owned bion will be very close to its same-numbered copy-to owned bion, I think this alignment will require just three, instead of Q, movements by copy-to owned bions, each moving very close to its same-numbered copy-from owned bion, to align the two spheres as wanted. Specifically, I think copy-to owned bion numbered 1, copy-to owned bion numbered Q, and copy-to owned bion numbered integer_part_of(Q ÷ 2), are, in effect, the best three points on the copy-to spherical shell to align it with the copy-from spherical shell. Then, for each of those three copy-to owned bions, each should exchange messages with the same-numbered copy-from owned bion to get its location and ultimately move very close to, and stay very close to, that same-numbered copy-from owned bion.
If I’ve made any mistakes in the previous two paragraphs, then please excuse that, because I’m not completely sure I’ll get the alignment result I say in the previous paragraph, where each copy-from owned bion will be very close to its same-numbered copy-to owned bion. However, I already know that I won’t be using the idea in the previous two paragraphs in my algorithm for the mind-copying process, because I think it wastes too much compute time to maintain a highly ordered spherical shell as described above, just to make mind-copying faster. Even so, I wanted to include the previous two paragraphs for completeness.
Divide all the message senders into many different smaller groups, such that each of those smaller groups has a much smaller number of message senders in it, than the group of all of the message senders. Then, only do the message sending for each of those smaller groups, one smaller group at a time, until they are all done.
Given the above list of three ways to avoid having any lost messages, I’m going to be using the first way and the third way in my algorithm for the mind-copying process.
For the first way, which is to reduce the total number of message senders, refer to what I say in 5.5.1 An unexpected side benefit: simultaneously within a gigantic number of owned bions, search thru all memories, or erase all memories, and in the Very Important paragraph.
Thus, the only copy-from owned bions—that will each have its Z memory copied to the same-numbered copy-to owned bion—are those owned bions in the copy-from soliton’s everything-else group of owned bions, which, with regard to their unsigned-integer unique identifiers, range from 101 to 2×1020 inclusive. So, instead of Q message senders (all of the copy-from owned bions), that has been reduced to almost 2×1020 message senders, which is a huge reduction.
Also, for the first way, which is to reduce the total number of message senders, see what I say in 5.3 The message-flood problem, regarding two different messaging scenarios, the do-not-resend-a-presumed-lost-message scenario and the resend-a-presumed-lost-message scenario. Also, in 5.2 Messaging in 3D space, and the limit on the size of the message text, I say: “Thus, I don’t think there is any need for the use of checksums, either during messaging or at the end of messaging, to guarantee that the Z memory received by a copy-to owned bion is the same Z memory sent in a sequence of messages by the same-numbered copy-from owned bion.”
Thus, for my mind-copying algorithm, to avoid doubling unnecessarily the number of message senders by including each same-numbered copy-to owned bion as a message sender, my mind-copying algorithm will be using the do-not-resend-a-presumed-lost-message scenario, instead of the resend-a-presumed-lost-message scenario.
Okay, that’s everything with regard to using the first way, which is to reduce the total number of message senders, to avoid having any lost messages. When comparing almost 2×1020 message senders with an estimated minimum compute speed of 1030 instructions per second for each computing element (see 5.3 The message-flood problem), is there a need for also using the third way to avoid having any lost messages? To help answer this question, see section 8, which follows. (Note: Section 8 has roughly 3,500 words, and it is mostly off-topic compared to the rest of this addendum, so you may want to skip over it, at least initially, and go to 9. The third-way code: divide the message senders into smaller groups and send their messages at different times without overlap.)
The purpose of this section is to see if my mind-copying algorithm, after already using the first way to avoid any lost messages, which is to reduce the total number of message senders, also needs to use the third way to avoid any lost messages, which will divide the message senders into smaller groups and send their messages at different times without overlap.
Note: For the approximations immediately below, I’m choosing a message size for this mind-copying process, of 1,100 bytes, and my reasoning is as follows: In my book, if I recall correctly, I defined only a single format for messages sent by the send() statement. However, for improved efficiency in special cases like the mind-copying process, I’m going to assume that the value of the first byte in any message, in effect, identifies to the computing-element program that message type and its format. And, in the case of messages copying Z memory in the mind-copying process, besides that message-identifying byte, the non-message-text part of that message needs to identify the copy-from soliton as the message sender’s owning soliton and the copy-to soliton as the message recipient’s owning soliton, and also identify the unsigned-integer unique identifier of both the sending and receiving owned bions, that, for this message type identified by that first byte, is the same value for both those two owned bions, because of being same-numbered. Thus, using the sizes given in 5.6 Improving the usability of copied learned programs for a big-random-number unique identifier of a particle, which is 35 bytes, and for the unsigned-integer unique identifier of an owned bion, which is 13 bytes, that gives a total size of this message type’s non-message-text part of 35+35+13 = 83 bytes. Also, for this message type’s message-text part, given my 1,100 byte estimate for the message size, the message-text part has 1,100−(83+1)=1,016 bytes it can use for the message-text part, which, I assume, begins with a 4-byte unsigned integer (this is the offset into the Z memory where the Z-memory part in this message-text was copied from; note: I’m assuming the Z memory is contiguous), followed by a 2-byte unsigned integer which is the length (can be zero) of the Z-memory part that follows in this message text. Okay, note that the maximum size in this message text for the Z-memory part is 1,016−6 which is 1,010 bytes, and this means that a million of these messages times 1,010 bytes of Z-memory per message is a bit more than a billion bytes of Z memory (in this addendum, the value of Z is assumed to be one billion bytes, which is 109 bytes), so, my choice of 1,100 bytes for the message size in my approximations below is a good choice.
Given what has been said so far in this addendum, these are the approximations I’ll be using to estimate the computational burden of message transmission for this mind-copying process:
Each computing element has a compute speed of 1030 instructions per second (these computer instructions are also known as machine instructions, because the computer is a machine).
Note: The machine-instruction count is a measure of time, which is implied by saying that each computing element has a compute speed of 1030 instructions per second. By analogy with humanity’s physical computers, regarding the computing-element computer, actions that take only one machine instruction include but are not limited to: loading a register with a register-sized value in memory, assuming the address of the memory is in another register; saving a register’s current value into memory, assuming the address of the memory is in another register; integer addition or subtraction given two integers in two different registers, with the integer result put in a register.
In the allowed time, each copy-from owned bion in the everything-else group, has to send one million (106) messages, and the total size of each message is 1,100 bytes.
In the allowed time, each copy-to owned bion in the everything-else group, has to receive one million (106) messages, and the total size of each message is 1,100 bytes.
In the allowed time, each copy-from soliton’s owned bion and each copy-to soliton’s owned bion, has to run my book’s message-transmission algorithm for each of one million (106) messages (the total size of each message is 1,100 bytes) sent by each of the copy-from owned bions in the everything-else group—excluding itself if it is also in the everything-else group and item 2 or 3 in this list applies to it—which, for simplicity, I’ll round up slightly to 2×1020 copy-from owned bions in the everything-else group as the message senders.
Note: For an owned bion in the everything-else group, in which case either item 2 or item 3 also applies along with this item 4, the “round up slightly”, in terms of its added computation cost for this item 4, is presumably greater than the computation cost of item 2 or 3 in this list for that owned bion in the everything-else group. Thus, for any copy-from or copy-to owned bion I can ignore estimating execution time for items 2 and 3, and just estimate for this item 4.
Okay, given the immediately above paragraph, I only need to estimate for item 4. So, to get a quick number, I’ll initially assume that the message-transmission cost for a single message of size 1,100 bytes, is one machine instruction. With this assumption, item 4 needs a total of (106×2×1020×1) machine instructions, which is 2×1026 machine instructions.
So, the initial comparison is 2×1026 machine instructions needed, versus 1030 machine instructions per second are available. So, just considering these two numbers, 1030 is 5,000 times bigger than 2×1026, which means that item 4 needs 0.2 milliseconds of compute time. So, next, I’ll get a more realistic estimate of the message-transmission cost for a single message of size 1,100 bytes, but first, I want to make three improvements to my book’s algorithm for message transmission, so that it runs faster.
Regarding message transmission, see my book’s subsection 3.8.5 The Learned-Program send() Statement: Algorithmic Details, and The Sphere-Filling Message-Transmission Algorithm. The two routines called to handle the message that was copied into its memory by an adjacent computing element, are examine_a_message_instance(message_instance) and pass_this_message_along(message_instance). Note: the call parameter message_instance is a pointer to the message in that owned-bion’s memory.
Note: In 8.2 To make message transmission faster, eliminate the square root by squaring both sides, and do that math comparison at most only once, instead of an average of three times, I’m going to make three improvements to my code in my book for the pass_this_message_along(message_instance) routine, so that it runs faster.
Specifically, the code improvements use the message_instance.transfer_count variable, and change the M_append(an XYZ coordinate) macro.
Regarding the message_instance.transfer_count, which is initialized to zero by the message sender, my book says:
For this message-transmission algorithm, whenever a computing element (denote as this_CE) receives (has copied to it) a message_instance from an adjacent computing element, this_CE does the following three steps [only the first step is shown here; see my book for the other two steps if curious]:
The first thing that this_CE does with the message_instance is increment message_instance.transfer_count by adding 1 to it. Note: this is the only change to the message_instance that this_CE will make.
Regarding the M_append(an XYZ coordinate) macro, my book says (note that (cx, cy, cz) is this_CE’s XYZ coordinate):
In the below selection code, “M_append(an XYZ coordinate)” is a macro that represents code that does the following: If the distance (computed using the distance formula) between the given XYZ coordinate and the message_instance.sender's_XYZ is not greater than message_instance.send_distance, then append that given XYZ coordinate to the give_to_list.
Note that the XYZ coordinate given to M_append() in the below selection code will always be the XYZ coordinate of a computing element that is adjacent to this_CE, assuming that this_CE has six adjacent computing elements. The six adjacent computing elements are: (cx + 1, cy, cz), (cx − 1, cy, cz), (cx, cy + 1, cz), (cx, cy − 1, cz), (cx, cy, cz + 1), (cx, cy, cz − 1).
While thinking about the compute cost of the pass_this_message_along(message_instance) routine in my book, I realized that computing the distance formula in the M_append() macro presumably has a high compute-cost because of the need to compute a square root. Also, I estimate that, given the six sides for the computing-element cube, the average call of pass_this_message_along(message_instance) will, in effect, compute the distance formula three times.
To compute the distance between two points in 3D space, point (x1, y1, z1) and point (x2, y2, z2), this is the distance formula:
square_root_of((x2 − x1)2 + (y2 − y1)2 + (z2 − z1)2)
The comparison in my book’s M_append(an XYZ coordinate) macro, shown here, compares A to B, such that A is “the distance (computed using the distance formula) between the given XYZ coordinate and the message_instance.sender's_XYZ”, and B is the “message_instance.send_distance”. So, to get rid of that computationally expensive square root in the distance formula, use algebra, and square both sides of the comparison. Also, the point (sx, sy, sz) is the message sender’s XYZ coordinates, and let the point (mx, my, mz) be the M_append() macro’s parameter, described as “an XYZ coordinate”. Then, the new and equivalent, but computationally less expensive comparison, becomes (signed arithmetic is assumed):
if (((sx − (mx))2 + (sy − (my))2 + (sz − (mz))2) [a comparison operator] (message_instance.send_distance × message_instance.send_distance))
My next improvement to my pass_this_message_along(message_instance) routine in my book, to make it run faster, is to only evaluate the immediately above if statement no more than once, instead of a presumed average of three times for each call of the pass_this_message_along(message_instance) routine. In effect, for the sake of running faster, the message-filled 3D sphere will be a very slightly rougher sphere shape than it would otherwise be, but I believe this tradeoff is worth it. So, this is another change to the M_append() macro.
Another improvement to make the pass_this_message_along(message_instance) routine run faster, is to recognize that if the message_instance.transfer_count is not greater than message_instance.send_distance, then it’s impossible for the computed distance (referring to my book’s definition of the M_append() macro) to be greater than message_instance.send_distance, so there is no reason to compute that distance.
So, making these three changes to my pass_this_message_along(message_instance) routine so that it runs faster, requires the following two changes to its code (each comment is enclosed by /* and */):
/*
Add this code at or near the beginning of the pass_this_message_along(message_instance) routine, before any occurrence of the M_append() macro in its code.
*/
if(message_instance.transfer_count > message_instance.send_distance)
compute_distance_once = true
else
compute_distance_once = false
endif
This is the new definition of the M_append(an XYZ coordinate) macro in that first paragraph (the second paragraph stays the same):
In the below selection code, “M_append(an XYZ coordinate, denoted as mx, my, mz)” is a macro that represents code that does the following:
if compute_distance_once is true
compute_distance_once = falseendif
/*
Note: to get rid of the square root in the distance formula, both sides of the comparison operator were squared.
*/
if (((sx − (mx))2 + (sy − (my))2 + (sz − (mz))2) is greater than (message_instance.send_distance × message_instance.send_distance))
/*endif
This return ends this call of pass_this_message_along(message_instance).
*/
return
append that given XYZ coordinate, (mx, my, mz), to the give_to_list.
Note; In this new definition of the M_append(an XYZ coordinate) macro, the idea of that return, ending that call of the pass_this_message_along(message_instance) routine, is that if that XYZ coordinate is outside of the allowed 3D sphere centered at message_instance.sender's_XYZ, then the other possible occurrences of the M_append(an XYZ coordinate) macro in that call of that pass_this_message_along(message_instance) routine, will also be outside of that allowed 3D sphere centered at message_instance.sender's_XYZ, which may not be true. This is the tradeoff mentioned above, resulting in a message-filled 3D sphere that will be a very slightly rougher sphere shape than it would be with my book’s definition of the M_append(an XYZ coordinate) macro.
First, I’ll give my estimate of how many machine instructions are needed to do the call of examine_a_message_instance(message_instance). Note: each sent message has only a single recipient (the same-numbered copy-to owned bion), and, as stated for item 4 above, I can ignore items 2 and 3, which means that the implied owned bion running this routine is not a recipient of the message pointed to by the message_instance, which means this message is not going to be added to this owned-bion’s message queue, so I’m going to roughly estimate that this call of examine_a_message_instance(message_instance) will cost 50 machine instructions.
Next, I’ll give my estimate of how many machine instructions are needed to do the call of pass_this_message_along(message_instance):
For the average message-transmission case in item 4, I’m going to assume that in the average case, the 1,100 byte message will be copied to 3 of the 6 adjacent computing elements, and I’m going to assume that a single machine instruction can copy 8 bytes at a time, copying from its own memory to an adjacent computing element. So, 1,100÷8 needs 138 machine instructions to copy the message, times 3 copies to do, needs 414 machine instructions.
Next, I’ll give my rough estimate of how many instructions are needed to run the rest of my revised pass_this_message_along(message_instance) routine: I’m estimating a cost of roughly 100 machine instructions plus the cost of evaluating this if statement once, which is the less-compute-costly distance comparison after squaring both sides of the comparison operator.
NOTE: The following indented paragraphs, enclosed by the boldfaced BEGIN and END, were written by me before I realized the algebraic simplification of getting rid of the square root in the distance formula by simply squaring both sides of the comparison operator. Initially, I thought I should just delete most of these paragraphs and only retain what I said about integer multiplication costing 3 machine instructions. However, I think what I wrote—along with the references I give—is interesting, and that’s why I decided to retain these paragraphs, but I’ve clearly marked them, by indenting them and enclosing them between BEGIN and END, because, with the exception of what I said about integer multiplication costing 3 machine instructions, these paragraphs are not needed to estimate the compute cost of my revised pass_this_message_along(message_instance) routine.
The Wikipedia page Methods of computing square roots says: “The most familiar such method, most suited for programmatic calculation, is Newton's method, which is based on a property of the derivative in the calculus.” And Newton’s method is described in the Wikipedia page Newton's method. However, in this usage case, the operand that will have its square root computed, will itself be an integer, and I only care about the integer part of the square root and not its fractional or remainder part, because it’s only use in the macro M_append() will be the comparison to the integer message_instance.send_distance, which means that the computing-element program might use the “Algorithm using Newton's method” given in the Wikipedia page Integer square root, and I’ll just assume that’s the algorithm used to compute the square root in my revised macro M_append().
Anyway, that last Wikipedia page, “Integer square root”, includes C code under the heading “Example implementation in C”, and because the n value to have its square root determined has to be greater than message_instance.send_distance (see here), which in this item 4 case will be a very large integer value—the distance unit in my book is the side-width of a computing element which is estimated to be 10−16 of a centimeter—which means that the “Using only integer division” in that Wikipedia page applies. And integer division (given two integers, compute the quotient and remainder, and in this usage case the remainder is not used), is presumably less costly in terms of compute time than using floating-point division.
Referring to the “Example implementation in C” in the previous paragraph, the initialize part has 3 divisions and one addition, and the iterative loop part has 2 divisions and one addition, and, if I guess a dozen iterations are needed for the average case in step 4, that’s 3+(2×12) which is 27 divisions and 13 additions needed to compute the integer square root. And add to that the three multiplications and two additions needed to compute the n value that will have its integer square root computed. So, given that the machine-instruction count is a measure of time, how many machine instructions do I want to give to integer multiplication, and how many to integer division? (Note: the integer additions, as I already state for item 1 above, cost one machine instruction each.)
Okay, I want to know the cost of integer division in terms of how many machine instructions are needed, and likewise for integer multiplication. These are the two Wikipedia pages: Division algorithm, and Multiplication algorithm. Also, after reading this article and its comments, Why does hardware division take much longer than multiplication?, it made me wonder: do the computing elements, assuming they are binary-based computers like our man-made physical computers, have the equivalent of the very complex circuitry and/or microcode that many modern microcomputers have, to make computing divisions and multiplications and also square-roots much faster than they would otherwise be? This question cannot be answered, because, as I already say in my book:
All particles, whether intelligent or common, are data stored in computing elements (chapter 1). Thus, particles—as an effect of the computing elements—cannot be used to directly probe and/or manipulate the computing elements. Thus, no civilization in this universe can ever know the actual instruction set of the computing elements, nor can it ever know the actual programming language of learned programs.
Okay, back to my above question of how many machine instructions do I want to give to integer multiplication, and how many to integer division? Referring to this October 2013 forum article, Math execution times for Arduino, and post #10 by the user named “system”, and referring to his numbers in the int64 column—presumably int64 is a signed 64-bit integer, and that is the operand type—in the table he shows, he gives 8428 for addition, 57038 for multiplication, and 274809 for division. Because I count addition as one machine instruction, that means that, given his numbers, integer multiplication costs 57038÷8428=6.77 which rounds to 7 machine instructions, and integer division costs 274809÷8428=32.61 which rounds to 33 machine instructions.
However, referring to the Instruction tables by Agner Fog, which focuses on Intel microcomputers, integer multiplication of 64-bit operands typically costs 3 clock ticks while integer addition of 64-bit operands typically costs one clock tick, which means, by analogy, that integer multiplication costs 3 machine instructions. In the case of integer division of 64-bit operands, there is more variability in Agner Fog’s numbers (for example, 37 to 100 clock ticks for Intel Nehalem, 39 to 103 clock ticks for Intel Haswell, 14 to 43 clock ticks for Intel Goldmont Plus, and 28 to 103 clock ticks for Intel Ivy Bridge).
So, given the two previous paragraphs, and for the sake of calculating a number, I’m going to assume that for a computing element, integer multiplication costs 3 machine instructions, and integer division costs 33 machine instructions. So, with these compute-cost assumptions, I’ll now compute the integer square root, given the data in this paragraph: 27 divisions and 13 additions needed to compute the integer square root, and the three multiplications and two additions needed to compute the n value that will have its integer square root computed, I get a total of (27 divisions×33)=891, plus (3 multiplications×3)=9, plus (15 additions×1)=15, for a total machine-instruction cost of 891+9+15=915 machine instructions.
Assuming integer multiplication costs 3 machine instructions, integer addition and subtraction each cost one machine instruction, and the comparison operator costs one machine instruction. What is the compute cost of this if statement, which will execute at most only once during a call of my revised pass_this_message_along(message_instance) routine: All of the operands are signed integers, and there are 3 subtractions, 2 additions, and 4 multiplications, and one comparison operator, which add up to 3+2+(4×3)+1=18 machine instructions.
Now, to get my estimated total cost for an owned bion doing one message transmission of an 1,100 byte message, and that owned bion is not a recipient of that message, I get a total cost of 50+414+100+18=582 machine instructions, and this is the more realistic estimate of the message-transmission cost for a single message of size 1,100 bytes mentioned here.
And now the comparison is (106×2×1020×582), which my calculator says is 1.164×1029 machine instructions needed to do all of item 4 above, versus 1030 machine instructions per second are available. So, 1030 is only 8.59 times bigger than 1.164×1029, and I think that’s close enough to justify also using the third way to avoid any lost messages, which will divide the nearly 2×1020 message senders into smaller groups and send their messages at different times without overlap.
The following third-way code will be in routine2 which is being run by the copy-from soliton. After the copy-from soliton gets the message from routine5 saying that it can start doing the mind copying, then this third-way code executes. Note: each comment in this third-way code is enclosed by /* and */.
/*
This is the beginning of the third-way code.
The actual mind-copying is about to begin, so, do the two erasures described in the Very Important paragraph.
*/
Send a message to the copy-to soliton, telling it to erase both its soliton-directory group and its storage-of-memories group.
/*
To avoid having any lost messages between each copy-from owned bion and its same-numbered copy-to owned bion, I’m going to divide the copy-from soliton’s everything-else group of owned bions into one thousand smaller groups.
Note: (2×1020) ÷ 1,000 = 2×1017
*/
range_low = 101
range_high = 2×1017
wait_time = 0.1 seconds
/*
The following for works as follows: First, sub is set to 1, and then, as long as the value of sub is less than or equal to one thousand, the code between do and end do is executed.
Note: When the for loop ends, every one of the owned bions in the copy-from soliton’s everything-else group of owned bions (owned bions numbered 101 thru 2×1020 inclusive), will be a recipient of one of those thousand messages sent by that for loop.
*/
for (sub = 1, sub <= 1,000)
do
Send one message to the owned bions of the copy-from soliton, in the range range_low thru range_high inclusive, telling each of those recipients to copy the Z memory in that copy-from owned bion to the same-numbered copy-to owned bion.
/*
Update the range for the next iteration of the for loop.
*/
range_low = range_high + 1
range_high = range_high + (2×1017)
/*
I’ve set the wait_time to one-tenth of a second (100 milliseconds), and this should be much more than enough time for all of the copy-from owned-bion recipients of the above message sent within this for loop, to each then send my estimate of roughly a million messages to the same-numbered copy-to owned bion, needed to copy my estimate of a billion bytes of Z memory. Also, note that step2 has already happened, because of that one-second wait in routine5, so none of those copy-from owned-bion recipients have any learned programs running, and also, because the copy-from soliton is still awake, none of the learning algorithms during sleep are running, so, other than the normal duties of every computing element—doing message transmission (see my book’s Two different Message-Transmission Algorithms) and, if holding a particle with mass, gravity messages, both sending and receiving gravity messages (see my book’s footnote 23)—those copy-from owned-bion recipients of the message sent above with range range_low thru range_high inclusive, will have most of the computing-element’s processing power to send those million messages, and, considering the estimated minimum compute speed of each computing element of 1030 instructions per second, a ten-times shorter wait_time of ten milliseconds, instead of 100 milliseconds, should also be more than enough time, I think (I’m including room in this wait_time of ten milliseconds for my suggested “much less than a nanosecond”—treating it as one nanosecond instead of “much less than a nanosecond”—wait time after each of roughly a million messages are sent by routine3).
*/
wait the wait_time
increment sub /* add 1 to it */
end do
end for
/*
A reminder: This code is being run by routine2 which is being run by the copy-from soliton.
At this point in this code, all 1,000 iterations of the above for loop have been done, and, given the above wait_time value of one-tenth of a second, the above for loop has taken about 100 seconds to run (1,000 × wait_time is 100 seconds, which is one minute and 40 seconds).
Also, at this point in this code, the mind-copying has been done, and no instance of either routine3 or routine4—see below in step4—should still be running, so there are three things left for this routine2 to do:
*/
- Send a message to the copy-to soliton, telling it that the mind-copying has been done.
- Erase the copy-from soliton’s mind-copying state information.
- Do what is needed to return the copy-from soliton’s associated awareness back to a normal awake state.
Send a message to the copy-to soliton, telling it that the mind-copying has been done.
/*
At this point, after sending the immediately above message to the copy-to soliton, the copy-from soliton no longer has any need for the mind-copying info in its state information about the copy-to party. Thus:
*/
Erase and/or reset as needed whatever mind-copying values are in this copy-from soliton’s state information. An example of a value that will be erased is the unique identifier of the copy-to soliton.
/*
At this point, the mind-copying process is done for the copy-from soliton. However, the copy-from soliton was awake at the start of the mind-copying process, and step2, which stopped and prevented all of the learned programs in the copy-from soliton’s mind from running, has put, and, in effect, kept, the copy-from soliton’s associated awareness in a solitonic-projection state, for, at this point in this code, about 1 minute and 41 seconds (adding the one-second wait in step3 and the 1 minute and 40 seconds wait resulting from the above wait_time of one-tenth of a second and the 1,000 iterations of the above for loop).
So, it’s time to get things back to normal for the copy-from soliton’s associated awareness, and that means that this routine2 will, in effect, undo at least some of what it did in step2. Specifically, at least some of those learned programs that were stopped in step2, need to be restarted and running again.
However, there is something about learned programs that I didn’t consider in my book, but I’ll consider here: The computing-element program probably has a predefined way of marking each learned program in an owned-bion’s Z memory with regard to what that learned program will do. For example, if a learned program is designed to be a callable routine with parameters, then that should be marked in some small predefined info block of memory—understood and used by the computing-element program—at the beginning of a learned program before the actual code of that learned program.
To get things back to normal for the copy-from soliton’s associated awareness, in terms of which learned programs to restart and run again, any learned program that is marked as a callable routine, would not be restarted here, even if it was running before when step2 stopped all learned programs from running, because a learned program marked as a callable routine can presumably only be run when it is called by some other learned program in that mind.
As already said above, the copy-from soliton’s associated awareness is still in a solitonic-projection state, so, to end that, the learned programs in its mind that generate sensory data for the awareness when it’s awake, such as vision and hearing, need to be running, and if a learned program generates data for input to the soliton’s associated awareness, that is certainly important enough to be marked in its info block (look two paragraphs above this one to see what I mean by an “info block”), for each of those learned programs that do that data generation for the awareness. If these learned programs are themselves callable routines, then any code that is trying to find which learned programs to run, would have to find out which learned program(s) are calling those learned programs and run them, unless those learned programs are also callable, and so on, until that code can find the root learned programs that are not callable and can be run.
Okay, at this point things are getting complicated, when there is a more simple solution: just run whatever learned program(s) are in its mind, that that copy-from soliton runs when it is waking up from sleep, which will give its associated awareness all the normal sensory inputs and other inputs that it normally has when awake, such as vision and hearing and being able to consciously think with its mind and also communicate with others.
However, the previous paragraph raises this question: With regard to the learned programs in a soliton’s mind, how does the computing-element program know which learned programs to run, to give that soliton’s associated awareness its awake experience, when it is not asleep? And this same question also applies to step5 below, in which the copy-to soliton now has a new mind, but how is that copy-to soliton’s associated awareness going to wake up with that new mind that it now has?
I think the best solution is to just assume that the computing-element program predefines the first owned bion in the everything-else group, which has the unsigned-integer unique identifier of 101, to be the location of lists, that are constructed and maintained over the course of time by the computing-element program, regarding all the learned programs currently in the rest of the everything-else group (those owned bions numbered 102 thru 2×1020 inclusive), and the computing-element program’s analysis of them (presumably this analysis would happen during sleep, and on an as-needed basis depending on what kind of changes, if any, have recently happened to the learned programs as a result of the computing-element program’s learning algorithms that can be run during sleep). Each of the current lists in that owned bion numbered 101 will associate an embodiment type with a list of root learned programs that should be running when that soliton/mind is in that type of embodiment, and the associated awareness is awake (look three paragraphs above this one to see what I mean by a “root learned program”).
Referring to the lists in the owned bion numbered 101, described in the previous paragraph: During normal sleep, when the associated awareness is ready to fall asleep, that awareness’s soliton will send a message to that owned bion numbered 101, telling it which embodiment list to use, and to stop running all the root learned programs in that list. And likewise, during normal sleep, when the associated awareness is ready to awake and end its sleep, that awareness’s soliton will send a message to that owned bion numbered 101, telling it which embodiment list to use, and to start running all the root learned programs in that list.
Referring to the previous paragraph and the stoppage of learned programs: Assume that stopping a learned program that has an ongoing call of another learned program in a different owned bion, that that will result in a message being sent to that other owned bion telling it that that calling learned program was stopped and that the call that it made, if still running, should also be stopped. Likewise, if a learned program is stopped, then stopping that learned program will also stop any ongoing threads of execution that that stopped learned program started (presumably, all these execution threads along with the learned program to be stopped, are running on the same owned bion).
During my life, there have certainly been many times when my mind has, in effect, awakened me from sleep. For example, in all of the out-of-body experiences I had (see my book), I was always asleep first, on my bed, when at some point I would become awake (conscious) and find myself either lying flat on my back (typically prior to a bion-body projection), or already in a bion-body, or already in a lucid-dream which, based on my experience with lucid dreams, had no actual embodiment. More commonly experienced, including by me, is being awakened by a loud noise while sleeping. Probably the most common example of this is a ringing alarm clock. Even in my retirement I use an alarm clock, albeit in year 2023 as I write this, a modern version of an alarm clock in the form of an app on a computerized touch-sensitive tablet. Anyway, to wake me up, I think my mind will send an alert message to my soliton telling it of the loud noise, which in turn will cause my soliton to send a message to that owned bion numbered 101, telling it to use the physical-embodiment list, and to start running all the root learned programs in that list.
Based on my own experiences in my life, I have three embodiment types: my physical embodiment (my human body that I’m using to type this on my home computer), my bion-body embodiment (see my book), and no embodiment (lucid dreaming, see my book). So, I have three of those lists in that owned bion numbered 101, and I assume all other humans also have those three lists.
Note that both the copy-from soliton and the copy-to soliton are in the no-embodiment state, because that is one of the requirements for the mind-copying process (see 5.7 Revised preconditions for doing a mind copying).
*/
To return the copy-from soliton’s associated awareness to its normal state when awake, send a message to that owned bion numbered 101, telling it to run all the root learned programs in its list for no-embodiment.
/*
This is the end of the third-way code.
This exit ends the running of routine2, which is being run by the copy-from soliton.
*/
exit
step4: In routine2, which is being run by the copy-from soliton, after already doing what is in step1 and step2 for routine2 to do, routine2 will then be waiting in a timed loop for the message from routine5 notifying the copy-from soliton that it can start doing the mind copying. And once that message from routine5 is received, and that timed loop is then exited, then the third-way code above, in routine2, is run. Then, after all one thousand iterations of the above for loop have been done, each owned bion in the copy-from soliton’s everything-else group has had its Z memory copied by messaging to the same-numbered owned bion in the copy-to soliton’s everything-else group, thereby replacing that part of the copy-to soliton’s mind. (Note: Recall that some small pieces of the copied Z memory are ignored and not copied into its own Z memory by the receiving copy-to owned-bion; specifically, the three constants in each owned bion’s state information, described in 5.4 The state information of an owned bion includes three constants that were set when that owned bion was created, that cannot be changed, and are unaffected by the mind-copying process.)
Regarding routine3 and routine4: After routine3 (running for each of the owned bions in the copy-from soliton’s everything-else group) and routine4 (running for each of the owned bions in the copy-to soliton’s everything-else group), have stopped all learned programs from running, both will be waiting in a loop (see step2’s last paragraph for a description of those two wait loops, one for routine3 and one for routine4).
While waiting in that loop, when a copy-from owned bion that is running routine3 is a recipient of the message sent in this step4 by routine2 when running the above third-way code, then that owned bion exits that wait loop and does the messaging of its Z memory to the same-numbered copy-to owned bion, using the do-not-resend-a-presumed-lost-message scenario. After sending each message in what may be a sequence of a million messages—see 5.2 Messaging in 3D space, and the limit on the size of the message text—routine3 should wait for a very short time (much less than a nanosecond, I think) before sending the next message in that sequence, to allow the recipient same-numbered copy-to owned bion, that is running routine4, enough time to process each received message.
Regarding how the copy-from owned bion running routine3 will notify the same-numbered copy-to owned bion running routine4 when there are no more Z-memory messages to be received, I’ve already said above: “presumably, after the same-numbered copy-from owned bion, running routine3, has sent the last Z-memory message, then that is either indicated in that last Z-memory message’s message text, or routine3 will send a final message telling that same-numbered copy-to owned bion that there are no more Z-memory messages”. After routine3 has sent its last message to that same-numbered copy-to owned bion, it exits.
Regarding routine4, which is waiting in its wait loop, whenever a copy-to owned bion that is running routine4 receives one of those Z-memory messages from the same-numbered copy-from owned bion, it examines that message’s message text—the computing-element program has predefined the format of this message text for mind-copying—and then copies the Z memory in that message text into its own Z memory, at the offset specified in that message text. When routine4 gets notified—see the previous paragraph—that there are no more of those Z-memory messages to be received, then process as needed that last received message and exit routine4. end_step4_description
step5: The copy-to soliton, which is running routine1, after already doing what is in step1, step2, and step3 for routine1 to do, is currently waiting in a loop to receive two different messages sent by routine2 which is being run by the copy-from soliton. The first message that will be received is shown above at the beginning of the third-way code, and it tells the copy-to soliton to erase both its soliton-directory group and its storage-of-memories group, and this routine1 will do those two erasures by sending the two erase messages described in the Very Important paragraph. The second message that will be received is also shown above in the third-way code, after the end for, and it will tell the copy-to soliton that the mind-copying has been done, and when this second message is received, routine1 will exit this wait loop.
At this point, the copy-to soliton/mind has its new mind, and needs nothing more from the copy-from soliton/mind, so there is no longer a reason to be running routine5, which has been keeping the two mind-copying parties close together in 3D space. Thus, routine1 now cancels routine5’s separate execution thread, which will, in effect, cause routine5 to exit and stop running.
Also at this point, because the mind-copying is done, this routine1 will erase and/or reset as needed whatever mind-copying values are in this copy-to soliton’s state information—an example of a value that will be erased is the unique identifier of the copy-from soliton. The same is done by routine2 for the copy-from soliton (see above in the third-way code, after the end for), and neither “erase and/or reset” should be delayed, because I want to prevent this mind-copying process from repeating itself the next time the copy-to soliton’s associated awareness falls asleep.
At the beginning of this mind-copying process, this copy-to soliton’s associated awareness had just fallen asleep. But it’s now less than two minutes later (assuming the wait times I’ve stated above), and this copy-to soliton now has its new mind, and also both its memories in its storage-of-memories group and the contents of its soliton directory in its soliton-directory group, have been erased, so what should be done for this copy-to soliton’s associated awareness, now? Note that that new mind, copied from the copy-from soliton/mind, includes new contents for all the owned bions in the copy-to soliton’s everything-else group of owned bions, including the owned bion numbered 101. So, with its new mind, this copy-to soliton and its associated awareness already have what is needed for both normal sleep and normal awakening from sleep, in that owned bion numbered 101. Regarding this, read the next-to-last comment (enclosed by /* and */) in the above third-way code.
So, at this point in time, for this copy-to soliton’s associated awareness, what should be done for it? Perhaps the best thing is for this routine1 to send a message to that owned bion numbered 101, and tell it to run all the root learned programs in its list for no-embodiment (the current state of the copy-to soliton is no-embodiment). Doing that will probably awaken that copy-to soliton’s associated awareness, which can then start experiencing that new mind that it now has, and it can start making new memories with that new mind. Alternatively, instead of doing that, if the copy-to soliton’s associated awareness is still unconscious (assuming the computing-element program can detect that somehow) then maybe it would be best to just restart the sleep process. So, do one or the other, and then exit that routine1. end_step5_description
As I say in 2. The problem in my book that this addendum corrects, I first consciously realized the problem in my book, May 12, 2023, and I began work on this addendum a few days later. And I’m finally done with all the thinking and writing and polishing of this addendum, and it’s October 31, 2023, about 5½ months after I started. And this is despite consciously working almost every day on it, at roughly five hours a day, because I was highly motivated to get this job done and correct that problem in my book.
Of course, the big reason this addendum has taken me so long, is because as I write this, I’m 67 years old. More specifically, I am an old man, consciously working with a mind hobbled by much slower thinking, and short-term memories that are forgotten a lot sooner than they used to be (this mental aging of myself is detailed in my revised 12th edition of my book, section 10.5 Three Changes to my Mind, that each happened when I was 65 years old, that I believe mark my entry into the beginning of Old Age for Me, and the start of my life living as an Old Man).
end of this addendum