Deutsch   English   Français   Italiano  
<v3fncn$2n53n$9@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: Two dozen people were simply wrong --- Try to prove otherwise ---
 pinned down
Date: Sat, 1 Jun 2024 13:56:39 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3fncn$2n53n$9@i2pn2.org>
References: <v3501h$lpnh$1@dont-email.me> <v3b9kj$2im02$1@i2pn2.org>
 <v3bale$222n5$1@dont-email.me> <v3bbs2$2im01$1@i2pn2.org>
 <v3bcre$22a8n$1@dont-email.me> <v3bduk$2im01$2@i2pn2.org>
 <v3bedb$22f8h$1@dont-email.me> <v3bfbm$2im01$3@i2pn2.org>
 <v3bg39$22o6m$1@dont-email.me> <v3cbhu$2k3ld$1@i2pn2.org>
 <v3clo2$28p7n$1@dont-email.me> <v3dft1$2lfup$1@i2pn2.org>
 <v3dhob$2dio8$1@dont-email.me> <v3dk0d$2lfup$2@i2pn2.org>
 <v3dkf2$2e2po$1@dont-email.me> <v3dmnc$2lfup$3@i2pn2.org>
 <v3do66$2ejq2$1@dont-email.me> <v3dqka$2lfup$4@i2pn2.org>
 <v3dsev$2f6ul$1@dont-email.me> <v3dtt4$2lfup$5@i2pn2.org>
 <v3dvr3$2jgjd$1@dont-email.me> <v3e0rj$2lfup$6@i2pn2.org>
 <v3e1m6$2jmc2$1@dont-email.me> <v3f09p$2n53o$1@i2pn2.org>
 <v3feqn$2rdp3$1@dont-email.me> <v3fgat$2n53n$5@i2pn2.org>
 <v3fhan$2rsbs$1@dont-email.me> <v3fi55$2n53o$6@i2pn2.org>
 <v3fiq7$2rsbs$5@dont-email.me> <v3flc5$2n53o$7@i2pn2.org>
 <v3flm8$2sm3s$1@dont-email.me> <v3fm1e$2n53n$8@i2pn2.org>
 <v3fmlc$2sogn$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 1 Jun 2024 17:56:39 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2856055"; 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: <v3fmlc$2sogn$1@dont-email.me>
Bytes: 8790
Lines: 164

On 6/1/24 1:44 PM, olcott wrote:
> On 6/1/2024 12:33 PM, Richard Damon wrote:
>> On 6/1/24 1:27 PM, olcott wrote:
>>> On 6/1/2024 12:22 PM, Richard Damon wrote:
>>>> On 6/1/24 12:38 PM, olcott wrote:
>>>>> On 6/1/2024 11:27 AM, Richard Damon wrote:
>>>>>> On 6/1/24 12:13 PM, olcott wrote:
>>>>>>> On 6/1/2024 10:56 AM, Richard Damon wrote:
>>>>>>>> On 6/1/24 11:30 AM, olcott wrote:
>>>>>>>>>
>>>>>>>>> *I will not discuss any other points with you until after you 
>>>>>>>>> either*
>>>>>>>>> (a) Acknowledge that DD correctly simulated by HH and ⟨Ĥ⟩ ⟨Ĥ⟩ 
>>>>>>>>> correctly
>>>>>>>>>      simulated by embedded_H remain stuck in recursive 
>>>>>>>>> simulation for
>>>>>>>>>      1 to ∞ of correct simulation or
>>>>>>>>>
>>>>>>>>> (b) Correctly prove otherwise.
>>>>>>>>
>>>>>>>> And until you answer the question of what that actually means, I 
>>>>>>>> will reply WHO CARES.
>>>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>>>>> 00       int HH(ptr p, ptr i);
>>>>>>> 01       int DD(ptr p)
>>>>>>> 02       {
>>>>>>> 03         int Halt_Status = HH(p, p);
>>>>>>> 04         if (Halt_Status)
>>>>>>> 05           HERE: goto HERE;
>>>>>>> 06         return Halt_Status;
>>>>>>> 07       }
>>>>>>> 08
>>>>>>> 09       int main()
>>>>>>> 10       {
>>>>>>> 11         HH(DD,DD);
>>>>>>> 12         return 0;
>>>>>>> 13       }
>>>>>>>
>>>>>>> Every DD correctly simulated by any HH of the infinite set of HH/DD
>>>>>>> pairs that match the above template never reaches past its own 
>>>>>>> simulated
>>>>>>> line 03 in 1 to ∞ steps of correct simulation of DD by HH.
>>>>>>>
>>>>>>> In this case HH is either a pure simulator that never halts or
>>>>>>> HH is a pure function that stops simulating after some finite number
>>>>>>> of simulated lines. The line count is stored in a local variable.
>>>>>>> The pure function HH always returns the meaningless value of 56
>>>>>>> after it stops simulating.
>>>>>>>
>>>>>>
>>>>>> So, still no answer, to teh question. 
>>>>>
>>>>> You can pretend that you don't understand something that you do indeed
>>>>> understand into perpetuity.
>>>>>
>>>>> The key measure of dishonestly would be that you continue to say
>>>>> that you don't understand yet never ever point out exactly what you
>>>>> don't understand and why you don't understand it.
>>>>>
>>>>>> I giuess that Mean YOU don't even know what you are asking, though 
>>>>>> it seems that now you are admitting that your HH doesn't actually 
>>>>>> ANSWER the question, so it isn't ACTUALL a decider for any 
>>>>>> function except the "56" mapping.
>>>>>>
>>>>>> I will repeat the question and until you answer the question of 
>>>>>> what that actually means, I will reply WHO CARES.
>>>>>>
>>>>>> DO you mean the simulation of the TEMPLATE DD, 
>>>>>
>>>>> *Of course I don't mean that nonsense. I mean exactly what I 
>>>>> specified*
>>>>>
>>>>>> which means that we CAN'T simulate the call HH as we have no code 
>>>>>> past point to simulate, and thus your claim is just a LIE.
>>>>>>
>>>>>> Or, do you mean a given instance of HH simulating a given instance 
>>>>>> of DD, at which point we never have the 1 to infinte number of 
>>>>>> simulatons of THAT INPUT, so your claim is just a LIE.
>>>>>>
>>>>>
>>>>> Every element of the infinite set of every H/D pairs...
>>>>> Every element of the infinite set of every H/D pairs...
>>>>> Every element of the infinite set of every H/D pairs...
>>>>>
>>>>> *Its not that hard when one refrains from dishonesty*
>>>>> We can't even say that you forgot these details from one reply
>>>>> to the next because the details are still in this same post.
>>>>>
>>>>
>>>> And every one gives a meaningless answer, 
>>>
>>> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
>>> DD correctly emulated by HH with an x86 emulator cannot possibly
>>> reach past its own machine instruction [00001c2e] in any finite
>>> number of steps of correct emulation.
>>>
>>
>> Why? I don't care about it.
>>
>> As I have said, the implication of your definition of "Correct 
>> SImulation" means that this says NOTHING about the halting behavior of 
>> DD. (only not halted yet)
>>
> 
> *THEN TRY TO REFUTE THIS UNEQUIVOCAL STATEMENT*
> DD correctly emulated by HH with an x86 emulator cannot possibly
> reach past its own machine instruction [00001c2e] in any finite
> *or infinite* number of steps of correct emulation.
> 
> When I say it that way you claim to be confused and what I do
> not say it that way you claim what I say is incomplete proof.

WHy do I care? I won't spend the effort to even try to refute something 
that is clearly meaningless.

You seem to have a conflict of definitions, as a given DD will only ever 
be simulated by ONE given HH that only simuates for one number of steps.

There is NO input that was actually simulated for all the number of 
steps indicated, as they were all different inputs, as you obviously are 
including the copy of HH in what DD is, so all the different numbers are 
with different HHs so different DDs.

Since they are all different simulations of DIFFERENT input, you need to 
show some established rule that lets you try to combine them, which you 
don't have.

Thus, this multitude of simulation of DIFFERENT machines provide NO 
difinitive information about the halting behavior of ANY of them, except 
for the ones where HH never aborts, which do show that the DD based on 
those are non-halting, but the HH doesn't answer.

No other HH is given those inputs, so that result does not apply to 
them, and to claim so is just lying with invalid logic.

You are just demonstarting that you don't understand how logic works, or 
even how to actually DEFINE things to do the logic on.

> 
>>> _DD()
>>> [00001c22] 55         push ebp
>>> [00001c23] 8bec       mov ebp,esp
>>> [00001c25] 51         push ecx
>>> [00001c26] 8b4508     mov eax,[ebp+08]
>>> [00001c29] 50         push eax        ; push DD 1c22
>>> [00001c2a] 8b4d08     mov ecx,[ebp+08]
>>> [00001c2d] 51         push ecx        ; push DD 1c22
>>> [00001c2e] e80ff7ffff call 00001342   ; call HH
>>> [00001c33] 83c408     add esp,+08
>>> [00001c36] 8945fc     mov [ebp-04],eax
>>> [00001c39] 837dfc00   cmp dword [ebp-04],+00
>>> [00001c3d] 7402       jz 00001c41
>>> [00001c3f] ebfe       jmp 00001c3f
>>> [00001c41] 8b45fc     mov eax,[ebp-04]
>>> [00001c44] 8be5       mov esp,ebp
>>> [00001c46] 5d         pop ebp
>>> [00001c47] c3         ret
>>> Size in bytes:(0038) [00001c47]
>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========