| Deutsch English Français Italiano |
|
<df9391f2befc77bee5a4eb8ceb58ceeac0abd27a@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: =?UTF-8?Q?Re=3A_Analysis_of_Flibble=E2=80=99s_Latest=3A_Detecting_v?=
=?UTF-8?Q?s=2E_Simulating_Infinite_Recursion_ZFC?=
Date: Sat, 24 May 2025 17:53:06 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <df9391f2befc77bee5a4eb8ceb58ceeac0abd27a@i2pn2.org>
References: <Ms4XP.801347$BFJ.668081@fx13.ams4>
<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> <87a573xz0s.fsf@bsb.me.uk>
<875xhrtbpr.fsf@nosuchdomain.example.com> <87y0umx63u.fsf@bsb.me.uk>
<871pseu9os.fsf@nosuchdomain.example.com> <100ssg5$qc3d$1@dont-email.me>
<100stgq$q5nm$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 24 May 2025 21:57:20 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="1783864"; 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: <100stgq$q5nm$3@dont-email.me>
Bytes: 5469
Lines: 98
On 5/24/25 12:52 PM, olcott wrote:
> On 5/24/2025 11:35 AM, Mike Terry wrote:
>> On 24/05/2025 01:36, Keith Thompson wrote:
>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>> [...]
>>>>>> And the big picture is that this can be done because false is the
>>>>>> correct halting decision for some halting computations. He has said
>>>>>> this explicitly (as I have posted before) but he has also
>>>>>> explained it
>>>>>> in words:
>>>>>>
>>>>>> | When-so-ever a halt decider correctly determines that its input
>>>>>> would
>>>>>> | never halt unless forced to halt by this halt decider this halt
>>>>>> | decider has made a correct not-halting determination.
>>>>>
>>>>> Hmm. I don't read that the way you do. Did I miss something?
>>>>>
>>>>> It assumes that the input is a non-halting computation ("its input
>>>>> would never halt") and asserts that, in certain circumstances,
>>>>> his mythical halt decider correctly determines that the input
>>>>> is non-halting.
>>>>>
>>>>> When his mythical halt decider correctly determines that its input
>>>>> doesn't halt, it has made a correct non-halting determination.
>>>>> It's just a tautology.
>>>>
>>>> It would be a tautology but for the "unless..." part. It does not make
>>>> the determination that it does not halt. It determines that it would
>>>> not halt were it not for the fact that the decider (a simulation) in
>>>> fact halts it.
>>>
>>> Right, so the computation itself is non-halting.
>>
>> No no no, it halts! (Assuming we're discussing the computation DD()
>> with PO's code.)
>>
>
>
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
> _DD()
> [00002162] 55 push ebp
> [00002163] 8bec mov ebp,esp
> [00002165] 51 push ecx
> [00002166] 6862210000 push 00002162
> [0000216b] e862f4ffff call 000015d2
> [00002170] 83c404 add esp,+04
> [00002173] 8945fc mov [ebp-04],eax
> [00002176] 837dfc00 cmp dword [ebp-04],+00
> [0000217a] 7402 jz 0000217e
> [0000217c] ebfe jmp 0000217c
> [0000217e] 8b45fc mov eax,[ebp-04]
> [00002181] 8be5 mov esp,ebp
> [00002183] 5d pop ebp
> [00002184] c3 ret
> Size in bytes:(0035) [00002184]
>
> It is a damned lie that DD simulated by HHH according
> to the rules of the x86 language ever reaches its own
> machine address 00002184 final halt state.
But that isn't the criteria that HHH is supposed to use.
So, you are just showing you are using a strawman.
And, it is just a damned lie that any HHH that returns an answer for
that input actually did a correct simulation of the input.
>
> The input to HHH(DD) specifies a non-halting sequence
> of configurations.
Nope, not if HHH(DD) returns 0.
Of course, you first have to fix DD to be a program that can be run by
including the implied code of HHH as part of it.
WHich is what makes your argument a lie, as each HHH gets a differnt DD
to look at.
>
> The above two are verified facts and anyone lying about
> this may be condemned to actual Hell.
> At least that is what Revelations 21:8 says.
>
Nope, those are verified LIES, based on the facts.
Sorry, you are just showing how bad your logic is, and how little you
know of the topic you are trying to talk about.