Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Every D(D) simulated by H presents non-halting behavior to H ###
Date: Mon, 27 May 2024 19:12:28 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3340s$29def$3@i2pn2.org>
References: <v18e32$1vbql$1@dont-email.me> <v2838r$29rd7$1@dont-email.me>
 <v2a8th$2ps09$1@dont-email.me> <v2ahqc$2qvr9$1@dont-email.me>
 <v2cb5s$39fvg$1@dont-email.me> <v2crk0$3cifp$1@dont-email.me>
 <v2cvuo$3dfkm$1@dont-email.me> <v2i921$jvcs$5@dont-email.me>
 <v2k7fe$12vjm$1@dont-email.me> <v2l0q8$17mu1$1@dont-email.me>
 <v2n4f7$1ms87$1@dont-email.me> <v2nfma$1or9h$4@dont-email.me>
 <v2pkqq$28mg0$1@dont-email.me> <v2qhr2$2dpfr$6@dont-email.me>
 <v2s6kk$2q0pf$1@dont-email.me> <v2skde$2s65h$1@dont-email.me>
 <v2uthd$3bjch$1@dont-email.me> <v2vdkp$3dtct$3@dont-email.me>
 <v2vned$3fl3r$1@dont-email.me> <v2vp8f$3g0m3$1@dont-email.me>
 <v31f7s$3ukf5$1@dont-email.me> <v3236b$29pd$1@dont-email.me>
 <v3249e$28n59$1@i2pn2.org> <v325v5$2pkb$4@dont-email.me>
 <v32730$28n59$3@i2pn2.org> <v329md$3mh0$1@dont-email.me>
 <v32afl$28n58$3@i2pn2.org> <v32b21$3un9$1@dont-email.me>
 <v32crg$2937i$2@i2pn2.org> <v32oa4$6fo3$2@dont-email.me>
 <v32u94$29def$1@i2pn2.org> <v332fc$84p2$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 27 May 2024 23:12:28 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2405839"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v332fc$84p2$2@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8471
Lines: 159

On 5/27/24 6:46 PM, olcott wrote:
> On 5/27/2024 4:34 PM, Richard Damon wrote:
>> On 5/27/24 3:52 PM, olcott wrote:
>>> On 5/27/2024 11:37 AM, Richard Damon wrote:
>>>> On 5/27/24 12:06 PM, olcott wrote:
>>>>> On 5/27/2024 10:56 AM, Richard Damon wrote:
>>>>>> On 5/27/24 11:43 AM, olcott wrote:
>>>>>>> On 5/27/2024 9:58 AM, Richard Damon wrote:
>>>>>>>> On 5/27/24 10:39 AM, olcott wrote:
>>>>>>>
>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>>>>> 00       int H(ptr p, ptr i);
>>>>>>> 01       int D(ptr p)
>>>>>>> 02       {
>>>>>>> 03         int Halt_Status = H(p, p);
>>>>>>> 04         if (Halt_Status)
>>>>>>> 05           HERE: goto HERE;
>>>>>>> 06         return Halt_Status;
>>>>>>> 07       }
>>>>>>> 08
>>>>>>> 09       int main()
>>>>>>> 10       {
>>>>>>> 11         H(D,D);
>>>>>>> 12         return 0;
>>>>>>> 13       }
>>>>>>>
>>>>>>> The above template refers to an infinite set of H/D pairs where D is
>>>>>>> correctly simulated by either pure simulator H or pure function 
>>>>>>> H. This
>>>>>>> was done because many reviewers used the shell game ploy to 
>>>>>>> endlessly
>>>>>>> switch which H/D pair was being referred to.
>>>>>>>
>>>>>>> Correct Simulation Defined
>>>>>>>     This is provided because many reviewers had a different 
>>>>>>> notion of
>>>>>>>     correct simulation that diverges from this notion.
>>>>>>>
>>>>>>>     A simulator is an x86 emulator that correctly emulates 1 to N 
>>>>>>> of the
>>>>>>>     x86 instructions of D in the order specified by the x86 
>>>>>>> instructions
>>>>>>>     of D. This may include M recursive emulations of H emulating 
>>>>>>> itself
>>>>>>>     emulating D.
>>>>>>
>>>>>> And how do you apply that to a TEMPLATE that doesn't define what a 
>>>>>> call H means 
>>>>>
>>>>> *It is completely defined and you are just ignoring this definition*
>>>>
>>>> So, what instruction does the call H in D go to to be simulated?
>>>>
>>>
>>> DISHONEST HEAD GAMES. WHEN WE APPLY THIS SAME REASONING TO THE
>>> LINZ TEMPLATE YOUR REASONING CALLS THE LINZ TEMPLATE NONSENSE.
>>
>> Nope, because Linz doesn't try to pass a Template to H, but the 
>> machine built from the template H^.
>>
>> As I said, if you assume the input is the machine built from the 
>> template you get the ability to define the simulation, you just now 
>> get every decider got a different input, so you can't just do the 
>> logic across them.
>>
>> YOU are the one trying to do dishonest head games
>>
>> (And who has been saying that insults are unprofessional?)
>>
>>>
>>>> As a template, there is no fixed H, so no instruction to look at.
>>>>
>>>>> H correctly simulates 1 to ∞ steps of D with either pure function H
>>>>> or pure simulator H. In none of these cases does the correctly 
>>>>> simulated
>>>>> D ever reach its own simulated final state and halt.
>>>>>
>>>>> Do some of these instances of H play a game of poker with themselves
>>>>> before or after they simulate D? Yes they do because the H/D pairs
>>>>> are an infinite set.
>>>>>
>>>>
>>>> But, how do they correctly simulate something that isn't there?
>>>>
>>>> Either they are simulating an INSTANCE of the template, in which 
>>>> case each H is looking at a DIFFERENT instance, and you can't relate 
>>>> one result to the other, or they are trying to simulate the 
>>>> Template, at which point you have the problem that the code to be 
>>>> simulated hasn't been defined, and thus you can't do what you define 
>>>> to do.
>>>
>>> I AM REFERRING TO THE EXACT SAME SORT OF INFINITE SET
>>> THAT THE LINZ TEMPLATE IS REFERRING TO AND YOU KNOW IT.
>>
>> Nope, Linz choose A SPECIFIC H out of the set, and gives it a SPECIFIC 
>> H^ built from that SPECIFIC H, and then works with that set. There is 
> 
> When you say "specific machine" you don't mean anything like a
> 100% completely specified sequence of state transitions encoded
> as a single unique finite string.

Mostly.

There doesn't need to be a unique finite string, but it is a 100% 
completely specified state transition/tape operation table.

Note, the sequences of states it goes through, will be a function of the 
input given to that machine.

No no-trival Turing machine has a unique finite string encoding because 
you can always re"name" the non-initial/non-final states generating a 
vast array of possible encodings (generally an infinite number of them)

Does that surprise you? It shouldn't

Note, that specific Turing machine H^ needs to be built from the 
specific Turing Machine H that it is being built to refute as being correct.

The key is we can show that for ANY machine that might claim to be a 
correct halt decider, the proof establishes a formula to construct a 
specific input you can give that specific machine to show that it isn't 
correct.

> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> Linz claims that out of the infinite possible implementations of
> embedded_H specified by the second ⊢* that none of them get the
> right answer.

Right, and he does it by categorical exhaustive logic.

> 
> I would be pretty dumb if Linz took this the way the you are taking it: 
> "there exists a specific implementation of embedded_H that gets the 
> wrong answer."
> 

Nope, I guess you don't understand how to do a categorical proof.

If you take an specific, but arbitrary, member of the set, and show that 
it is wrong. Then, since the choice was arbitrary, you can point out 
that the exact same proof could be done to any other member of the set, 
thus NO member of the set can be right.

The point is that when you are dealing with a specific machine, and the 
specific input you are giving that machine, you have at hand a large set 
of tools that let you talk about that machine,

If you try to work with all of them at once, it is much harder to get 
things right, as you need to keep all the relationships between the 
elements in order.

The key point is that most of the Theory provides details about the 
behaivior of *A* machine, not sets of machines. After all, when you run 
a machine, you run a specific machine and get a specific answer from 
that machine, so to handle a set you need to look at each of them 
individually anyway.