2012/9/12 Quentin Anciaux <allco...@gmail.com>

>
>
> 2012/9/12 benjayk <benjamin.jaku...@googlemail.com>
>
>>
>>
>>
>> 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).
>
>
> So back to what I said before... your "meta" program is an oracle not
> emulable by a turing machine, not a program. It can know exactly on what it
> runs.
>
> And your "program" is not a program, it is a program + an oracle (the
> oracle is the blackbox that can know on which level the program is running).
>
> Nothing new here, and nothing that contradict computationalism.
>
> Quentin
>


And so as such, contrary to what you claim... such a program *can't* run on
actual hardware, because it is *impossible* to implement the oracle it uses.

Quentin


>
>
>> 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.
>>
>>
>
>
> --
> All those moments will be lost in time, like tears in rain.
>



-- 
All those moments will be lost in time, like tears in rain.

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