Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Halting Problem: What Constitutes Pathological Input
Date: Thu, 8 May 2025 06:56:40 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <3e8a39c56cadded1ed4991761fbe92ccc696089e@i2pn2.org>
References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvb43f$15u5b$4@dont-email.me>
 <vvb4ok$o4v0$9@dont-email.me> <vvb52g$15u5b$6@dont-email.me>
 <vvb5ca$o4v0$10@dont-email.me> <vvb5vp$15u5b$7@dont-email.me>
 <vvb675$o4v0$11@dont-email.me> <vvb9d7$1av94$3@dont-email.me>
 <vvbani$1b6l1$1@dont-email.me> <vvbb6s$1av94$4@dont-email.me>
 <vvbcb3$1b6l1$2@dont-email.me> <vvbe0j$1av94$8@dont-email.me>
 <vvbecc$1b6l1$6@dont-email.me> <vvbhk0$1ijna$1@dont-email.me>
 <vvc7t9$29pp8$1@dont-email.me> <vvc86c$2a4cs$1@dont-email.me>
 <vvcufi$2sk4a$3@dont-email.me> <vvdlff$3i09b$2@dont-email.me>
 <vvdmqe$3huo6$4@dont-email.me> <vvdneq$3k2gc$3@dont-email.me>
 <42d875b9727dae90799e064ac33b9e1be866f2b5@i2pn2.org>
 <vvegg3$89u0$7@dont-email.me>
 <2f87c70ff64c8b83fa2456545e3250930158a3b5@i2pn2.org>
 <vvfu5d$130t3$4@dont-email.me>
 <6528755608b2bbe4206f2b8e11c78417ba77dde5@i2pn2.org>
 <vvh6c5$1gq2p$2@dont-email.me>
 <7df81c8bceda5f15cbb0d608507628065adcff63@i2pn2.org>
 <vvhbp0$1hom3$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 8 May 2025 11:22:25 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3647871"; 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: <vvhbp0$1hom3$2@dont-email.me>

On 5/8/25 12:26 AM, olcott wrote:
> On 5/7/2025 10:59 PM, Richard Damon wrote:
>> On 5/7/25 10:53 PM, olcott wrote:
>>> On 5/7/2025 9:28 PM, Richard Damon wrote:
>>>> On 5/7/25 11:27 AM, olcott wrote:
>>>>> On 5/7/2025 6:01 AM, Richard Damon wrote:
>>>>>> On 5/6/25 10:28 PM, olcott wrote:
>>>>>>> On 5/6/2025 5:59 PM, Richard Damon wrote:
>>>>>>>> On 5/6/25 3:20 PM, olcott wrote:
>>>>>>>>> On 5/6/2025 2:10 PM, Fred. Zwarts wrote:
>>>>>>>>>> Op 06.mei.2025 om 20:47 schreef olcott:
>>>>>>>>>>> On 5/6/2025 7:14 AM, dbush wrote:
>>>>>>>>>>>> On 5/6/2025 1:54 AM, olcott wrote:
>>>>>>>>>>>>> On 5/6/2025 12:49 AM, Richard Heathfield wrote:
>>>>>>>>>>>>>> On 06/05/2025 00:29, olcott wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <snip>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is the problem incorrect specification that creates
>>>>>>>>>>>>>>> the contradiction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not at all. The contradiction arises from the fact that it 
>>>>>>>>>>>>>> is not possible to construct a universal decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Everyone here insists that functions computed
>>>>>>>>>>>>>>> by models of computation can ignore inputs and
>>>>>>>>>>>>>>> base their output on something else.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think anyone's saying that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe you don't read so well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> What are the exact steps for DD to be emulated by HHH
>>>>>>>>>>>>> according to the semantics of the x86 language?
>>>>>>>>>>>>> *Only an execution trace will do*
>>>>>>>>>>>>
>>>>>>>>>>>> The exact same steps for DD to be emulated by UTM.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _DD()
>>>>>>>>>>> [00002133] 55         push ebp      ; housekeeping
>>>>>>>>>>> [00002134] 8bec       mov ebp,esp   ; housekeeping
>>>>>>>>>>> [00002136] 51         push ecx      ; make space for local
>>>>>>>>>>> [00002137] 6833210000 push 00002133 ; push DD
>>>>>>>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
>>>>>>>>>>> [00002141] 83c404     add esp,+04
>>>>>>>>>>> [00002144] 8945fc     mov [ebp-04],eax
>>>>>>>>>>> [00002147] 837dfc00   cmp dword [ebp-04],+00
>>>>>>>>>>> [0000214b] 7402       jz 0000214f
>>>>>>>>>>> [0000214d] ebfe       jmp 0000214d
>>>>>>>>>>> [0000214f] 8b45fc     mov eax,[ebp-04]
>>>>>>>>>>> [00002152] 8be5       mov esp,ebp
>>>>>>>>>>> [00002154] 5d         pop ebp
>>>>>>>>>>> [00002155] c3         ret
>>>>>>>>>>> Size in bytes:(0035) [00002155]
>>>>>>>>>>>
>>>>>>>>>>> Machine address by machine address specifics
>>>>>>>>>>> that you know that you cannot provide because
>>>>>>>>>>> you know that you are wrong.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That you do not understand it, does not mean that it has not 
>>>>>>>>>> been provided to you. It has, many times. If you do not know 
>>>>>>>>>> that you are wrong, you must be very stupid.
>>>>>>>>>
>>>>>>>>> Everything besides a machine address by machine
>>>>>>>>> address of DD emulated by HHH (according to the
>>>>>>>>> rules of the x86 language) where the emulated
>>>>>>>>> DD reaches its own "ret" instruction
>>>>>>>>
>>>>>>>> In other words, if people don't agree with your fantasy that is 
>>>>>>>> just in error, then "they" must be wrong.
>>>>>>>>
>>>>>>>> No, it
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION*
>>>>>>>>
>>>>>>>> No, YOU are a dishoneast dodge from the actual question
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Most of my reviewers switch to rhetoric when they
>>>>>>>>> know that they are wrong and still want to disagree.
>>>>>>>>> Disagreement (not truth) is their highest priority.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, that is just you projecting again.
>>>>>>>
>>>>>>> You keep saying the DD emulated by HHH according
>>>>>>> to the rules of the x86 language is wrong.
>>>>>>
>>>>>> Right, because it stops wnen it should not.
>>>>>>
>>>>>>>
>>>>>>> You keep arguing that HHH is required to break these
>>>>>>> rules to conform with the common misconception that HHH
>>>>>>> is required to report on the direct execution of DD().
>>>>>>
>>>>>> No, it needs to keep to them, which it doesn\'t.
>>>>>>
>>>>>> Where did I say it must break the rules?
>>>>>>
>>>>>
>>>>> DD correctly simulated by HHH according to the rules
>>>>> of the x86 language cannot possibly halt.
>>>>
>>>> Which is a non-sense statement, as HHH doesn't correctly simulate 
>>>> its input DD by those rules, as you have demonstarted,
>>>>
>>>
>>> Liar
>>>
>>
>> *THE* HHH is defined to abort it simulation.
>>
>> Aborted simulations are, by definition, not correct simulation per the 
>> x86 language.
>>
>> Thus, you are a liar.
>>
>> Maybe I should take you to court over this slander.
> 
> It would be libel dumb bunny and I have much more on
> you than you have on me. The only errors that you
> "know" of that I made are your own misconceptions.
> 

Depend if posting on USENET is considered a "publication" for that purpose.

And you are wrong about the later.

Since your own words have been shown to be based on equivocatins and 
lies, "misunderstanding" what you say is a given.

And, Reckless disregard for the actual truth makes the defense of "but 
that is what I believe" not valid. There is the reasonable person rule, 
that requires that a reason person must be able to believe what you 
claim to believe as somethig reasnable.

> 
>>
>> After all, I can prove my point, as you HAVE stipulated what the code 
>> for HHH is, and 
> 
> 
>> can produce the actual definition of the x86 language, 
> Not allowed to make any counterfeit x86 language.

Straight from Intel. Where do you get yours, that allows programs to 
just stop?

> 
>> and show how they disagree.
>>
> 
> I have never ever gave a rat's ass what anyone thinks of me.
> Doofuses are not my judge.

That's good, because I suspect almost everyone that has heard your words 
understands that you are just a stupid crank.

========== REMAINDER OF ARTICLE TRUNCATED ==========