Quentin Anciaux-2 wrote:
> 
> 2012/9/12 Quentin Anciaux <allco...@gmail.com>
> 
>>
>>
>> 2012/9/12 benjayk <benjamin.jaku...@googlemail.com>
>>
>>>
>>>
>>> Quentin Anciaux-2 wrote:
>>> >
>>> > 2012/9/11 Quentin Anciaux <allco...@gmail.com>
>>> >
>>> >>
>>> >>
>>> >> 2012/9/11 benjayk <benjamin.jaku...@googlemail.com>
>>> >>
>>> >>>
>>> >>>
>>> >>> Quentin Anciaux-2 wrote:
>>> >>> >
>>> >>> > 2012/9/11 benjayk <benjamin.jaku...@googlemail.com>
>>> >>> >
>>> >>> >>
>>> >>> >>
>>> >>> >> Quentin Anciaux-2 wrote:
>>> >>> >> >
>>> >>> >> > 2012/9/11 benjayk <benjamin.jaku...@googlemail.com>
>>> >>> >> >
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> Quentin Anciaux-2 wrote:
>>> >>> >> >> >
>>> >>> >> >> > 2012/9/10 benjayk <benjamin.jaku...@googlemail.com>
>>> >>> >> >> >
>>> >>> >> >> >>
>>> >>> >> >> >>
>>> >>> >> >> >> > > No program can determine its hardware.  This is a
>>> >>> consequence
>>> >>> >> of
>>> >>> >> >> the
>>> >>> >> >> >> > > Church
>>> >>> >> >> >> > > Turing thesis.  The particular machine at the lowest
>>> level
>>> >>> has
>>> >>> >> no
>>> >>> >> >> >> > bearing
>>> >>> >> >> >> > > (from the program's perspective).
>>> >>> >> >> >> > If that is true, we can show that CT must be false,
>>> because
>>> >>> we
>>> >>> >> *can*
>>> >>> >> >> >> > define
>>> >>> >> >> >> > a "meta-program" that has access to (part of) its own
>>> >>> hardware
>>> >>> >> >> (which
>>> >>> >> >> >> > still
>>> >>> >> >> >> > is intuitively computable - we can even implement it on a
>>> >>> >> computer).
>>> >>> >> >> >> >
>>> >>> >> >> >>
>>> >>> >> >> >> It's false, the program *can't* know that the hardware it
>>> has
>>> >>> >> access
>>> >>> >> >> to
>>> >>> >> >> >> is
>>> >>> >> >> >> the *real* hardware and not a simulated hardware. The
>>> program
>>> >>> has
>>> >>> >> only
>>> >>> >> >> >> access to hardware through IO, and it can't tell (as never
>>> >>> ever)
>>> >>> >> from
>>> >>> >> >> >> that
>>> >>> >> >> >> interface if what's outside is the *real* outside or
>>> simulated
>>> >>> >> >> outside.
>>> >>> >> >> >> <\quote>
>>> >>> >> >> >> Yes that is true. If anything it is true because the
>>> hardware
>>> >>> is
>>> >>> >> not
>>> >>> >> >> even
>>> >>> >> >> >> clearly determined at the base level (quantum uncertainty).
>>> >>> >> >> >> I should have expressed myself more accurately and written
>>> "
>>> >>> >> >> "hardware"
>>> >>> >> >> "
>>> >>> >> >> >> or
>>> >>> >> >> >> "relative 'hardware'". We can define a (meta-)programs that
>>> >>> have
>>> >>> >> >> access
>>> >>> >> >> >> to
>>> >>> >> >> >> their "hardware" in the sense of knowing what they are
>>> running
>>> >>> on
>>> >>> >> >> >> relative
>>> >>> >> >> >> to some notion of "hardware". They cannot be emulated using
>>> >>> >> universal
>>> >>> >> >> >> turing
>>> >>> >> >> >> machines
>>> >>> >> >> >
>>> >>> >> >> >
>>> >>> >> >> > Then it's not a program if it can't run on a universal
>>> turing
>>> >>> >> machine.
>>> >>> >> >> >
>>> >>> >> >> The funny thing is, it *can* run on a universal turing
>>> machine.
>>> >>> Just
>>> >>> >> that
>>> >>> >> >> it
>>> >>> >> >> may lose relative correctness if we do that.
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > Then you must be wrong... I don't understand your point. If
>>> it's
>>> a
>>> >>> >> program
>>> >>> >> > it has access to the "outside" through IO, hence it is
>>> impossible
>>> >>> for a
>>> >>> >> > program to differentiate "real" outside from simulated
>>> outside...
>>> >>> It's
>>> >>> >> a
>>> >>> >> > simple fact, so either you're wrong or what you're describing
>>> is
>>> >>> not
>>> >>> a
>>> >>> >> > program, not an algorithm and not a computation.
>>> >>> >> OK, it depends on what you mean by "program". If you presume that
>>> a
>>> >>> >> program
>>> >>> >> can't access its "hardware",
>>> >>> >
>>> >>> >
>>> >>> > I *do not presume it*... it's a *fact*.
>>> >>> >
>>> >>> >
>>> >>> Well, I presented a model of a program that can do that (on some
>>> level,
>>> >>> not
>>> >>> on the level of physical hardware), and is a program in the most
>>> >>> fundamental
>>> >>> way (doing step-by-step execution of instructions).
>>> >>> All you need is a program hierarchy where some programs have access
>>> to
>>> >>> programs that are below them in the hierarchy (which are the
>>> "hardware"
>>> >>> though not the *hardware*).
>>> >>>
>>> >>
>>> >> What's your point ? How the simulated hardware would fail ? It's
>>> >> impossible, so until you're clearer (your point is totally fuzzy), I
>>> >> stick
>>> >> to "you must be wrong".
>>> >>
>>> >
>>> > So either you assume some kind of "oracle" device, in this case, the
>>> thing
>>> > you describe is no more a program, but a program + an oracle, the
>>> oracle
>>> > obviously is not simulable on a turing machine, or an infinite regress
>>> of
>>> > level.
>>> >
>>> >
>>> The simulated hardware can't fail in the model, just like a turing
>>> machine
>>> can't fail. Of course in reality it can fail, that is beside the point.
>>>
>>> You are right, my explanation is not that clear, because it is a quite
>>> subtle thing.
>>>
>>> Maybe I shouldn't have used the word "hardware". The point is just that
>>> we
>>> can define (meta-)programs that have access to some aspect of programs
>>> that
>>> are below it on the program hierarchy (normal programs), that can't be
>>> accessed by the program themselves. They can't emulated in general,
>>> because
>>> sometimes the emulating program will necessarily emulate the wrong level
>>> (because it can't correctly emulate that the meta-program is accessing
>>> what
>>> it is *actually* doing on the most fundamental level).
>>> They still are programs in the most fundamental sense.
>>>
>>> They don't require oracles or something else that is hard to actually
>>> use,
>>> they just have to know something about the hierarchy and the programs
>>> involved (which programs or kind of programs are above or below it) and
>>> have
>>> access to the states of other programs. Both are perfectly implementable
>>> on
>>> a normal computer. They can even be implemented on a turing machine, but
>>> not
>>> in general. They can also be simulated on turing machines, just not
>>> necessarily correctly (the turing machine may incorrectly ignore which
>>> level
>>> it is operating on relative to the meta-program).
>>>
>>
>> I still don't see why, what you describe is wishful thinking, or you're
>> wrong, or you can't explain correctly, what I understand from what you
>> write, is that you are wrong.
>>
>>>
>>> We can still argue that these aren't programs in every sense but I think
>>> what is executable on a normal computer can be rightfully called
>>> program.
>>>
>>
>> Then if it's executable, then the simulated thing can't be different
>> (give
>> different results) than the non simulated one, so it's clear you don't
>> understand what is a computer and what is a program.
>>
>>
> And I can show that you're wrong:
> 
> - You say you can write a program on an actual computer that can know it
> is
> running on "real" hardware such that I could not create a virtual
> machine/interpreter running that program, with the program giving the same
> result.
> 
That's not what I am saying. I am saying that if it gave the same results,
it may not be correct anymore relative to the levels we defined the
meta-level on, because the result would have to change based on what this
virtual machine is doing (because the meta-program it is supposed to be
emulating accesses the hardware of that virtual machine). Note "may", it
depends on the specific definitions of levels.

Also, I am not saying that we cannot emulate that program at all, just not
with a turing machine. That is because we can write a meta-program that
knows what a turing machine is and knows if one attempts to emulate it and
subsequently accesess its states to reflect on what it's doing (thus making
the emulation incorrect because it emulates the wrong level). This is not
necessarily precisely possible in real life, because here no turing machines
exists and there is no clear lowest level. But there being no real
meta-programs is no more a problem than no real turing machines existing.
The point is that we can easily define a meta-program that accesses the
programs that attempt to emulate it, because in theory it is definable which
the lowest level is (simply the level we formulate the computation on).
That's all that is required to make the point from a computer science view.
You may still say that this is not a program anymore, but I believe that it
fits very well into our intuitive notion of "program".

I would like to see a definition of a program that excludes what I am
talking about. Do you have one?

benjayk
-- 
View this message in context: 
http://old.nabble.com/Why-the-Church-Turing-thesis--tp34348236p34424939.html
Sent from the Everything List mailing list archive at Nabble.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Everything List" group.
To post to this group, send email to everything-list@googlegroups.com.
To unsubscribe from this group, send email to 
everything-list+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/everything-list?hl=en.

Reply via email to