Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy
Subject: Re: H(D,D) cannot even be asked about the behavior of D(D) V3
 ---IGNORING ALL OTHER REPLIES
Date: Sat, 15 Jun 2024 19:01:36 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v4l6gg$3n5d$1@i2pn2.org>
References: <v4kf3h$3h3iu$7@dont-email.me> <v4kfoa$2218$19@i2pn2.org>
 <v4l2mr$3l6pa$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 15 Jun 2024 23:01:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="122029"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v4l2mr$3l6pa$1@dont-email.me>
Bytes: 9710
Lines: 214

On 6/15/24 5:56 PM, olcott wrote:
> On 6/15/2024 11:33 AM, Richard Damon wrote:
>> On 6/15/24 12:22 PM, olcott wrote:
>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>  > On 6/13/24 11:32 AM, olcott wrote:
>>>  >>
>>>  >> It is contingent upon you to show the exact steps of how H computes
>>>  >> the mapping from the x86 machine language finite string input to
>>>  >> H(D,D) using the finite string transformation rules specified by
>>>  >> the semantics of the x86 programming language that reaches the
>>>  >> behavior of the directly executed D(D)
>>>  >>
>>>  >
>>>  > Why? I don't claim it can.
>>>
>>> The first six steps of this mapping are when instructions
>>> at the machine address range of [00000cfc] to [00000d06]
>>> are simulated/executed.
>>>
>>> After that the behavior of D correctly simulated by H diverges
>>> from the behavior of D(D) because the call to H(D,D) by D
>>> correctly simulated by H cannot possibly return to D.
>>
>> Nope, the steps of D correctly simulated by H will EXACTLY match the 
>> steps of D directly executed, until H just gives up and guesses.
>>
> 
> When we can see that D correctly simulated by H cannot possibly
> reach its simulated final state at machine address [00000d1d]
> after one recursive simulation and the same applies for 2,3,...N
> recursive simulations then we can abort the simulated input and
> correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about Halting,

Remember, your analysis was done with the input CHANGING with H, which 
means any N used different than what your H actually uses, is INVALID 
for discussing what THIS D does.

IF you did it right, and asked what would an H that simulated farther 
THIS input, which means D calls the original H, then if that simulates 
father, it WOULD see the simulated ORIGINAL H abort and return to D and 
D halt.

But this H can't do that, so it can't see it.

So, you not only ask the wrong question, but you ask it of the wrong input.

> 
> That you call this a guess seems disingenuous at least and dishonest
> at most. it is as if you are denying mathematical induction.

But the D that Linz talks about has its own copy of H, as is needed to 
make it an actual computation, and thus doesn't change when you think 
about different machines simuating it.

> 
>> By your defintions, the ONLY correct simulation of D by H MUST follow 
>> the call H into the instructions of H, and then continue there forever 
>> until H either gives up simulating, or it happens to simulate the 
>> return from H to D (which doesn't look like it will ever happen).
>>
> 
> Yes and when I say 2 + 3 = 5 you are not free to disagree and be
> correct.

Just like you don't get to change the code of D, including the fact that 
it calls the ORIGINAL H, an d isn't a template anymore, and thatthe 
criteria *IS* does it halt when directly run, and not about "the correct 
simulation by H" which isn't even a valid criteria.

> 
>> This is the ONLY thing that matches your definition of Correct 
>> Simulation.
>>
> 
> The x86 language defines the semantics of correct simulation that
> you denigrate this to my opinion seems disingenuous at least and
> dishonest at most.

Right, which means the ONLY "correct simulation" of D simulates the call 
to H and the code in H, so the correct simulation by H is EXACTLY the 
same as the direct execution up to the point when H gives up and stops, 
so you claim that they differ is just a LIE.

> 
>> And that means that you definition of the "Input" is shown to be 
>> incorrect (or insufficient for H to do what it needs to do). The input 
>> CAN NOT be just those instructions shown below, but must include the 
>> contents of ALL the memory used by the program.
>>
> 
> It is the sequence of x86 instructions specified by the machine
> language of D that is being examined. We cannot simply ignore
> the recursive simulation effect of the call from D to H(D,D).
> That D makes this call is what make D correctly simulated by H
> fail to halt.

No, we done ignore them, we simulate through them.

Note, somehow you think thaT H only needs to simulate the instruction in 
the C function of D, but that is INCORRCT, and if you try to use that 
defintion, H must stop as soon as it gets to the call H and can not 
proceeed.

The problem here is that, to be the needed input, the input actually 
needs to include all the code that D uses, including H and everyting 
that H calls, or the input is just incorrect.

> 
>> And this comes out naturally, because to ask about the program 
>> represented by the input, the input needs to represent a FULL PROGRAM, 
>> which includes ALL of the algorithm used by the code, so ALL of the 
>> program.
>>
> 
> That D calls H in recursive simulation is what makes D correctly
> simulated by H never halt. H is merely watching what D does
> until it see that D correctly simulated by H cannot possibly halt
> on the basis of something just like mathematical induction.

Nope, That only holds if H is defined to never abort.

You are just proving you don't understand what you are talking about and 
are just being a pathological liar with a total and reckless disregard 
for the truth.

> 
> We can directly see that 1,2,3...N recursive simulations do
> not result in D correctly simulated by H reaching its simulated
> final state of [00000d1d].


Nope, and in fact it seems that EVERYT simulation that you have done 
that tries to go past those first 7 instuctions violate you definition 
of a "Correct Simulation" and thus ALL You logic is just wrong.
> 
>> Thus, the input "D", includes its copy of H that was DEFINED by Linz 
>> and Sipser to be part of the machine, and when you do your logic, you 
>> can't change that code.
>>
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (g) goto (d) with one more level of simulation
> 
> When embedded_H is a UTM we can see that Ĥ ⟨Ĥ⟩ never halts.

And if embedded_H is a UTM< then so is H, and then H fails to be a decider.

So either H / embedded_H *IS* programmed to abort it simulation at some 
point, so that H (H^) (H^) can go to qn, and thus H^ (H^) will also have 
its embedded_H abort its simulation and go to qn and thus H^ (H^) Halts, 
or H (H^) (H^) just never answers.

Both are wrong.

> 
> This by itself proves that the same thing applies when embedded_H
> is based on a UTM that stops simulating and rejects its input at
> any point after it sees

There is no sucn thing. You are effectively basing you argument on the 
puppy that *IS* a 15 story office building.

> 
> two complete simulations show a pair of identical TMD's are
> simulating a pair of identical inputs.  We can see this thus
========== REMAINDER OF ARTICLE TRUNCATED ==========