Deutsch   English   Français   Italiano  
<v19kf6$5asr$22@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Sun, 5 May 2024 23:57:26 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v19kf6$5asr$22@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>
 <v18tov$22tig$1@dont-email.me> <v18v9q$5asr$13@i2pn2.org>
 <v192q4$2436r$1@dont-email.me> <v194kl$5asq$8@i2pn2.org>
 <v19bjn$25pgk$1@dont-email.me> <v19e8g$5asq$11@i2pn2.org>
 <v19j84$2bkma$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 6 May 2024 03:57:26 -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
Content-Language: en-US
In-Reply-To: <v19j84$2bkma$3@dont-email.me>
Bytes: 10259
Lines: 235

On 5/5/24 11:36 PM, olcott wrote:
> On 5/5/2024 9:11 PM, Richard Damon wrote:
>> On 5/5/24 9:26 PM, olcott wrote:
>>> On 5/5/2024 6:27 PM, Richard Damon wrote:
>>>> On 5/5/24 6:56 PM, olcott wrote:
>>>>> On 5/5/2024 4:56 PM, Richard Damon wrote:
>>>>>> On 5/5/24 5:30 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.
>>>>>>>
>>>>>>> We are talking about the infinite set of H/D pairs where
>>>>>>> D is simulated by the same H that D calls.
>>>>>>>
>>>>>>> Elements of this set of H/D pairs simulate from 1 to infinite 
>>>>>>> steps of D and each one of them does this in an infinite number 
>>>>>>> of different ways.
>>>>>>
>>>>>> (this is wrong, as EACH H only simulates its one D one way, so 
>>>>>> each one doesn't simulate in an infinite number of ways, but I 
>>>>>> think you are just failing at grammer here
>>>>>>
>>>>>>>
>>>>>>> There are an infinite number of different ways for H to simulate
>>>>>>> 1 step of D.
>>>>>>
>>>>>> So?
>>>>>>
>>>>>
>>>>> *Your system clock is off you responded to my 5:30 post at 4:56*
>>>>
>>>> No, you don't seem to understand about TIME ZONES.
>>>>
>>>> I guess that is too advanced for you.
>>>>
>>>
>>> USENET posts are in universal time and only translated
>>> in the news reader. That your replies are coming in
>>> before some of my later posts indicates an issue
>>> on your end.
>>
>> What makes you think that time stamps are in Universal Time.
>>
>> Your posts date stamp for this message is:
>> Sun, 5 May 2024 20:26:15 -0500
>>
>> Indicating it was sent at 8:26:15 PM by your local clock which is 5 
>> hours behind GMT.
>>
>> My news reader, when I replied, converted that time to MY local time 
>> zone, which is -0400
>>
>> As to order changing, it isn't unusual for messages posted from 
>> different servers to get to places with differing speeds.
>>
>> I am not sure how you think MY postes going FAST is an issue. If my 
>> posts are passing your posts, then it must be your posts are SLOW
>>
>> Unless you think someone on usenet has developed a time traveling 
>> gateway.
>>
>> Or, do you think that I have some special connections where I can get 
>> your posts before you make them.
>>
> 
> I check new posts on the basis of those that come up
> last in time/stamp order. Your new posts are coming
> up before several of my own posts that came after.

Then your "timestamp" processing is wrong.

As I posted, all the time stamps in the messages were correct and in the 
proper order when converted to GMT.

Note, if you are ignoring the time zone info because you think all time 
stamps are in GMT, you WILL get it wrong since my timezone is diffferent 
than yours.

That or you are using a News server that is mangling things, but since 
you seem to be using ES, that is wouldn't be the case.

My ES feed is looking right.

> 
>>>
>>>>>
>>>>>> The TWO methods I posted still follow that description and show 
>>>>>> how H can simulate past the point that you say NO H can get past,
>>>>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========