Path: ...!news.snarked.org!news.nk.ca!rocksolid2!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: Sun, 5 May 2024 18:44:50 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v19252$5asr$14@i2pn2.org>
References: <v18e32$1vbql$1@dont-email.me> <v18f9e$5asq$4@i2pn2.org>
 <v18lj3$20ukn$1@dont-email.me> <v18sq6$5asr$9@i2pn2.org>
 <v18vni$23glj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 5 May 2024 22:44:51 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="175003"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v18vni$23glj$1@dont-email.me>
Content-Language: en-US
Bytes: 8886
Lines: 205

On 5/5/24 6:03 PM, olcott wrote:
> On 5/5/2024 4:13 PM, Richard Damon wrote:
>> On 5/5/24 3:10 PM, olcott wrote:
>>> On 5/5/2024 12:22 PM, Richard Damon wrote:
>>>> On 5/5/24 1:02 PM, olcott wrote:
>>>>> The x86utm operating system: https://github.com/plolcott/x86utm 
>>>>> enables
>>>>> one C function to execute another C function in debug step mode.
>>>>> Simulating Termination analyzer H simulates the x86 machine code of 
>>>>> its
>>>>> input (using libx86emu) in debug step mode until it correctly 
>>>>> matches a
>>>>> correct non-halting behavior pattern proving that its input will never
>>>>> stop running unless aborted.
>>>>
>>>> Except that the pattern it uses is incorrect, since H(D,D) using 
>>>> this "pattern" says that D(D) will not halt, where, when main calls 
>>>> D(D), it does return/halt, so H is just incorrect.
>>>>
>>>>
>>>>>
>>>>> Can D correctly simulated by H terminate normally?
>>>>> 00 int H(ptr x, ptr x)  // ptr is pointer to int function
>>>>> 01 int D(ptr x)
>>>>> 02 {
>>>>> 03   int Halt_Status = H(x, x);
>>>>> 04   if (Halt_Status)
>>>>> 05     HERE: goto HERE;
>>>>> 06   return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11   H(D,D);
>>>>> 12 }
>>>>>
>>>>> *Execution Trace*
>>>>> Line 11: main() invokes H(D,D);
>>>>>
>>>>> *keeps repeating* (unless aborted)
>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>
>>>>> *Simulation invariant*
>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>
>>>> Nope, PROVEN WRONG AND THE PROOF IGNORED, PO have even claimed that 
>>>> it would be trivial to show the error in the proof, but hasn't done 
>>>> it, showing that he doesn't actually have an answer to the 
>>>> refutation, and thus by just repeating a statment that is know to at 
>>>> least potentially have a problem as if it was just clearly true is 
>>>> just a pathological lie.
>>>>
>>>>>
>>>>> The above execution trace proves that (for every H/D pair of the
>>>>> infinite set of H/D pairs) each D(D) simulated by the H that this D(D)
>>>>> calls cannot possibly reach past its own line 03.
>>>>
>>>> Except that the proof shows that you are not smart enough to think 
>>>> of some of the ways arround the problem (even though those methods 
>>>> were discussed a long time back)
>>>>
>>>
>>> The above execution trace proves the behavior of each D simulated by
>>> each H of the elements of the infinite set of H/D pairs where this D
>>> calls that H.
>>
>> Nope, your problem is you stop simulating at the call to H and then 
>> resort to incorrect logic to try to figure out what happens next.
>>
> 
> I have to usually tell you the exactly same thing several
> hundreds of times before you notice that I ever said it once.
> 
> We are talking about the infinite set of H/D pairs where
> D is simulated by the same H that D calls.
> 
> We are talking about the infinite set of H/D pairs where
> D is simulated by the same H that D calls.
> 
> We are talking about the infinite set of H/D pairs where
> D is simulated by the same H that D calls.
> 
> H that simulates the D that calls H(D,D) will simulate to
> 1 ∞ steps of D.

Nope, when your H simulates the call to H(D,D) inside D, your H does NOT 
simulated that H, but instead simultes the machine that that machine 
would be simulating.

The simulation of the D(D) that H(D,D) would be simulating is DIFFERENT 
than simulating H simulting D(D), so your H is not doing what it claims 
to be doing.

There ARE conditions underwhich those two simulation can have a 
correspondence made, but do not, and can not, establish that for this 
case, you just incorrectly assume it, since you just don't understand 
what simulation actually means.

I have still proven, and you haven't even attempted to refute, your 
claim that no H can simulated D beyond the call to H. This makes your 
claims just disproven lies and the repeating of them evidence of you 
being a pathological liar that doesn't know the meaning of truth.


> 
> When H stops simulating D then the simulated H that D calls
> also immediately stops because the executed H(D,D) that was
> simulating D(D) was also simulating the H(D,D) that D(D)
> calls as a part of its simulation of D(D).
> 
> 

When H stops simulating D, then the SIMULATION of H that calls D stops.

The actual machine that is being simulated does not, as there is nothing 
to stop it.

You just don't understand the fundamental nature of a Turing Machine.

The thing is, the "State Transition Table/Tape operation" listing of a 
Turing Machine is NOT a piece of "SOFTWARE", but is the Hardware 
Description Language of the special purpose machine that is that Turing 
Machine. The input tape is the "Programming".

Note, that "Hardware" needs nothing supplied to it to run, except for 
the input tape, so it can't be halted once started.

This makes the UTM, just a different, "Hardware" implementation that 
takes a description of any other Turing Machine, and simulates it, 
giving the exact same results as if we built that specialized 
"hardware". Thus one set of "hardware" can do all problems, and turns 
the Hardware Description Language of the sepecialized machine into 
something now more like a "software" program (as it is given on the 
input, not the hardware design of the machine).

So, All these "Machines" being given as input, have full behavior 
defined by the instruction built into them, and are NOT dependent on the 
actual simulation done by H, so its "aborting" its simulation does NOT 
affect the behavior that H is being asked to decide on, it just makes 
the rest of the behavior beyond H's visibility.

> 
> 
> 
> 
>> You are just stuck in the wrong ideas about H.
>>
>>>
>>> If you are claiming that you have some top secret proof that shows
>>> the above execution trace is incorrect I am taking this as the empty
>>> claims of evidence of election fraud that no one has ever seen.
>>>
>>
>> But not "Top Secret" as openly published here, and it was using ideas 
>> that have been discussed here in the past.
>>
>>
>>
>>> *I will perpetually hound you for this evidence*
>>> *I will perpetually hound you for this evidence*
>>> *I will perpetually hound you for this evidence*
>>
>> By LYING that it was not presented.
>>
>>
>>>
>>> This same method worked on an election denier, they deleted all
>>> of their claims of election fraud and left.
>>
>> So, are you willing to put up or shut up?
>>
>> If I can show you how to write a valid C program H that can correctly 
>> simulates this D above (that calls my H), will you abandon your 
>> repeated claims that you can do this?
>>
>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========