Deutsch   English   Français   Italiano  
<3a002adf6f6bcd5f4c2cd17ce95a16a07d29d02c@i2pn2.org>

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

Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!news.neodome.net!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 09:19:36 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <3a002adf6f6bcd5f4c2cd17ce95a16a07d29d02c@i2pn2.org>
References: <Ms4XP.801347$BFJ.668081@fx13.ams4>
 <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> <87msb2x39x.fsf@bsb.me.uk>
 <87tt5aslwo.fsf@nosuchdomain.example.com> <100rjtj$hgh5$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 13:22:31 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1731810"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <100rjtj$hgh5$1@dont-email.me>
Content-Language: en-US
Bytes: 8760
Lines: 152

On 5/24/25 1:02 AM, olcott wrote:
> On 5/23/2025 10:55 PM, Keith Thompson wrote:
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>> 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.
>>>
>>> Maybe it makes less sense out of the context it was posted in.  This was
>>> when he was being less obtuse.  The computation in question only halts
>>> because it is halted by the decider on which it is built.  It is a
>>> halting computation, but according to PO it can reported as not halting
>>> because of what would happen if it were not halted by the decider from
>>> which it is derived.
>>
>> I think you're misreading it (or, if you prefer, I have yet to be
>> convinced that I'm misreading it).
>>
>> | 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.
>>
>> Call the "halt decider" H, and the input I.  If you perform the
>> computation specified by I, it never halts.  olcott's statement
>> is that if H correctly determines that I never halts (assume for
>> now that that's possible), then H can correctly report that I
>> never halts.  This is true, tautological, and uninteresting.
>>
>> There is *another* computation, I-simulated-by-H.  This computation
>> may halt if H decides to halt it.  But I-simulated-by-H is not I.
>> H's alleged job is to determine the halting status of I, not the
>> halting status of I-simulated-by-H.
>>
>> I think you're saying that H *incorrectly* reports that
>> I-simulated-by-H never halts.  My interpretation is that H
>> *correctly* reports that I never halts.
>>
>> The above is based only on that isolated statement, without reference
>> to olcott's other claims.  Moving on to the larger context:
>>
>> If a general solution to the halting problem were possible (we
>> know it isn't), a simulating halt decider could be one possible
>> way to approach it.  It is, I suppose, a tempting idea.  You could
>> imagine a simulator that runs a program one step at a time, and
>> after each step, reports that it just halted if it has, or performs
>> some analysis that attempts to determine that it will never halt.
>> If it's able to make that determination, the simulator can halt
>> and correctly report that the simulated program never halts.
>>
> 
> Good and correct. You are one of my best reviewers.
> 
>> If the program runs on a machine with a finite number of states, this
>> is actually possible; a repeated state implies that the program is
>> in an infinite loop.  The problem is that a Turing machine is not
>> limited to a finite number of states (including the state of the
>> tape), and such an analysis is not possible in the general case.
>> I think olcott thinks it is possible.
>>
> 
> Most TM's seem to have a finite number of states.
> They have unlimited tape.
> 
>>> Subsequent wordings have all been about hiding this.  Just prior to this
>>> wording was the even more explicit claim that non-halting is correct
>>> because of what "would happen if line 15 were commented out".  It's
>>> always been about what would be the correct decision were the
>>> computation not what it actually is.
>>
>> Sure, I have no doubt that olcott has written contradictory things
>> (to the extent that they're clear enough to be contradictory).
>> I just don't think he's done is on the case of this specific
>> statement.
>>
> 
> _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]
> 
> DDD simulated by HHH according to the semantics of
> he x86 language remains in recursive emulation until
> stopped.

But the above is not a "program", and thus can not be simulated 
correctly. To make it one, we need to add the contents of HHH to the 
program and the input.

Then any HHH that does correctly simulate this input is not a decider, 
as it will not finish.

And, and HHH that aborts, was given a DIFFERENT INPUT, since that input 
contains the code for that HHH. Since the definition of behavior is what 
the program represented did (or equivalently, the results of a correct 
simulation, which by definition exactly matches that direct execution) 
and such a execution/simulation will reach the final state, since the 
HHH(DDD) that it calls *WILL* return as was the stipulation for this 
case, the only CORRECT answer for HHH that aborts and returns would be a 
1, but you code returns 0, so it is just incorrect.

Your logic is just based on the LIE of a category error or the assertion 
that two different programs are the same,

Sorry, you are just proving that you whole logic system is based on lying.



> 
>>>> I suppose Ben quoted PO saying this, because PO /uses/ it to justify 
>>>> that a
>>>> particular /halting/ computation will never halt,
>>>
>>> He may be doing that now, but he used to use this form of words to
>>> justify why non-halting is the correct result for some halting
>>> computations.  Obviously, to keep people talking he has had to scramble
>>> to get away from what he has said in the past without repudiating it.
>>> No crank likes admit they were ever wrong.
>>
>> Agreed.
>>
> 
>