XPost: comp.theory, sci.logic, sci.math
On 3/16/2022 10:02 PM, Richard Damon wrote:
On 3/16/22 10:04 PM, olcott wrote:
On 3/16/2022 8:54 PM, Richard Damon wrote:
On 3/16/22 9:16 PM, olcott wrote:
On 3/16/2022 8:08 PM, Richard Damon wrote:
On 3/16/22 8:51 PM, olcott wrote:
On 3/16/2022 7:47 PM, Richard Damon wrote:
On 3/16/22 7:32 PM, olcott wrote:
On 3/16/2022 6:22 PM, Richard Damon wrote:
On 3/16/22 6:56 PM, olcott wrote:
On 3/16/2022 5:41 PM, Richard Damon wrote:
On 3/16/22 3:10 PM, olcott wrote:
On 3/16/2022 12:37 PM, Mike Terry wrote:
On 16/03/2022 17:20, olcott wrote:
On 3/16/2022 12:04 PM, Mike Terry wrote:
On 16/03/2022 14:15, olcott wrote:
On 3/16/2022 2:21 AM, Jeff Barnett wrote:
On 3/15/2022 4:02 PM, olcott wrote:
On 3/15/2022 4:48 PM, Jeff Barnett wrote: >>>>>>>>>>>>>>>>>>> On 3/15/2022 1:44 PM, olcott wrote:
On 3/15/2022 1:58 PM, Jeff Barnett wrote: >>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:11 AM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 3/15/2022 10:44 AM, Malcolm McLean wrote: >>>>>>>>>>>>>>>>>>>>>
<MAJOR SNIP>
So how would you describe a compiler which is >>>>>>>>>>>>>>>>>>>>>>> "bootstrapped", i.e. fed its own >>>>>>>>>>>>>>>>>>>>>>> source code?
A compiler that is fed its own source-code is not >>>>>>>>>>>>>>>>>>>>>> the same because the compiler does not execute >>>>>>>>>>>>>>>>>>>>>> this source-code.
This is one of your best Peter. Along the way >>>>>>>>>>>>>>>>>>>>> you've had 100s of messages that have said that >>>>>>>>>>>>>>>>>>>>> simulation as a basis for a Halting Problem >>>>>>>>>>>>>>>>>>>>> solution is hopeless. Of course you pay no >>>>>>>>>>>>>>>>>>>>> attention because it's unlikely you understood what >>>>>>>>>>>>>>>>>>>>> you were being told. So here you are looping back >>>>>>>>>>>>>>>>>>>>> over years of the same bone headed approach. >>>>>>>>>>>>>>>>>>>>>
Let's start with a few basics:
Nothing executes source code; even an interpreter >>>>>>>>>>>>>>>>>>>>> ingests it first.
A compiler the compiles its own source-code is >>>>>>>>>>>>>>>>>>>> nothing at all like executing this source code. >>>>>>>>>>>>>>>>>>>
You really do have rocks in your head. Think for at >>>>>>>>>>>>>>>>>>> least 2 seconds before responding and getting it all >>>>>>>>>>>>>>>>>>> wrong. The mistakes you are making with the above >>>>>>>>>>>>>>>>>>> statement are so basic that I hardly know where to >>>>>>>>>>>>>>>>>>> start. As I've been told many times it's harder to >>>>>>>>>>>>>>>>>>> teach Kindergarten than grad students. And in this >>>>>>>>>>>>>>>>>>> instance, with you, we have a sixty year old crawling >>>>>>>>>>>>>>>>>>> around in diapers.
An interpreter that interprets source code can be >>>>>>>>>>>>>>>>>>>> reasonably construed as running this source code. >>>>>>>>>>>>>>>>>>>
Perhaps. The issue is it really doesn't know that it >>>>>>>>>>>>>>>>>>> is it's own source code, does it? And, in fact, >>>>>>>>>>>>>>>>>>> neither it nor any observer is aware of any vicious >>>>>>>>>>>>>>>>>>> self reference. Only a dunce would worry about it. >>>>>>>>>>>>>>>>>>> You do worry don't you?
In other words you are saying that no one is bright >>>>>>>>>>>>>>>>>> enough to be able to detect what is essentially >>>>>>>>>>>>>>>>>> infinite recursion.
You soiled your diapers again. I said nothing of the >>>>>>>>>>>>>>>>> sort. I will say it now though, nobody is intelligent >>>>>>>>>>>>>>>>> enough to systematically (by algorithm) spot infinite >>>>>>>>>>>>>>>>> recursion. God can't do it either. It's not
theoretically possible. Only an ignorant nitwit would >>>>>>>>>>>>>>>>> not know that and prattle on for years about it. >>>>>>>>>>>>>>>>>
I already have a group of many experts that concur that >>>>>>>>>>>>>>>> infinite recursion can be detected and the criterion >>>>>>>>>>>>>>>> measure by which it is correctly detected.
I'm afraid that you lack the intellect to understand >>>>>>>>>>>>>>> exactly what other people are saying on technical issues. >>>>>>>>>>>>>>> How many times have you quoted me (and others here) as >>>>>>>>>>>>>>> supporting something you've claimed, whereas it turns out >>>>>>>>>>>>>>> you had just misunderstood some remark that had been >>>>>>>>>>>>>>> made? [Answer: lots of times!]
You also have a habit of going elsewhere, and "tricking" >>>>>>>>>>>>>>> the people there into "agreeing" with some claim you've >>>>>>>>>>>>>>> made here by not properly explaining the full context of >>>>>>>>>>>>>>> your claim. Then you come back here selectively quoting >>>>>>>>>>>>>>> some "expert" to suggest he is supporting you. [Like when >>>>>>>>>>>>>>> you went to the x86 group and showed them your "trace" >>>>>>>>>>>>>>> asking them if they could see what's going on, and got >>>>>>>>>>>>>>> one of them to say "it's looping...". You failed to >>>>>>>>>>>>>>> mention the trace was not the "processor trace" they >>>>>>>>>>>>>>> would naturally expect, and that there was simulation >>>>>>>>>>>>>>> involved, and that your trace was in fact some kind of >>>>>>>>>>>>>>> "merged simulation trace", and that you were using this >>>>>>>>>>>>>>> trace to disprove the Halting Problem theorem.]
It's been pointed out to you many times that algorithms >>>>>>>>>>>>>>> exhist that can identify /some/ infinite loops/recursions >>>>>>>>>>>>>>> as such, but no algorithm detects ALL non-halting behaviour. >>>>>>>>>>>>>>>
And specifically, your test (looking for more than one >>>>>>>>>>>>>>> call to a particular address etc.) is /unsound/ when you >>>>>>>>>>>>>>> try to use it on your "merged simulation" trace. No >>>>>>>>>>>>>>> expert would say otherwise if they had been given the >>>>>>>>>>>>>>> full context, so probably you've just tricked someone >>>>>>>>>>>>>>> again...
Mike.
None-the-less is is self-evident that the input presented >>>>>>>>>>>>>> to the copy of the Linz H embedded at Ĥ.qx does specify >>>>>>>>>>>>>> infinitely nested simulation to simulating halt decider >>>>>>>>>>>>>> embedded_H thus proving that a transition to Ĥ.qn by >>>>>>>>>>>>>> embedded_H would be correct.
You mean self-evident TO YOU. To people who have an >>>>>>>>>>>>> understanding of TMs it is simply wrong or meaningless >>>>>>>>>>>>> (depending on how tolerant people are of your wishy-washy >>>>>>>>>>>>> phrasing).
Mike.
They simply dogmatically state that the believe that I am >>>>>>>>>>>> wrong about this yet cannot point to the specific error >>>>>>>>>>>> because there is none:
When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates
⟨Ĥ1⟩ ⟨Ĥ2⟩
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H >>>>>>>>>>>> simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H >>>>>>>>>>>> simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H >>>>>>>>>>>> simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
The above repeating pattern shows that the correctly
simulated input to embedded_H would never reach its final >>>>>>>>>>>> state of ⟨Ĥ⟩.qn conclusively proving that this simulated >>>>>>>>>>>> input never halts. This enables embedded_H to abort its >>>>>>>>>>>> simulation and correctly transition to Ĥ.qn.
The error has been pointed out to you many times, but you >>>>>>>>>>> seem either too dumb or too dishonest to see/admit the error. >>>>>>>>>>>
You cannot show that the simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
can possibly ever reach its own final state ⟨Ĥ⟩.qn in any >>>>>>>>>> finite number of simulated steps YOU FREAKING BRAIN DEAD MORON! >>>>>>>>>>
Ĥ.qn is not the final state of any simulated input:
YOU FREAKING BRAIN DEAD MORON!
Ĥ.qn is only the final state of the simulating halt decider >>>>>>>>>> YOU FREAKING BRAIN DEAD MORON!
But I CAN and HAVE proven that the CORRECT simulation of <H^> >>>>>>>>> <H^> by an ACTUAL UTM does reach that state.
Not at all because you are a BRAIN DEAD MORON you are simply TOO >>>>>>>> DAMNED STUPID to know the difference between when the simulated >>>>>>>> input reaches the final state of this simulated input and when >>>>>>>> the directly executed halt decider reaches its own final state. >>>>>>>>
If the simulation doesn't match the actual exectution, then it
isn't a correct simulation.
It is a verifiable fact that the pure simulation of the input to
embedded_H would never halt in any finite number of steps of
simulation.
Quit being a "Putin says he is rescuing Ukraine" liar.
Another Fallicy, you like them don't you. Doesn't help your
arguement one bit, and just shows you have nothing to stand on.
It is only 'verifiable' that the pure simulation does this if H is
JUST a pure simulator and never aborts.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Whether embedded_H aborts its simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ or not the >>>> simulated input cannot reach its own final state of ⟨Ĥ⟩.qn.
The simulated input has a final state: ⟨Ĥ⟩.qn and the halt decider >>>> has an entirely different final state: Ĥ.qn these are not the same.
Already disproven and you are just showing you are ignorant of how
Turing Machines work,
Because, in FACT, unless you are LYING about building H^ correctly,
the final state of H^, H^.Qn IS the exact same state as the H.Qn
So you are saying that embedded_H is simulating its actual self and is
never ever being directly executed?
It is not the exact one-and-the-same state. It is a copy of an
equivalent state in an entirely different process.
There is an actual 'self' of embedded_H that is embedded in the H^
machine, and this sub-machine is given the input <H^> <H^> to decide on,
by simulating if that is its pleasure.
So in part YES, embedded_H is simulation a representaiton of itself. (it
is a category error to say it is simulation its actual self, or even a
copy of itself).
There also MUST be a Turing Machine H, which is the origial decider that
is claimed to be correct, as an actual independent machine, and the
behavior of the embedded copy of it must behave exactly like this
independent copy or you didn't build H^ correctly.
This actual machine H has terminal state H.Qy and H.Qn (or possibly just named Qy and Qn), and when we embedded a copy of that machine H into H^,
then the states H.Qy and H.Qn become the exact equivalent states H^.Qy
and H^.Qn, and if H applied to <M> w goes to H.Qn then the embedded copy
you are calling goes to its equivalenet state to H.Qn which IS H^.Qn
Unless you are going to claim that identical copies of a Turing Machine
given exactly the same input can behave differently, they are
effectively the identical state. Unless you want to say that the 2 that
you get from 1+1 is different than the 2 you get from 5-3, you are going
to run into problems claiming they are different.
If you DO want to claim that identical copies of a Turing Machine given exactly the same input can do something different, please provide an
ACTAUL example, or STFU.
Until you do, then it is an established fact that if H <M> <M> goes to
state H.Qn, then it is a fact that the H^ that has a copy of that H in
it goes to H^.Qn and halts when applied to the input <M>, so H^ applied
to <H^> will halt if H applied to <H^> <H^> goes to H.Qn claiming that
input represents a non-halting computation, but that computation is
EXACTLY H^ applied to <H^> which we just showed halted.
This is the key part where you err.
Ĥ applied to ⟨Ĥ⟩ differs from embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
Ĥ applied to ⟨Ĥ⟩ reaches its final state only when embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ aborts its simulation.
This falls under the general principle that when-so-ever the simulation
of any input to a simulating halt decider must be aborted to prevent its infinite simulation this input is correctly rejected as non-halting.
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)