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: At least 100 people kept denying the easily verified fact ---
 last communication with Richard
Date: Fri, 7 Jun 2024 15:50:52 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3voas$39ri5$21@i2pn2.org>
References: <v3o2dj$jm9q$1@dont-email.me> <v3r914$354i9$7@i2pn2.org>
 <v3r9ds$1b96e$1@dont-email.me> <v3rb52$354ia$7@i2pn2.org>
 <v3rbaj$1bg3t$1@dont-email.me> <v3rc4m$354i9$8@i2pn2.org>
 <v3rcgn$1bpcn$1@dont-email.me> <v3rcks$354i9$9@i2pn2.org>
 <v3rd3r$1bsem$1@dont-email.me> <v3s5g6$36git$2@i2pn2.org>
 <v3sc8c$1gra7$2@dont-email.me> <v3tq33$388rj$13@i2pn2.org>
 <v3tstr$1td1o$2@dont-email.me> <v3tuqh$388ri$1@i2pn2.org>
 <v3v0qj$22vrk$1@dont-email.me> <v3v85d$39ri5$11@i2pn2.org>
 <v3vacl$242e9$8@dont-email.me> <v3vh9l$a5e$2@news.muc.de>
 <v3vhvq$25ojk$2@dont-email.me> <v3vj8p$39ri6$7@i2pn2.org>
 <v3vk9b$266aq$2@dont-email.me>
 <8c92495d4433776d8ddc4706fb1de05b245f5829.camel@gmail.com>
 <v3vn5u$26d04$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 7 Jun 2024 19:50:52 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3468869"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v3vn5u$26d04$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 9900
Lines: 217

On 6/7/24 3:31 PM, olcott wrote:
> On 6/7/2024 1:57 PM, wij wrote:
>> On Fri, 2024-06-07 at 13:41 -0500, olcott wrote:
>>> On 6/7/2024 1:24 PM, Richard Damon wrote:
>>>> On 6/7/24 2:02 PM, olcott wrote:
>>>>> On 6/7/2024 12:50 PM, Alan Mackenzie wrote:
>>>>>> [ Followup-To: set ]
>>>>>>
>>>>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>>>>
>>>>>> [ .... ]
>>>>>>
>>>>>>> _DD()
>>>>>>> [00001e12] 55         push ebp
>>>>>>> [00001e13] 8bec       mov  ebp,esp
>>>>>>> [00001e15] 51         push ecx
>>>>>>> [00001e16] 8b4508     mov  eax,[ebp+08]
>>>>>>> [00001e19] 50         push eax      ; push DD
>>>>>>> [00001e1a] 8b4d08     mov  ecx,[ebp+08]
>>>>>>> [00001e1d] 51         push ecx      ; push DD
>>>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>>
>>>>>>> A {correct simulation} means that each instruction of the
>>>>>>> above x86 machine language of DD is correctly simulated
>>>>>>> by HH and simulated in the correct order.
>>>>>>
>>>>>> That's a bit of sudden and substantial change, isn't it?  Less than a
>>>>>> few
>>>>>> days ago, you were defining a correct simulation as "1 to N
>>>>>> instructions"
>>>>>> simulated (without ever specifying what you meant by N).  It seems 
>>>>>> that
>>>>>> the simulation of exactly one instruction would have met your 
>>>>>> criterion.
>>>>>>
>>>>>> That now seems to have changed.
>>>>>>
>>>>>
>>>>> Because I am a relatively terrible writer I must constantly
>>>>> improve my words on the basis of reviews.
>>>>>
>>>>> Try to show how this DD correctly simulated by any HH ever
>>>>> stops running without having its simulation aborted by HH.
>>>>>
>>>>> _DD()
>>>>> [00001e12] 55         push ebp
>>>>> [00001e13] 8bec       mov  ebp,esp
>>>>> [00001e15] 51         push ecx
>>>>> [00001e16] 8b4508     mov  eax,[ebp+08]
>>>>> [00001e19] 50         push eax      ; push DD
>>>>> [00001e1a] 8b4d08     mov  ecx,[ebp+08]
>>>>> [00001e1d] 51         push ecx      ; push DD
>>>>> [00001e1e] e85ff5ffff call 00001382 ; call HH
>>>>>
>>>>> A {correct simulation} means that each instruction of the
>>>>> above x86 machine language of DD is correctly simulated
>>>>> by HH and simulated in the correct order.
>>>>>
>>>>> Anyone claiming that HH should report on the behavior
>>>>> of the directly executed DD(DD) is requiring a violation
>>>>> of the above definition of correct simulation.
>>>>>
>>>>
>>>> And thus you admit that HH is not a Halt Decider,
>>>
>>> More dishonest deflection.
>>> The point that I made and you try to deflect using the strawman
>>> deception as a fake rebuttal is the I just proved that DD is correctly
>>> simulated by HH and this is not the same behavior as the directly
>>> executed DD(DD).
>>>
>>
>> The Halting Problem asks for a program H (precisely a TM) that:
>> IF H(D,D)==1, THEN D(D) will return.
>> ELSE If H(D,D)==0, THEN D(D) will never return.
>> ELSE HP is undecidable
>>
>> You keep solving POOH !!! and made lots of lies.
>>
>> Surrender to my GUR, son.
>>
> 
> If people are going to be dishonest about simple things
> such as the actual behavior of actual x86 code where
> they consistently deny verified facts

But what have people disagreed about on the actual code.

DO you deny that the actual x86 code when run will halt since your 
HH(DD,DD) will return 0 to let it be a decider?

> 
> then we certainly cannot trust these people with more
> difficult issues that require at least some slight degree
> of judgment call.

But nothing should require a "judgement call".


> 
> When we can show that even in the halting problem HH
> is only required to report on the behavior of DD correctly
> simulated by HH these dishonest people merely use that
> as another deflection point for their dishonesty.

But that is just a LIE, because that isn't the quesiton of the Halting 
problem, only of your POOP.

The Halting problem SPECIFICALLY asks the question if the machine 
described by the input, that is the direct execution of DD(DD), will 
halt or not when run.

Please show your reference that it can be ANYTHING like what you are 
claiming, that is just your own pathological lie because you can not 
face realitiy.

Since you lie about that, why should anyone believe your statements 
about other things.

> 
> The way around this that just worked is to stay diligently
> focused one one single point until the dishonest people
> finally admit that they have simply ignored all the proofs
> for three solid years.
> 
> On 6/5/2024 10:58 PM, Richard Damon wrote:
>  > On 6/5/24 11:44 PM, olcott wrote:
>  >>
>  >> THIS IS ALL THAT YOU WILL EVER GET TO TALK
>  >> TO ME ABOUT UNTIL YOU ACKNOWLEDGE THAT
>  >> I AM CORRECT OR YOU PROVE THAT I AM INCORRECT
>  >
>  > But, as I said, I won't acknowledge that you
>  > are correct, because I am not willing to put
>  > that effort into your worthless claim.
>  >
> 
> Here is the earliest version of the proof (that everyone
> has simply ignored for three solid years) that P correctly
> simulated by H would never stop running unless aborted.

Which isn't a proof, but does show a possible origin for your strawman 
of why you thought you could change the question.

> 
> Halting problem undecidability and infinitely nested simulation
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> 
> The fact that the execution trace of P derived by the executed
> H and the simulated H exactly matches the machine code of P
> proves that each instruction of P was simulated correctly and
> in the correct order this conclusively proves that P is correctly
> simulated by both of these instances of H.

It shows they were simulated correct for as far as they went.

The simulation of the CALL H is just WRONG,

Either you need to show the actual x86 instructions of HH being simulated,

or the simulation needs to show the equivalent return of HH, which since 
you claim it correctly returns 0 would be that.

Any simulation that shows that HH will never return is just wrong, or is 
ending with invalid or unsound logic from a correct partial simulation 
========== REMAINDER OF ARTICLE TRUNCATED ==========