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: 195 page execution trace of DDD correctly simulated by HH0
 ---Boilerplate Reply
Date: Fri, 21 Jun 2024 13:40:43 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v54dur$lkkc$7@i2pn2.org>
References: <v4vrfg$2793f$1@dont-email.me> <v50o2t$2fh98$2@dont-email.me>
 <v51dc8$2jmrd$1@dont-email.me> <v53b0s$324b4$1@dont-email.me>
 <v53tjm$35vak$1@dont-email.me> <v5415i$lkkc$1@i2pn2.org>
 <v543k2$376u3$1@dont-email.me> <v5460r$lkkc$3@i2pn2.org>
 <v54br6$38n2k$2@dont-email.me> <v54c3r$lkkc$5@i2pn2.org>
 <v54crs$38n2k$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 21 Jun 2024 17:40:44 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="709260"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v54crs$38n2k$4@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5964
Lines: 115

On 6/21/24 1:22 PM, olcott wrote:
> On 6/21/2024 12:09 PM, Richard Damon wrote:
>> On 6/21/24 1:04 PM, olcott wrote:
>>> On 6/21/2024 10:25 AM, Richard Damon wrote:
>>>> On 6/21/24 10:44 AM, olcott wrote:
>>>>> On 6/21/2024 9:02 AM, Richard Damon wrote:
>>>>>> On 6/21/24 9:01 AM, olcott wrote:
>>>>>>> On 6/21/2024 2:44 AM, Fred. Zwarts wrote:
>>>>>>>> Op 20.jun.2024 om 16:12 schreef olcott:
>>>>>>>>> On 6/20/2024 3:09 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 20.jun.2024 om 02:00 schreef olcott:
>>>>>>>>>>> This shows all of the steps of HH0 simulating DDD
>>>>>>>>>>> calling a simulated HH0 simulating DDD
>>>>>>>>>>>
>>>>>>>>>>> https://liarparadox.org/HH0_(DDD)_Full_Trace.pdf
>>>>>>>>>>> *Some of the key instructions are color coded*
>>>>>>>>>>> GREEN---DebugStep Address
>>>>>>>>>>> RED-----HH Address
>>>>>>>>>>> YELLOW--All of the DDD instructions
>>>>>>>>>>> CYAN----Return from DebugStep to Decide_Halting_HH
>>>>>>>>>>>
>>>>>>>>>>> _DDD()
>>>>>>>>>>> [000020a2] 55         push ebp      ; housekeeping
>>>>>>>>>>> [000020a3] 8bec       mov ebp,esp   ; housekeeping
>>>>>>>>>>> [000020a5] 68a2200000 push 000020a2 ; push DDD
>>>>>>>>>>> [000020aa] e8f3f9ffff call 00001aa2 ; call H0
>>>>>>>>>>> [000020af] 83c404     add esp,+04   ; housekeeping
>>>>>>>>>>> [000020b2] 5d         pop ebp       ; housekeeping
>>>>>>>>>>> [000020b3] c3         ret           ; never gets here
>>>>>>>>>>> Size in bytes:(0018) [000020b3]
>>>>>>>>>>>
>>>>>>>>>>> Exactly which step of DDD emulated by H0 was emulated
>>>>>>>>>>> incorrectly such that this emulation would be complete?
>>>>>>>>>>> AKA DDD emulated by H0 reaches machine address [000020b3]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If the simulation of a program with a loop of 5 iterations is 
>>>>>>>>>> aborted after 3 iterations, all instructions are correctly 
>>>>>>>>>> simulated. Nevertheless, it is an incorrect simulation, 
>>>>>>>>>> because it should simulate up to the final state of the program.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be helpful if you answer the actual question being asked
>>>>>>>>> right here and thus not answer some other question that was asked
>>>>>>>>> somewhere else.
>>>>>>>>
>>>>>>>> If you do not understand that I answered the question why the 
>>>>>>>> simulation is incorrect, it is hopeless. The question which 
>>>>>>>> instruction is incorrect is not the right question.
>>>>>>>>
>>>>>>>
>>>>>>> If you say that something is incorrect and can't be specific
>>>>>>> then your rebuttal is pure bluster with no actual basis.
>>>>>>>
>>>>>>> You need to show every single freaking step of exactly
>>>>>>> DDD correctly emulated by HH0 reaches past its own
>>>>>>> machine address [0000209b] or all you have is BULLSHIT!
>>>>>>>
>>>>>>
>>>>>> Which proves your duplicity, since no one is claiming that.
>>>>>>
>>>>>
>>>>> If you claim that I have made a mistake and cannot point
>>>>> to the exact details of this mistake then everyone will
>>>>> know that you are lying about there being any actual mistake.
>>>>
>>>> Sure
>>>>
>>>> First, NO ONE has said that *H* (or what every you are calling your 
>>>> decider today) can correct simulate the input to a final state.
>>>>
>>>
>>> Then you understand that H(D,D) is not even being
>>> asked the question: Does D(D) halt?
>>>
>>
>> Of course it is, at least if it is claimed to be a Halt Decider.
>>
> 
> When there is no mapping from the finite string x86 machine
> language input to H(D,D) to the  behavior of D(D) then
> H(D,D) IS NOT being asked about the behavior of D(D).

But there *IS* a mapping, it just isn't a COMPUTABLE MAPPING.

> 
> *That this is simply over-your-head does not make me wrong*

No, the fact that this is above YOUR Head makes YOU WRONG.

> 
> Not even being asked about the behavior of D(D) is
> not the same situation as:
> 
> the logical impossibility of specifying a halt decider H
> that correctly reports the halt status of input D that is
> defined to do the opposite of whatever value that H reports.
> Of course this is impossible.

You are just quoting from the proof that shows that the question is 
about an uncomputable mapping.

Nothing wrong with that, except you tiny brain can't process it.

> 
> 
>> Nothing says that the decider has to actually be ABLE to answer the 
>> question, only that the answer exists. Uncomputable problems just 
>> can't be solved with a computation.
>>
>> You just refuse to accept the only definition of that which is valid, 
>> because you logic can't handle it (and thus is wrong for the field).
>