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

Started byMr Flibble <flibble@red-dwarf.jmc.corp>
First post2025-05-11 13:21 +0000
Last post2025-05-13 11:27 +0300
Articles 20 on this page of 123 — 11 participants

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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

#118635

Fromolcott <polcott333@gmail.com>
Date2025-05-11 21:53 -0500
Message-ID<vvrnrg$sjai$2@dont-email.me>
In reply to#118632
On 5/11/2025 9:42 PM, dbush wrote:
> On 5/11/2025 10:39 PM, olcott wrote:
>> On 5/11/2025 9:34 PM, dbush wrote:
>>> On 5/11/2025 10:30 PM, olcott wrote:
>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> No one here is using any actual reasoning
>>>>>>>> in their rebuttals of my work.
>>>>>>>
>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>> the rules of its implementation's language standard, 
>>>>>>
>>>>>> My compiler disagrees so I can't fix that.
>>>>>
>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>> writing in C or whether you're not.
>>>>>
>>>>
>>>>
>>>> _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]
>>>>
>>>> When testing the proof-of-concept not one line
>>>> of my code is relevant. The only thing that needs
>>>> be determined is the behavior of DDD under some
>>>> HHH 
>>>
>>> Category error.  Algorithm DDD isn't fully defined until algorithm 
>>> HHH is fully defined.
>>>
>>> So yes the code is relevant.
>>
>> Algorithm HHH is fully defined as an x86 emulator
>> that emulates one or more steps of DDD according
>> to the rules of the x86 language.
> 
> Which means "some HHH" is a category error.  There is only one algorithm 
> HHH and one algorithm DDD.
> 

*You absolutely refuse to get the gist of anything*

There cannot possibly exist an x86 emulator at machine
address 000015d2 that emulates one or more instructions
of DDD according to the rules of the x86 language such
that the correctly emulated DDD reaches its own "ret"
instruction final halt state.


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

#118636

Fromdbush <dbush.mobile@gmail.com>
Date2025-05-11 22:54 -0400
Message-ID<vvrntc$s0mk$7@dont-email.me>
In reply to#118635
On 5/11/2025 10:53 PM, olcott wrote:
> On 5/11/2025 9:42 PM, dbush wrote:
>> On 5/11/2025 10:39 PM, olcott wrote:
>>> On 5/11/2025 9:34 PM, dbush wrote:
>>>> On 5/11/2025 10:30 PM, olcott wrote:
>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>> in their rebuttals of my work.
>>>>>>>>
>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>
>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>
>>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>>> writing in C or whether you're not.
>>>>>>
>>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> When testing the proof-of-concept not one line
>>>>> of my code is relevant. The only thing that needs
>>>>> be determined is the behavior of DDD under some
>>>>> HHH 
>>>>
>>>> Category error.  Algorithm DDD isn't fully defined until algorithm 
>>>> HHH is fully defined.
>>>>
>>>> So yes the code is relevant.
>>>
>>> Algorithm HHH is fully defined as an x86 emulator
>>> that emulates one or more steps of DDD according
>>> to the rules of the x86 language.
>>
>> Which means "some HHH" is a category error.  There is only one 
>> algorithm HHH and one algorithm DDD.
>>
> 
> *You absolutely refuse to get the gist of anything*
> 
> There cannot possibly exist an x86 emulator at machine
> address 000015d2 that emulates one or more instructions
> of DDD 

Changing the input is not allowed.

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

#118639

Fromolcott <polcott333@gmail.com>
Date2025-05-11 21:57 -0500
Message-ID<vvro2s$sjai$4@dont-email.me>
In reply to#118636
On 5/11/2025 9:54 PM, dbush wrote:
> On 5/11/2025 10:53 PM, olcott wrote:
>> On 5/11/2025 9:42 PM, dbush wrote:
>>> On 5/11/2025 10:39 PM, olcott wrote:
>>>> On 5/11/2025 9:34 PM, dbush wrote:
>>>>> On 5/11/2025 10:30 PM, olcott wrote:
>>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>>> in their rebuttals of my work.
>>>>>>>>>
>>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>>
>>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>>
>>>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>>>> writing in C or whether you're not.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> When testing the proof-of-concept not one line
>>>>>> of my code is relevant. The only thing that needs
>>>>>> be determined is the behavior of DDD under some
>>>>>> HHH 
>>>>>
>>>>> Category error.  Algorithm DDD isn't fully defined until algorithm 
>>>>> HHH is fully defined.
>>>>>
>>>>> So yes the code is relevant.
>>>>
>>>> Algorithm HHH is fully defined as an x86 emulator
>>>> that emulates one or more steps of DDD according
>>>> to the rules of the x86 language.
>>>
>>> Which means "some HHH" is a category error.  There is only one 
>>> algorithm HHH and one algorithm DDD.
>>>
>>
>> *You absolutely refuse to get the gist of anything*
>>
>> There cannot possibly exist an x86 emulator at machine
>> address 000015d2 that emulates one or more instructions
>> of DDD 
> 
> Changing the input is not allowed.

I am talking about every element of an infinite set you nitwit.

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

#118640

Fromdbush <dbush.mobile@gmail.com>
Date2025-05-11 22:59 -0400
Message-ID<vvro6m$s0mk$9@dont-email.me>
In reply to#118639
On 5/11/2025 10:57 PM, olcott wrote:
> On 5/11/2025 9:54 PM, dbush wrote:
>> On 5/11/2025 10:53 PM, olcott wrote:
>>> On 5/11/2025 9:42 PM, dbush wrote:
>>>> On 5/11/2025 10:39 PM, olcott wrote:
>>>>> On 5/11/2025 9:34 PM, dbush wrote:
>>>>>> On 5/11/2025 10:30 PM, olcott wrote:
>>>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>>>> in their rebuttals of my work.
>>>>>>>>>>
>>>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>>>
>>>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>>>
>>>>>>>> C compilers are obliged to diagnose syntax errors. If they 
>>>>>>>> don't, they're not-quite-C compilers. You need to decide whether 
>>>>>>>> you're writing in C or whether you're not.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> When testing the proof-of-concept not one line
>>>>>>> of my code is relevant. The only thing that needs
>>>>>>> be determined is the behavior of DDD under some
>>>>>>> HHH 
>>>>>>
>>>>>> Category error.  Algorithm DDD isn't fully defined until algorithm 
>>>>>> HHH is fully defined.
>>>>>>
>>>>>> So yes the code is relevant.
>>>>>
>>>>> Algorithm HHH is fully defined as an x86 emulator
>>>>> that emulates one or more steps of DDD according
>>>>> to the rules of the x86 language.
>>>>
>>>> Which means "some HHH" is a category error.  There is only one 
>>>> algorithm HHH and one algorithm DDD.
>>>>
>>>
>>> *You absolutely refuse to get the gist of anything*
>>>
>>> There cannot possibly exist an x86 emulator at machine
>>> address 000015d2 that emulates one or more instructions
>>> of DDD 
>>
>> Changing the input is not allowed.
> 
> I am talking about every element of an infinite set you nitwit.
> 

And in doing so you're changing the input.

Changing the input is not allowed.

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

#118786

FromRichard Damon <richard@damon-family.org>
Date2025-05-12 21:39 -0400
Message-ID<43370e2aa6b5cd75a3a0b2a5680718bf6aead7c9@i2pn2.org>
In reply to#118639
On 5/11/25 10:57 PM, olcott wrote:
> On 5/11/2025 9:54 PM, dbush wrote:
>> On 5/11/2025 10:53 PM, olcott wrote:
>>> On 5/11/2025 9:42 PM, dbush wrote:
>>>> On 5/11/2025 10:39 PM, olcott wrote:
>>>>> On 5/11/2025 9:34 PM, dbush wrote:
>>>>>> On 5/11/2025 10:30 PM, olcott wrote:
>>>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> <snip>
>>>>>>>>>>
>>>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>>>> in their rebuttals of my work.
>>>>>>>>>>
>>>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>>>
>>>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>>>
>>>>>>>> C compilers are obliged to diagnose syntax errors. If they 
>>>>>>>> don't, they're not-quite-C compilers. You need to decide whether 
>>>>>>>> you're writing in C or whether you're not.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> When testing the proof-of-concept not one line
>>>>>>> of my code is relevant. The only thing that needs
>>>>>>> be determined is the behavior of DDD under some
>>>>>>> HHH 
>>>>>>
>>>>>> Category error.  Algorithm DDD isn't fully defined until algorithm 
>>>>>> HHH is fully defined.
>>>>>>
>>>>>> So yes the code is relevant.
>>>>>
>>>>> Algorithm HHH is fully defined as an x86 emulator
>>>>> that emulates one or more steps of DDD according
>>>>> to the rules of the x86 language.
>>>>
>>>> Which means "some HHH" is a category error.  There is only one 
>>>> algorithm HHH and one algorithm DDD.
>>>>
>>>
>>> *You absolutely refuse to get the gist of anything*
>>>
>>> There cannot possibly exist an x86 emulator at machine
>>> address 000015d2 that emulates one or more instructions
>>> of DDD 
>>
>> Changing the input is not allowed.
> 
> I am talking about every element of an infinite set you nitwit.
> 

None of which get the right answer, as we need to look at each one 
individually, since they all get different inputs (at least if the input 
is legal, and contains all its code).

Sorry, you are just proving that you are telling an INFINITE number of LIES.

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

#118785

FromRichard Damon <richard@damon-family.org>
Date2025-05-12 21:38 -0400
Message-ID<f882aef658889492a5200ea12661740177f9f2cc@i2pn2.org>
In reply to#118635
On 5/11/25 10:53 PM, olcott wrote:
> On 5/11/2025 9:42 PM, dbush wrote:
>> On 5/11/2025 10:39 PM, olcott wrote:
>>> On 5/11/2025 9:34 PM, dbush wrote:
>>>> On 5/11/2025 10:30 PM, olcott wrote:
>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>> in their rebuttals of my work.
>>>>>>>>
>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>
>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>
>>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>>> writing in C or whether you're not.
>>>>>>
>>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> When testing the proof-of-concept not one line
>>>>> of my code is relevant. The only thing that needs
>>>>> be determined is the behavior of DDD under some
>>>>> HHH 
>>>>
>>>> Category error.  Algorithm DDD isn't fully defined until algorithm 
>>>> HHH is fully defined.
>>>>
>>>> So yes the code is relevant.
>>>
>>> Algorithm HHH is fully defined as an x86 emulator
>>> that emulates one or more steps of DDD according
>>> to the rules of the x86 language.
>>
>> Which means "some HHH" is a category error.  There is only one 
>> algorithm HHH and one algorithm DDD.
>>
> 
> *You absolutely refuse to get the gist of anything*
> 
> There cannot possibly exist an x86 emulator at machine
> address 000015d2 that emulates one or more instructions
> of DDD according to the rules of the x86 language such
> that the correctly emulated DDD reaches its own "ret"
> instruction final halt state.
> 
> 


So?

Why does there need to be?

It would only need to be there if you stipulated that you HHH *WAS* a 
correct emulator, but then, as you have proved, it doesn't return an 
answer and thus is not a decider.

Your problem is you seem to not understand that the question put to H is 
an OBJECTIVE question, not based on what "H sees" but about what is just 
true, and that means just by SOME correct emulator (which will do the 
same as direct execution).

You are showing that you just fundamentally don't understand the meaning 
of TRUTH, and think it ok to just lie about things.

You also show you don't understand the basic rules of computation 
theory, and think it ok to just make up your own ideas, which become 
lles when you ignore the instruction that others have given,

IT just shows that you seem to be incapbable of actually following the 
rules of systems, because you are just naturally rebelious, which is 
what is going to put you into that lake of fire.

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

#118846

FromMikko <mikko.levanto@iki.fi>
Date2025-05-13 10:58 +0300
Message-ID<vvuu42$1mmmr$1@dont-email.me>
In reply to#118635
On 2025-05-12 02:53:36 +0000, olcott said:
   ...

>>>> On 5/11/2025 10:30 PM, olcott wrote:

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

> There cannot possibly exist an x86 emulator at machine
> address 000015d2 that emulates one or more instructions
> of DDD according to the rules of the x86 language such
> that the correctly emulated DDD reaches its own "ret"
> instruction final halt state.

Nothing in the above code says that there is not an emulator
there that does exacatly that. It may skip the emulation of
some or all of its own instructions as those are not
instructionos of DDD.

-- 
Mikko

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

#118669

FromRichard Damon <richard@damon-family.org>
Date2025-05-12 07:47 -0400
Message-ID<41dae2a5a7264cb19777d8ab7cae6d15b5d73f07@i2pn2.org>
In reply to#118626
On 5/11/25 10:30 PM, olcott wrote:
> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>> On 12/05/2025 03:05, olcott wrote:
>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>> On 12/05/2025 02:12, olcott wrote:
>>>>
>>>> <snip>
>>>>
>>>>> No one here is using any actual reasoning
>>>>> in their rebuttals of my work.
>>>>
>>>> I have already shown several places where your 'work' violates the 
>>>> rules of its implementation's language standard, 
>>>
>>> My compiler disagrees so I can't fix that.
>>
>> C compilers are obliged to diagnose syntax errors. If they don't, 
>> they're not-quite-C compilers. You need to decide whether you're 
>> writing in C or whether you're not.
>>
> 
> 
> _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]
> 
> When testing the proof-of-concept not one line
> of my code is relevant. The only thing that needs
> be determined is the behavior of DDD under some
> HHH that emulates DDD according to the rules of
> the x86 language.

But then HHH  must do that, and you HHH that answers doesn't.


> 
> The ONLY reason that you or anyone else brings up
> these other things is that you (and they) know that
> I am correct and yet want to dishonestly disagree anyway.
> 

No, you are proving yourself just a stupid liar,

Since the HHH that answers doesn't do a correct eulation of the input, 
having it assume it does is just a LIE.

Remember, "Correct Emulation" includes not stopping until reachine the end.

Yes, as a decider it "must" stop to be one, but that makes it not be the 
correct emulator you assume, so you logic is just the belief in Fairy 
Tales, tales about a Truth Fairy that can make impossible statement be true.

That is your world of LIES.

> This might possibly send you all to actual Hell
> if such a place exists.
> 

No, since we are talking truth. You insistance on holding to lies will 
send you there.

And not beliveing in it won't keep you out of it.

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

#118685

Fromolcott <polcott333@gmail.com>
Date2025-05-12 10:46 -0500
Message-ID<vvt557$14pca$9@dont-email.me>
In reply to#118669
On 5/12/2025 6:47 AM, Richard Damon wrote:
> On 5/11/25 10:30 PM, olcott wrote:
>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>> On 12/05/2025 03:05, olcott wrote:
>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>> No one here is using any actual reasoning
>>>>>> in their rebuttals of my work.
>>>>>
>>>>> I have already shown several places where your 'work' violates the 
>>>>> rules of its implementation's language standard, 
>>>>
>>>> My compiler disagrees so I can't fix that.
>>>
>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>> they're not-quite-C compilers. You need to decide whether you're 
>>> writing in C or whether you're not.
>>>
>>
>>
>> _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]
>>
>> When testing the proof-of-concept not one line
>> of my code is relevant. The only thing that needs
>> be determined is the behavior of DDD under some
>> HHH that emulates DDD according to the rules of
>> the x86 language.
> 
> But then HHH  must do that, and you HHH that answers doesn't.
> 
> 

Of every x86 emulator at machine address 000015d2
that correctly emulates 1 or more instructions of
DDD none of these correctly emulated DDD instances
ever reaches its own "ret" instruction final halt state.

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

#118686

Fromdbush <dbush.mobile@gmail.com>
Date2025-05-12 11:48 -0400
Message-ID<vvt58a$15ceh$4@dont-email.me>
In reply to#118685
On 5/12/2025 11:46 AM, olcott wrote:
> On 5/12/2025 6:47 AM, Richard Damon wrote:
>> On 5/11/25 10:30 PM, olcott wrote:
>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>> On 12/05/2025 03:05, olcott wrote:
>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> No one here is using any actual reasoning
>>>>>>> in their rebuttals of my work.
>>>>>>
>>>>>> I have already shown several places where your 'work' violates the 
>>>>>> rules of its implementation's language standard, 
>>>>>
>>>>> My compiler disagrees so I can't fix that.
>>>>
>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>> writing in C or whether you're not.
>>>>
>>>
>>>
>>> _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]
>>>
>>> When testing the proof-of-concept not one line
>>> of my code is relevant. The only thing that needs
>>> be determined is the behavior of DDD under some
>>> HHH that emulates DDD according to the rules of
>>> the x86 language.
>>
>> But then HHH  must do that, and you HHH that answers doesn't.
>>
>>
> 
> Of every x86 emulator at machine address 000015d2
> that correctly emulates 1 or more instructions of
> DDD none of these correctly emulated DDD instances
> ever reaches its own "ret" instruction final halt state.
> 


Changing the input is not allowed.

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

#118693

Fromolcott <polcott333@gmail.com>
Date2025-05-12 11:03 -0500
Message-ID<vvt64m$14pca$14@dont-email.me>
In reply to#118686
On 5/12/2025 10:48 AM, dbush wrote:
> On 5/12/2025 11:46 AM, olcott wrote:
>> On 5/12/2025 6:47 AM, Richard Damon wrote:
>>> On 5/11/25 10:30 PM, olcott wrote:
>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>> No one here is using any actual reasoning
>>>>>>>> in their rebuttals of my work.
>>>>>>>
>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>> the rules of its implementation's language standard, 
>>>>>>
>>>>>> My compiler disagrees so I can't fix that.
>>>>>
>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>> writing in C or whether you're not.
>>>>>
>>>>
>>>>
>>>> _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]
>>>>
>>>> When testing the proof-of-concept not one line
>>>> of my code is relevant. The only thing that needs
>>>> be determined is the behavior of DDD under some
>>>> HHH that emulates DDD according to the rules of
>>>> the x86 language.
>>>
>>> But then HHH  must do that, and you HHH that answers doesn't.
>>>
>>>
>>
>> Of every x86 emulator at machine address 000015d2
>> that correctly emulates 1 or more instructions of
>> DDD none of these correctly emulated DDD instances
>> ever reaches its own "ret" instruction final halt state.
>>
> 
> 
> Changing the input is not allowed.

Of the infinite set of HHH/DDD pairs that are
being simultaneously evaluated each DDD has
its own unique HHH thus nothing has changed
for this element of the infinite set.



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

#118694

Fromdbush <dbush.mobile@gmail.com>
Date2025-05-12 12:05 -0400
Message-ID<vvt67n$15ceh$7@dont-email.me>
In reply to#118693
On 5/12/2025 12:03 PM, olcott wrote:
> On 5/12/2025 10:48 AM, dbush wrote:
>> On 5/12/2025 11:46 AM, olcott wrote:
>>> On 5/12/2025 6:47 AM, Richard Damon wrote:
>>>> On 5/11/25 10:30 PM, olcott wrote:
>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>> in their rebuttals of my work.
>>>>>>>>
>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>
>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>
>>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>>> writing in C or whether you're not.
>>>>>>
>>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> When testing the proof-of-concept not one line
>>>>> of my code is relevant. The only thing that needs
>>>>> be determined is the behavior of DDD under some
>>>>> HHH that emulates DDD according to the rules of
>>>>> the x86 language.
>>>>
>>>> But then HHH  must do that, and you HHH that answers doesn't.
>>>>
>>>>
>>>
>>> Of every x86 emulator at machine address 000015d2
>>> that correctly emulates 1 or more instructions of
>>> DDD none of these correctly emulated DDD instances
>>> ever reaches its own "ret" instruction final halt state.
>>>
>>
>>
>> Changing the input is not allowed.
> 
> Of the infinite set of HHH/DDD pairs that are
> being simultaneously evaluated each DDD has
> its own unique HHH 

And thus you've changed DDD.

Changing the input is not allowed.

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

#118788

FromRichard Damon <richard@damon-family.org>
Date2025-05-12 21:44 -0400
Message-ID<2ad764cb2ebe0858b1549908f13e9451ab8294dc@i2pn2.org>
In reply to#118693
On 5/12/25 12:03 PM, olcott wrote:
> On 5/12/2025 10:48 AM, dbush wrote:
>> On 5/12/2025 11:46 AM, olcott wrote:
>>> On 5/12/2025 6:47 AM, Richard Damon wrote:
>>>> On 5/11/25 10:30 PM, olcott wrote:
>>>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 03:05, olcott wrote:
>>>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>> No one here is using any actual reasoning
>>>>>>>>> in their rebuttals of my work.
>>>>>>>>
>>>>>>>> I have already shown several places where your 'work' violates 
>>>>>>>> the rules of its implementation's language standard, 
>>>>>>>
>>>>>>> My compiler disagrees so I can't fix that.
>>>>>>
>>>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>>>> writing in C or whether you're not.
>>>>>>
>>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> When testing the proof-of-concept not one line
>>>>> of my code is relevant. The only thing that needs
>>>>> be determined is the behavior of DDD under some
>>>>> HHH that emulates DDD according to the rules of
>>>>> the x86 language.
>>>>
>>>> But then HHH  must do that, and you HHH that answers doesn't.
>>>>
>>>>
>>>
>>> Of every x86 emulator at machine address 000015d2
>>> that correctly emulates 1 or more instructions of
>>> DDD none of these correctly emulated DDD instances
>>> ever reaches its own "ret" instruction final halt state.
>>>
>>
>>
>> Changing the input is not allowed.
> 
> Of the infinite set of HHH/DDD pairs that are
> being simultaneously evaluated each DDD has
> its own unique HHH thus nothing has changed
> for this element of the infinite set.
> 

??? Each DDD has its own HHH which are all differnt.

I guess you are trying to say that all the natural numbers are the same.

Sorry, you are getting dumber and showing how little you understand 
about what you are saying.

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

#118787

FromRichard Damon <richard@damon-family.org>
Date2025-05-12 21:43 -0400
Message-ID<d7f81938689e2ce2621cf7970f7420521e5b93af@i2pn2.org>
In reply to#118685
On 5/12/25 11:46 AM, olcott wrote:
> On 5/12/2025 6:47 AM, Richard Damon wrote:
>> On 5/11/25 10:30 PM, olcott wrote:
>>> On 5/11/2025 9:23 PM, Richard Heathfield wrote:
>>>> On 12/05/2025 03:05, olcott wrote:
>>>>> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>>>>>> On 12/05/2025 02:12, olcott wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>> No one here is using any actual reasoning
>>>>>>> in their rebuttals of my work.
>>>>>>
>>>>>> I have already shown several places where your 'work' violates the 
>>>>>> rules of its implementation's language standard, 
>>>>>
>>>>> My compiler disagrees so I can't fix that.
>>>>
>>>> C compilers are obliged to diagnose syntax errors. If they don't, 
>>>> they're not-quite-C compilers. You need to decide whether you're 
>>>> writing in C or whether you're not.
>>>>
>>>
>>>
>>> _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]
>>>
>>> When testing the proof-of-concept not one line
>>> of my code is relevant. The only thing that needs
>>> be determined is the behavior of DDD under some
>>> HHH that emulates DDD according to the rules of
>>> the x86 language.
>>
>> But then HHH  must do that, and you HHH that answers doesn't.
>>
>>
> 
> Of every x86 emulator at machine address 000015d2
> that correctly emulates 1 or more instructions of
> DDD none of these correctly emulated DDD instances
> ever reaches its own "ret" instruction final halt state.
> 

But there is no correct x86 emulator at that machine address, as you 
have stipulated that is HHH, which DOES aboft its emulation.

And the actual criteria doesn't say anything about where the correct 
emulator needs to be, (or even that we use a emulator, we are supposed 
to be looking at the direct execution).

All you are doing is proving that you are nothing but an i=gnorant 
pathological liar that doesn't care about what is actually the correct 
answer or the correct rules.

Sorry, you have made you ideas dead to the word by showing how little 
you understand and how little you care about the truth.

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

#118668

FromRichard Damon <richard@damon-family.org>
Date2025-05-12 07:43 -0400
Message-ID<25041b9a3b869085831f110eef49d59fa4e8f5b1@i2pn2.org>
In reply to#118620
On 5/11/25 10:05 PM, olcott wrote:
> On 5/11/2025 8:34 PM, Richard Heathfield wrote:
>> On 12/05/2025 02:12, olcott wrote:
>>
>> <snip>
>>
>>> No one here is using any actual reasoning
>>> in their rebuttals of my work.
>>
>> I have already shown several places where your 'work' violates the 
>> rules of its implementation's language standard, 
> 
> My compiler disagrees so I can't fix that.
> Halt7.c must be compiled with the Microsoft
> compiler to get the correct object file type.
> 

The problem is your compiler doesn't satisfy the requirements of the 
language standard.

And you CAN fix that, at least a lot of it, but using the proper options 
when running it to have it be more conforming.

It seems you like the idea of allowing programs to have undefined 
behavior, which isn't allowed.

But that is because you need to break the rules to make you claims sound 
more likely to not be the lies they are. That is just your nature as a 
pathological liar.

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

#118611

FromRichard Damon <richard@damon-family.org>
Date2025-05-11 21:37 -0400
Message-ID<43f0f4158610d859516ba3e0115a8a2b8bd7630b@i2pn2.org>
In reply to#118604
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,

THAT is honest.

Note, "Dogma" can be truth, when it is pronouncement of the definitions 
of the system.

All you are doing is trying to respond with baseless assertation based 
on equivocations, contradictions, and outright lies.

THAT is just dishonest, and prove that you have no idea about what you 
are talking about.

If you want to try to create a new system, as you sometimes seem to 
imply when you get a bit more honest, you need to be actually honest 
about it, and not pretend that you system is not "the system". You can 
try to work out a real detailed and complete definition of POOPS (Peter 
Olcotts Other Programming System) and then show what it can do, and see 
if you can find any takers willing to see if it is useful.

Until then, you are just proving yourself to be just a blantant liar 
that thinks rules don't apply to him.

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

#118621

Fromolcott <polcott333@gmail.com>
Date2025-05-11 21:09 -0500
Message-ID<vvrl9h$o2ab$6@dont-email.me>
In reply to#118611
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.

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

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

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

#118629

FromRichard Heathfield <rjh@cpax.org.uk>
Date2025-05-12 03:37 +0100
Message-ID<vvrmso$nt1l$2@dont-email.me>
In reply to#118621
On 12/05/2025 03:09, 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

ALL C compilers are required to diagnose ALL syntax errors and 
ALL constraint violations.

> and considered
> irrelevant by another compiler

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.

> provides zero evidence
> that DDD correctly emulated by some HHH halts.

Oh, we're a /long/ way off that. We've got all the dodgy derefs 
to fix first.

<snip>

> Because you don't give a rat's ass for the actual
> truth

We've known the truth for 90 years, and there's no 'actual truth' 
about a buggy program that gives the wrong answer.

> you ignore the actual rebuttal requirements.

You mean like your ignoring rebuttals of your dodgy code?

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

#118643

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2025-05-11 20:11 -0700
Message-ID<87frha4j5w.fsf@nosuchdomain.example.com>
In reply to#118629
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.

[...]

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

#118644

Fromolcott <polcott333@gmail.com>
Date2025-05-11 22:32 -0500
Message-ID<vvrq3u$sjai$6@dont-email.me>
In reply to#118643
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]

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.

-- 
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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7  Next page →

Back to top | Article view | comp.theory

csiph-web