Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #118475 > unrolled thread
| Started by | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| First post | 2025-05-11 13:21 +0000 |
| Last post | 2025-05-13 11:27 +0300 |
| Articles | 20 on this page of 123 — 11 participants |
Back to article view | Back to comp.theory
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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-11 14:10 -0400 |
| Message-ID | <vvqp5p$h4nm$10@dont-email.me> |
| In reply to | #118537 |
On 5/11/2025 1:54 PM, olcott wrote:
> On 5/11/2025 12:49 PM, dbush wrote:
>> On 5/11/2025 1:44 PM, olcott wrote:
>>> On 5/11/2025 12:34 PM, dbush wrote:
>>>> On 5/11/2025 1:14 PM, olcott wrote:
>>>>> On 5/11/2025 11:54 AM, dbush wrote:
>>>>>> On 5/11/2025 12:49 PM, olcott wrote:
>>>>>>> The category error is actually the fact that everyone
>>>>>>> here expects a termination analyzer to report on behavior
>>>>>>> other than the behavior that its input finite string
>>>>>>> actually specifies.
>>>>>>
>>>>>> That's because it's whether or not the algorithm described by the
>>>>>> input halts when executed directly.
>>>>>>
>>>>>> No one cares what "the behavior that its input finite string
>>>>>> specifies" because that's not what we asked about.
>>>>>
>>>>> int sum(int x, int y) { return x + y ; }
>>>>> when you ask about the sum of 5 + 7 using sum(3,2)
>>>>> you are asking the wrong question.
>>>>>
>>>>> HHH reports on the behavior that DDD specifies.
>>>>> sum reports on the sum that its inputs specify.
>>>>>
>>>>
>>>> Category error. (2,3) is not (5,7), but (DDD) is (DDD).
>>>>
>>>
>>> DDD correctly emulated by HHH SPECIFIES RECURSIVE EMULATION
>>> DDD correctly emulated by HHH1 DOES NOT SPECIFY RECURSIVE EMULATION
>>>
>>>
>>>
>>
>> What DDD "specifies" is irrelevent. What matters is what algorithm is
>> described by DDD,
>
> Specifies means provides every single step
> of the entire execution trace.
>
> Describes means to mention some details.
> We could "describe" DDD by saying that DDD
> has the name DDD.
>
False. By definition, a description contains all information necessary
to exactly replicate what was described.
"DDD" describes the fixed code of the function DDD, the fixed code of
the function HHH, and the fixed code of every thing HHH calls down to
the OS level.
That UTM(DDD) exactly replicates the behavior of DDD when executed
directly proves this is an accurate description.
Which means that given the description "DDD", the response is required
to be 1 to meet the requirements:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X
described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 13:18 -0500 |
| Message-ID | <vvqpl2$is9c$1@dont-email.me> |
| In reply to | #118538 |
On 5/11/2025 1:10 PM, dbush wrote:
> On 5/11/2025 1:54 PM, olcott wrote:
>> On 5/11/2025 12:49 PM, dbush wrote:
>>> On 5/11/2025 1:44 PM, olcott wrote:
>>>> On 5/11/2025 12:34 PM, dbush wrote:
>>>>> On 5/11/2025 1:14 PM, olcott wrote:
>>>>>> On 5/11/2025 11:54 AM, dbush wrote:
>>>>>>> On 5/11/2025 12:49 PM, olcott wrote:
>>>>>>>> The category error is actually the fact that everyone
>>>>>>>> here expects a termination analyzer to report on behavior
>>>>>>>> other than the behavior that its input finite string
>>>>>>>> actually specifies.
>>>>>>>
>>>>>>> That's because it's whether or not the algorithm described by the
>>>>>>> input halts when executed directly.
>>>>>>>
>>>>>>> No one cares what "the behavior that its input finite string
>>>>>>> specifies" because that's not what we asked about.
>>>>>>
>>>>>> int sum(int x, int y) { return x + y ; }
>>>>>> when you ask about the sum of 5 + 7 using sum(3,2)
>>>>>> you are asking the wrong question.
>>>>>>
>>>>>> HHH reports on the behavior that DDD specifies.
>>>>>> sum reports on the sum that its inputs specify.
>>>>>>
>>>>>
>>>>> Category error. (2,3) is not (5,7), but (DDD) is (DDD).
>>>>>
>>>>
>>>> DDD correctly emulated by HHH SPECIFIES RECURSIVE EMULATION
>>>> DDD correctly emulated by HHH1 DOES NOT SPECIFY RECURSIVE EMULATION
>>>>
>>>>
>>>>
>>>
>>> What DDD "specifies" is irrelevent. What matters is what algorithm
>>> is described by DDD,
>>
>> Specifies means provides every single step
>> of the entire execution trace.
>>
>> Describes means to mention some details.
>> We could "describe" DDD by saying that DDD
>> has the name DDD.
>>
>
> False. By definition, a description contains all information necessary
> to exactly replicate what was described.
>
> "DDD" describes the fixed code of the function DDD, the fixed code of
> the function HHH, and the fixed code of every thing HHH calls down to
> the OS level.
>
> That UTM(DDD) exactly replicates the behavior of DDD when executed
> directly proves this is an accurate description.
HHH1(DDD) is the fully functional UTM(DDD)
DDD does not specify recursive emulation with HHH1.
DDD is emulated by HHH1 according to the rules of the x86 language
HHH(DDD) DDD specifies recursive emulation with HHH.
DDD is emulated by HHH according to the rules of the x86 language
Everyone merely assumes that I must have made some
mistake somewhere yet is not technically competent
enough to see that there is no mistake.
--
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]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-11 14:21 -0400 |
| Message-ID | <vvqpr1$h4nm$11@dont-email.me> |
| In reply to | #118539 |
On 5/11/2025 2:18 PM, olcott wrote:
> On 5/11/2025 1:10 PM, dbush wrote:
>> On 5/11/2025 1:54 PM, olcott wrote:
>>> On 5/11/2025 12:49 PM, dbush wrote:
>>>> On 5/11/2025 1:44 PM, olcott wrote:
>>>>> On 5/11/2025 12:34 PM, dbush wrote:
>>>>>> On 5/11/2025 1:14 PM, olcott wrote:
>>>>>>> On 5/11/2025 11:54 AM, dbush wrote:
>>>>>>>> On 5/11/2025 12:49 PM, olcott wrote:
>>>>>>>>> The category error is actually the fact that everyone
>>>>>>>>> here expects a termination analyzer to report on behavior
>>>>>>>>> other than the behavior that its input finite string
>>>>>>>>> actually specifies.
>>>>>>>>
>>>>>>>> That's because it's whether or not the algorithm described by
>>>>>>>> the input halts when executed directly.
>>>>>>>>
>>>>>>>> No one cares what "the behavior that its input finite string
>>>>>>>> specifies" because that's not what we asked about.
>>>>>>>
>>>>>>> int sum(int x, int y) { return x + y ; }
>>>>>>> when you ask about the sum of 5 + 7 using sum(3,2)
>>>>>>> you are asking the wrong question.
>>>>>>>
>>>>>>> HHH reports on the behavior that DDD specifies.
>>>>>>> sum reports on the sum that its inputs specify.
>>>>>>>
>>>>>>
>>>>>> Category error. (2,3) is not (5,7), but (DDD) is (DDD).
>>>>>>
>>>>>
>>>>> DDD correctly emulated by HHH SPECIFIES RECURSIVE EMULATION
>>>>> DDD correctly emulated by HHH1 DOES NOT SPECIFY RECURSIVE EMULATION
>>>>>
>>>>>
>>>>>
>>>>
>>>> What DDD "specifies" is irrelevent. What matters is what algorithm
>>>> is described by DDD,
>>>
>>> Specifies means provides every single step
>>> of the entire execution trace.
>>>
>>> Describes means to mention some details.
>>> We could "describe" DDD by saying that DDD
>>> has the name DDD.
>>>
>>
>> False. By definition, a description contains all information
>> necessary to exactly replicate what was described.
>>
>> "DDD" describes the fixed code of the function DDD, the fixed code of
>> the function HHH, and the fixed code of every thing HHH calls down to
>> the OS level.
>>
>> That UTM(DDD) exactly replicates the behavior of DDD when executed
>> directly proves this is an accurate description.
>
> HHH1(DDD) is the fully functional UTM(DDD)
> DDD does not specify recursive emulation with HHH1.
And it describes an algorithm which halts when executed directly.
> DDD is emulated by HHH1 according to the rules of the x86 language
And it does so correctly, showing that the algorithm described halts.
>
> HHH(DDD) DDD specifies recursive emulation with HHH.
But it describes an algorithm which halts when executed directly.
> DDD is emulated by HHH according to the rules of the x86 language
A lie, as you have admitted otherwise on the record:
On 5/5/2025 8:24 AM, dbush wrote:
> On 5/4/2025 11:03 PM, dbush wrote:
>> On 5/4/2025 10:05 PM, olcott wrote:
>>> On 5/4/2025 7:23 PM, Richard Damon wrote:
>>>> But HHH doesn't correct emulated DD by those rules, as those rules
>>>> do not allow HHH to stop its emulation,
>>>
>>> Sure they do you freaking moron...
>>
>> Then show where in the Intel instruction manual that the execution of
>> any instruction other than a HLT is allowed to stop instead of
>> executing the next instruction.
>>
>> Failure to do so in your next reply, or within one hour of your next
>> post on this newsgroup, will be taken as you official on-the-record
>> admission that there is no such allowance and that HHH does NOT
>> correctly simulate DD.
>
> Let the record show that Peter Olcott made the following post in this
> newsgroup after the above message:
>
> On 5/4/2025 11:04 PM, olcott wrote:
> > D *WOULD NEVER STOP RUNNING UNLESS*
> > indicates that professor Sipser was agreeing
> > to hypotheticals AS *NOT CHANGING THE INPUT*
> >
> > You are taking
> > *WOULD NEVER STOP RUNNING UNLESS*
> > to mean *NEVER STOPS RUNNING* that is incorrect.
>
> And has made no attempt after over 9 hours to show where in the Intel
> instruction manual that execution is allowed to stop after any
> instruction other than HLT.
>
> Therefore, as per the above criteria:
>
> LET THE RECORD SHOW
>
> That Peter Olcott
>
> Has *officially* admitted
>
> That DD is NOT correctly simulated by HHH
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-11 19:27 +0100 |
| Message-ID | <vvqq5q$i3hn$5@dont-email.me> |
| In reply to | #118538 |
On 11/05/2025 19:10, dbush wrote:
> On 5/11/2025 1:54 PM, olcott wrote:
>> On 5/11/2025 12:49 PM, dbush wrote:
>>> On 5/11/2025 1:44 PM, olcott wrote:
>>>> On 5/11/2025 12:34 PM, dbush wrote:
>>>>> On 5/11/2025 1:14 PM, olcott wrote:
>>>>>> On 5/11/2025 11:54 AM, dbush wrote:
>>>>>>> On 5/11/2025 12:49 PM, olcott wrote:
>>>>>>>> The category error is actually the fact that everyone
>>>>>>>> here expects a termination analyzer to report on behavior
>>>>>>>> other than the behavior that its input finite string
>>>>>>>> actually specifies.
>>>>>>>
>>>>>>> That's because it's whether or not the algorithm described
>>>>>>> by the input halts when executed directly.
>>>>>>>
>>>>>>> No one cares what "the behavior that its input finite
>>>>>>> string specifies" because that's not what we asked about.
>>>>>>
>>>>>> int sum(int x, int y) { return x + y ; }
>>>>>> when you ask about the sum of 5 + 7 using sum(3,2)
>>>>>> you are asking the wrong question.
>>>>>>
>>>>>> HHH reports on the behavior that DDD specifies.
>>>>>> sum reports on the sum that its inputs specify.
>>>>>>
>>>>>
>>>>> Category error. (2,3) is not (5,7), but (DDD) is (DDD).
>>>>>
>>>>
>>>> DDD correctly emulated by HHH SPECIFIES RECURSIVE EMULATION
>>>> DDD correctly emulated by HHH1 DOES NOT SPECIFY RECURSIVE
>>>> EMULATION
>>>>
>>>>
>>>>
>>>
>>> What DDD "specifies" is irrelevent. What matters is what
>>> algorithm is described by DDD,
>>
>> Specifies means provides every single step
>> of the entire execution trace.
>>
>> Describes means to mention some details.
>> We could "describe" DDD by saying that DDD
>> has the name DDD.
>>
>
> False. By definition, a description contains all information
> necessary to exactly replicate what was described.
By your definition, perhaps, but Mr Olcott's interpretation of
the word is perfectly reasonable, perfectly ordinary, and easy to
justify from the dictionary.
Why not cede this utterly unimportant point instead of fighting a
side-battle you can't win? It hardly matters, after all.
What really matters is this: by simulating DDD, can HHH make
correct predictions of the behaviour DDD exhibits when run
natively? Call it definition or call it description if you will,
but what we're really after is behaviour.
If it can, that will give us a lemma - a staging post for the
next part - but I'm not holding my breath. HHH still has syntax
errors.
--
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]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-11 16:59 +0000 |
| Message-ID | <WH4UP.229898$_Npd.172992@fx01.ams4> |
| In reply to | #118510 |
On Sun, 11 May 2025 11:49:51 -0500, olcott wrote: > On 5/11/2025 11:05 AM, Mr Flibble wrote: >> On Sun, 11 May 2025 10:56:02 -0500, olcott wrote: >> >>> On 5/11/2025 10:49 AM, Mr Flibble wrote: >>>> On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote: >>>> >>>>> On 11/05/2025 16:34, 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. >>>>> >>>>> Indeed. It has to have meaning. It does. That meaning has to be >>>>> understood by sufficiently intelligent people. It is. >>>>> >>>>> You don't like the question. I get that. I don't know /why/ you >>>>> don't like it, because all your explanations to date have been >>>>> complete expletive deleted. For a Usenet article to be semantically >>>>> correct, it helps if your readers can understand what the <exp. >>>>> del.> you're talking about. >>>>> >>>>> What I get from your stand is that you agree with olcott that a >>>>> 'pathological' input halts... no, never halts... well, you can't >>>>> decide between you, but you're agreed that it's definitely >>>>> decidable, right? >>>> >>>> Re-read the OP for my answer: >>>> >>>> Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction >>>> in the Halting Problem >>>> >> =========================================================================================== >>>> >>>> Summary ------- >>>> Flibble argues that the Halting Problem's undecidability proof is >>>> built on a category (type) error: it assumes a program and its own >>>> representation (as a finite string) are interchangeable. This >>>> assumption fails under simulating deciders, revealing a type >>>> distinction through behavioral divergence. As such, all deciders must >>>> respect this boundary, and diagonalization becomes ill-formed. This >>>> reframing dissolves the paradox by making the Halting Problem itself >>>> an ill-posed question. >>>> >>>> 1. Operational Evidence of Type Distinction >>>> ------------------------------------------- >>>> - When a program (e.g., `DD()`) is passed to a simulating halt >>>> decider (`HHH`), it leads to infinite recursion. >>>> - This behavior differs from direct execution (e.g., a crash due to a >>>> stack overflow). >>> >>> The directly executed DD() simply halts because HHH has stopped the >>> infinite recursion that it specifies on its second recursive call. >> >> That behaviour is due to a decision you have made, that I disagree >> with, >> the correct thing to do is to allow infinite recursion to manifest as >> stack overflow rather than return an artificial halting result. >> >> > That fails to meet the spec of a termination analyzer. Nevertheless it is impossible to obtain a halting result as the problem is ill-formed: mapping a halting result of non-halting to the infinite recursion manifesting due to type mismatch is entirely artificial. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 12:06 -0500 |
| Message-ID | <vvqlf0$gldn$16@dont-email.me> |
| In reply to | #118514 |
On 5/11/2025 11:59 AM, Mr Flibble wrote: > On Sun, 11 May 2025 11:49:51 -0500, olcott wrote: > >> On 5/11/2025 11:05 AM, Mr Flibble wrote: >>> On Sun, 11 May 2025 10:56:02 -0500, olcott wrote: >>> >>>> On 5/11/2025 10:49 AM, Mr Flibble wrote: >>>>> On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote: >>>>> >>>>>> On 11/05/2025 16:34, 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. >>>>>> >>>>>> Indeed. It has to have meaning. It does. That meaning has to be >>>>>> understood by sufficiently intelligent people. It is. >>>>>> >>>>>> You don't like the question. I get that. I don't know /why/ you >>>>>> don't like it, because all your explanations to date have been >>>>>> complete expletive deleted. For a Usenet article to be semantically >>>>>> correct, it helps if your readers can understand what the <exp. >>>>>> del.> you're talking about. >>>>>> >>>>>> What I get from your stand is that you agree with olcott that a >>>>>> 'pathological' input halts... no, never halts... well, you can't >>>>>> decide between you, but you're agreed that it's definitely >>>>>> decidable, right? >>>>> >>>>> Re-read the OP for my answer: >>>>> >>>>> Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction >>>>> in the Halting Problem >>>>> >>> > =========================================================================================== >>>>> >>>>> Summary ------- >>>>> Flibble argues that the Halting Problem's undecidability proof is >>>>> built on a category (type) error: it assumes a program and its own >>>>> representation (as a finite string) are interchangeable. This >>>>> assumption fails under simulating deciders, revealing a type >>>>> distinction through behavioral divergence. As such, all deciders must >>>>> respect this boundary, and diagonalization becomes ill-formed. This >>>>> reframing dissolves the paradox by making the Halting Problem itself >>>>> an ill-posed question. >>>>> >>>>> 1. Operational Evidence of Type Distinction >>>>> ------------------------------------------- >>>>> - When a program (e.g., `DD()`) is passed to a simulating halt >>>>> decider (`HHH`), it leads to infinite recursion. >>>>> - This behavior differs from direct execution (e.g., a crash due to a >>>>> stack overflow). >>>> >>>> The directly executed DD() simply halts because HHH has stopped the >>>> infinite recursion that it specifies on its second recursive call. >>> >>> That behaviour is due to a decision you have made, that I disagree >>> with, >>> the correct thing to do is to allow infinite recursion to manifest as >>> stack overflow rather than return an artificial halting result. >>> >>> >> That fails to meet the spec of a termination analyzer. > > Nevertheless it is impossible to obtain a halting result as the problem is > ill-formed: mapping a halting result of non-halting to the infinite > recursion manifesting due to type mismatch is entirely artificial. > > /Flibble When a simulating termination analyzer examines the behavior that its input actually specifies and reports on this, then in the case of every conventional Halting Problem proof it is correct to reject this input as non-halting. -- 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]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-11 17:15 +0000 |
| Message-ID | <eX4UP.687993$4AM6.454940@fx17.ams4> |
| In reply to | #118517 |
On Sun, 11 May 2025 12:06:40 -0500, olcott wrote: > On 5/11/2025 11:59 AM, Mr Flibble wrote: >> On Sun, 11 May 2025 11:49:51 -0500, olcott wrote: >> >>> On 5/11/2025 11:05 AM, Mr Flibble wrote: >>>> On Sun, 11 May 2025 10:56:02 -0500, olcott wrote: >>>> >>>>> On 5/11/2025 10:49 AM, Mr Flibble wrote: >>>>>> On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote: >>>>>> >>>>>>> On 11/05/2025 16:34, 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. >>>>>>> >>>>>>> Indeed. It has to have meaning. It does. That meaning has to be >>>>>>> understood by sufficiently intelligent people. It is. >>>>>>> >>>>>>> You don't like the question. I get that. I don't know /why/ you >>>>>>> don't like it, because all your explanations to date have been >>>>>>> complete expletive deleted. For a Usenet article to be >>>>>>> semantically correct, it helps if your readers can understand what >>>>>>> the <exp. del.> you're talking about. >>>>>>> >>>>>>> What I get from your stand is that you agree with olcott that a >>>>>>> 'pathological' input halts... no, never halts... well, you can't >>>>>>> decide between you, but you're agreed that it's definitely >>>>>>> decidable, right? >>>>>> >>>>>> Re-read the OP for my answer: >>>>>> >>>>>> Flibble’s Leap: Why Behavioral Divergence Implies a Type >>>>>> Distinction in the Halting Problem >>>>>> >>>>>> >> =========================================================================================== >>>>>> >>>>>> Summary ------- >>>>>> Flibble argues that the Halting Problem's undecidability proof is >>>>>> built on a category (type) error: it assumes a program and its own >>>>>> representation (as a finite string) are interchangeable. This >>>>>> assumption fails under simulating deciders, revealing a type >>>>>> distinction through behavioral divergence. As such, all deciders >>>>>> must respect this boundary, and diagonalization becomes ill-formed. >>>>>> This reframing dissolves the paradox by making the Halting Problem >>>>>> itself an ill-posed question. >>>>>> >>>>>> 1. Operational Evidence of Type Distinction >>>>>> ------------------------------------------- >>>>>> - When a program (e.g., `DD()`) is passed to a simulating halt >>>>>> decider (`HHH`), it leads to infinite recursion. >>>>>> - This behavior differs from direct execution (e.g., a crash due to >>>>>> a stack overflow). >>>>> >>>>> The directly executed DD() simply halts because HHH has stopped the >>>>> infinite recursion that it specifies on its second recursive call. >>>> >>>> That behaviour is due to a decision you have made, that I disagree >>>> with, >>>> the correct thing to do is to allow infinite recursion to manifest as >>>> stack overflow rather than return an artificial halting result. >>>> >>>> >>> That fails to meet the spec of a termination analyzer. >> >> Nevertheless it is impossible to obtain a halting result as the problem >> is ill-formed: mapping a halting result of non-halting to the infinite >> recursion manifesting due to type mismatch is entirely artificial. >> >> /Flibble > > When a simulating termination analyzer examines the behavior that its > input actually specifies and reports on this, then in the case of every > conventional Halting Problem proof it is correct to reject this input as > non-halting. But it would "halt" due to stack overflow if you let the simulation proceed. The truth is it neither halts nor doesn't halt as the question being asked is ill-formed. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 12:19 -0500 |
| Message-ID | <vvqm6g$i5d0$1@dont-email.me> |
| In reply to | #118521 |
On 5/11/2025 12:15 PM, Mr Flibble wrote: > On Sun, 11 May 2025 12:06:40 -0500, olcott wrote: > >> On 5/11/2025 11:59 AM, Mr Flibble wrote: >>> On Sun, 11 May 2025 11:49:51 -0500, olcott wrote: >>> >>>> On 5/11/2025 11:05 AM, Mr Flibble wrote: >>>>> On Sun, 11 May 2025 10:56:02 -0500, olcott wrote: >>>>> >>>>>> On 5/11/2025 10:49 AM, Mr Flibble wrote: >>>>>>> On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote: >>>>>>> >>>>>>>> On 11/05/2025 16:34, 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. >>>>>>>> >>>>>>>> Indeed. It has to have meaning. It does. That meaning has to be >>>>>>>> understood by sufficiently intelligent people. It is. >>>>>>>> >>>>>>>> You don't like the question. I get that. I don't know /why/ you >>>>>>>> don't like it, because all your explanations to date have been >>>>>>>> complete expletive deleted. For a Usenet article to be >>>>>>>> semantically correct, it helps if your readers can understand what >>>>>>>> the <exp. del.> you're talking about. >>>>>>>> >>>>>>>> What I get from your stand is that you agree with olcott that a >>>>>>>> 'pathological' input halts... no, never halts... well, you can't >>>>>>>> decide between you, but you're agreed that it's definitely >>>>>>>> decidable, right? >>>>>>> >>>>>>> Re-read the OP for my answer: >>>>>>> >>>>>>> Flibble’s Leap: Why Behavioral Divergence Implies a Type >>>>>>> Distinction in the Halting Problem >>>>>>> >>>>>>> >>> > =========================================================================================== >>>>>>> >>>>>>> Summary ------- >>>>>>> Flibble argues that the Halting Problem's undecidability proof is >>>>>>> built on a category (type) error: it assumes a program and its own >>>>>>> representation (as a finite string) are interchangeable. This >>>>>>> assumption fails under simulating deciders, revealing a type >>>>>>> distinction through behavioral divergence. As such, all deciders >>>>>>> must respect this boundary, and diagonalization becomes ill-formed. >>>>>>> This reframing dissolves the paradox by making the Halting Problem >>>>>>> itself an ill-posed question. >>>>>>> >>>>>>> 1. Operational Evidence of Type Distinction >>>>>>> ------------------------------------------- >>>>>>> - When a program (e.g., `DD()`) is passed to a simulating halt >>>>>>> decider (`HHH`), it leads to infinite recursion. >>>>>>> - This behavior differs from direct execution (e.g., a crash due to >>>>>>> a stack overflow). >>>>>> >>>>>> The directly executed DD() simply halts because HHH has stopped the >>>>>> infinite recursion that it specifies on its second recursive call. >>>>> >>>>> That behaviour is due to a decision you have made, that I disagree >>>>> with, >>>>> the correct thing to do is to allow infinite recursion to manifest as >>>>> stack overflow rather than return an artificial halting result. >>>>> >>>>> >>>> That fails to meet the spec of a termination analyzer. >>> >>> Nevertheless it is impossible to obtain a halting result as the problem >>> is ill-formed: mapping a halting result of non-halting to the infinite >>> recursion manifesting due to type mismatch is entirely artificial. >>> >>> /Flibble >> >> When a simulating termination analyzer examines the behavior that its >> input actually specifies and reports on this, then in the case of every >> conventional Halting Problem proof it is correct to reject this input as >> non-halting. > > But it would "halt" due to stack overflow if you let the simulation > proceed. > That is not what halting means. Halting means reaching a final halt state and terminating normally. Neither DDD nor DD correctly emulated by HHH can do that. > The truth is it neither halts nor doesn't halt as the question being asked > is ill-formed. > > /Flibble -- 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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-11 18:26 +0100 |
| Message-ID | <vvqmkm$i3hn$3@dont-email.me> |
| In reply to | #118521 |
On 11/05/2025 18:15, Mr Flibble wrote: > The truth is it neither halts nor doesn't halt as the question being asked > is ill-formed. So it's stopped running, but it's started hopping? Your answer is bizarre, but it makes a lot more sense when we realise that you are desperately trying to avoid saying that it's undecidable. -- 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]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-11 17:33 +0000 |
| Message-ID | <3c5UP.70485$v0S.5020@fx14.ams4> |
| In reply to | #118526 |
On Sun, 11 May 2025 18:26:46 +0100, Richard Heathfield wrote: > On 11/05/2025 18:15, Mr Flibble wrote: >> The truth is it neither halts nor doesn't halt as the question being >> asked is ill-formed. > > So it's stopped running, but it's started hopping? > > > Your answer is bizarre, but it makes a lot more sense when we realise > that you are desperately trying to avoid saying that it's undecidable. It is undecidable but not for the reason given by Turing. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-11 18:48 +0100 |
| Message-ID | <vvqnu0$i3hn$4@dont-email.me> |
| In reply to | #118528 |
On 11/05/2025 18:33, Mr Flibble wrote: > On Sun, 11 May 2025 18:26:46 +0100, Richard Heathfield wrote: > >> On 11/05/2025 18:15, Mr Flibble wrote: >>> The truth is it neither halts nor doesn't halt as the question being >>> asked is ill-formed. >> >> So it's stopped running, but it's started hopping? >> >> >> Your answer is bizarre, but it makes a lot more sense when we realise >> that you are desperately trying to avoid saying that it's undecidable. > > It is undecidable Finally! > but not for the reason given by Turing. Pausing only to reflect that in his 1936 paper on computable numbers he didn't use the word 'halt' (not even once), I'll leave it at that and let you think about which reason Turing gave and what issue you have with it. -- 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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-11 18:15 +0100 |
| Message-ID | <vvqm03$i3hn$1@dont-email.me> |
| In reply to | #118514 |
On 11/05/2025 17:59, Mr Flibble wrote: > it is impossible to obtain a halting result That sure looks like a concession that it's impossible to devise an algorithm that will produce a halting result. Well done. We got you there in the end. -- 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]
| From | Mr Flibble <flibble@red-dwarf.jmc.corp> |
|---|---|
| Date | 2025-05-11 17:26 +0000 |
| Message-ID | <g55UP.688178$4AM6.545580@fx17.ams4> |
| In reply to | #118520 |
On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: > On 11/05/2025 17:59, Mr Flibble wrote: >> it is impossible to obtain a halting result > > > That sure looks like a concession that it's impossible to devise an > algorithm that will produce a halting result. > > Well done. We got you there in the end. No. The reason why it is impossible to obtain a halting result for pathological input is not the reason proposed by Turing (i.e. self- referential diagonalization), it is impossible to obtain a halting result for pathological input because the self-referential conflation of decider and input is a category error that prevents us from performing diagonalization. To usefully advance research in this area pathological input needs to be excluded from the set of programs that can be analysed by a decider. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-05-11 18:31 +0100 |
| Message-ID | <vvqmu2$g8ck$6@dont-email.me> |
| In reply to | #118525 |
On 11/05/2025 18:26, Mr Flibble wrote: > On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: > >> On 11/05/2025 17:59, Mr Flibble wrote: >>> it is impossible to obtain a halting result >> >> >> That sure looks like a concession that it's impossible to devise an >> algorithm that will produce a halting result. >> >> Well done. We got you there in the end. > > No. Well, yyeess, actually. > The reason why it is impossible Hold that thought. Never mind the reason for now. We can come to that another time. "...it is impossible..." Precisely. QED^3. > to obtain a halting result for > pathological input is not the reason proposed by Turing (i.e. self- > referential diagonalization), blah blah blah yeah yeah > it is impossible to obtain a halting result So it's undecidable, then? Yeah, I spotted that too. > for pathological input because the self-referential conflation of decider > and input is a category error that prevents us from performing > diagonalization. more blah blah blah yeah yeah -- 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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-11 16:05 -0700 |
| Message-ID | <87o6vy4ulc.fsf@nosuchdomain.example.com> |
| In reply to | #118525 |
Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
> On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote:
>
>> On 11/05/2025 17:59, Mr Flibble wrote:
>>> it is impossible to obtain a halting result
>>
>>
>> That sure looks like a concession that it's impossible to devise an
>> algorithm that will produce a halting result.
>>
>> Well done. We got you there in the end.
>
> No. The reason why it is impossible to obtain a halting result for
> pathological input is not the reason proposed by Turing (i.e. self-
> referential diagonalization), it is impossible to obtain a halting result
> for pathological input because the self-referential conflation of decider
> and input is a category error that prevents us from performing
> diagonalization.
Is it possible to determine whether a given input is "pathological" or not?
> To usefully advance research in this area pathological input needs to be
> excluded from the set of programs that can be analysed by a decider.
Can this exclusion be performed reliably and consistently?
--
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]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 18:14 -0500 |
| Message-ID | <vvrb1g$me5h$2@dont-email.me> |
| In reply to | #118578 |
On 5/11/2025 6:05 PM, Keith Thompson wrote: > Mr Flibble <flibble@red-dwarf.jmc.corp> writes: >> On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: >> >>> On 11/05/2025 17:59, Mr Flibble wrote: >>>> it is impossible to obtain a halting result >>> >>> >>> That sure looks like a concession that it's impossible to devise an >>> algorithm that will produce a halting result. >>> >>> Well done. We got you there in the end. >> >> No. The reason why it is impossible to obtain a halting result for >> pathological input is not the reason proposed by Turing (i.e. self- >> referential diagonalization), it is impossible to obtain a halting result >> for pathological input because the self-referential conflation of decider >> and input is a category error that prevents us from performing >> diagonalization. > > Is it possible to determine whether a given input is "pathological" or not? > >> To usefully advance research in this area pathological input needs to be >> excluded from the set of programs that can be analysed by a decider. > > Can this exclusion be performed reliably and consistently? > That is a good question. The answer is definitely yes. When HHH emulates DDD it only needs to see that DDD is calling itself with no conditional branch instructions inbetween. Whether a function computed by a Turing machine can do this is a different question. -- 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]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 19:45 -0400 |
| Message-ID | <f2bc11d4d57ba6260c0cca597204057a28c8276e@i2pn2.org> |
| In reply to | #118581 |
On 5/11/25 7:14 PM, olcott wrote: > On 5/11/2025 6:05 PM, Keith Thompson wrote: >> Mr Flibble <flibble@red-dwarf.jmc.corp> writes: >>> On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: >>> >>>> On 11/05/2025 17:59, Mr Flibble wrote: >>>>> it is impossible to obtain a halting result >>>> >>>> >>>> That sure looks like a concession that it's impossible to devise an >>>> algorithm that will produce a halting result. >>>> >>>> Well done. We got you there in the end. >>> >>> No. The reason why it is impossible to obtain a halting result for >>> pathological input is not the reason proposed by Turing (i.e. self- >>> referential diagonalization), it is impossible to obtain a halting >>> result >>> for pathological input because the self-referential conflation of >>> decider >>> and input is a category error that prevents us from performing >>> diagonalization. >> >> Is it possible to determine whether a given input is "pathological" or >> not? >> >>> To usefully advance research in this area pathological input needs to be >>> excluded from the set of programs that can be analysed by a decider. >> >> Can this exclusion be performed reliably and consistently? >> > > That is a good question. The answer is definitely > yes. When HHH emulates DDD it only needs to see > that DDD is calling itself with no conditional branch > instructions inbetween. > > Whether a function computed by a Turing machine can > do this is a different question. > So, try to do it. Note, if your system *IS* the equivalent of a Turing Machine, then if yours can do it so can a Turing Machine. The problem is that you system is NOT the equivalent of the pair of Turing Machines, and you have even made stipulations that prove that your system is less than Turing Complete. The key problem is that you have inforced a restriction that the function HHH can not be "cloned" as can be done in a real Turing System. If I can make an equvalent copy of the code of HHH (and perhaps make some cosmetic but not functional changing) then HHH can not detect that operation. This is of course, beyond your comprehension.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-05-11 19:41 -0500 |
| Message-ID | <vvrg32$n9a9$2@dont-email.me> |
| In reply to | #118589 |
On 5/11/2025 6:45 PM, Richard Damon wrote: > On 5/11/25 7:14 PM, olcott wrote: >> On 5/11/2025 6:05 PM, Keith Thompson wrote: >>> Mr Flibble <flibble@red-dwarf.jmc.corp> writes: >>>> On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: >>>> >>>>> On 11/05/2025 17:59, Mr Flibble wrote: >>>>>> it is impossible to obtain a halting result >>>>> >>>>> >>>>> That sure looks like a concession that it's impossible to devise an >>>>> algorithm that will produce a halting result. >>>>> >>>>> Well done. We got you there in the end. >>>> >>>> No. The reason why it is impossible to obtain a halting result for >>>> pathological input is not the reason proposed by Turing (i.e. self- >>>> referential diagonalization), it is impossible to obtain a halting >>>> result >>>> for pathological input because the self-referential conflation of >>>> decider >>>> and input is a category error that prevents us from performing >>>> diagonalization. >>> >>> Is it possible to determine whether a given input is "pathological" >>> or not? >>> >>>> To usefully advance research in this area pathological input needs >>>> to be >>>> excluded from the set of programs that can be analysed by a decider. >>> >>> Can this exclusion be performed reliably and consistently? >>> >> >> That is a good question. The answer is definitely >> yes. When HHH emulates DDD it only needs to see >> that DDD is calling itself with no conditional branch >> instructions inbetween. >> >> Whether a function computed by a Turing machine can >> do this is a different question. >> > > So, try to do it. > No need to. DDD emulated by HHH according to the rules of the computational language that DD is encoded within already proves that the HP "impossible" input specifies a non-halting sequence of configurations. This by itself is much more progress than anyone else has ever made on the halting problem. To the best of my recollection Mike has already agreed that the outermost HHH can dig into the details of all of the levels of recursive simulation to get the details that it currently uses. All of these details are merely data to this outermost HHH. This is analogous to a master UTM examining all of its own tape, even those portions that are allocated to slave UTMs. -- 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]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-05-11 20:43 -0400 |
| Message-ID | <vvrg7j$mv2a$2@dont-email.me> |
| In reply to | #118594 |
On 5/11/2025 8:41 PM, olcott wrote: > On 5/11/2025 6:45 PM, Richard Damon wrote: >> On 5/11/25 7:14 PM, olcott wrote: >>> On 5/11/2025 6:05 PM, Keith Thompson wrote: >>>> Mr Flibble <flibble@red-dwarf.jmc.corp> writes: >>>>> On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: >>>>> >>>>>> On 11/05/2025 17:59, Mr Flibble wrote: >>>>>>> it is impossible to obtain a halting result >>>>>> >>>>>> >>>>>> That sure looks like a concession that it's impossible to devise an >>>>>> algorithm that will produce a halting result. >>>>>> >>>>>> Well done. We got you there in the end. >>>>> >>>>> No. The reason why it is impossible to obtain a halting result for >>>>> pathological input is not the reason proposed by Turing (i.e. self- >>>>> referential diagonalization), it is impossible to obtain a halting >>>>> result >>>>> for pathological input because the self-referential conflation of >>>>> decider >>>>> and input is a category error that prevents us from performing >>>>> diagonalization. >>>> >>>> Is it possible to determine whether a given input is "pathological" >>>> or not? >>>> >>>>> To usefully advance research in this area pathological input needs >>>>> to be >>>>> excluded from the set of programs that can be analysed by a decider. >>>> >>>> Can this exclusion be performed reliably and consistently? >>>> >>> >>> That is a good question. The answer is definitely >>> yes. When HHH emulates DDD it only needs to see >>> that DDD is calling itself with no conditional branch >>> instructions inbetween. >>> >>> Whether a function computed by a Turing machine can >>> do this is a different question. >>> >> >> So, try to do it. >> > > No need to. DDD emulated by HHH according to the > rules of the computational language that DD is > encoded within Doesn't happen, as you have admitted on the record: On 5/5/2025 8:24 AM, dbush wrote: > On 5/4/2025 11:03 PM, dbush wrote: >> On 5/4/2025 10:05 PM, olcott wrote: >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>> But HHH doesn't correct emulated DD by those rules, as those rules >>>> do not allow HHH to stop its emulation, >>> >>> Sure they do you freaking moron... >> >> Then show where in the Intel instruction manual that the execution of >> any instruction other than a HLT is allowed to stop instead of >> executing the next instruction. >> >> Failure to do so in your next reply, or within one hour of your next >> post on this newsgroup, will be taken as you official on-the-record >> admission that there is no such allowance and that HHH does NOT >> correctly simulate DD. > > Let the record show that Peter Olcott made the following post in this > newsgroup after the above message: > > On 5/4/2025 11:04 PM, olcott wrote: > > D *WOULD NEVER STOP RUNNING UNLESS* > > indicates that professor Sipser was agreeing > > to hypotheticals AS *NOT CHANGING THE INPUT* > > > > You are taking > > *WOULD NEVER STOP RUNNING UNLESS* > > to mean *NEVER STOPS RUNNING* that is incorrect. > > And has made no attempt after over 9 hours to show where in the Intel > instruction manual that execution is allowed to stop after any > instruction other than HLT. > > Therefore, as per the above criteria: > > LET THE RECORD SHOW > > That Peter Olcott > > Has *officially* admitted > > That DD is NOT correctly simulated by HHH
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2025-05-11 21:13 -0400 |
| Message-ID | <faa0eeeda0e841eacce5537fc2a994b6be9d73f9@i2pn2.org> |
| In reply to | #118594 |
On 5/11/25 8:41 PM, olcott wrote: > On 5/11/2025 6:45 PM, Richard Damon wrote: >> On 5/11/25 7:14 PM, olcott wrote: >>> On 5/11/2025 6:05 PM, Keith Thompson wrote: >>>> Mr Flibble <flibble@red-dwarf.jmc.corp> writes: >>>>> On Sun, 11 May 2025 18:15:47 +0100, Richard Heathfield wrote: >>>>> >>>>>> On 11/05/2025 17:59, Mr Flibble wrote: >>>>>>> it is impossible to obtain a halting result >>>>>> >>>>>> >>>>>> That sure looks like a concession that it's impossible to devise an >>>>>> algorithm that will produce a halting result. >>>>>> >>>>>> Well done. We got you there in the end. >>>>> >>>>> No. The reason why it is impossible to obtain a halting result for >>>>> pathological input is not the reason proposed by Turing (i.e. self- >>>>> referential diagonalization), it is impossible to obtain a halting >>>>> result >>>>> for pathological input because the self-referential conflation of >>>>> decider >>>>> and input is a category error that prevents us from performing >>>>> diagonalization. >>>> >>>> Is it possible to determine whether a given input is "pathological" >>>> or not? >>>> >>>>> To usefully advance research in this area pathological input needs >>>>> to be >>>>> excluded from the set of programs that can be analysed by a decider. >>>> >>>> Can this exclusion be performed reliably and consistently? >>>> >>> >>> That is a good question. The answer is definitely >>> yes. When HHH emulates DDD it only needs to see >>> that DDD is calling itself with no conditional branch >>> instructions inbetween. >>> >>> Whether a function computed by a Turing machine can >>> do this is a different question. >>> >> >> So, try to do it. >> > > No need to. DDD emulated by HHH according to the > rules of the computational language that DD is > encoded within already proves that the HP > "impossible" input specifies a non-halting > sequence of configurations. So, you are admitting you can't. The rules of computation language say that HHH must be a funciton of *OMLY* it explict input, and thus for HHH to actually emulate DDD, then the HHH that DDD calls must be part of the input (and part of DDD). Since none of your HHH's that give an answer actually DO a correct emulation, and that is the only kind really accept by computational language (without the EXPLICT partial modifier), your statement is just a NULL statement that doesn't say anything. Since the CORRECT emulation of DDD by the rules you require (minus the invalid restriction that it be by a machine that can't do it) shows that DDD WILL halt for any of your HHH that return an answer, so every HHH(DDD) that returns 0 is just wrong. > > This by itself is much more progress than anyone > else has ever made on the halting problem. > Nope, as it is just lies. > To the best of my recollection > Mike has already agreed that the outermost HHH > can dig into the details of all of the levels > of recursive simulation to get the details that > it currently uses. All of these details are > merely data to this outermost HHH. > > This is analogous to a master UTM examining > all of its own tape, even those portions that > are allocated to slave UTMs. > Which doesn't help, since you don't actually have any UTMs. Remember, BY DEFINITON, a UTM just reproduces the behavior of the machine described by its input. Not report what it does, but to DO it. So, BY DEFINITION, a UTM given a non-halting input, can not halt. And thus, a UTM can't be used as a decider if the input can be a non-halting program, and thus worthless as a Halt Decider. Remember, one way of stateing the requirements of a Halt Decider is that H(D) returns "Halting" if UTM(D) will halt, and "Non-Halting" if UTM(D) will not halt. THis does not mean change D to use UTM, it mean the exact D that was given to H is given to UTM, and NONE of the code used by it changes. The fact that you model can't seem to handle that just shows your model is incorrect. And yes, the outer Decider can try to understand the contents and meaning of the tape of the machine it is emulating, but first you have to show how it recognizes that machine, when you don't put non-Turing Complete limitations on your programs like you do. This means that DDD can have its own copy of HHH and thus HHH can't use its address as the test, and DDD needs to be able to make a copy of its input at another portion of the tape (new memory addresses in your system). Try to allow that and see what you get. The fact that your system fails to be Turing Complete just proves that it can't be the equivalent of the systems in the proof.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web