On Tue, Dec 10, 2013 at 9:45 PM, meekerdb <meeke...@verizon.net> wrote:
> On 12/10/2013 2:07 AM, Telmo Menezes wrote:
>>
>> On Mon, Dec 9, 2013 at 8:02 PM, meekerdb <meeke...@verizon.net> wrote:
>>>
>>> On 12/9/2013 1:35 AM, Bruno Marchal wrote:
>>>>
>>>>
>>>> On 08 Dec 2013, at 22:53, Telmo Menezes wrote:
>>>>
>>>>> On Sun, Dec 8, 2013 at 6:59 PM, John Clark <johnkcl...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Telmo Menezes
>>>>>>
>>>>>>>> you must also reject the MWI, because you live
>>>>>>
>>>>>>
>>>>>>
>>>>>> Who is "you"? Telmo's post was only 63 words long but the pronoun
>>>>>> "you"
>>>>>> was
>>>>>> used 8 times, that's almost 13%. When it is necessary to hide behind
>>>>>> personal pronouns when a philosophical idea regarding duplicating
>>>>>> machines
>>>>>> and personal identity is discussed it's clear that something is wrong.
>>>>>>
>>>>>>>> in the first person,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Which first person? The first person of John Clark of one hour ago?
>>>>>> The
>>>>>> first person of John Clark standing left of the duplicating machine?
>>>>>> The
>>>>>> first person of John Clark standing right of the duplicating machine?
>>>>>
>>>>>
>>>>> You're avoiding my question. Why don't you also reject the MWI?
>>>>
>>>>
>>>>
>>>> I would like to know that too. Quentin has already asked this many times
>>>> to John, and we got unclear answer.
>>>>
>>>> John invoked the fact that with comp the duplication are done only in
>>>> one
>>>> branch of the universe, but did not explain why would that change
>>>> anything
>>>> (without adding some non Turing emulable magic in some place).
>>>>
>>>> I think Quentin is right, and John C. just develop irrational rhetoric
>>>> do
>>>> avoid moving on in the argument, ... then he talk like if I was defining
>>>> comp by its consequences, but this is another rhetorical trick, often
>>>> used
>>>> by those who want to mock the enterprise.
>>>>
>>>> It is interesting. I try to figure out what is really stucking him so
>>>> much. i do the same with my students in math. Why some people avoid
>>>> reason
>>>> in some circumstance. Given that Quentin seems to qualify himself as
>>>> atheist, it can't be simply Clark's atheism, isn't it? But then what?
>>>
>>>
>>> I think the sticking point, one which I also feel with some force, is the
>>> implicit assumption in the question, "Where will you find yourself." that
>>> there is a unique "you".
>>
>> Brent,
>>
>> Although naive, I find the following analogy useful: consider how
>> computer operating systems create new processes. A common method, in
>> UNIX operating systems is "forking" the current execution path. I will
>> cut and paste the relevant parts from the man page on my computer:
>>
>> NAME
>>
>>       fork -- create a new process
>>
>> DESCRIPTION
>>
>>       Fork() causes creation of a new process.  The new process (child
>> process) is an
>>
>>       exact copy of the calling process (parent process) except for the
>> following:
>>
>>
>>             o   The child process has a unique process ID.
>>
>>
>>             o   The child process has a different parent process ID
>> (i.e., the process
>>
>>                 ID of the parent process).
>>
>> [...]
>>
>> RETURN VALUES
>>
>>       Upon successful completion, fork() returns a value of 0 to the
>> child process and
>
>
> Fork() was called by the parent process; so it should return a value to the
> parent process, not the child process.

Fork() is an instruction that is part of some program. This program is
running in some process P1. When fork() is called, the operating
system creates a new process P2 and copies both the program and the
execution context of the program to P2. The execution context includes
the instruction pointer, that indicates the current instruction being
executed. After the copy, both P1 and P2 will point to the instruction
after fork(), with the only difference that fork() will have returned
different values to the parent and the child. It returns values on
both processes, and the operating system intervenes here to make them
different -- the OS acts as a duplication machine.

>
>>
>>       returns the process ID of the child process to the parent process.
>>
>> [...]
>>
>>
>> So let's say the original process A is forked at some point in time t,
>> and process B is created. The only different things about A and B is a
>> value called the process identifier (pid). This could be a very simple
>> analogy for a person being in Moscow or Brussels.
>>
>> So let's say the process records its pid before the fork. After the
>> fork, both processes are programmed to check their pid again and
>> compare it with what was stored. For one you will get "equal", for
>> another you will get "different".
>>
>> If you ask the program, before the fork, to predict if it will find
>> itself in the state "equal" or "unequal" after the fork, the most
>> correct program will assign p=.5 to each one of these outcomes. Any
>> program that assigns a different p will be shown to be less correct by
>> repeating this experiment a number of times.
>
>
> ?? What does "the program" refer to in "ask the program"?  If you ask A to
> print out whether it's pid is equal to the pid recorded before the fork, A
> can always correctly print "yes".  Similarly B can always print "no".  So
> what does it mean to "ask the program"? You seem to have implicitly created
> two programs and there is no unique referent for "the program".

Both the parent and the copy contain exactly the same algorithm. So
here, I can objectively refer to the program as a well defined
sequence of instructions, and an instance of the program as a process
running this set of instructions. I can have several instances of the
program running, in this case 2. From inside the program it is not
possible to see what the operating system is doing at a lower level,
but it is possible to measure some differences (be in Brussels, have
the same process id as before).

So we can have a simple program that does the following:

a = my process id           // personal diary
fork()                              // going through the duplicator
b = my process id
if a == b                         // answer the question "where am I?"
  location = "Brussels"
else
  location = "Moscow"
print ("I see " + location)

If we run this program, we will end up with two programs giving two
different answers, although both will legitimately have  the same
personal history stored in variable a. We can extend the program by
having it try to predict the future:


a = my process id           // personal diary
if (coin_flip == tails)
  prediction = "Brussels"
else
  prediction = "Moscow"
fork()                              // going through the duplicator
b = my process id
if a == b                         // answer the question "where am I?"
  location = "Brussels"
else
  location = "Moscow"
print ("I see " + location)
if (location == prediction)
  print "My prediction was correct"
else
  print "My prediction was false"

If we repeat this a number of times, we will find that the program
instances are right about 50% of the time. There is no possible
algorithm that does better (or worse) than this before the fork,
provided it predicts either "Moscow" or "Brussels".

Going through the duplicator, we are in the same situation as this program.

Telmo.


> Brent
>
>
>>
>> The program can tell you the state with p=1 after the fork.
>>
>> Otherwise, both programs will feel "unique", in the sense that their
>> algorithms remain unchanged. It is now possible for them to interact,
>> in the same way that the victims of the duplication experiment can
>> shake hands or play chess.
>>
>> If you ask any of the programs about a record of their states before
>> the fork, they will give you equal answers (if they are correct
>> programs).
>>
>>
>> What do you think?
>>
>> Telmo.
>>
>>
>>>   Under the theory of souls it would make sense to
>>> ask, which duplicate will your soul go to. But under computationalism
>>> there
>>> is no answer be the duplication entails that there is no "you", there are
>>> only computations that "think" you.
>>>
>>> Brent
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Everything List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to everything-list+unsubscr...@googlegroups.com.
>>> To post to this group, send email to everything-list@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/everything-list.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Everything List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to everything-list+unsubscr...@googlegroups.com.
> To post to this group, send email to everything-list@googlegroups.com.
> Visit this group at http://groups.google.com/group/everything-list.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
"Everything List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to everything-list+unsubscr...@googlegroups.com.
To post to this group, send email to everything-list@googlegroups.com.
Visit this group at http://groups.google.com/group/everything-list.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to