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.
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.
