Deutsch   English   Français   Italiano  
<vvh73f$1bt2l$3@dont-email.me>

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

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Halting Problem: What Constitutes Pathological Input
Date: Wed, 7 May 2025 23:06:23 -0400
Organization: A noiseless patient Spider
Lines: 162
Message-ID: <vvh73f$1bt2l$3@dont-email.me>
References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvav6o$o4v0$4@dont-email.me>
 <vvb329$15u5b$1@dont-email.me> <vvb37g$1451r$1@dont-email.me>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 08 May 2025 05:06:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a565b5a0e22116f8f680253905402a9a";
	logging-data="1438805"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+87cVg3qHu3QN1/YIv5uyF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tt5DZUzEJNbi++eghvF6YdUIdWk=
Content-Language: en-US
In-Reply-To: <vvh6c5$1gq2p$2@dont-email.me>
Bytes: 7901

On 5/7/2025 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
> 


That would be you:


On 5/5/2025 8:24 AM, dbush wrote:
 > On 5/4/2025 11:03 PM, dbush wrote:
 >> On 5/4/2025 10:05 PM, olcott wrote:
 >>> On 5/4/2025 7:23 PM, Richard Damon wrote:
 >>>> But HHH doesn't correct emulated DD by those rules, as those rules
 >>>> do not allow HHH to stop its emulation,
 >>>
 >>> Sure they do you freaking moron...
 >>
 >> Then show where in the Intel instruction manual that the execution of
 >> any instruction other than a HLT is allowed to stop instead of
 >> executing the next instruction.
 >>
 >> Failure to do so in your next reply, or within one hour of your next
 >> post on this newsgroup, will be taken as you official on-the-record
 >> admission that there is no such allowance and that HHH does NOT
 >> correctly simulate DD.
 >
 > Let the record show that Peter Olcott made the following post in this
 > newsgroup after the above message:
 >
 > On 5/4/2025 11:04 PM, olcott wrote:
 >  > D *WOULD NEVER STOP RUNNING UNLESS*
 >  > indicates that professor Sipser was agreeing
 >  > to hypotheticals AS *NOT CHANGING THE INPUT*
 >  >
 >  > You are taking
 >  > *WOULD NEVER STOP RUNNING UNLESS*
 >  > to mean *NEVER STOPS RUNNING* that is incorrect.
 >
 > And has made no attempt after over 9 hours to show where in the Intel
 > instruction manual that execution is allowed to stop after any
 > instruction other than HLT.
 >
 > Therefore, as per the above criteria:
 >
 > LET THE RECORD SHOW
 >
 > That Peter Olcott
 >
 > Has *officially* admitted
 >
 > That DD is NOT correctly simulated by HHH