Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.math > #640346 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-10-20 22:00 -0500 |
| Last post | 2025-10-22 13:36 -0400 |
| Articles | 20 on this page of 66 — 8 participants |
Back to article view | Back to sci.math
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:00 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-20 23:05 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:13 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-20 23:16 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:25 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-20 23:29 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-21 03:20 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-20 22:29 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 06:56 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 08:25 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 07:48 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 09:00 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 08:47 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 09:50 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 09:25 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Python <jpierre.messager@gmail.com> - 2025-10-22 14:27 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 13:30 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 15:40 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 10:47 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 17:07 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 12:11 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 13:38 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 18:40 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 André G. Isaak <agisaak@gm.invalid> - 2025-10-22 13:24 -0600
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 14:30 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 15:31 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Richard Heathfield <rjh@cpax.org.uk> - 2025-10-22 20:34 +0100
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 19:52 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 15:00 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 20:20 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 15:35 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 16:43 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST olcott <polcott333@gmail.com> - 2025-10-22 16:12 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-22 14:32 -0700
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST dbush <dbush.mobile@gmail.com> - 2025-10-22 17:50 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 23:01 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST olcott <polcott333@gmail.com> - 2025-10-23 09:55 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 16:47 +0000
"there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 12:22 -0500
Re: "there will still be a nested simulation tower" Kaz "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-23 11:50 -0700
Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 21:11 +0000
"there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 17:08 -0500
Re: "there will still be a nested simulation tower" Kaz "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-23 15:21 -0700
Re: "there will still be a nested simulation tower" Kaz "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-23 15:26 -0700
Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-23 18:40 -0400
Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 17:48 -0500
Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-23 19:09 -0400
Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 23:55 +0000
Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 19:00 -0500
Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 23:45 +0000
Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-23 18:51 -0500
Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-23 20:14 -0400
"there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-22 17:14 -0500
Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-22 18:33 -0400
Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 23:15 +0000
Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-22 18:24 -0500
Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-22 20:14 -0400
Re: "there will still be a nested simulation tower" Kaz Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-23 01:22 +0000
Re: "there will still be a nested simulation tower" Kaz olcott <polcott333@gmail.com> - 2025-10-22 20:47 -0500
Re: "there will still be a nested simulation tower" Kaz dbush <dbush.mobile@gmail.com> - 2025-10-22 22:13 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Julio Di Egidio <julio@diegidio.name> - 2025-10-23 08:02 +0200
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-23 09:51 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 olcott <polcott333@gmail.com> - 2025-10-22 14:55 -0500
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 16:24 -0400
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-22 21:55 +0000
Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 dbush <dbush.mobile@gmail.com> - 2025-10-22 13:36 -0400
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-22 12:11 -0500 |
| Message-ID | <10db38t$pbu6$1@dont-email.me> |
| In reply to | #640391 |
On 10/22/2025 12:07 PM, Kaz Kylheku wrote: > On 2025-10-22, olcott <polcott333@gmail.com> wrote: >> On 10/22/2025 10:40 AM, Kaz Kylheku wrote: >>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote: >>>>>> And when I identify a flaw yo simply ignore >>>>>> whatever I say. >>>>> >>>>> Nope; all the ways you say claim you've identified a flaw have been >>>>> dissected by multiple poeple to a much greater detail than they deserve. >>>>> >>>>> It is disingenuous to say that you've simply had your details ignored. >>>>> >>>> >>>> Turing machines in general can only compute mappings >>>> from their inputs. The halting problem requires computing >>>> mappings that in some cases are not provided in the >>>> inputs therefore the halting problem is wrong. >>> >>> The halting problem positively does not propose anything >>> like that, which would be gapingly wrong. >> >> It only seems that way because you are unable to > > No, it doesn't only seem that way. Thanks for playing. > >> provide the actual mapping that the actual input >> to HHH(DD) specifies when DD is simulated by HHH >> according to the semantics of the C language, > > DD is a "finite string input" which specifies a behavior that is > independent of what simulates it, That is stupidly incorrect. That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. -- Copyright 2025 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-10-22 13:38 -0400 |
| Message-ID | <10db4r8$pmc4$5@dont-email.me> |
| In reply to | #640392 |
On 10/22/2025 1:11 PM, olcott wrote: > On 10/22/2025 12:07 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 10:40 AM, Kaz Kylheku wrote: >>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote: >>>>>>> And when I identify a flaw yo simply ignore >>>>>>> whatever I say. >>>>>> >>>>>> Nope; all the ways you say claim you've identified a flaw have been >>>>>> dissected by multiple poeple to a much greater detail than they >>>>>> deserve. >>>>>> >>>>>> It is disingenuous to say that you've simply had your details >>>>>> ignored. >>>>>> >>>>> >>>>> Turing machines in general can only compute mappings >>>>> from their inputs. The halting problem requires computing >>>>> mappings that in some cases are not provided in the >>>>> inputs therefore the halting problem is wrong. >>>> >>>> The halting problem positively does not propose anything >>>> like that, which would be gapingly wrong. >>> >>> It only seems that way because you are unable to >> >> No, it doesn't only seem that way. Thanks for playing. >> >>> provide the actual mapping that the actual input >>> to HHH(DD) specifies when DD is simulated by HHH >>> according to the semantics of the C language, >> >> DD is a "finite string input" which specifies a behavior that is >> independent of what simulates it, > > That is stupidly incorrect. > That DD calls HHH(DD) (its own simulator) IS PART OF > THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. And the fact that HHH(DD) returns 0 causing DD to subsequently halt is also part of the behavior specified by finite string DD.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-22 18:40 +0000 |
| Message-ID | <20251022112453.201@kylheku.com> |
| In reply to | #640392 |
On 2025-10-22, olcott <polcott333@gmail.com> wrote: > On 10/22/2025 12:07 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 10:40 AM, Kaz Kylheku wrote: >>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote: >>>>>>> And when I identify a flaw yo simply ignore >>>>>>> whatever I say. >>>>>> >>>>>> Nope; all the ways you say claim you've identified a flaw have been >>>>>> dissected by multiple poeple to a much greater detail than they deserve. >>>>>> >>>>>> It is disingenuous to say that you've simply had your details ignored. >>>>>> >>>>> >>>>> Turing machines in general can only compute mappings >>>>> from their inputs. The halting problem requires computing >>>>> mappings that in some cases are not provided in the >>>>> inputs therefore the halting problem is wrong. >>>> >>>> The halting problem positively does not propose anything >>>> like that, which would be gapingly wrong. >>> >>> It only seems that way because you are unable to >> >> No, it doesn't only seem that way. Thanks for playing. >> >>> provide the actual mapping that the actual input >>> to HHH(DD) specifies when DD is simulated by HHH >>> according to the semantics of the C language, >> >> DD is a "finite string input" which specifies a behavior that is >> independent of what simulates it, > > That is stupidly incorrect. > That DD calls HHH(DD) (its own simulator) IS PART OF > THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. In no way am I saying that DD is not built on HHH, and does not have a behavior dependent on that of HHH. Why would I ever say that? But that entire bundle is one fixed case DD, with a single behavior, which is a property of DD, which is a finite string. DD can be passed as an argument to any decider, not only HHH. For instance, don't you have a HHH1 such that HHH1(DD) correctly steps DD to the end and returns the correct value 1? DD's behavior is dependent on a decider which it calls; but not dependent on anything which is analyzing DD. Even when those two are the same, they are different instances/activations. DD creates an activation of HHH on whose result it depends. The definition of DD's behavior does not depend on the ongoing activation of something which happens to be analyzing it; it has no knowledge of that. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2025-10-22 13:24 -0600 |
| Message-ID | <10dbb0g$rpuu$1@dont-email.me> |
| In reply to | #640399 |
On 2025-10-22 12:40, Kaz Kylheku wrote: > On 2025-10-22, olcott <polcott333@gmail.com> wrote: >> On 10/22/2025 12:07 PM, Kaz Kylheku wrote: >>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>> On 10/22/2025 10:40 AM, Kaz Kylheku wrote: >>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote: >>>>>>>> And when I identify a flaw yo simply ignore >>>>>>>> whatever I say. >>>>>>> >>>>>>> Nope; all the ways you say claim you've identified a flaw have been >>>>>>> dissected by multiple poeple to a much greater detail than they deserve. >>>>>>> >>>>>>> It is disingenuous to say that you've simply had your details ignored. >>>>>>> >>>>>> >>>>>> Turing machines in general can only compute mappings >>>>>> from their inputs. The halting problem requires computing >>>>>> mappings that in some cases are not provided in the >>>>>> inputs therefore the halting problem is wrong. >>>>> >>>>> The halting problem positively does not propose anything >>>>> like that, which would be gapingly wrong. >>>> >>>> It only seems that way because you are unable to >>> >>> No, it doesn't only seem that way. Thanks for playing. >>> >>>> provide the actual mapping that the actual input >>>> to HHH(DD) specifies when DD is simulated by HHH >>>> according to the semantics of the C language, >>> >>> DD is a "finite string input" which specifies a behavior that is >>> independent of what simulates it, >> >> That is stupidly incorrect. >> That DD calls HHH(DD) (its own simulator) IS PART OF >> THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. > > In no way am I saying that DD is not built on HHH, and > does not have a behavior dependent on that of HHH. > Why would I ever say that? > > But that entire bundle is one fixed case DD, with a single behavior, > which is a property of DD, which is a finite string. I think part of the problem here is that Olcott doesn't grasp that the "finite string input" DD *must* include as a substring the entire description of HHH. André > DD can be passed as an argument to any decider, not only HHH. > > For instance, don't you have a HHH1 such that HHH1(DD) > correctly steps DD to the end and returns the correct value 1? > > DD's behavior is dependent on a decider which it calls; > but not dependent on anything which is analyzing DD. > > Even when those two are the same, they are different > instances/activations. > > DD creates an activation of HHH on whose result it depends. > > The definition of DD's behavior does not depend on the ongoing > activation of something which happens to be analyzing it; > it has no knowledge of that. > -- To email remove 'invalid' & replace 'gm' with well known Google mail service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-22 14:30 -0500 |
| Message-ID | <10dbbc8$rubc$1@dont-email.me> |
| In reply to | #640405 |
On 10/22/2025 2:24 PM, André G. Isaak wrote: > On 2025-10-22 12:40, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 12:07 PM, Kaz Kylheku wrote: >>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>> On 10/22/2025 10:40 AM, Kaz Kylheku wrote: >>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote: >>>>>>>>> And when I identify a flaw yo simply ignore >>>>>>>>> whatever I say. >>>>>>>> >>>>>>>> Nope; all the ways you say claim you've identified a flaw have been >>>>>>>> dissected by multiple poeple to a much greater detail than they >>>>>>>> deserve. >>>>>>>> >>>>>>>> It is disingenuous to say that you've simply had your details >>>>>>>> ignored. >>>>>>>> >>>>>>> >>>>>>> Turing machines in general can only compute mappings >>>>>>> from their inputs. The halting problem requires computing >>>>>>> mappings that in some cases are not provided in the >>>>>>> inputs therefore the halting problem is wrong. >>>>>> >>>>>> The halting problem positively does not propose anything >>>>>> like that, which would be gapingly wrong. >>>>> >>>>> It only seems that way because you are unable to >>>> >>>> No, it doesn't only seem that way. Thanks for playing. >>>> >>>>> provide the actual mapping that the actual input >>>>> to HHH(DD) specifies when DD is simulated by HHH >>>>> according to the semantics of the C language, >>>> >>>> DD is a "finite string input" which specifies a behavior that is >>>> independent of what simulates it, >>> >>> That is stupidly incorrect. >>> That DD calls HHH(DD) (its own simulator) IS PART OF >>> THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. >> >> In no way am I saying that DD is not built on HHH, and >> does not have a behavior dependent on that of HHH. >> Why would I ever say that? >> >> But that entire bundle is one fixed case DD, with a single behavior, >> which is a property of DD, which is a finite string. > > I think part of the problem here is that Olcott doesn't grasp that the > "finite string input" DD *must* include as a substring the entire > description of HHH. > > André > That includes that HHH(DD) keeps simulating yet another instance of itself and DD forever and ever until it fully understands that no simulated DD can possibly ever reach its own final halt state. That five LLM systems immediately understood this and figured it all out on their own seems strong evidence that you are being disingenuous with me right now. -- Copyright 2025 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-10-22 15:31 -0400 |
| Message-ID | <10dbbec$rre0$1@dont-email.me> |
| In reply to | #640406 |
On 10/22/2025 3:30 PM, olcott wrote: > On 10/22/2025 2:24 PM, André G. Isaak wrote: >> On 2025-10-22 12:40, Kaz Kylheku wrote: >>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>> On 10/22/2025 12:07 PM, Kaz Kylheku wrote: >>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/22/2025 10:40 AM, Kaz Kylheku wrote: >>>>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>>>>> On 10/20/2025 10:20 PM, Kaz Kylheku wrote: >>>>>>>>>> And when I identify a flaw yo simply ignore >>>>>>>>>> whatever I say. >>>>>>>>> >>>>>>>>> Nope; all the ways you say claim you've identified a flaw have >>>>>>>>> been >>>>>>>>> dissected by multiple poeple to a much greater detail than they >>>>>>>>> deserve. >>>>>>>>> >>>>>>>>> It is disingenuous to say that you've simply had your details >>>>>>>>> ignored. >>>>>>>>> >>>>>>>> >>>>>>>> Turing machines in general can only compute mappings >>>>>>>> from their inputs. The halting problem requires computing >>>>>>>> mappings that in some cases are not provided in the >>>>>>>> inputs therefore the halting problem is wrong. >>>>>>> >>>>>>> The halting problem positively does not propose anything >>>>>>> like that, which would be gapingly wrong. >>>>>> >>>>>> It only seems that way because you are unable to >>>>> >>>>> No, it doesn't only seem that way. Thanks for playing. >>>>> >>>>>> provide the actual mapping that the actual input >>>>>> to HHH(DD) specifies when DD is simulated by HHH >>>>>> according to the semantics of the C language, >>>>> >>>>> DD is a "finite string input" which specifies a behavior that is >>>>> independent of what simulates it, >>>> >>>> That is stupidly incorrect. >>>> That DD calls HHH(DD) (its own simulator) IS PART OF >>>> THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. >>> >>> In no way am I saying that DD is not built on HHH, and >>> does not have a behavior dependent on that of HHH. >>> Why would I ever say that? >>> >>> But that entire bundle is one fixed case DD, with a single behavior, >>> which is a property of DD, which is a finite string. >> >> I think part of the problem here is that Olcott doesn't grasp that the >> "finite string input" DD *must* include as a substring the entire >> description of HHH. >> >> André >> > > That includes that HHH(DD) keeps simulating yet > another instance of itself and DD forever and ever False, as demonstrated by the fact that HHH(DD) returns.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-10-22 20:34 +0100 |
| Message-ID | <10dbbkn$ro7p$1@dont-email.me> |
| In reply to | #640405 |
On 22/10/2025 20:24, André G. Isaak wrote: > On 2025-10-22 12:40, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 12:07 PM, Kaz Kylheku wrote: <snip> >>>> DD is a "finite string input" which specifies a behavior that is >>>> independent of what simulates it, >>> >>> That is stupidly incorrect. >>> That DD calls HHH(DD) (its own simulator) IS PART OF >>> THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES. >> >> In no way am I saying that DD is not built on HHH, and >> does not have a behavior dependent on that of HHH. >> Why would I ever say that? >> >> But that entire bundle is one fixed case DD, with a single >> behavior, >> which is a property of DD, which is a finite string. > > I think part of the problem here is that Olcott doesn't grasp > that the "finite string input" DD *must* include as a substring > the entire description of HHH. He also seems to be missing the fact that HHH's sole input is a function pointer that it immediately invalidates by casting the pointer into into a uint32_t. HHH's ability to simulate DD is like a dog's walking on his hind legs. It doesn't work well, but you are surprised to find it working at all. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 With apologies to Dr Johnson.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-22 19:52 +0000 |
| Message-ID | <20251022125116.739@kylheku.com> |
| In reply to | #640405 |
On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: > On 2025-10-22 12:40, Kaz Kylheku wrote: >> But that entire bundle is one fixed case DD, with a single behavior, >> which is a property of DD, which is a finite string. > > I think part of the problem here is that Olcott doesn't grasp that the > "finite string input" DD *must* include as a substring the entire > description of HHH. Furthermore, he doesn't get that it doesn't literally have to be HHH, but the same algorithm: a workalike. The HHH analyzing DD's halting could be in C, while the HHH called by DD could be in Python. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-22 15:00 -0500 |
| Message-ID | <10dbd5g$sbbj$3@dont-email.me> |
| In reply to | #640411 |
On 10/22/2025 2:52 PM, Kaz Kylheku wrote: > On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >> On 2025-10-22 12:40, Kaz Kylheku wrote: >>> But that entire bundle is one fixed case DD, with a single behavior, >>> which is a property of DD, which is a finite string. >> >> I think part of the problem here is that Olcott doesn't grasp that the >> "finite string input" DD *must* include as a substring the entire >> description of HHH. > > Furthermore, he doesn't get that it doesn't literally have to be HHH, > but the same algorithm: a workalike. > > The HHH analyzing DD's halting could be in C, while the HHH > called by DD could be in Python. > DD does call HHH(DD) in recursive simulation and you try to get away with lying about it. -- Copyright 2025 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-22 20:20 +0000 |
| Message-ID | <20251022131901.397@kylheku.com> |
| In reply to | #640413 |
On 2025-10-22, olcott <polcott333@gmail.com> wrote: > On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>> But that entire bundle is one fixed case DD, with a single behavior, >>>> which is a property of DD, which is a finite string. >>> >>> I think part of the problem here is that Olcott doesn't grasp that the >>> "finite string input" DD *must* include as a substring the entire >>> description of HHH. >> >> Furthermore, he doesn't get that it doesn't literally have to be HHH, >> but the same algorithm: a workalike. >> >> The HHH analyzing DD's halting could be in C, while the HHH >> called by DD could be in Python. > > DD does call HHH(DD) in recursive simulation > and you try to get away with lying about it. I'm saying that's not a requirement in the halting problem. DD does not have to use that implementation of HHH; it can have its own clean-room implementation and it can be in any language. But nonetheless, yes, there will still be a nested simulation tower. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-22 15:35 -0500 |
| Message-ID | <10dbf5s$t0bv$1@dont-email.me> |
| In reply to | #640416 |
On 10/22/2025 3:20 PM, Kaz Kylheku wrote: > On 2025-10-22, olcott <polcott333@gmail.com> wrote: >> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>> which is a property of DD, which is a finite string. >>>> >>>> I think part of the problem here is that Olcott doesn't grasp that the >>>> "finite string input" DD *must* include as a substring the entire >>>> description of HHH. >>> >>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>> but the same algorithm: a workalike. >>> >>> The HHH analyzing DD's halting could be in C, while the HHH >>> called by DD could be in Python. >> >> DD does call HHH(DD) in recursive simulation >> and you try to get away with lying about it. > > I'm saying that's not a requirement in the halting problem. > Yet again with deflection. That the input to HHH(DD) specfies non-haltin and HHH(DD) correctly reports this proves that the proof does not prove its point or that the halting problem incorrectly requires HHH to report on behavior that the input to HHH(DD) does not specify. > DD does not have to use that implementation of HHH; it can have > its own clean-room implementation and it can be in any language. > > But nonetheless, yes, there will still be a nested simulation tower. > -- Copyright 2025 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-10-22 16:43 -0400 |
| Message-ID | <10dbfme$rre0$5@dont-email.me> |
| In reply to | #640418 |
On 10/22/2025 4:35 PM, olcott wrote: > On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>> which is a property of DD, which is a finite string. >>>>> >>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>> "finite string input" DD *must* include as a substring the entire >>>>> description of HHH. >>>> >>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>> but the same algorithm: a workalike. >>>> >>>> The HHH analyzing DD's halting could be in C, while the HHH >>>> called by DD could be in Python. >>> >>> DD does call HHH(DD) in recursive simulation >>> and you try to get away with lying about it. >> >> I'm saying that's not a requirement in the halting problem. >> > > Yet again with deflection. > That the input to HHH(DD) specfies non-haltin False, as you have admitted otherwise: On 10/20/2025 11:51 PM, olcott wrote: > On 10/20/2025 10:45 PM, dbush wrote: >> And it is a semantic tautology that a finite string description of a >> Turing machine is stipulated to specify all semantic properties of the >> described machine, including whether it halts when executed directly. >> And it is this semantic property that halt deciders are required to >> report on. > > Yes that is all correct
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-22 16:12 -0500 |
| Subject | Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST |
| Message-ID | <10dbhc6$tibf$1@dont-email.me> |
| In reply to | #640416 |
On 10/22/2025 3:20 PM, Kaz Kylheku wrote: > On 2025-10-22, olcott <polcott333@gmail.com> wrote: >> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>> which is a property of DD, which is a finite string. >>>> >>>> I think part of the problem here is that Olcott doesn't grasp that the >>>> "finite string input" DD *must* include as a substring the entire >>>> description of HHH. >>> >>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>> but the same algorithm: a workalike. >>> >>> The HHH analyzing DD's halting could be in C, while the HHH >>> called by DD could be in Python. >> >> DD does call HHH(DD) in recursive simulation >> and you try to get away with lying about it. > > I'm saying that's not a requirement in the halting problem. > > DD does not have to use that implementation of HHH; it can have > its own clean-room implementation and it can be in any language. > > But nonetheless, yes, there will still be a nested simulation tower. > I made sure to read what you said all the way through this time. DD correctly simulated by HHH cannot possibly reach its own final halt state no matter what HHH does. -- Copyright 2025 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-22 14:32 -0700 |
| Subject | Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST |
| Message-ID | <10dbih5$to13$1@dont-email.me> |
| In reply to | #640423 |
On 10/22/2025 2:12 PM, olcott wrote: > On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>> which is a property of DD, which is a finite string. >>>>> >>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>> "finite string input" DD *must* include as a substring the entire >>>>> description of HHH. >>>> >>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>> but the same algorithm: a workalike. >>>> >>>> The HHH analyzing DD's halting could be in C, while the HHH >>>> called by DD could be in Python. >>> >>> DD does call HHH(DD) in recursive simulation >>> and you try to get away with lying about it. >> >> I'm saying that's not a requirement in the halting problem. >> >> DD does not have to use that implementation of HHH; it can have >> its own clean-room implementation and it can be in any language. >> >> But nonetheless, yes, there will still be a nested simulation tower. >> > > I made sure to read what you said all the way through > this time. This time? How many other times do not even read at all? Just a skim, then your self-moron program kicks in? Humm... > DD correctly simulated by HHH cannot possibly > reach its own final halt state no matter what HHH does. > > HHH(DD) can return 0 and DD halts? If not, just say that HHH(DD) always returns 1?
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-10-22 17:50 -0400 |
| Subject | Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST |
| Message-ID | <10dbjjg$u4u3$1@dont-email.me> |
| In reply to | #640423 |
On 10/22/2025 5:12 PM, olcott wrote: > On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>> which is a property of DD, which is a finite string. >>>>> >>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>> "finite string input" DD *must* include as a substring the entire >>>>> description of HHH. >>>> >>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>> but the same algorithm: a workalike. >>>> >>>> The HHH analyzing DD's halting could be in C, while the HHH >>>> called by DD could be in Python. >>> >>> DD does call HHH(DD) in recursive simulation >>> and you try to get away with lying about it. >> >> I'm saying that's not a requirement in the halting problem. >> >> DD does not have to use that implementation of HHH; it can have >> its own clean-room implementation and it can be in any language. >> >> But nonetheless, yes, there will still be a nested simulation tower. >> > > I made sure to read what you said all the way through > this time. DD correctly simulated by HHH Does not exist because HHH aborts > cannot possibly > reach its own final halt state no matter what HHH does. But HHH is an algorithm which means it does exactly one thing and one thing only. Anything else is not HHH.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-22 23:01 +0000 |
| Subject | Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST |
| Message-ID | <20251022155918.251@kylheku.com> |
| In reply to | #640423 |
On 2025-10-22, olcott <polcott333@gmail.com> wrote: > On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>> which is a property of DD, which is a finite string. >>>>> >>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>> "finite string input" DD *must* include as a substring the entire >>>>> description of HHH. >>>> >>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>> but the same algorithm: a workalike. >>>> >>>> The HHH analyzing DD's halting could be in C, while the HHH >>>> called by DD could be in Python. >>> >>> DD does call HHH(DD) in recursive simulation >>> and you try to get away with lying about it. >> >> I'm saying that's not a requirement in the halting problem. >> >> DD does not have to use that implementation of HHH; it can have >> its own clean-room implementation and it can be in any language. >> >> But nonetheless, yes, there will still be a nested simulation tower. >> > > I made sure to read what you said all the way through > this time. DD correctly simulated by HHH cannot possibly > reach its own final halt state no matter what HHH does. The /simulation/ of DD by HHH will not /reproduce/ the halt state of DD, which DD undeniably /has/. DD specifies a procedure that transitions to a terminating state, whether any given simulation of it is carried far enough to show that.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-23 09:55 -0500 |
| Subject | Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST |
| Message-ID | <10ddfl3$1qu47$1@dont-email.me> |
| In reply to | #640433 |
On 10/22/2025 6:01 PM, Kaz Kylheku wrote: > On 2025-10-22, olcott <polcott333@gmail.com> wrote: >> On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>>> which is a property of DD, which is a finite string. >>>>>> >>>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>>> "finite string input" DD *must* include as a substring the entire >>>>>> description of HHH. >>>>> >>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>>> but the same algorithm: a workalike. >>>>> >>>>> The HHH analyzing DD's halting could be in C, while the HHH >>>>> called by DD could be in Python. >>>> >>>> DD does call HHH(DD) in recursive simulation >>>> and you try to get away with lying about it. >>> >>> I'm saying that's not a requirement in the halting problem. >>> >>> DD does not have to use that implementation of HHH; it can have >>> its own clean-room implementation and it can be in any language. >>> >>> But nonetheless, yes, there will still be a nested simulation tower. >>> >> >> I made sure to read what you said all the way through >> this time. DD correctly simulated by HHH cannot possibly >> reach its own final halt state no matter what HHH does. > > The /simulation/ of DD by HHH will not /reproduce/ the halt > state of DD, which DD undeniably /has/. > *Hence the halting problem is wrong* Turing machine deciders only compute the mapping from their finite string inputs to an accept state or reject state on the basis that this input finite string specifies a semantic or syntactic property. This means that the ultimate measure of the behavior that a finite string input D specifies is D correctly simulated by simulating halt decider H. The halting problem requires that halt deciders do what no Turing machine decider can do report on the semantic property of non-inputs. > DD specifies a procedure that transitions to a terminating state, > whether any given simulation of it is carried far enough to show that. -- Copyright 2025 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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-10-23 16:47 +0000 |
| Subject | Re: Never any actual rebuttal to HHH(DD)==0 Since 10/13/2022 --- NST |
| Message-ID | <20251023093909.930@kylheku.com> |
| In reply to | #640455 |
On 2025-10-23, olcott <polcott333@gmail.com> wrote: > On 10/22/2025 6:01 PM, Kaz Kylheku wrote: >> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>>>> which is a property of DD, which is a finite string. >>>>>>> >>>>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>>>> "finite string input" DD *must* include as a substring the entire >>>>>>> description of HHH. >>>>>> >>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>>>> but the same algorithm: a workalike. >>>>>> >>>>>> The HHH analyzing DD's halting could be in C, while the HHH >>>>>> called by DD could be in Python. >>>>> >>>>> DD does call HHH(DD) in recursive simulation >>>>> and you try to get away with lying about it. >>>> >>>> I'm saying that's not a requirement in the halting problem. >>>> >>>> DD does not have to use that implementation of HHH; it can have >>>> its own clean-room implementation and it can be in any language. >>>> >>>> But nonetheless, yes, there will still be a nested simulation tower. >>>> >>> >>> I made sure to read what you said all the way through >>> this time. DD correctly simulated by HHH cannot possibly >>> reach its own final halt state no matter what HHH does. >> >> The /simulation/ of DD by HHH will not /reproduce/ the halt >> state of DD, which DD undeniably /has/. >> > *Hence the halting problem is wrong* The much simpler explanation is that the decider is wrong. By being wrong, it contributes one point of evidence that confirms the theorem. > Turing machine deciders only compute the mapping > from their finite string inputs to an accept state > or reject state on the basis that this input finite > string specifies a semantic or syntactic property. I don't understand what you think you're achieving by repeating this, but its inclusion does mean that your poting has four correct lines, improving its correctness average. > The halting problem requires that halt deciders do what > no Turing machine decider can do report on the semantic > property of non-inputs. It positively doesn't. Even the diagonal cases that defeat deciders are all valid inputs: self-contained finite strings denoting machines, which perpetrate their trick without referencing anything outside of their own description. You are just making up nonsense and presenting without a shred of rational evidence (which, of course, doesn't exist for a falsehood). -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-10-23 12:22 -0500 |
| Subject | "there will still be a nested simulation tower" Kaz |
| Message-ID | <10ddo7r$1v6re$1@dont-email.me> |
| In reply to | #640458 |
On 10/23/2025 11:47 AM, Kaz Kylheku wrote: > On 2025-10-23, olcott <polcott333@gmail.com> wrote: >> On 10/22/2025 6:01 PM, Kaz Kylheku wrote: >>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>> On 10/22/2025 3:20 PM, Kaz Kylheku wrote: >>>>> On 2025-10-22, olcott <polcott333@gmail.com> wrote: >>>>>> On 10/22/2025 2:52 PM, Kaz Kylheku wrote: >>>>>>> On 2025-10-22, André G Isaak <agisaak@gm.invalid> wrote: >>>>>>>> On 2025-10-22 12:40, Kaz Kylheku wrote: >>>>>>>>> But that entire bundle is one fixed case DD, with a single behavior, >>>>>>>>> which is a property of DD, which is a finite string. >>>>>>>> >>>>>>>> I think part of the problem here is that Olcott doesn't grasp that the >>>>>>>> "finite string input" DD *must* include as a substring the entire >>>>>>>> description of HHH. >>>>>>> >>>>>>> Furthermore, he doesn't get that it doesn't literally have to be HHH, >>>>>>> but the same algorithm: a workalike. >>>>>>> >>>>>>> The HHH analyzing DD's halting could be in C, while the HHH >>>>>>> called by DD could be in Python. >>>>>> >>>>>> DD does call HHH(DD) in recursive simulation >>>>>> and you try to get away with lying about it. >>>>> >>>>> I'm saying that's not a requirement in the halting problem. >>>>> >>>>> DD does not have to use that implementation of HHH; it can have >>>>> its own clean-room implementation and it can be in any language. >>>>> >>>>> But nonetheless, yes, there will still be a nested simulation tower. >>>>> >>>> >>>> I made sure to read what you said all the way through >>>> this time. DD correctly simulated by HHH cannot possibly >>>> reach its own final halt state no matter what HHH does. >>> >>> The /simulation/ of DD by HHH will not /reproduce/ the halt >>> state of DD, which DD undeniably /has/. >>> >> *Hence the halting problem is wrong* > > The much simpler explanation is that the decider is wrong. https://www.liarparadox.org/Simple_but_Wrong.png > By being > wrong, it contributes one point of evidence that confirms the theorem. > >> Turing machine deciders only compute the mapping >> from their finite string inputs to an accept state >> or reject state on the basis that this input finite >> string specifies a semantic or syntactic property. > > I don't understand what you think you're achieving by repeating > this, but its inclusion does mean that your poting has four > correct lines, improving its correctness average. > >> The halting problem requires that halt deciders do what >> no Turing machine decider can do report on the semantic >> property of non-inputs. > > It positively doesn't. HHH(DD) does report on the behavior that its actual input actually specifies: On 10/22/2025 3:20 PM, Kaz Kylheku wrote: > there will still be a nested simulation tower The halting problem requires HHH(DD) to report on something else, QED the halting problem is wrong. Turing machine deciders only compute the mapping from their finite string inputs to an accept state or reject state on the basis that this input finite string specifies a semantic or syntactic property. This means that the ultimate measure of the behavior that a finite string input D specifies is D correctly simulated by simulating halt decider H. The halting problem requires that halt deciders do what no Turing machine decider can do report on the semantic property of non-inputs. > Even the diagonal cases that defeat deciders are skipping over examining the actual underlying details > all valid inputs: self-contained finite strings denoting machines, which > perpetrate their trick without referencing anything outside of their own > description. > > You are just making up nonsense and presenting without a shred of > rational evidence (which, of course, doesn't exist for a falsehood). > -- Copyright 2025 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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-10-23 11:50 -0700 |
| Subject | Re: "there will still be a nested simulation tower" Kaz |
| Message-ID | <10ddtdl$21gl1$1@dont-email.me> |
| In reply to | #640459 |
On 10/23/2025 10:22 AM, olcott wrote: [....] > HHH(DD) does report on the behavior that its actual > input actually specifies: Can your HHH(DD) hit all possible paths of DD? Keep in mind that DD's behavior is dependent on the return value of HHH(DD), right? [...]
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | sci.math
csiph-web