Deutsch   English   Français   Italiano  
<v56k4h$onl4$4@i2pn2.org>

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

Path: ...!news.misty.com!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: Sat, 22 Jun 2024 09:38:25 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v56k4h$onl4$4@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> <v565d9$3mg7e$1@dont-email.me>
 <v56iht$3or0r$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 22 Jun 2024 13:38:25 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="810660"; 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: <v56iht$3or0r$4@dont-email.me>
Content-Language: en-US
Bytes: 5805
Lines: 101

On 6/22/24 9:11 AM, olcott wrote:
> On 6/22/2024 4:27 AM, Fred. Zwarts wrote:
>> Op 21.jun.2024 om 15:01 schreef olcott:
>>> 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.
>>>
>>
>> If ..., but that condition is not present, so the 'then' does not apply.
>> This makes the sentence completely superfluous. I would expect better 
>> from someone who claims to be an experienced programmer.
>>
>> But since I pointed out in a very detailed way, why it is incorrect, 
>> your reply shows that you do not understand where you are talking 
>> about, which then becomes utterly nonsense.
>>
>> The question which instruction is incorrectly simulated already shows 
>> your error. The error is not that an instruction is simulated 
>> incorrectly, but that some instruction are not simulated at all.
>> Why is that already over your head?
>>
> 
> It is a verified fact that the behavior that finite string DDD presents
> to HH0 is that when DDD correctly simulated by HH0 calls HH0(DDD) that
> this call DOES NOT RETURN.
> 
> It is a verified fact that the behavior that finite string DDD presents
> to HH1 is that when DDD correctly simulated by HH0 calls HH1(DDD) that
> this call DOES RETURN.
> 
> I don't get why people here insist on lying about verified facts.
> 


The problem is that the "behavior" that the finite string DDD presents 
to HH0, is DEFINED by the problem. And if that problem is the Halting 
Problem, that behavior is the behavior of the machine the input 
represents. If HH0 treats the input as having a different behavior, then 
HH0 just isn't a Halting Decider, but something else.

If HH0 is supposed to be a Halting decider, but uses a method that makes 
it see something other than that behavior, then it is just an incorrect 
Halting Decider, and its algorithm just creates an incorrect recreation 
of the property of the input it is supposed to be working on.


A bit of a side note, the actual "Input" to HH0, is a pointer to memory, 
and as such it passes a reference to ALL of memory considering the 
starting point to be that address, so your "Input" isn't actually the 
few bytes of DDD, but ALL of memory and a starting point. If you 
actually mean that the input is just those few bytes pointed to by the 
address, then the input is improperly formed and is NOT a proper 
representation of the input machine, becuase it is incomplete.

The fact you don't understand this, seems to imply you are lacking the 
basic knowledge to be talking about this sort of thing.