| Deutsch English Français Italiano |
|
<7bceaf8dc041e517b4a15d0ac381e3684f202c58@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
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: How do computations actually work?
Date: Thu, 29 May 2025 07:11:09 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <7bceaf8dc041e517b4a15d0ac381e3684f202c58@i2pn2.org>
References: <Ms4XP.801347$BFJ.668081@fx13.ams4>
<100ktr7$2reaa$1@dont-email.me> <100l09v$2tae8$5@dont-email.me>
<100l1ov$2ul3j$1@dont-email.me> <100l3jh$2v0e9$1@dont-email.me>
<100l5c8$2ul3j$2@dont-email.me> <100l75g$2vpq3$1@dont-email.me>
<100l887$2ul3i$2@dont-email.me> <100l9gh$30aak$1@dont-email.me>
<100lc4o$30pgm$1@dont-email.me> <100ld1u$312c9$1@dont-email.me>
<100lg4g$31jt3$1@dont-email.me> <100lkdv$32ib3$1@dont-email.me>
<100lmif$32v06$1@dont-email.me> <100lmp3$32ven$1@dont-email.me>
<100m319$38k55$2@dont-email.me> <87jz69xlpx.fsf@nosuchdomain.example.com>
<100mder$39slu$2@dont-email.me> <100oipb$3oge1$1@dont-email.me>
<100onkd$3t5cb$1@dont-email.me> <100rti1$jfld$1@dont-email.me>
<100so11$p071$5@dont-email.me> <100un10$1a22r$1@dont-email.me>
<100vasi$1d5lg$10@dont-email.me> <10119o9$1u1o3$1@dont-email.me>
<101230n$22da5$9@dont-email.me> <1013tk3$2hj2v$1@dont-email.me>
<1014mru$2lsi8$10@dont-email.me> <1016er3$354rb$1@dont-email.me>
<10176sk$39etk$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 29 May 2025 11:29:17 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="2409768"; 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: <10176sk$39etk$2@dont-email.me>
On 5/28/25 10:33 AM, olcott wrote:
> On 5/28/2025 2:43 AM, Mikko wrote:
>> On 2025-05-27 15:48:14 +0000, olcott said:
>>
>>> On 5/27/2025 3:37 AM, Mikko wrote:
>>>> On 2025-05-26 15:57:11 +0000, olcott said:
>>>>
>>>>> On 5/26/2025 3:46 AM, Mikko wrote:
>>>>>> On 2025-05-25 14:53:06 +0000, olcott said:
>>>>>>
>>>>>>> On 5/25/2025 4:14 AM, Mikko wrote:
>>>>>>>> On 2025-05-24 15:18:57 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 5/24/2025 2:47 AM, Mikko wrote:
>>>>>>>>>> On 2025-05-23 02:47:40 +0000, olcott changed the subject to
>>>>>>>>>>> How do computations actually work?
>>>>>>>>>>
>>>>>>>>>> Each computation works differently. It does not matter how it
>>>>>>>>>> works as
>>>>>>>>>> long as there are instructions that fully specify how that
>>>>>>>>>> computation
>>>>>>>>>> shall be performed.
>>>>>>>>>
>>>>>>>>> All termination analyzers are required to report on the
>>>>>>>>> behavior that their input finite string specifies.
>>>>>>>>
>>>>>>>> To report correctly. Though the input string to a termination
>>>>>>>> analyzer
>>>>>>>> usially is incomlete: the input string usually specifies different
>>>>>>>> behavours depending on the input that is not shown to the
>>>>>>>> termination
>>>>>>>> analyzer, and the analyzer's report must cover all of them.
>>>>>>>>
>>>>>>>> A partial termination analyzer may fail to report but is not
>>>>>>>> allowed
>>>>>>>> to report incorrectly.
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>> HHH(DDD);
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> DDD simulated by HHH cannot possibly reach its
>>>>>>> "return" statement final halt state, only liars
>>>>>>> will disagree.
>>>>>>
>>>>>> Again a straw man deception. Where reasonable people disgraee is the
>>>>>> relevance of that claim. The behavour specified by DDD does reach the
>>>>>> final return from DDD. Whether HHH can simulate that part of the
>>>>>> behaviour is irrelevant. Even without the simjlation HHH decides
>>>>>> correctly if and only if it determines and reports that DDD halts.
>>>>>
>>>>> _DDD()
>>>>> [00002192] 55 push ebp
>>>>> [00002193] 8bec mov ebp,esp
>>>>> [00002195] 6892210000 push 00002192
>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH
>>>>> [0000219f] 83c404 add esp,+04
>>>>> [000021a2] 5d pop ebp
>>>>> [000021a3] c3 ret
>>>>> Size in bytes:(0018) [000021a3]
>>>>>
>>>>> How many recursive emulations does HHH have to
>>>>> wait before its emulated DDD magically halts
>>>>> on its own without ever needing to be aborted?
>>>>
>>>> In order to determine that you need a program that simulates DDD and
>>>> all
>>>> functios DDD calls and detects and counts and reports emulation levels.
>>>
>>> No you don't. All that you need to do is simply imagine
>>> that HHH is an x86 emulator capable of emulating itself
>>> emulating DDD. // *This is fully operational code*
>>
>> Well, you needn't if you have a good substitution. But imagination is
>> not a good substitution of real work with a real tool.
>>
>
> https://github.com/plolcott/x86utm/blob/master/Halt7.c
> has an HHH that does simulate itself simulating DDD.
>
And the DDD that halts, showing it is wrong.
Your world is just full of contradictions:
Either your input is just invalid because it doesn't contrain all its
code or the code from that Halt7.c is inclided in all arguments, and
thus you can't have any other HHH, as it has been defined.
Either you definition of HHH is actually a program, or you can't talk
about it being a decider, since those must be programs, and that means
it ALWAYS does the same thing, and nevef something else.
The input to a decider must be a program, and thus include all of its
code. EIther you include that code as part of the input, or your input
is invalid.
Either that code it includes is of a program, and thus fixed, or it just
isn't valid.
If that code is fixed, it doesn't change when you imagine some other
decider, they hypothetical decider looks at us.
If you try to say that the decider *IS* that Hypothetical Decider,
either it always behaves that way, or you are just lying.
Sorry, your world is just built on lies, that you seems to be trying to
beleive.