On Wed, Dec 11, 2013 at 1:57 PM, meekerdb <meeke...@verizon.net> wrote:
> On 12/11/2013 12:23 AM, Telmo Menezes wrote:
>
>> 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.
>>
>
>
> I don't disagree with any of that. But by providing a with an id prior to
> the fork and then testing after the fork you are effectively modeling a
> "soul" that is not duplicated but rather belongs to one of the copies and
> not the other; and the soul always goes to Moscow.
>
Don't let the fact that it is called a "pid" (Process ID mislead you). I
think it is better to think of it as an observation from something external
to the running program, as you need to make a "system call", that is, ask
the OS what it is. It does not come from within the program. Then the
result of this "observation" is stored in a variable (local memory
available to that program), so the analogy is quite perfect with the
duplication machine. You make an observation and store the memory, then
you clone yourself into two copies, and perform another system call to
learn your "pid" again, i.e., make a second observation. This time each
copy gets back a different result.
Jason
>
> But it is pretty much what I suggested to John; that he should consider a
> repeated sequence of teleportations and what conclusion John_n might draw.
>
> Brent
>
>
>
>> 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.
>
--
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.
