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: =?UTF-8?Q?Re=3A_Flibble=E2=80=99s_Leap=3A_Why_Behavioral_Divergence?=
 =?UTF-8?Q?_Implies_a_Type_Distinction_in_the_Halting_Problem?=
Date: Mon, 12 May 2025 21:48:03 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <2c4b30d47a3249d874b2b38a3932c00a81181061@i2pn2.org>
References: <vv1UP.77894$JJT6.54808@fx16.ams4> <vvqd4u$g8a1$1@dont-email.me>
 <7N2UP.527443$wBt6.464256@fx15.ams4> <vvqfgq$gmmk$1@dont-email.me>
 <os3UP.670056$BFJ.223954@fx13.ams4> <vvqgpt$gmmk$4@dont-email.me>
 <aG3UP.366972$wBVe.321504@fx06.ams4>
 <39947848bf73be52ee6fbbeb6d0d929009dfec8e@i2pn2.org>
 <fR8UP.92502$o31.50010@fx04.ams4>
 <fb3915123ad5c4703b92df902c37267fce2c4812@i2pn2.org>
 <vvrhk6$nejb$2@dont-email.me> <vvrhtj$nnmf$1@dont-email.me>
 <43f0f4158610d859516ba3e0115a8a2b8bd7630b@i2pn2.org>
 <vvrl9h$o2ab$6@dont-email.me> <vvrmso$nt1l$2@dont-email.me>
 <87frha4j5w.fsf@nosuchdomain.example.com> <vvrq3u$sjai$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2025 02:50:07 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="118633"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vvrq3u$sjai$6@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 5/11/25 11:32 PM, olcott wrote:
> On 5/11/2025 10:11 PM, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...]
>>> ALL C compilers are required to diagnose ALL syntax errors and ALL
>>> constraint violations.
>>
>> Yes, all conforming C compilers are required to do that.  (Well,
>> strictly speaking they're only required to issue at least one diagnostic
>> for any translation unit that violates a syntax rule or constraint.)
>>
>> [...]
>>
>>> In my experience, Microsoft's C compiler - although not perfect - is
>>> pretty good at following conformance rules. I'd be surprised to learn
>>> from a competent source that it misses a syntax error.
>>
>> I wouldn't, since few if any C compilers are conforming by default.
>>
>> I've just tried 4 different C compilers (gcc, clang, and tcc
>> on Ubuntu, MS Visual Studio 2022 on Windows), and none of them
>> diagnosed a stray semicolon at file scope *by default*.  gcc and
>> clang can be persuaded to diagnose it.  tcc, as far as I can tell,
>> cannot; I don't believe it claims to be fully conforming in any mode.
>> I wasn't able to get MSVS to diagnose it, but there could easily
>> be an option that I'm missing.
>>
>> If I wanted to prove something in mathematical logic using C code as
>> a vehicle, I personally would try to use fully standard-conforming C.
>> I *might* consider using a more lax C-like language, such as the
>> language accepted by some C compiler in its default mode -- but I'd
>> need a good reason to do that, and I'd want a rigorous definition
>> of anything I use that differs from standard C.
>>
>> It's possible that olcott's C-like code has well defined behavior
>> in the implementation he's using.  If so, I'm not sure there's any
>> fundamental reason to use something close to C rather than using C
>> itself in an attempted refutation of some well known mathematical
>> proof.  (I wouldn't expect either C or something C-like to be a
>> good vehicle for such a proof.  I don't think C is defined rigorously
>> enough to be useful for such a task, and any C-like language is even
>> less so.)
>>
>> olcott will likely use this to claim that I support his views.
>> He will be wrong.
>>
>> [...]
>>
> 
> C code is not as 100% exactingly precise as x86 code.
> 
> _DDD()
> [00002172] 55         push ebp      ; housekeeping
> [00002173] 8bec       mov  ebp,esp  ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404     add  esp,+04
> [00002182] 5d         pop  ebp
> [00002183] c3         ret
> Size in bytes:(0018) [00002183]

Which just is not a program, as you have been told, so it is an input 
that CAN NOT be emulated past the call instruction.


> 
> When one or more steps of DDD are correctly emulated
> by any x86 emulator HHH the result is the same as
> this code correctly simulated by a C interpreter.
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> I have the "return" statement in there because it
> marks a final halt state that is never reached.
> 
> If a computation stops running for any reason
> besides reaching a final halt state comp theory
> says that this computation never halted. Thus
> DDD emulated by HHH never halts.
> 
> People in this forum have been consistently dishonest
> about this point for three years.
> 

The computation CAN NOT stop for any reason other than reaching the 
final state.

The fact that the emulation does, just proves that it isn't a correct 
emulation.

You are just showing your total ignorance of the rules of the system you 
are talking about, and that you just don't care, so your words are DEAE 
to anyone with a bit of intelegence, and you are securing your prime 
seats on the trip to the lake of fire.