| Deutsch English Français Italiano |
|
<100s59d$kqg3$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
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 11:59:08 +0200
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <100s59d$kqg3$1@dont-email.me>
References: <Ms4XP.801347$BFJ.668081@fx13.ams4>
<100kt0c$2tae8$3@dont-email.me> <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> <87a573xz0s.fsf@bsb.me.uk>
<875xhrtbpr.fsf@nosuchdomain.example.com> <100r2mb$b2b1$1@dont-email.me>
<100r3vi$b5vm$1@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 11:59:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8c305cec74a1f8d9646d533051f06774";
logging-data="682499"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187N2PfOPnHztjfNVrdBqWJ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2nJkOmfrY5hAsK44hRLqA1GiWK4=
Content-Language: nl, en-GB
In-Reply-To: <100r3vi$b5vm$1@dont-email.me>
Bytes: 4067
Op 24.mei.2025 om 02:30 schreef olcott:
> On 5/23/2025 7:08 PM, Mike Terry wrote:
>> On 23/05/2025 19:37, Keith Thompson wrote:
>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> 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.
>>
>> You're reading it the way most people would, and in the way I said
>> Sipser would be interpreting the oft-quoted "Sipser quote". I don't
>> think you've missed anything particularly.
>>
>> I suppose Ben quoted PO saying this, because PO /uses/ it to justify
>> that a particular /halting/ computation will never halt, PO's HHH
>> simulates DDD (which halts) but before DDD halts it spots a pattern in
>> the simulation, and announces non-halting.
>
> In other words you expect that the HHH that DD calls
> to report on the behavior of its caller?
>
> How the f-ck can it do that?
All information is present in the input specification, including the
code of DDD and all function called by DDD up to the OS-level.
So, HHH has all the information needed to see the behaviour of the caller.
That HHH has a bug that prevents it see the full specification does not
change the fact that the specification is in the input.