Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #118475 > unrolled thread

Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem

Back to article view | Back to comp.theory

Contents

  Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 13:21 +0000
    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 15:44 +0100
      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 14:48 +0000
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:25 +0100
          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 15:34 +0000
            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:47 +0100
              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 15:49 +0000
                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 10:56 -0500
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 12:01 -0400
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem joes <noreply@example.org> - 2025-05-11 16:04 +0000
                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 11:51 -0500
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 16:05 +0000
                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 11:49 -0500
                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 12:54 -0400
                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 12:14 -0500
                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:24 +0100
                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 13:34 -0400
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 12:44 -0500
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 13:49 -0400
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 12:54 -0500
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 14:10 -0400
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 13:18 -0500
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 14:21 -0400
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 19:27 +0100
                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 16:59 +0000
                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 12:06 -0500
                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 17:15 +0000
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 12:19 -0500
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:26 +0100
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 17:33 +0000
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:48 +0100
                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:15 +0100
                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 17:26 +0000
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:31 +0100
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 16:05 -0700
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 18:14 -0500
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 19:45 -0400
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 19:41 -0500
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 20:43 -0400
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 21:13 -0400
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 20:48 -0500
                                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 07:40 -0400
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem joes <noreply@example.org> - 2025-05-12 09:29 +0000
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 19:16 -0400
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 17:13 +0100
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 15:58 -0400
                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 15:55 -0400
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 21:42 +0000
                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 16:45 -0500
                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 19:22 -0400
                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 19:19 -0400
                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 02:07 +0100
                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 20:12 -0500
                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 02:34 +0100
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 21:05 -0500
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 03:23 +0100
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 21:30 -0500
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 22:34 -0400
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 21:39 -0500
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 22:42 -0400
                                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 21:53 -0500
                                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 22:54 -0400
                                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 21:57 -0500
                                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-11 22:59 -0400
                                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:39 -0400
                                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:38 -0400
                                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mikko <mikko.levanto@iki.fi> - 2025-05-13 10:58 +0300
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 07:47 -0400
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 10:46 -0500
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-12 11:48 -0400
                                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 11:03 -0500
                                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-12 12:05 -0400
                                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:44 -0400
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:43 -0400
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 07:43 -0400
                          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 21:37 -0400
                            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 21:09 -0500
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 03:37 +0100
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 20:11 -0700
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 22:32 -0500
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 05:13 +0100
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:48 -0400
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 05:12 +0100
                                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-11 21:37 -0700
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 05:58 +0100
                                      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-13 22:22 +0100
                                        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-05-13 22:45 +0100
                              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 07:51 -0400
                                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 10:48 -0500
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-12 11:54 -0400
                                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:51 -0400
            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 11:29 -0500
              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 18:03 +0100
                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Ben Bacarisse <ben@bsb.me.uk> - 2025-05-12 17:32 +0100
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 11:52 -0500
                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:56 -0400
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-12 18:58 +0100
                    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Ben Bacarisse <ben@bsb.me.uk> - 2025-05-13 01:08 +0100
                  Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem wij <wyniijj5@gmail.com> - 2025-05-13 06:57 +0800
                    Truthmaker Maximalism and pathological self-reference olcott <polcott333@gmail.com> - 2025-05-12 18:15 -0500
                      Re: Truthmaker Maximalism and pathological self-reference wij <wyniijj5@gmail.com> - 2025-05-13 07:28 +0800
                        Re: Truthmaker Maximalism and pathological self-reference olcott <polcott333@gmail.com> - 2025-05-12 18:39 -0500
            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 15:54 -0400
          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mikko <mikko.levanto@iki.fi> - 2025-05-12 11:59 +0300
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-11 10:49 -0500
          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 17:11 +0100
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 15:48 -0400
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 10:22 -0500
          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 21:59 -0400
          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mikko <mikko.levanto@iki.fi> - 2025-05-13 11:18 +0300
      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mr Flibble <flibble@red-dwarf.jmc.corp> - 2025-05-11 14:59 +0000
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Heathfield <rjh@cpax.org.uk> - 2025-05-11 16:25 +0100
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 16:00 -0400
    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-11 15:42 -0400
    Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mikko <mikko.levanto@iki.fi> - 2025-05-12 11:53 +0300
      Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 10:16 -0500
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-12 11:21 -0400
          Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 11:09 -0500
            Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-12 12:15 -0400
              Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem olcott <polcott333@gmail.com> - 2025-05-12 11:43 -0500
                Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem dbush <dbush.mobile@gmail.com> - 2025-05-12 12:49 -0400
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Richard Damon <richard@damon-family.org> - 2025-05-12 22:04 -0400
        Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem Mikko <mikko.levanto@iki.fi> - 2025-05-13 11:27 +0300

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

#118651

On 12/05/2025 04:32, olcott wrote:
> C code is not as 100% exactingly precise as x86 code.

Mine is.

Yours? Maybe not so much.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#118789

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.

[toc] | [prev] | [next] | [standalone]

#118650

On 12/05/2025 04:11, 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.)

I was unintentionally ambiguous, for which I apologise.

The point I sought to make is that there is no syntax error (or 
constraint violation) so trivial that a compiler is given licence 
not to issue a diagnostic it if it has no other reason so to do.

That is, they are all capable of ticking the box that says 'must 
issue at least one diagnostic'.

> 
> [...]
> 
>> 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 was talking about conforming mode, which IIRC (it's been a 
while) is invoked by -W4 (a warning level that I habitually used 
in the days when I still used Microsoft software).

> 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.

Could you crank MSVS up to -W4 (or whatever the max is these 
days) and try again? I hate to impose, but of course it's your 
own fault for qualifying as a competent source. ;-)

If it doesn't diagnose at its maximum warning level, then okay, 
~I lose the syntax battle.

> 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.

So would I, if only to fend off pedantic fuss-pots such as... 
well, me, I suppose...

[Aside: I just checked what I laughingly call my archives to 
verify this, and I found an old (and I do mean ancient) Monty 
Hall simulation - 100 lines of C that gcc wasn't too pleased with 
when I turned on nanny mode, but which I'd be perfectly happy to 
defend before the X3J11 committee.

100 lines isn't much, of course, but it was throwaway code, so I 
had less motivation than usual to follow the rules, but follow 
them I still did.]

...and also to eliminate a potential source of error. Why tempt fate?

> 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.

Likewise.

I'd also steer clear of basing a mathematical proof on a program 
that is sensitive to the file formats of a particular platform. 
I'd need an *astoundingly* good reason to do that.

> 
> 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.)

FYI Agda, Lean, and Rocq all offer proof vehicles, and all three 
are likely to be better suited to the task than is C.

> olcott will likely use this to claim that I support his views.
> He will be wrong.

It hardly matters. A crank is a crank is a crank.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#118652

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 12/05/2025 04:11, 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.)
>
> I was unintentionally ambiguous, for which I apologise.
>
> The point I sought to make is that there is no syntax error (or
> constraint violation) so trivial that a compiler is given licence not
> to issue a diagnostic it if it has no other reason so to do.
>
> That is, they are all capable of ticking the box that says 'must issue
> at least one diagnostic'.
>
>> [...]
>> 
>>> 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 was talking about conforming mode, which IIRC (it's been a while) is
> invoked by -W4 (a warning level that I habitually used in the days
> when I still used Microsoft software).
>
>> 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.
>
> Could you crank MSVS up to -W4 (or whatever the max is these days) and
> try again? I hate to impose, but of course it's your own fault for
> qualifying as a competent source. ;-)

It's "/W4".  The default appears to be "/W3".

With "/W4", or even "/Wall", it still doesn't diagnose a stray semicolon
at file scope.  (I wouldn't expect a warning option to be the
incantation that makes the compiler conform to the standard.)

The "/Za" option is supposed to disable language extensions, but it
complains that "'/Za' and '/std:c17' command-line options are
incompatible".

The implementation supports both C and C++.  It seems to treat C as a
second-class citizen.  (I think, but I'm not sure, that a stray
semicolon at file scope is legal in C++; it's called an
"empty-declaration".)

> If it doesn't diagnose at its maximum warning level, then okay, ~I
> lose the syntax battle.

I'd say that Microsoft's compiler loses the syntax battle.

[Remainder read and snipped]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#118653

On 12/05/2025 05:37, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 12/05/2025 04:11, 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.)
>>
>> I was unintentionally ambiguous, for which I apologise.
>>
>> The point I sought to make is that there is no syntax error (or
>> constraint violation) so trivial that a compiler is given licence not
>> to issue a diagnostic it if it has no other reason so to do.
>>
>> That is, they are all capable of ticking the box that says 'must issue
>> at least one diagnostic'.
>>
>>> [...]
>>>
>>>> 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 was talking about conforming mode, which IIRC (it's been a while) is
>> invoked by -W4 (a warning level that I habitually used in the days
>> when I still used Microsoft software).
>>
>>> 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.
>>
>> Could you crank MSVS up to -W4 (or whatever the max is these days) and
>> try again? I hate to impose, but of course it's your own fault for
>> qualifying as a competent source. ;-)
> 
> It's "/W4".

/, yes. I meant /, honest. [Crosses fingers behind back]

>  The default appears to be "/W3".
> 
> With "/W4", or even "/Wall", it still doesn't diagnose a stray semicolon
> at file scope.  (I wouldn't expect a warning option to be the
> incantation that makes the compiler conform to the standard.)
> 
> The "/Za" option

...rings a very faint bell.

> is supposed to disable language extensions,

/Za used to do a fair job. For example, it revealed BCPL comments 
in math.h, back in the day when BCPL comments were a syntax 
error. Irritating because I wanted a clean compile but didn't 
want to hack about in the implementation headers. (I can't 
remember how I solved that - a pragma, possibly.)

> but it
> complains that "'/Za' and '/std:c17' command-line options are
> incompatible".

Ha!

> The implementation supports both C and C++.  It seems to treat C as a
> second-class citizen.

That was always the case, although the rumour is that they're 
taking C conformance more seriously these days. (I heard that 
quite recently. This year, I think.)

>  (I think, but I'm not sure, that a stray
> semicolon at file scope is legal in C++; it's called an
> "empty-declaration".)

I wasted half an hour trying to chase down the same question.

> 
>> If it doesn't diagnose at its maximum warning level, then okay, ~I
>> lose the syntax battle.
> 
> I'd say that Microsoft's compiler loses the syntax battle.

Fair enough. But it does mean that Mr Olcott has a reasonable 
excuse for his code failing to observe a C syntax rule. He should 
still fix it, of course, but I'm not seeing any great interest 
from Mr Olcott in getting the code right.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#118921

On 12/05/2025 05:37, Keith Thompson wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 12/05/2025 04:11, 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.)
>>
>> I was unintentionally ambiguous, for which I apologise.
>>
>> The point I sought to make is that there is no syntax error (or
>> constraint violation) so trivial that a compiler is given licence not
>> to issue a diagnostic it if it has no other reason so to do.
>>
>> That is, they are all capable of ticking the box that says 'must issue
>> at least one diagnostic'.
>>
>>> [...]
>>>
>>>> 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 was talking about conforming mode, which IIRC (it's been a while) is
>> invoked by -W4 (a warning level that I habitually used in the days
>> when I still used Microsoft software).
>>
>>> 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.
>>
>> Could you crank MSVS up to -W4 (or whatever the max is these days) and
>> try again? I hate to impose, but of course it's your own fault for
>> qualifying as a competent source. ;-)
> 
> It's "/W4".  The default appears to be "/W3".

At W4 or Wall I get a messages such as:
1>c:\products\source\scratch10\ctest.c(8): warning C4019: empty statement at global scope
1>c:\products\source\scratch10\ctest.c(12): warning C4019: empty statement at global scope

The help for the error code:

 
<https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4019?view=msvc-170>

> 
> With "/W4", or even "/Wall", it still doesn't diagnose a stray semicolon
> at file scope.  (I wouldn't expect a warning option to be the
> incantation that makes the compiler conform to the standard.)

Eh?  On my system I got the above messages for stray semi-colons.  I'm using VS2017.

> 
> The "/Za" option is supposed to disable language extensions, but it
> complains that "'/Za' and '/std:c17' command-line options are
> incompatible".
> 
> The implementation supports both C and C++.  It seems to treat C as a
> second-class citizen.  (I think, but I'm not sure, that a stray
> semicolon at file scope is legal in C++; it's called an
> "empty-declaration".)
> 
>> If it doesn't diagnose at its maximum warning level, then okay, ~I
>> lose the syntax battle.
> 
> I'd say that Microsoft's compiler loses the syntax battle.
> 
> [Remainder read and snipped]
> 

[toc] | [prev] | [next] | [standalone]

#118925

On 13/05/2025 22:22, Mike Terry wrote:
> On 12/05/2025 05:37, Keith Thompson wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 12/05/2025 04:11, 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.)
>>>
>>> I was unintentionally ambiguous, for which I apologise.
>>>
>>> The point I sought to make is that there is no syntax error (or
>>> constraint violation) so trivial that a compiler is given licence not
>>> to issue a diagnostic it if it has no other reason so to do.
>>>
>>> That is, they are all capable of ticking the box that says 'must issue
>>> at least one diagnostic'.
>>>
>>>> [...]
>>>>
>>>>> 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 was talking about conforming mode, which IIRC (it's been a while) is
>>> invoked by -W4 (a warning level that I habitually used in the days
>>> when I still used Microsoft software).
>>>
>>>> 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.
>>>
>>> Could you crank MSVS up to -W4 (or whatever the max is these days) and
>>> try again? I hate to impose, but of course it's your own fault for
>>> qualifying as a competent source. ;-)
>>
>> It's "/W4".  The default appears to be "/W3".
> 
> At W4 or Wall I get a messages such as:
> 1>c:\products\source\scratch10\ctest.c(8): warning C4019: empty statement at global scope
> 1>c:\products\source\scratch10\ctest.c(12): warning C4019: empty statement at global scope
> 
> The help for the error code:
> 
> 
> <https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4019?view=msvc-170> 
> 
> 
>>
>> With "/W4", or even "/Wall", it still doesn't diagnose a stray semicolon
>> at file scope.  (I wouldn't expect a warning option to be the
>> incantation that makes the compiler conform to the standard.)
> 
> Eh?  On my system I got the above messages for stray semi-colons.  I'm using VS2017.

Oh right - I also had /Za set, and it seems it needs both /W4 and /Za.  I don't have any /std: 
option as it doesn't seem to be valid for VS2017.

> 
>>
>> The "/Za" option is supposed to disable language extensions, but it
>> complains that "'/Za' and '/std:c17' command-line options are
>> incompatible".
>>
>> The implementation supports both C and C++.  It seems to treat C as a
>> second-class citizen.  (I think, but I'm not sure, that a stray
>> semicolon at file scope is legal in C++; it's called an
>> "empty-declaration".)
>>
>>> If it doesn't diagnose at its maximum warning level, then okay, ~I
>>> lose the syntax battle.
>>
>> I'd say that Microsoft's compiler loses the syntax battle.
>>
>> [Remainder read and snipped]
>>

[toc] | [prev] | [next] | [standalone]

#118670

On 5/11/25 10:09 PM, olcott wrote:
> On 5/11/2025 8:37 PM, Richard Damon wrote:
>> On 5/11/25 9:12 PM, olcott wrote:
>>> On 5/11/2025 8:07 PM, Richard Heathfield wrote:
>>>> On 12/05/2025 00:19, Richard Damon wrote:
>>>>> On 5/11/25 5:42 PM, Mr Flibble wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> I am happy with my final solution; I glanced over all your
>>>>>> responses in this thread and they are all invalid.
>>>>>
>>>>>
>>>>> In other words, you are admtting to being happy to be in error.
>>>>
>>>> He has form for placing a finger in each ear and yelling "I'm right 
>>>> I'm right I'm right you're all wrong!"
>>>>
>>>> There's no talking to 2-year-olds.
>>>>
>>>
>>> No one here is using any actual reasoning
>>> in their rebuttals of my work. They rely
>>> on dogma, misdirection, deflection and the
>>> strawman error.
>>>
>>> The last three methods are dishonest.
>>>
>>
>> No, they are responding with rules and definitions from the system in 
>> question,
>>
> 
> A syntax error reporting by one compiler and considered
> irrelevant by another compiler provides zero evidence
> that DDD correctly emulated by some HHH halts.

I wasn't talking about "Syntax Errors".

I was talking about the rules of the field of Computation Theory.

> 
> _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]
> 
> THE ONLY THING THAT SHOWS THIS IS THE IS THE
> COMPLETE SEQUENCE OF EMULATED STEPS WHERE DDD HALTS.

Which is impossble to do as the above is *NOT* a program, as it fails to 
have all the code that it uses.

Sorry, you are just proving you own utter ignorance.


> 
> Because you don't give a rat's ass for the actual
> truth you ignore the actual rebuttal requirements.
> 

No, you are the one ignoring the truth, as you think you can make up 
your own rules.

The rules themselves will judge you and make you concept just lies.

Ignorance is NOT an excuse. Honest mistakes might be forgiven, but 
DELIBERATELY ignoring the truth makes you GUILTY of the LIES you have 
been saying all your life.

DDD, without the HHH that it calls, is just not a program.

If DDD include HHH, then the "input" must contain that too.

Your system just doesn't obey its own rules, and thus is just invalid.

[toc] | [prev] | [next] | [standalone]

#118687

On 5/12/2025 6:51 AM, Richard Damon wrote:
> On 5/11/25 10:09 PM, olcott wrote:
>> On 5/11/2025 8:37 PM, Richard Damon wrote:
>>> On 5/11/25 9:12 PM, olcott wrote:
>>>> On 5/11/2025 8:07 PM, Richard Heathfield wrote:
>>>>> On 12/05/2025 00:19, Richard Damon wrote:
>>>>>> On 5/11/25 5:42 PM, Mr Flibble wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>> I am happy with my final solution; I glanced over all your
>>>>>>> responses in this thread and they are all invalid.
>>>>>>
>>>>>>
>>>>>> In other words, you are admtting to being happy to be in error.
>>>>>
>>>>> He has form for placing a finger in each ear and yelling "I'm right 
>>>>> I'm right I'm right you're all wrong!"
>>>>>
>>>>> There's no talking to 2-year-olds.
>>>>>
>>>>
>>>> No one here is using any actual reasoning
>>>> in their rebuttals of my work. They rely
>>>> on dogma, misdirection, deflection and the
>>>> strawman error.
>>>>
>>>> The last three methods are dishonest.
>>>>
>>>
>>> No, they are responding with rules and definitions from the system in 
>>> question,
>>>
>>
>> A syntax error reporting by one compiler and considered
>> irrelevant by another compiler provides zero evidence
>> that DDD correctly emulated by some HHH halts.
> 
> I wasn't talking about "Syntax Errors".
> 
> I was talking about the rules of the field of Computation Theory.
> 
>>
>> _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]
>>
>> THE ONLY THING THAT SHOWS THIS IS THE IS THE
>> COMPLETE SEQUENCE OF EMULATED STEPS WHERE DDD HALTS.
> 
> Which is impossble to do as the above is *NOT* a program, as it fails to 
> have all the code that it uses.

It need not be a program knucklehead.
Termination analyzers often work on C functions.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#118689

On 5/12/2025 11:48 AM, olcott wrote:
> On 5/12/2025 6:51 AM, Richard Damon wrote:
>> On 5/11/25 10:09 PM, olcott wrote:
>>> On 5/11/2025 8:37 PM, Richard Damon wrote:
>>>> On 5/11/25 9:12 PM, olcott wrote:
>>>>> On 5/11/2025 8:07 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 00:19, Richard Damon wrote:
>>>>>>> On 5/11/25 5:42 PM, Mr Flibble wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>>> I am happy with my final solution; I glanced over all your
>>>>>>>> responses in this thread and they are all invalid.
>>>>>>>
>>>>>>>
>>>>>>> In other words, you are admtting to being happy to be in error.
>>>>>>
>>>>>> He has form for placing a finger in each ear and yelling "I'm 
>>>>>> right I'm right I'm right you're all wrong!"
>>>>>>
>>>>>> There's no talking to 2-year-olds.
>>>>>>
>>>>>
>>>>> No one here is using any actual reasoning
>>>>> in their rebuttals of my work. They rely
>>>>> on dogma, misdirection, deflection and the
>>>>> strawman error.
>>>>>
>>>>> The last three methods are dishonest.
>>>>>
>>>>
>>>> No, they are responding with rules and definitions from the system 
>>>> in question,
>>>>
>>>
>>> A syntax error reporting by one compiler and considered
>>> irrelevant by another compiler provides zero evidence
>>> that DDD correctly emulated by some HHH halts.
>>
>> I wasn't talking about "Syntax Errors".
>>
>> I was talking about the rules of the field of Computation Theory.
>>
>>>
>>> _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]
>>>
>>> THE ONLY THING THAT SHOWS THIS IS THE IS THE
>>> COMPLETE SEQUENCE OF EMULATED STEPS WHERE DDD HALTS.
>>
>> Which is impossble to do as the above is *NOT* a program, as it fails 
>> to have all the code that it uses.
> 
> It need not be a program knucklehead.

In that case, what you're doing has nothing to do with the halting 
problem, as halting is a property of programs / algorithms, not 
individual C functions.

[toc] | [prev] | [next] | [standalone]

#118790

On 5/12/25 11:48 AM, olcott wrote:
> On 5/12/2025 6:51 AM, Richard Damon wrote:
>> On 5/11/25 10:09 PM, olcott wrote:
>>> On 5/11/2025 8:37 PM, Richard Damon wrote:
>>>> On 5/11/25 9:12 PM, olcott wrote:
>>>>> On 5/11/2025 8:07 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 00:19, Richard Damon wrote:
>>>>>>> On 5/11/25 5:42 PM, Mr Flibble wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>>> I am happy with my final solution; I glanced over all your
>>>>>>>> responses in this thread and they are all invalid.
>>>>>>>
>>>>>>>
>>>>>>> In other words, you are admtting to being happy to be in error.
>>>>>>
>>>>>> He has form for placing a finger in each ear and yelling "I'm 
>>>>>> right I'm right I'm right you're all wrong!"
>>>>>>
>>>>>> There's no talking to 2-year-olds.
>>>>>>
>>>>>
>>>>> No one here is using any actual reasoning
>>>>> in their rebuttals of my work. They rely
>>>>> on dogma, misdirection, deflection and the
>>>>> strawman error.
>>>>>
>>>>> The last three methods are dishonest.
>>>>>
>>>>
>>>> No, they are responding with rules and definitions from the system 
>>>> in question,
>>>>
>>>
>>> A syntax error reporting by one compiler and considered
>>> irrelevant by another compiler provides zero evidence
>>> that DDD correctly emulated by some HHH halts.
>>
>> I wasn't talking about "Syntax Errors".
>>
>> I was talking about the rules of the field of Computation Theory.
>>
>>>
>>> _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]
>>>
>>> THE ONLY THING THAT SHOWS THIS IS THE IS THE
>>> COMPLETE SEQUENCE OF EMULATED STEPS WHERE DDD HALTS.
>>
>> Which is impossble to do as the above is *NOT* a program, as it fails 
>> to have all the code that it uses.
> 
> It need not be a program knucklehead.
> Termination analyzers often work on C functions.
> 

Nope, only PROGRAMS. Now, SOME C funcitons are programs (in the 
computation sense) because they include all there code.

You are just showing how little you understand what you have read, 
because you just don't know the meaning of the words you used.

Have you ever ACTUALLY SEEN a paper about a termination analyizer that 
analyized a non-leaf function, without the actual definition of the 
functions it calls?

You are just showing why the world will just ignore everything you have 
said, even the few ideas that might of had some truth in them, becuase 
it is just too much to figure it out. Your signal to noise is so 
negative, it isn't worth the effort.

[toc] | [prev] | [next] | [standalone]

#118507

On 5/11/2025 10:34 AM, Mr Flibble wrote:
> On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
> 
>> For a question to be semantically incorrect, it takes more than just you
>> and your allies to be unhappy with it.
> 
> For a question to be semantically correct, it takes more than just you and
> your allies to be happy with it.
> 
> Your turn, mate.
> 
> /Flibble

For a polar yes/no question to be proven incorrect
only requires that both yes and no are the wrong answer.
Copyright 2015 PL Olcott

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#118516

On 11/05/2025 17:29, olcott wrote:
> On 5/11/2025 10:34 AM, Mr Flibble wrote:
>> On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
>>
>>> For a question to be semantically incorrect, it takes more 
>>> than just you
>>> and your allies to be unhappy with it.
>>
>> For a question to be semantically correct, it takes more than 
>> just you and
>> your allies to be happy with it.
>>
>> Your turn, mate.
>>
>> /Flibble
> 
> For a polar yes/no question to be proven incorrect
> only requires that both yes and no are the wrong answer.

Fair enough.

Definition: YNA - a type of answer that has exactly one of 
exactly two possible values, either 'yes' xor 'no' - not both, 
not neither, and not banana or half-past four.

The two questions I presented upthread, which I'll now label QA 
and QB, are both of type YNA. They are as follows:

QA: "P is a syntactically correct program in some well-defined 
Turing-complete language. Does P stop when it is applied to this 
data X?"

QB: ``Is it possible to write a program that answers QA for 
arbitrary P and arbitrary X?"

For any P and any X, QA has a correct YNA answer. What that 
answer is depends on P and X, but QA(P,X) can correctly answer 
with one valid YNA response or the other.

QB, similarly, asks a YNA question. Either it's possible or it 
isn't. Alan Turing's work on decidability proved that the answer 
is 'no'. Mr Olcott believes that the proof is erroneous, so he 
might prefer to answer 'yes'. But one and only one of those 
answers is correct.

The question, then, is semantically correct in accordance with Mr 
Olcott's criterion.

I find it hard to credit that a grown man needs this stuff 
spelled out, but there it is.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#118702

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 11/05/2025 17:29, olcott wrote:
>> On 5/11/2025 10:34 AM, Mr Flibble wrote:
>>> On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
>>>
>>>> For a question to be semantically incorrect, it takes more than just
>>>> you
>>>> and your allies to be unhappy with it.
>>>
>>> For a question to be semantically correct, it takes more than just you
>>> and
>>> your allies to be happy with it.
>>>
>>> Your turn, mate.
>>>
>>> /Flibble
>> For a polar yes/no question to be proven incorrect
>> only requires that both yes and no are the wrong answer.
>
> Fair enough.
>
> Definition: YNA - a type of answer that has exactly one of exactly two
> possible values, either 'yes' xor 'no' - not both, not neither, and not
> banana or half-past four.
>
> The two questions I presented upthread, which I'll now label QA and QB, are
> both of type YNA. They are as follows:
>
> QA: "P is a syntactically correct program in some well-defined
> Turing-complete language. Does P stop when it is applied to this data
> X?"

Sometimes PO accepts this a yes/no question with a correct answer in
every case and sometimes he does not.  On those days when he does accept
it, he asserts (quite unambiguously -- I can post a direct quote or a
message ID) that no is sometimes the correct answer even when P(X)
halts.

> QB: ``Is it possible to write a program that answers QA for arbitrary P and
> arbitrary X?"
>
> For any P and any X, QA has a correct YNA answer. What that answer is
> depends on P and X, but QA(P,X) can correctly answer with one valid YNA
> response or the other.

But on some days, PO does /not/ accept that there is a correct yes/no
answer to QA in every case.  On those days, he thinks there is a
"pathological input" for which there is no correct answer.

This was a very common problem with students.  They so buy into the
assumption "let H be a TM that decides halting" that they think that H'
and H^ (to use Linz's notation) also exist and so there really is a
concrete string of symbols (the encoding of H^ which I write as [H^])
such that H^([H^]) halts if it doesn't and doesn't halt if it does.

Of course, there are no pathological inputs like this because H does not
exist.  For every TM, M, the machines M' and M^ do indeed exist, [M^]
really is some finite string of symbols and M^([M^]) either halts or it
does not halt.  But because none of the infinite variety of Ms
implements the halting function, there is no paradox or pathological
input anywhere to be seen.

Aside...  Forgive me for repeatedly replying to you.  It's because I
know you from comp.lang.c and because you are, I think, new to this
thread which has been going on for over 20 years.  I think everyone else
here knows the history, but you might not know what PO has said in the
past and, anyway, I think it helps to remind everyone that PO has given
the game away more than once.

All the recent junk using x86 simulations was once very much clearer.
He posted a function:

u32 Halts(u32 P, u32 I)
{
 static u32* execution_trace;
 slave_state->EIP = P;                    // Function to invoke
 while (!Aborted)
 {
   u32 EIP = slave_state->EIP;            // Instruction to be executed
   DebugStep(master_state, slave_state);  // Execute this instruction
   PushBack(local_execution_trace_list, EIP);
   Aborted = Needs_To_Be_Aborted(execution_trace, (u32)Halts);
 }
 return 0;  // Does not halt
END_OF_CODE: // Input has normally terminated
 return 1;
}

and explained that 0 (does not halt) is the correct return for the
classic "confounding input" like so:

  "When we comment out the line of Halts() that tests for its need to
  abort then H_Hat() remains in infinite recursion, proving that its
  abort decision was correct."

All really clear: Halts is correct because it reports on what some other
program would do -- the H_Hat constructed from the modified Halts
function without the like that stops the simulation!

That was way too clear, so we got all more recent guff and, as far as I
know, he no loner ties to justify this ruse quite so explicitly.  His
argument is now that the simulation is correct right up until the point
when it isn't (as Mike Terry demonstrated quite explicitly).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#118710

On 5/12/2025 11:32 AM, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> 
>> On 11/05/2025 17:29, olcott wrote:
>>> On 5/11/2025 10:34 AM, Mr Flibble wrote:
>>>> On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
>>>>
>>>>> For a question to be semantically incorrect, it takes more than just
>>>>> you
>>>>> and your allies to be unhappy with it.
>>>>
>>>> For a question to be semantically correct, it takes more than just you
>>>> and
>>>> your allies to be happy with it.
>>>>
>>>> Your turn, mate.
>>>>
>>>> /Flibble
>>> For a polar yes/no question to be proven incorrect
>>> only requires that both yes and no are the wrong answer.
>>
>> Fair enough.
>>
>> Definition: YNA - a type of answer that has exactly one of exactly two
>> possible values, either 'yes' xor 'no' - not both, not neither, and not
>> banana or half-past four.
>>
>> The two questions I presented upthread, which I'll now label QA and QB, are
>> both of type YNA. They are as follows:
>>
>> QA: "P is a syntactically correct program in some well-defined
>> Turing-complete language. Does P stop when it is applied to this data
>> X?"
> 
> Sometimes PO accepts this a yes/no question with a correct answer in
> every case and sometimes he does not.  On those days when he does accept
> it, he asserts (quite unambiguously -- I can post a direct quote or a
> message ID) that no is sometimes the correct answer even when P(X)
> halts.
> 

The Tarski undefinability theorem totally fails when
it is understood that every form of the Liar Paradox
is simply not a truth bearer, thus the Liar Paradox
must be rejected as not an element of any formal
system of mathematical logic.

>> QB: ``Is it possible to write a program that answers QA for arbitrary P and
>> arbitrary X?"
>>
>> For any P and any X, QA has a correct YNA answer. What that answer is
>> depends on P and X, but QA(P,X) can correctly answer with one valid YNA
>> response or the other.
> 
> But on some days, PO does /not/ accept that there is a correct yes/no
> answer to QA in every case.  On those days, he thinks there is a
> "pathological input" for which there is no correct answer.
> 

I have dropped my other view that that the halting
problem counter-example input is malformed because
its recursive simulation prevents the "do the opposite"
of whatever its corresponding termination analyzer reports
is unreachable code.

> This was a very common problem with students.  They so buy into the
> assumption "let H be a TM that decides halting" that they think that H'
> and H^ (to use Linz's notation) also exist and so there really is a
> concrete string of symbols (the encoding of H^ which I write as [H^])
> such that H^([H^]) halts if it doesn't and doesn't halt if it does.
> 
> Of course, there are no pathological inputs like this because H does not
> exist.  For every TM, M, the machines M' and M^ do indeed exist, [M^]
> really is some finite string of symbols and M^([M^]) either halts or it
> does not halt.  But because none of the infinite variety of Ms
> implements the halting function, there is no paradox or pathological
> input anywhere to be seen.
> 
> Aside...  Forgive me for repeatedly replying to you.  It's because I
> know you from comp.lang.c and because you are, I think, new to this
> thread which has been going on for over 20 years.  I think everyone else
> here knows the history, but you might not know what PO has said in the
> past and, anyway, I think it helps to remind everyone that PO has given
> the game away more than once.
> 
> All the recent junk using x86 simulations was once very much clearer.
> He posted a function:
> 
> u32 Halts(u32 P, u32 I)
> {
>   static u32* execution_trace;
>   slave_state->EIP = P;                    // Function to invoke
>   while (!Aborted)
>   {
>     u32 EIP = slave_state->EIP;            // Instruction to be executed
>     DebugStep(master_state, slave_state);  // Execute this instruction
>     PushBack(local_execution_trace_list, EIP);
>     Aborted = Needs_To_Be_Aborted(execution_trace, (u32)Halts);
>   }
>   return 0;  // Does not halt
> END_OF_CODE: // Input has normally terminated
>   return 1;
> }
> 
> and explained that 0 (does not halt) is the correct return for the
> classic "confounding input" like so:
> 
>    "When we comment out the line of Halts() that tests for its need to
>    abort then H_Hat() remains in infinite recursion, proving that its
>    abort decision was correct."
> 
> All really clear: Halts is correct because it reports on what some other
> program would do -- the H_Hat constructed from the modified Halts
> function without the like that stops the simulation!
> 
> That was way too clear, so we got all more recent guff and, as far as I
> know, he no loner ties to justify this ruse quite so explicitly.  His
> argument is now that the simulation is correct right up until the point
> when it isn't (as Mike Terry demonstrated quite explicitly).
> 

Try to show how the "do the opposite" code
is reachable from DD correctly simulated by HHH.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#118791

On 5/12/25 12:52 PM, olcott wrote:
> On 5/12/2025 11:32 AM, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 11/05/2025 17:29, olcott wrote:
>>>> On 5/11/2025 10:34 AM, Mr Flibble wrote:
>>>>> On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
>>>>>
>>>>>> For a question to be semantically incorrect, it takes more than just
>>>>>> you
>>>>>> and your allies to be unhappy with it.
>>>>>
>>>>> For a question to be semantically correct, it takes more than just you
>>>>> and
>>>>> your allies to be happy with it.
>>>>>
>>>>> Your turn, mate.
>>>>>
>>>>> /Flibble
>>>> For a polar yes/no question to be proven incorrect
>>>> only requires that both yes and no are the wrong answer.
>>>
>>> Fair enough.
>>>
>>> Definition: YNA - a type of answer that has exactly one of exactly two
>>> possible values, either 'yes' xor 'no' - not both, not neither, and not
>>> banana or half-past four.
>>>
>>> The two questions I presented upthread, which I'll now label QA and 
>>> QB, are
>>> both of type YNA. They are as follows:
>>>
>>> QA: "P is a syntactically correct program in some well-defined
>>> Turing-complete language. Does P stop when it is applied to this data
>>> X?"
>>
>> Sometimes PO accepts this a yes/no question with a correct answer in
>> every case and sometimes he does not.  On those days when he does accept
>> it, he asserts (quite unambiguously -- I can post a direct quote or a
>> message ID) that no is sometimes the correct answer even when P(X)
>> halts.
>>
> 
> The Tarski undefinability theorem totally fails when
> it is understood that every form of the Liar Paradox
> is simply not a truth bearer, thus the Liar Paradox
> must be rejected as not an element of any formal
> system of mathematical logic.

Nope. You just don't understand the proof.

In fact, the proof is based on the fact that we MUST reject the Liar 
Paradox, and the existance of a Truth Predicate (as defined) forces us 
(by Godel's proof) to accept it and give it a logic value.

Of course, that is all above your understand, but that doesn't make it 
wrong, it makes YOU wrong.

> 
>>> QB: ``Is it possible to write a program that answers QA for arbitrary 
>>> P and
>>> arbitrary X?"
>>>
>>> For any P and any X, QA has a correct YNA answer. What that answer is
>>> depends on P and X, but QA(P,X) can correctly answer with one valid YNA
>>> response or the other.
>>
>> But on some days, PO does /not/ accept that there is a correct yes/no
>> answer to QA in every case.  On those days, he thinks there is a
>> "pathological input" for which there is no correct answer.
>>
> 
> I have dropped my other view that that the halting
> problem counter-example input is malformed because
> its recursive simulation prevents the "do the opposite"
> of whatever its corresponding termination analyzer reports
> is unreachable code.
> 
>> This was a very common problem with students.  They so buy into the
>> assumption "let H be a TM that decides halting" that they think that H'
>> and H^ (to use Linz's notation) also exist and so there really is a
>> concrete string of symbols (the encoding of H^ which I write as [H^])
>> such that H^([H^]) halts if it doesn't and doesn't halt if it does.
>>
>> Of course, there are no pathological inputs like this because H does not
>> exist.  For every TM, M, the machines M' and M^ do indeed exist, [M^]
>> really is some finite string of symbols and M^([M^]) either halts or it
>> does not halt.  But because none of the infinite variety of Ms
>> implements the halting function, there is no paradox or pathological
>> input anywhere to be seen.
>>
>> Aside...  Forgive me for repeatedly replying to you.  It's because I
>> know you from comp.lang.c and because you are, I think, new to this
>> thread which has been going on for over 20 years.  I think everyone else
>> here knows the history, but you might not know what PO has said in the
>> past and, anyway, I think it helps to remind everyone that PO has given
>> the game away more than once.
>>
>> All the recent junk using x86 simulations was once very much clearer.
>> He posted a function:
>>
>> u32 Halts(u32 P, u32 I)
>> {
>>   static u32* execution_trace;
>>   slave_state->EIP = P;                    // Function to invoke
>>   while (!Aborted)
>>   {
>>     u32 EIP = slave_state->EIP;            // Instruction to be executed
>>     DebugStep(master_state, slave_state);  // Execute this instruction
>>     PushBack(local_execution_trace_list, EIP);
>>     Aborted = Needs_To_Be_Aborted(execution_trace, (u32)Halts);
>>   }
>>   return 0;  // Does not halt
>> END_OF_CODE: // Input has normally terminated
>>   return 1;
>> }
>>
>> and explained that 0 (does not halt) is the correct return for the
>> classic "confounding input" like so:
>>
>>    "When we comment out the line of Halts() that tests for its need to
>>    abort then H_Hat() remains in infinite recursion, proving that its
>>    abort decision was correct."
>>
>> All really clear: Halts is correct because it reports on what some other
>> program would do -- the H_Hat constructed from the modified Halts
>> function without the like that stops the simulation!
>>
>> That was way too clear, so we got all more recent guff and, as far as I
>> know, he no loner ties to justify this ruse quite so explicitly.  His
>> argument is now that the simulation is correct right up until the point
>> when it isn't (as Mike Terry demonstrated quite explicitly).
>>
> 
> Try to show how the "do the opposite" code
> is reachable from DD correctly simulated by HHH.
> 
> int DD()
> {
>    int Halt_Status = HHH(DD);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 

But it doesn't need to be reachable by HHH's partial simulation, it just 
needs to be reachable by the execution of the function.

Since that calls the HHH(DD) that *WILL* return 0 (since that *IS* what 
you claim it is "correctly" doing) and that makes DD Halt.

SInce it halts, HHH was WRONG, and you are shown to be a liar to say it 
was correct. This is not an honest mistake by you, but a reckless 
disregard for the truth, perhaps combined with a mental inability to 
understand the logic of the system, making you just a pathological liar.

[toc] | [prev] | [next] | [standalone]

#118725

On 12/05/2025 17:32, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> 

<snip>

>>
>> QA: "P is a syntactically correct program in some well-defined
>> Turing-complete language. Does P stop when it is applied to this data
>> X?"
> 
> Sometimes PO accepts this a yes/no question with a correct answer in
> every case and sometimes he does not.  On those days when he does accept
> it, he asserts (quite unambiguously -- I can post a direct quote or a
> message ID) that no is sometimes the correct answer even when P(X)
> halts.
> 
>> QB: ``Is it possible to write a program that answers QA for arbitrary P and
>> arbitrary X?"

<snip>

> But on some days, PO does /not/ accept that there is a correct yes/no
> answer to QA in every case.  On those days, he thinks there is a
> "pathological input" for which there is no correct answer.

<foreshadowing>
   Sit up, folks...
</foreshadowing>

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> This was a very common problem with students.  They so buy into the
> assumption "let H be a TM that decides halting" that they think that H'
> and H^ (to use Linz's notation) also exist and so there really is a
> concrete string of symbols (the encoding of H^ which I write as [H^])
> such that H^([H^]) halts if it doesn't and doesn't halt if it does.
> 
> Of course, there are no pathological inputs like this because H does not
> exist.  For every TM, M, the machines M' and M^ do indeed exist, [M^]
> really is some finite string of symbols and M^([M^]) either halts or it
> does not halt.  But because none of the infinite variety of Ms
> implements the halting function, there is no paradox or pathological
> input anywhere to be seen.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Here, Ben cuts straight to the heart of the matter. If you 
haven't got it yet, cut along the plussed lines, optimise the 
font size for one full page, print, and blu-tac the page to your 
fridge.

> Aside...  Forgive me for repeatedly replying to you.

Nothing to forgive.

> It's because I
> know you from comp.lang.c and because you are, I think, new to this
> thread which has been going on for over 20 years.

I am, yes. 20 years, though? Really? That's one hell of a 
filibuster, albeit one that's several decades too late.

> I think everyone else
> here knows the history, but you might not know what PO has said in the
> past and, anyway, I think it helps to remind everyone that PO has given
> the game away more than once.

...which suggests that he may be yanking a 20-year-old chain just 
because he likes to hear it rattle.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#118759

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 12/05/2025 17:32, Ben Bacarisse wrote:
...
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> This was a very common problem with students.  They so buy into the
>> assumption "let H be a TM that decides halting" that they think that H'
>> and H^ (to use Linz's notation) also exist and so there really is a
>> concrete string of symbols (the encoding of H^ which I write as [H^])
>> such that H^([H^]) halts if it doesn't and doesn't halt if it does.
>> Of course, there are no pathological inputs like this because H does not
>> exist.  For every TM, M, the machines M' and M^ do indeed exist, [M^]
>> really is some finite string of symbols and M^([M^]) either halts or it
>> does not halt.  But because none of the infinite variety of Ms
>> implements the halting function, there is no paradox or pathological
>> input anywhere to be seen.
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Here, Ben cuts straight to the heart of the matter.

You are too kind.

...
>> Aside...  Forgive me for repeatedly replying to you.
>
> Nothing to forgive.
>
>> It's because I
>> know you from comp.lang.c and because you are, I think, new to this
>> thread which has been going on for over 20 years.
>
> I am, yes. 20 years, though? Really? That's one hell of a filibuster, albeit
> one that's several decades too late.

The first record I have in my notes is from 2004:

From: "Peter Olcott" <olc...@worldnet.att.net>
Subject: Re: Attempt to Refute the Halting Problem's Refutation
Message-ID: <3qbTc.205522$OB3.200659@bgtnsc05-news.ops.worldnet.att.net>
Date: Fri, 13 Aug 2004 22:38:55 GMT

Statement of what I have achieved
I have correctly refuted each and every mechanism by which the
above statement has been proven to be true. I have not shown that
solving the Halting Problem is possible, merely refuted every proof
that it is impossible.

> ...which suggests that he may be yanking a 20-year-old chain just because he
> likes to hear it rattle.

I would suggest that he is the kind of narcissist that gets his
validation from the status of the people he insults.  I think there is a
name for it, but I forget.  Usenet is their natural home.  Einstein was
wrong, Cantor was wrong, Turing was wrong...

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#118749

On Mon, 2025-05-12 at 17:32 +0100, Ben Bacarisse wrote:
[cut]
> 
> Of course, there are no pathological inputs like this because H does not
> exist.  

That is the key point.
The 'pathological' input D exists only when the assumed halting decider H exists.
D exists AFTER H does, so putting them together to discuss (or to form logical
expression or even 'theorem', maybe) as though both exist at the same time is
very dubious.

Tradition logic is insufficient for math/logic, the foundation of science.
The implication is profound and goes beyond most people thought.

https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
...
Peano's axioms, which are the basis of mathematical logic, have a serious flaw:
Without a termination condition, it is impossible to explain "∞∉ℕ" (if the
definition of numbers relies on Peano's axioms).
This has led to many theories related to infinity, including density and other
laws and logical inferences, to have the same blind spots and mistakes (Personal
opinion: The reasoning/axiomatic system may need to be changed to a procedual
description)...

So, in some POOH's rebuttal (just olcott's text, he don't understand what logic
'if' means) that uses logic (Tarski,Sisper,Russell,PL,...), that logic 
themselves are invalid (I should save the long ellaberation).

In short, my opinion is that TM/algorithm (C/C++/Assembly could and should be 
the language for building theorys of math/CS/..), is the foundation of science
better than contemporary, what-so-called 'strict, consistent/complete' axiomized
system.
Also, this idea can prove Church–Turing thesis: TM cannot be proved to be 
exceeded simply because (current) axiomized system is less powerful than TM.

Back to POOH's pathological input theory:
The pathological input exists is because POOH exists.

[toc] | [prev] | [next] | [standalone]

#118751 — Truthmaker Maximalism and pathological self-reference

On 5/12/2025 5:57 PM, wij wrote:
> On Mon, 2025-05-12 at 17:32 +0100, Ben Bacarisse wrote:
> [cut]
>>
>> Of course, there are no pathological inputs like this because H does not
>> exist.
> 
> That is the key point.
> The 'pathological' input D exists only when the assumed halting decider H exists.
> D exists AFTER H does, so putting them together to discuss (or to form logical
> expression or even 'theorem', maybe) as though both exist at the same time is
> very dubious.
> 
> Tradition logic is insufficient for math/logic, the foundation of science.
> The implication is profound and goes beyond most people thought.
> 
> https://sourceforge.net/projects/cscall/files/MisFiles/RealNumber2-en.txt/download
> ...
> Peano's axioms, which are the basis of mathematical logic, have a serious flaw:
> Without a termination condition, it is impossible to explain "∞∉ℕ" (if the
> definition of numbers relies on Peano's axioms).
> This has led to many theories related to infinity, including density and other
> laws and logical inferences, to have the same blind spots and mistakes (Personal
> opinion: The reasoning/axiomatic system may need to be changed to a procedual
> description)...
> 
> So, in some POOH's rebuttal (just olcott's text, he don't understand what logic
> 'if' means) that uses logic (Tarski,Sisper,Russell,PL,...), that logic
> themselves are invalid (I should save the long ellaberation).
> 
> In short, my opinion is that TM/algorithm (C/C++/Assembly could and should be
> the language for building theorys of math/CS/..), is the foundation of science
> better than contemporary, what-so-called 'strict, consistent/complete' axiomized
> system.
> Also, this idea can prove Church–Turing thesis: TM cannot be proved to be
> exceeded simply because (current) axiomized system is less powerful than TM.
> 
> Back to POOH's pathological input theory:
> The pathological input exists is because POOH exists.
> 

"This sentence is false" is proven by Prolog
to be semantically incorrect because of its
pathological self-reference. Prolog sees this
as infinitely recursive.

Here we are 2000 years after the Liar Paradox
https://en.wikipedia.org/wiki/Liar_paradox#History
And the best minds in the world are at most pretty
sure that it isn't true.

{Truthmaker Maximalism} is the sub-field of philosophy
that should have the answer to this.

"This sentence is not true" has no truthmaker.
"This sentence has no truthmaker" has no truthmaker.

There is no sequence of truth preserving operations
from Basic Facts that derives either sentence.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7  Next page →

Back to top | Article view | comp.theory

csiph-web