Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.math > #640762 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2025-11-14 09:00 -0600 |
| Last post | 2025-11-28 11:01 -0500 |
| Articles | 20 on this page of 81 — 7 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.
The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-14 09:00 -0600
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-17 07:31 -0600
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-17 07:31 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-26 12:01 +0200
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 09:17 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-26 10:29 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 18:35 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 13:55 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 14:58 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 21:47 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 15:53 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 22:19 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 16:48 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 18:00 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-26 23:55 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 18:20 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 00:39 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 18:51 -0600
Re: The halting problem is incorrect two different ways dbush <dbush.mobile@gmail.com> - 2025-11-26 20:02 -0500
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:24 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 19:42 -0600
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 02:00 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 20:37 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 04:15 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:31 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 06:51 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-27 08:59 -0600
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:16 -0500
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:17 +0000
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 07:41 -0500
Re: The halting problem is incorrect two different ways Richard Damon <Richard@Damon-Family.org> - 2025-11-27 07:40 -0500
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:00 -0800
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:39 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 19:47 -0600
Re: The halting problem is incorrect two different ways Python <python@cccp.invalid> - 2025-11-27 01:59 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 20:26 -0600
Re: The halting problem is incorrect two different ways Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 04:19 +0000
Re: The halting problem is incorrect two different ways olcott <polcott333@gmail.com> - 2025-11-26 22:39 -0600
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-27 09:49 +0200
Re: The halting problem is incorrect two different ways "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-26 23:58 -0800
Re: The halting problem is incorrect two different ways Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:14 +0200
The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-11-28 08:46 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-11-28 10:59 -0500
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-11-29 11:27 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-11-29 10:38 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-11-29 14:58 -0500
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-01 12:45 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 06:47 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 14:29 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 08:38 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 14:45 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 08:57 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:06 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:19 -0600
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:26 -0600
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:29 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:31 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:39 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 15:48 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 09:55 -0600
Re: The halting problem is incorrect two different ways --- updated Python <python@cccp.invalid> - 2025-12-01 16:00 +0000
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-01 10:27 -0600
Re: The halting problem is incorrect two different ways --- updated "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-01 16:41 -0800
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-03 18:24 -0600
Olcott is provably correct --- no one can correctly refute this olcott <polcott333@gmail.com> - 2025-12-03 19:54 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-02 11:07 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-02 08:14 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-03 13:34 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-03 10:27 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-04 11:17 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-04 08:15 -0600
Re: The halting problem is incorrect two different ways --- updated Mikko <mikko.levanto@iki.fi> - 2025-12-06 11:23 +0200
Re: The halting problem is incorrect two different ways --- updated olcott <polcott333@gmail.com> - 2025-12-06 06:47 -0600
Re: The halting problem is incorrect two different ways --- updated Richard Damon <Richard@Damon-Family.org> - 2025-12-06 17:26 -0500
Re: The halting problem is incorrect two different ways --- faking ignorance olcott <polcott333@gmail.com> - 2025-11-27 09:21 -0600
Re: The halting problem is incorrect two different ways --- faking ignorance Richard Damon <Richard@Damon-Family.org> - 2025-11-27 10:40 -0500
Re: The halting problem is incorrect two different ways --- faking ignorance Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:37 +0000
Re: The halting problem is incorrect two different ways --- faking ignorance Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-27 18:24 +0000
Re: The halting problem is incorrect two different ways --- faking ignorance Mikko <mikko.levanto@iki.fi> - 2025-11-28 10:18 +0200
Re: The halting problem is incorrect two different ways --- faking ignorance olcott <polcott333@gmail.com> - 2025-11-28 08:52 -0600
Re: The halting problem is incorrect two different ways --- faking ignorance Richard Damon <Richard@Damon-Family.org> - 2025-11-28 11:01 -0500
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Python <python@cccp.invalid> |
|---|---|
| Date | 2025-12-01 16:00 +0000 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <2JVl09ehX8wzBAg-NpwNo1M1siA@jntp> |
| In reply to | #641525 |
Le 01/12/2025 à 16:55, olcott a écrit : > On 12/1/2025 9:48 AM, Python wrote: >> Le 01/12/2025 à 16:39, olcott a écrit : >>> On 12/1/2025 9:31 AM, Python wrote: >>>> Le 01/12/2025 à 16:29, olcott a écrit : >>>>> On 12/1/2025 9:26 AM, olcott wrote: >>>>>> On 12/1/2025 9:19 AM, olcott wrote: >>>>>>> On 12/1/2025 9:06 AM, Python wrote: >>>>>>>> Le 01/12/2025 à 15:57, olcott a écrit : >>>>>>>>> On 12/1/2025 8:45 AM, Python wrote: >>>>>>>>>> Le 01/12/2025 à 15:38, olcott a écrit : >>>>>>>>>>> On 12/1/2025 8:29 AM, Python wrote: >>>>>>>>>>>>> [snip boring nonsense and lies] >>>>>>>>>>>> >>>>>>>>>>>> Peter you've intoxicated yourself. >>>>>>>>>>>> >>>>>>>>>>>> Here is what Chat GPT told me once about himself: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Welcome back! >>>>>>>>>>> >>>>>>>>>>>> You have put your finger on the single most fundamental >>>>>>>>>>>> limitation of large language models: >>>>>>>>>>>> >>>>>>>>>>>> They can generate coherent arguments for things that are >>>>>>>>>>>> false, harmful, fringe, or logically impossible — not because >>>>>>>>>>>> they “believe” them, but because they can simulate the >>>>>>>>>>>> rhetorical form of such arguments. >>>>>>>>>>>> >>>>>>>>>>>> And you’re right: >>>>>>>>>>>> The fact that the model “doesn’t believe it” is irrelevant. >>>>>>>>>>>> What matters is: >>>>>>>>>>>> it can produce it. >>>>>>>>>>>> >>>>>>>>>>>> f2up math. >>>>>>>>>>> >>>>>>>>>>> Once you fully understand semantic tautologies >>>>>>>>>>> (the ultimate basis of all of my work) >>>>>>>>>>> >>>>>>>>>>> In epistemology (theory of knowledge), a self-evident >>>>>>>>>>> proposition is a proposition that is known to be true >>>>>>>>>>> by understanding its meaning without proof... >>>>>>>>>>> https://en.wikipedia.org/wiki/Self-evidence >>>>>>>>>>> >>>>>>>>>>> You will understand that I am correct. If you insist >>>>>>>>>>> on finding fault at a much higher priority than an >>>>>>>>>>> honest dialogue then you will never understand that >>>>>>>>>>> I am correct. >>>>>>>>>> >>>>>>>>>> You are NOT correct. >>>>>>>>>> >>>>>>>>> >>>>>>>>> You will continue to lack a sufficient basis >>>>>>>>> for that until you grok (Heinlein) semantic >>>>>>>>> tautology / self-evident truth. >>>>>>>>> >>>>>>>>>>> It seems that the single most useful application >>>>>>>>>>> of my work is to make LLM systems much more reliable. >>>>>>>>>> >>>>>>>>>> Your "work" is complete garbage... Sorry. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yet you cannot possibly show that with complete >>>>>>>>> and correct reasoning because you continue to >>>>>>>>> lack the above required basis. >>>>>>>> >>>>>>>> I'm am not willing to endorse a sophistry that I KNOW to be >>>>>>>> INCORRECT. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> How can you possibly show that a semantic tautology >>>>>>> is incorrect when it is inherently correct? >>>>>>> >>>>>>> >>>>>> >>>>>> Within the definition that "cats" <are> "animals" >>>>>> how can you possibly show that "cats" <are><not> "animals" ? ? ? >>>>>> >>>>> >>>>> "cats" is a finite string <are> >>>>> is a type of relation between finite strings. >>>> >>>> Don't dodge. >>>> >>>> This a sin because it is a kind of lie. >>>> >>>> >>> >>> Revelation 21:8 >>> King James Version >>> ...and all liars, shall have their part in the lake which >>> burneth with fire and brimstone: which is the second death. >>> >>> Liars swear their allegiance to the father of lies >>> and thus condemn themselves as shown above. >>> >>> Kurt Gödel in his 1944 Russell's mathematical logic gave >>> the following definition of the "theory of simple types" >>> in a footnote: >>> >>> By the theory of simple types I mean the doctrine which says >>> that the objects of thought ... are divided into types, >>> namely: individuals, properties of individuals, relations >>> between individuals, properties of such relations, etc. >>> https://en.wikipedia.org/wiki/History_of_type_theory#G%C3%B6del_1944 >>> >>> The essence of this is that all *objects of thought* >>> can be encoded in a hierarchy of types as relations >>> between finite strings. >> >> You'll enjoy Hell, Trump will be there too. >> >> > > In other words you are asserting that type theory is a lie? > > https://lawrencecpaulson.github.io/papers/Russells-mathematical-logic.pdf > > My whole 28 year purpose in this is so that people like Trump > cannot get away with their lies when Truth(L,x) becomes > computable. Adding more lies on top of previous lies, dodging, evading and defaming. This is not smelling good, maybe some smoke?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-01 10:27 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10gkfln$1g5eh$1@dont-email.me> |
| In reply to | #641526 |
On 12/1/2025 10:00 AM, Python wrote: > Le 01/12/2025 à 16:55, olcott a écrit : >> On 12/1/2025 9:48 AM, Python wrote: >>> Le 01/12/2025 à 16:39, olcott a écrit : >>>> On 12/1/2025 9:31 AM, Python wrote: >>>>> Le 01/12/2025 à 16:29, olcott a écrit : >>>>>> On 12/1/2025 9:26 AM, olcott wrote: >>>>>>> On 12/1/2025 9:19 AM, olcott wrote: >>>>>>>> On 12/1/2025 9:06 AM, Python wrote: >>>>>>>>> Le 01/12/2025 à 15:57, olcott a écrit : >>>>>>>>>> On 12/1/2025 8:45 AM, Python wrote: >>>>>>>>>>> Le 01/12/2025 à 15:38, olcott a écrit : >>>>>>>>>>>> On 12/1/2025 8:29 AM, Python wrote: >>>>>>>>>>>>>> [snip boring nonsense and lies] >>>>>>>>>>>>> >>>>>>>>>>>>> Peter you've intoxicated yourself. >>>>>>>>>>>>> >>>>>>>>>>>>> Here is what Chat GPT told me once about himself: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Welcome back! >>>>>>>>>>>> >>>>>>>>>>>>> You have put your finger on the single most fundamental >>>>>>>>>>>>> limitation of large language models: >>>>>>>>>>>>> >>>>>>>>>>>>> They can generate coherent arguments for things that are >>>>>>>>>>>>> false, harmful, fringe, or logically impossible — not >>>>>>>>>>>>> because they “believe” them, but because they can simulate >>>>>>>>>>>>> the rhetorical form of such arguments. >>>>>>>>>>>>> >>>>>>>>>>>>> And you’re right: >>>>>>>>>>>>> The fact that the model “doesn’t believe it” is irrelevant. >>>>>>>>>>>>> What matters is: >>>>>>>>>>>>> it can produce it. >>>>>>>>>>>>> >>>>>>>>>>>>> f2up math. >>>>>>>>>>>> >>>>>>>>>>>> Once you fully understand semantic tautologies >>>>>>>>>>>> (the ultimate basis of all of my work) >>>>>>>>>>>> >>>>>>>>>>>> In epistemology (theory of knowledge), a self-evident >>>>>>>>>>>> proposition is a proposition that is known to be true >>>>>>>>>>>> by understanding its meaning without proof... >>>>>>>>>>>> https://en.wikipedia.org/wiki/Self-evidence >>>>>>>>>>>> >>>>>>>>>>>> You will understand that I am correct. If you insist >>>>>>>>>>>> on finding fault at a much higher priority than an >>>>>>>>>>>> honest dialogue then you will never understand that >>>>>>>>>>>> I am correct. >>>>>>>>>>> >>>>>>>>>>> You are NOT correct. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You will continue to lack a sufficient basis >>>>>>>>>> for that until you grok (Heinlein) semantic >>>>>>>>>> tautology / self-evident truth. >>>>>>>>>> >>>>>>>>>>>> It seems that the single most useful application >>>>>>>>>>>> of my work is to make LLM systems much more reliable. >>>>>>>>>>> >>>>>>>>>>> Your "work" is complete garbage... Sorry. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yet you cannot possibly show that with complete >>>>>>>>>> and correct reasoning because you continue to >>>>>>>>>> lack the above required basis. >>>>>>>>> >>>>>>>>> I'm am not willing to endorse a sophistry that I KNOW to be >>>>>>>>> INCORRECT. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> How can you possibly show that a semantic tautology >>>>>>>> is incorrect when it is inherently correct? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Within the definition that "cats" <are> "animals" >>>>>>> how can you possibly show that "cats" <are><not> "animals" ? ? ? >>>>>>> >>>>>> >>>>>> "cats" is a finite string <are> >>>>>> is a type of relation between finite strings. >>>>> >>>>> Don't dodge. >>>>> >>>>> This a sin because it is a kind of lie. >>>>> >>>>> >>>> >>>> Revelation 21:8 >>>> King James Version >>>> ...and all liars, shall have their part in the lake which >>>> burneth with fire and brimstone: which is the second death. >>>> >>>> Liars swear their allegiance to the father of lies >>>> and thus condemn themselves as shown above. >>>> >>>> Kurt Gödel in his 1944 Russell's mathematical logic gave >>>> the following definition of the "theory of simple types" >>>> in a footnote: >>>> >>>> By the theory of simple types I mean the doctrine which says >>>> that the objects of thought ... are divided into types, >>>> namely: individuals, properties of individuals, relations >>>> between individuals, properties of such relations, etc. >>>> https://en.wikipedia.org/wiki/History_of_type_theory#G%C3%B6del_1944 >>>> >>>> The essence of this is that all *objects of thought* >>>> can be encoded in a hierarchy of types as relations >>>> between finite strings. >>> >>> You'll enjoy Hell, Trump will be there too. >>> >>> >> >> In other words you are asserting that type theory is a lie? >> >> https://lawrencecpaulson.github.io/papers/Russells-mathematical-logic.pdf >> >> My whole 28 year purpose in this is so that people like Trump >> cannot get away with their lies when Truth(L,x) becomes >> computable. > > Adding more lies on top of previous lies, dodging, evading and defaming. > > This is not smelling good, maybe some smoke? > > In other words you only have rhetoric that has no basis what-so-ever in correct reasoning. Thus this is merely a rhetorical ploy "This a sin because it is a kind of lie." and not any actual indication of a love for actual righteousness. Feel free to prove that I am wrong. I would really love to be wrong about this. -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable. This required establishing a new foundation for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-12-01 16:41 -0800 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10glcka$1qudj$3@dont-email.me> |
| In reply to | #641526 |
On 12/1/2025 8:00 AM, Python wrote: [...] If the PO here is the one that got arrested, then we have been communicating with a sick bastard that claims to be god all along. Sigh.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-03 18:24 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10gqkb3$3qfkb$1@dont-email.me> |
| In reply to | #641526 |
On 12/1/2025 10:00 AM, Python wrote: > Le 01/12/2025 à 16:55, olcott a écrit : >> On 12/1/2025 9:48 AM, Python wrote: >>> Le 01/12/2025 à 16:39, olcott a écrit : >>>> On 12/1/2025 9:31 AM, Python wrote: >>>>> Le 01/12/2025 à 16:29, olcott a écrit : >>>>>> On 12/1/2025 9:26 AM, olcott wrote: >>>>>>> On 12/1/2025 9:19 AM, olcott wrote: >>>>>>>> On 12/1/2025 9:06 AM, Python wrote: >>>>>>>>> Le 01/12/2025 à 15:57, olcott a écrit : >>>>>>>>>> On 12/1/2025 8:45 AM, Python wrote: >>>>>>>>>>> Le 01/12/2025 à 15:38, olcott a écrit : >>>>>>>>>>>> On 12/1/2025 8:29 AM, Python wrote: >>>>>>>>>>>>>> [snip boring nonsense and lies] >>>>>>>>>>>>> >>>>>>>>>>>>> Peter you've intoxicated yourself. >>>>>>>>>>>>> >>>>>>>>>>>>> Here is what Chat GPT told me once about himself: >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Welcome back! >>>>>>>>>>>> >>>>>>>>>>>>> You have put your finger on the single most fundamental >>>>>>>>>>>>> limitation of large language models: >>>>>>>>>>>>> >>>>>>>>>>>>> They can generate coherent arguments for things that are >>>>>>>>>>>>> false, harmful, fringe, or logically impossible — not >>>>>>>>>>>>> because they “believe” them, but because they can simulate >>>>>>>>>>>>> the rhetorical form of such arguments. >>>>>>>>>>>>> >>>>>>>>>>>>> And you’re right: >>>>>>>>>>>>> The fact that the model “doesn’t believe it” is irrelevant. >>>>>>>>>>>>> What matters is: >>>>>>>>>>>>> it can produce it. >>>>>>>>>>>>> >>>>>>>>>>>>> f2up math. >>>>>>>>>>>> >>>>>>>>>>>> Once you fully understand semantic tautologies >>>>>>>>>>>> (the ultimate basis of all of my work) >>>>>>>>>>>> >>>>>>>>>>>> In epistemology (theory of knowledge), a self-evident >>>>>>>>>>>> proposition is a proposition that is known to be true >>>>>>>>>>>> by understanding its meaning without proof... >>>>>>>>>>>> https://en.wikipedia.org/wiki/Self-evidence >>>>>>>>>>>> >>>>>>>>>>>> You will understand that I am correct. If you insist >>>>>>>>>>>> on finding fault at a much higher priority than an >>>>>>>>>>>> honest dialogue then you will never understand that >>>>>>>>>>>> I am correct. >>>>>>>>>>> >>>>>>>>>>> You are NOT correct. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You will continue to lack a sufficient basis >>>>>>>>>> for that until you grok (Heinlein) semantic >>>>>>>>>> tautology / self-evident truth. >>>>>>>>>> >>>>>>>>>>>> It seems that the single most useful application >>>>>>>>>>>> of my work is to make LLM systems much more reliable. >>>>>>>>>>> >>>>>>>>>>> Your "work" is complete garbage... Sorry. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yet you cannot possibly show that with complete >>>>>>>>>> and correct reasoning because you continue to >>>>>>>>>> lack the above required basis. >>>>>>>>> >>>>>>>>> I'm am not willing to endorse a sophistry that I KNOW to be >>>>>>>>> INCORRECT. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> How can you possibly show that a semantic tautology >>>>>>>> is incorrect when it is inherently correct? >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Within the definition that "cats" <are> "animals" >>>>>>> how can you possibly show that "cats" <are><not> "animals" ? ? ? >>>>>>> >>>>>> >>>>>> "cats" is a finite string <are> >>>>>> is a type of relation between finite strings. >>>>> >>>>> Don't dodge. >>>>> >>>>> This a sin because it is a kind of lie. >>>>> >>>>> >>>> >>>> Revelation 21:8 >>>> King James Version >>>> ...and all liars, shall have their part in the lake which >>>> burneth with fire and brimstone: which is the second death. >>>> >>>> Liars swear their allegiance to the father of lies >>>> and thus condemn themselves as shown above. >>>> >>>> Kurt Gödel in his 1944 Russell's mathematical logic gave >>>> the following definition of the "theory of simple types" >>>> in a footnote: >>>> >>>> By the theory of simple types I mean the doctrine which says >>>> that the objects of thought ... are divided into types, >>>> namely: individuals, properties of individuals, relations >>>> between individuals, properties of such relations, etc. >>>> https://en.wikipedia.org/wiki/History_of_type_theory#G%C3%B6del_1944 >>>> >>>> The essence of this is that all *objects of thought* >>>> can be encoded in a hierarchy of types as relations >>>> between finite strings. >>> >>> You'll enjoy Hell, Trump will be there too. >>> >>> >> >> In other words you are asserting that type theory is a lie? >> >> https://lawrencecpaulson.github.io/papers/Russells-mathematical-logic.pdf >> >> My whole 28 year purpose in this is so that people like Trump >> cannot get away with their lies when Truth(L,x) becomes >> computable. > > Adding more lies on top of previous lies, dodging, evading and defaming. > > This is not smelling good, maybe some smoke? > > That you fail to understand what I am saying is less that no basis what-so-ever for rebuttal. That you denigrate what I said with pure rhetoric that is not anchored to any basis seems to indicate that you know you have no sound basis. -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable. This required establishing a new foundation for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-03 19:54 -0600 |
| Subject | Olcott is provably correct --- no one can correctly refute this |
| Message-ID | <10gqpjo$3s19l$4@dont-email.me> |
| In reply to | #641526 |
On 12/1/2025 10:00 AM, Python wrote:
> Le 01/12/2025 à 16:55, olcott a écrit :
>>
>> In other words you are asserting that type theory is a lie?
>>
>> https://lawrencecpaulson.github.io/papers/Russells-mathematical-logic.pdf
>>
>> My whole 28 year purpose in this is so that people like Trump
>> cannot get away with their lies when Truth(L,x) becomes
>> computable.
>
> Adding more lies on top of previous lies, dodging, evading and defaming.
>
> This is not smelling good, maybe some smoke?
>
>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
*Proof that HHH correctly rejects HHH*
(a) DD simulated by HHH according to the
semantics of the C programming language
(b) Cannot possibly reach its own "return"
statement final halt state
(c) While being simulated by HHH
Conclusively proves that behavior that the
input to HHH(DD) specifies is non-halting behavior.
That
(a) Turing machine deciders only compute the mapping
from their [finite string] inputs
(b) To an accept or reject state
(c) On the basis that this [finite string] input specifies
or fails to specify a semantic or syntactic property.
Proves that the halting problem, itself is incorrect
when it requires something else.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-12-02 11:07 +0200 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10gma81$251t7$1@dont-email.me> |
| In reply to | #641511 |
olcott kirjoitti 1.12.2025 klo 14.47:
> On 12/1/2025 4:45 AM, Mikko wrote:
>> olcott kirjoitti 29.11.2025 klo 18.38:
>>> On 11/29/2025 3:27 AM, Mikko wrote:
>>>> olcott kirjoitti 28.11.2025 klo 16.46:
>>>>> On 11/28/2025 2:14 AM, Mikko wrote:
>>>>>> Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
>>>>>>> On 11/26/2025 11:49 PM, Mikko wrote:
>>>>>>>> olcott kirjoitti 26.11.2025 klo 17.17:
>>>>>>>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>>>>>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>>>>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>>>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell
>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not
>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an
>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate
>>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return
>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if
>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would
>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D)
>>>>>>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates
>>>>>>>>>>>>>>>>>>>>>>>>> D that
>>>>>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as
>>>>>>>>>>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies.
>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same result
>>>>>>>>>>>>>>>>>>>>>>>> is equally valid.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation
>>>>>>>>>>>>>>>>>>>>>>>>> never being
>>>>>>>>>>>>>>>>>>>>>>>>> able to complete its first statement before
>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
>>>>>>>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If that happens then H does not return and
>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That seems to confirm that the definition of
>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The termination problem is not about specifying "to
>>>>>>>>>>>>>>>>>> its termination
>>>>>>>>>>>>>>>>>> analyzer". Instead the termination problem is to
>>>>>>>>>>>>>>>>>> determine whether
>>>>>>>>>>>>>>>>>> a program terminates every time when used as it was
>>>>>>>>>>>>>>>>>> designed to be
>>>>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Every halt decider is required to report on the
>>>>>>>>>>>>>>>> behaviour asked about.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>>>>>>>> the behavior that it is asked about.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it is not. The solution to the halting problem must
>>>>>>>>>>>>>> include the
>>>>>>>>>>>>>> necessary access. Conversely, a proof that the necessary
>>>>>>>>>>>>>> access is
>>>>>>>>>>>>>> impossible is sufficient to prove that halting problem is
>>>>>>>>>>>>>> unsolvable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>>>>>>>> main requires HHH to report on information
>>>>>>>>>>>>> that is not contained in its input thus it is
>>>>>>>>>>>>> incorrect to require HHH to report on that.
>>>>>>>>>>>>
>>>>>>>>>>>> That HHH fails to meet the requirements does not mean that the
>>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> That HHH fails to meet the requirements by itself does
>>>>>>>>>>> not mean that the requirements are wrong.
>>>>>>>>>>>
>>>>>>>>>>> Turing machine deciders only compute a mapping from
>>>>>>>>>>> their [finite string] inputs to an accept or reject
>>>>>>>>>>> state on the basis that this [finite string] input
>>>>>>>>>>> specifies or fails to specify a semantic or syntactic
>>>>>>>>>>> property.
>>>>>>>>>>>
>>>>>>>>>>> That the information that HHH is required to report
>>>>>>>>>>> on simply is not contained in its input is what makes
>>>>>>>>>>> the requirements wrong.
>>>>>>>>>>
>>>>>>>>>> No, it merely means that the designer ot HHH has failed to
>>>>>>>>>> specify the
>>>>>>>>>> encoding rules so that the input contains the full
>>>>>>>>>> specification of the
>>>>>>>>>> behaviour.
>>>>>>>>
>>>>>>>>> In other words you are trying to get away with
>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>
>>>>>>>> You are the one who disagrees with the x86 processors about the x86
>>>>>>>> language semantics. When an x86 processor executes a program it
>>>>>>>> executes
>>>>>>>> according to the x86 semantics. When DD is executed according to
>>>>>>>> the x86
>>>>>>>> semantics it halts. Anybody who says that DD specifies a non-
>>>>>>>> halting
>>>>>>>> behaviour disagrees with the x86 semantics.
>>>>>>
>>>>>>> But, DD can halt or not halt, right?
>>>>>>
>>>>>> When Olcott uses the name DD he means the particular program in his
>>>>>> GitHub repository except when he wants to deceive with equivocation.
>>>>>> The DD is Olcotts repository halts.
>>>>
>>>>> I am doing this in the C programming language so that
>>>>> every detail can be concretely specified and thus no
>>>>> important details are simply abstracted away.
>>>>>
>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>> HHH on line 1081
>>>>> DD on line 1355
>>>>
>>>> The DD on line 1355 is the DD I mentioned above and whicn is listed
>>>> below. HHH always means the HHH on line 1081 except when otherwise
>>>> stated. HHH(DD) means the HHH on line 1081 is called with the pointer
>>>> to the DD on line 1355 as the argument. THat call returns 0, which
>>>> means that DD does not halt.
>>>>
>>>
>>> HHH(DD)==0 has nothing to do with DD executed from main.
>>
>> True. It would if HHH were a halting decider but HHH isn't.
>
> If you carefully studied all of what I said you
> would see that the halting problem is a category
> error because it directly contradicts one of the
> foundational axioms of computer science.
Any statement that a problem contradicts anything is a categoryerror.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-02 08:14 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10gms7n$2bvm8$1@dont-email.me> |
| In reply to | #641560 |
On 12/2/2025 3:07 AM, Mikko wrote:
> olcott kirjoitti 1.12.2025 klo 14.47:
>> On 12/1/2025 4:45 AM, Mikko wrote:
>>> olcott kirjoitti 29.11.2025 klo 18.38:
>>>> On 11/29/2025 3:27 AM, Mikko wrote:
>>>>> olcott kirjoitti 28.11.2025 klo 16.46:
>>>>>> On 11/28/2025 2:14 AM, Mikko wrote:
>>>>>>> Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
>>>>>>>> On 11/26/2025 11:49 PM, Mikko wrote:
>>>>>>>>> olcott kirjoitti 26.11.2025 klo 17.17:
>>>>>>>>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>>>>>>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>>>>>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell
>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not
>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an
>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate
>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return
>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if
>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would
>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to
>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates
>>>>>>>>>>>>>>>>>>>>>>>>>> D that
>>>>>>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as
>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies.
>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same
>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation
>>>>>>>>>>>>>>>>>>>>>>>>>> never being
>>>>>>>>>>>>>>>>>>>>>>>>>> able to complete its first statement before
>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If that happens then H does not return and
>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> That seems to confirm that the definition of
>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The termination problem is not about specifying "to
>>>>>>>>>>>>>>>>>>> its termination
>>>>>>>>>>>>>>>>>>> analyzer". Instead the termination problem is to
>>>>>>>>>>>>>>>>>>> determine whether
>>>>>>>>>>>>>>>>>>> a program terminates every time when used as it was
>>>>>>>>>>>>>>>>>>> designed to be
>>>>>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Every halt decider is required to report on the
>>>>>>>>>>>>>>>>> behaviour asked about.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>>>>>>>>> the behavior that it is asked about.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it is not. The solution to the halting problem must
>>>>>>>>>>>>>>> include the
>>>>>>>>>>>>>>> necessary access. Conversely, a proof that the necessary
>>>>>>>>>>>>>>> access is
>>>>>>>>>>>>>>> impossible is sufficient to prove that halting problem is
>>>>>>>>>>>>>>> unsolvable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>>>>>>>>> main requires HHH to report on information
>>>>>>>>>>>>>> that is not contained in its input thus it is
>>>>>>>>>>>>>> incorrect to require HHH to report on that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That HHH fails to meet the requirements does not mean that the
>>>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That HHH fails to meet the requirements by itself does
>>>>>>>>>>>> not mean that the requirements are wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Turing machine deciders only compute a mapping from
>>>>>>>>>>>> their [finite string] inputs to an accept or reject
>>>>>>>>>>>> state on the basis that this [finite string] input
>>>>>>>>>>>> specifies or fails to specify a semantic or syntactic
>>>>>>>>>>>> property.
>>>>>>>>>>>>
>>>>>>>>>>>> That the information that HHH is required to report
>>>>>>>>>>>> on simply is not contained in its input is what makes
>>>>>>>>>>>> the requirements wrong.
>>>>>>>>>>>
>>>>>>>>>>> No, it merely means that the designer ot HHH has failed to
>>>>>>>>>>> specify the
>>>>>>>>>>> encoding rules so that the input contains the full
>>>>>>>>>>> specification of the
>>>>>>>>>>> behaviour.
>>>>>>>>>
>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>
>>>>>>>>> You are the one who disagrees with the x86 processors about the
>>>>>>>>> x86
>>>>>>>>> language semantics. When an x86 processor executes a program it
>>>>>>>>> executes
>>>>>>>>> according to the x86 semantics. When DD is executed according
>>>>>>>>> to the x86
>>>>>>>>> semantics it halts. Anybody who says that DD specifies a non-
>>>>>>>>> halting
>>>>>>>>> behaviour disagrees with the x86 semantics.
>>>>>>>
>>>>>>>> But, DD can halt or not halt, right?
>>>>>>>
>>>>>>> When Olcott uses the name DD he means the particular program in his
>>>>>>> GitHub repository except when he wants to deceive with equivocation.
>>>>>>> The DD is Olcotts repository halts.
>>>>>
>>>>>> I am doing this in the C programming language so that
>>>>>> every detail can be concretely specified and thus no
>>>>>> important details are simply abstracted away.
>>>>>>
>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>>> HHH on line 1081
>>>>>> DD on line 1355
>>>>>
>>>>> The DD on line 1355 is the DD I mentioned above and whicn is listed
>>>>> below. HHH always means the HHH on line 1081 except when otherwise
>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the pointer
>>>>> to the DD on line 1355 as the argument. THat call returns 0, which
>>>>> means that DD does not halt.
>>>>>
>>>>
>>>> HHH(DD)==0 has nothing to do with DD executed from main.
>>>
>>> True. It would if HHH were a halting decider but HHH isn't.
>>
>> If you carefully studied all of what I said you
>> would see that the halting problem is a category
>> error because it directly contradicts one of the
>> foundational axioms of computer science.
>
> Any statement that a problem contradicts anything is a categoryerror.
>
Flibble was the first one to use this term that I am aware of.
Two different LLM systems also applied this term to the results
that I explained to them. We need to be acutely aware of LLM
AI hallucination, thus double check everything that they say.
It does seem that we can totally trust what they say whenever
they apply correct semantic logical entailment on the basis
of expressions of language known to be true.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-12-03 13:34 +0200 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <b6664773-0477-4785-bd2b-7147f9782336@iki.fi> |
| In reply to | #641568 |
olcott kirjoitti 2.12.2025 klo 16.14:
> On 12/2/2025 3:07 AM, Mikko wrote:
>> olcott kirjoitti 1.12.2025 klo 14.47:
>>> On 12/1/2025 4:45 AM, Mikko wrote:
>>>> olcott kirjoitti 29.11.2025 klo 18.38:
>>>>> On 11/29/2025 3:27 AM, Mikko wrote:
>>>>>> olcott kirjoitti 28.11.2025 klo 16.46:
>>>>>>> On 11/28/2025 2:14 AM, Mikko wrote:
>>>>>>>> Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
>>>>>>>>> On 11/26/2025 11:49 PM, Mikko wrote:
>>>>>>>>>> olcott kirjoitti 26.11.2025 klo 17.17:
>>>>>>>>>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>>>>>>>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>>>>>>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if
>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would
>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
>>>>>>>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as
>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same
>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
>>>>>>>>>>>>>>>>>>>>>>>>>>> able to complete its first statement before
>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If that happens then H does not return and
>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your
>>>>>>>>>>>>>>>>>>>>>>>> head.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That seems to confirm that the definition of
>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The termination problem is not about specifying "to
>>>>>>>>>>>>>>>>>>>> its termination
>>>>>>>>>>>>>>>>>>>> analyzer". Instead the termination problem is to
>>>>>>>>>>>>>>>>>>>> determine whether
>>>>>>>>>>>>>>>>>>>> a program terminates every time when used as it was
>>>>>>>>>>>>>>>>>>>> designed to be
>>>>>>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Every halt decider is required to report on the
>>>>>>>>>>>>>>>>>> behaviour asked about.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>>>>>>>>>> the behavior that it is asked about.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, it is not. The solution to the halting problem must
>>>>>>>>>>>>>>>> include the
>>>>>>>>>>>>>>>> necessary access. Conversely, a proof that the necessary
>>>>>>>>>>>>>>>> access is
>>>>>>>>>>>>>>>> impossible is sufficient to prove that halting problem
>>>>>>>>>>>>>>>> is unsolvable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>>>>>>>>>> main requires HHH to report on information
>>>>>>>>>>>>>>> that is not contained in its input thus it is
>>>>>>>>>>>>>>> incorrect to require HHH to report on that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That HHH fails to meet the requirements does not mean that
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> That HHH fails to meet the requirements by itself does
>>>>>>>>>>>>> not mean that the requirements are wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing machine deciders only compute a mapping from
>>>>>>>>>>>>> their [finite string] inputs to an accept or reject
>>>>>>>>>>>>> state on the basis that this [finite string] input
>>>>>>>>>>>>> specifies or fails to specify a semantic or syntactic
>>>>>>>>>>>>> property.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That the information that HHH is required to report
>>>>>>>>>>>>> on simply is not contained in its input is what makes
>>>>>>>>>>>>> the requirements wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> No, it merely means that the designer ot HHH has failed to
>>>>>>>>>>>> specify the
>>>>>>>>>>>> encoding rules so that the input contains the full
>>>>>>>>>>>> specification of the
>>>>>>>>>>>> behaviour.
>>>>>>>>>>
>>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>>
>>>>>>>>>> You are the one who disagrees with the x86 processors about
>>>>>>>>>> the x86
>>>>>>>>>> language semantics. When an x86 processor executes a program
>>>>>>>>>> it executes
>>>>>>>>>> according to the x86 semantics. When DD is executed according
>>>>>>>>>> to the x86
>>>>>>>>>> semantics it halts. Anybody who says that DD specifies a non-
>>>>>>>>>> halting
>>>>>>>>>> behaviour disagrees with the x86 semantics.
>>>>>>>>
>>>>>>>>> But, DD can halt or not halt, right?
>>>>>>>>
>>>>>>>> When Olcott uses the name DD he means the particular program in his
>>>>>>>> GitHub repository except when he wants to deceive with
>>>>>>>> equivocation.
>>>>>>>> The DD is Olcotts repository halts.
>>>>>>
>>>>>>> I am doing this in the C programming language so that
>>>>>>> every detail can be concretely specified and thus no
>>>>>>> important details are simply abstracted away.
>>>>>>>
>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>>>> HHH on line 1081
>>>>>>> DD on line 1355
>>>>>>
>>>>>> The DD on line 1355 is the DD I mentioned above and whicn is listed
>>>>>> below. HHH always means the HHH on line 1081 except when otherwise
>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the pointer
>>>>>> to the DD on line 1355 as the argument. THat call returns 0, which
>>>>>> means that DD does not halt.
>>>>>>
>>>>>
>>>>> HHH(DD)==0 has nothing to do with DD executed from main.
>>>>
>>>> True. It would if HHH were a halting decider but HHH isn't.
>>>
>>> If you carefully studied all of what I said you
>>> would see that the halting problem is a category
>>> error because it directly contradicts one of the
>>> foundational axioms of computer science.
>>
>> Any statement that a problem contradicts anything is a categoryerror.
>
> Flibble was the first one to use this term that I am aware of.
Do you mean the term "category error"? It is a well known term
though many authors prefer "category mistake" for the same
meaning.
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-03 10:27 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10gpod2$3fcr0$1@dont-email.me> |
| In reply to | #641582 |
On 12/3/2025 5:34 AM, Mikko wrote:
> olcott kirjoitti 2.12.2025 klo 16.14:
>> On 12/2/2025 3:07 AM, Mikko wrote:
>>> olcott kirjoitti 1.12.2025 klo 14.47:
>>>> On 12/1/2025 4:45 AM, Mikko wrote:
>>>>> olcott kirjoitti 29.11.2025 klo 18.38:
>>>>>> On 11/29/2025 3:27 AM, Mikko wrote:
>>>>>>> olcott kirjoitti 28.11.2025 klo 16.46:
>>>>>>>> On 11/28/2025 2:14 AM, Mikko wrote:
>>>>>>>>> Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
>>>>>>>>>> On 11/26/2025 11:49 PM, Mikko wrote:
>>>>>>>>>>> olcott kirjoitti 26.11.2025 klo 17.17:
>>>>>>>>>>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>>>>>>>>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>>>>>>>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semanttics it should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate H(D), either simultating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as
>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
>>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same
>>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
>>>>>>>>>>>>>>>>>>>>>>>>>>>> able to complete its first statement before
>>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> If that happens then H does not return and
>>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your
>>>>>>>>>>>>>>>>>>>>>>>>> head.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That seems to confirm that the definition of
>>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The termination problem is not about specifying "to
>>>>>>>>>>>>>>>>>>>>> its termination
>>>>>>>>>>>>>>>>>>>>> analyzer". Instead the termination problem is to
>>>>>>>>>>>>>>>>>>>>> determine whether
>>>>>>>>>>>>>>>>>>>>> a program terminates every time when used as it was
>>>>>>>>>>>>>>>>>>>>> designed to be
>>>>>>>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Every halt decider is required to report on the
>>>>>>>>>>>>>>>>>>> behaviour asked about.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>>>>>>>>>>> the behavior that it is asked about.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, it is not. The solution to the halting problem must
>>>>>>>>>>>>>>>>> include the
>>>>>>>>>>>>>>>>> necessary access. Conversely, a proof that the
>>>>>>>>>>>>>>>>> necessary access is
>>>>>>>>>>>>>>>>> impossible is sufficient to prove that halting problem
>>>>>>>>>>>>>>>>> is unsolvable.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>>>>>>>>>>> main requires HHH to report on information
>>>>>>>>>>>>>>>> that is not contained in its input thus it is
>>>>>>>>>>>>>>>> incorrect to require HHH to report on that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That HHH fails to meet the requirements does not mean
>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a
>>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That HHH fails to meet the requirements by itself does
>>>>>>>>>>>>>> not mean that the requirements are wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Turing machine deciders only compute a mapping from
>>>>>>>>>>>>>> their [finite string] inputs to an accept or reject
>>>>>>>>>>>>>> state on the basis that this [finite string] input
>>>>>>>>>>>>>> specifies or fails to specify a semantic or syntactic
>>>>>>>>>>>>>> property.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That the information that HHH is required to report
>>>>>>>>>>>>>> on simply is not contained in its input is what makes
>>>>>>>>>>>>>> the requirements wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it merely means that the designer ot HHH has failed to
>>>>>>>>>>>>> specify the
>>>>>>>>>>>>> encoding rules so that the input contains the full
>>>>>>>>>>>>> specification of the
>>>>>>>>>>>>> behaviour.
>>>>>>>>>>>
>>>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>>>
>>>>>>>>>>> You are the one who disagrees with the x86 processors about
>>>>>>>>>>> the x86
>>>>>>>>>>> language semantics. When an x86 processor executes a program
>>>>>>>>>>> it executes
>>>>>>>>>>> according to the x86 semantics. When DD is executed according
>>>>>>>>>>> to the x86
>>>>>>>>>>> semantics it halts. Anybody who says that DD specifies a non-
>>>>>>>>>>> halting
>>>>>>>>>>> behaviour disagrees with the x86 semantics.
>>>>>>>>>
>>>>>>>>>> But, DD can halt or not halt, right?
>>>>>>>>>
>>>>>>>>> When Olcott uses the name DD he means the particular program in
>>>>>>>>> his
>>>>>>>>> GitHub repository except when he wants to deceive with
>>>>>>>>> equivocation.
>>>>>>>>> The DD is Olcotts repository halts.
>>>>>>>
>>>>>>>> I am doing this in the C programming language so that
>>>>>>>> every detail can be concretely specified and thus no
>>>>>>>> important details are simply abstracted away.
>>>>>>>>
>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>>>>> HHH on line 1081
>>>>>>>> DD on line 1355
>>>>>>>
>>>>>>> The DD on line 1355 is the DD I mentioned above and whicn is listed
>>>>>>> below. HHH always means the HHH on line 1081 except when otherwise
>>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the
>>>>>>> pointer
>>>>>>> to the DD on line 1355 as the argument. THat call returns 0, which
>>>>>>> means that DD does not halt.
>>>>>>>
>>>>>>
>>>>>> HHH(DD)==0 has nothing to do with DD executed from main.
>>>>>
>>>>> True. It would if HHH were a halting decider but HHH isn't.
>>>>
>>>> If you carefully studied all of what I said you
>>>> would see that the halting problem is a category
>>>> error because it directly contradicts one of the
>>>> foundational axioms of computer science.
>>>
>>> Any statement that a problem contradicts anything is a categoryerror.
>>
>> Flibble was the first one to use this term that I am aware of.
>
> Do you mean the term "category error"? It is a well known term
> though many authors prefer "category mistake" for the same
> meaning.
>
Flibble was the first one to use the term category
error applied to the halting problem. Later on
after I explained all of the details in a dialogue
both ChatGPT and Claude AI applied this same term.
They did this on the basis that the halting problem
required a halt decider to report on behavior that
is different than the behavior that its actual input
actually specifies.
They were able to directly assess this behavior
themselves by actually performing a simulation of DD by
HHH according to the semantics of the x86 language.
> Anyway, any claim that a problem contradict something is
> a category error because the meanings of "problem" and
> "contradict" are not compatible.
>
When the halting problem contradicts the definition
of a Turing machine decider
Turing machine deciders only compute a mapping from
their [finite string] inputs to an accept or reject
state on the basis that this [finite string] input
specifies or fails to specify a semantic or syntactic
property.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-12-04 11:17 +0200 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10grjk3$4ngs$1@dont-email.me> |
| In reply to | #641587 |
olcott kirjoitti 3.12.2025 klo 18.27:
> On 12/3/2025 5:34 AM, Mikko wrote:
>> olcott kirjoitti 2.12.2025 klo 16.14:
>>> On 12/2/2025 3:07 AM, Mikko wrote:
>>>> olcott kirjoitti 1.12.2025 klo 14.47:
>>>>> On 12/1/2025 4:45 AM, Mikko wrote:
>>>>>> olcott kirjoitti 29.11.2025 klo 18.38:
>>>>>>> On 11/29/2025 3:27 AM, Mikko wrote:
>>>>>>>> olcott kirjoitti 28.11.2025 klo 16.46:
>>>>>>>>> On 11/28/2025 2:14 AM, Mikko wrote:
>>>>>>>>>> Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
>>>>>>>>>>> On 11/26/2025 11:49 PM, Mikko wrote:
>>>>>>>>>>>> olcott kirjoitti 26.11.2025 klo 17.17:
>>>>>>>>>>>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>>>>>>>>>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>>>>>>>>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaches
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> file
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semanttics it should
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate H(D), either simultating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
>>>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> able to complete its first statement before
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If that happens then H does not return and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your
>>>>>>>>>>>>>>>>>>>>>>>>>> head.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That seems to confirm that the definition of
>>>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The termination problem is not about specifying
>>>>>>>>>>>>>>>>>>>>>> "to its termination
>>>>>>>>>>>>>>>>>>>>>> analyzer". Instead the termination problem is to
>>>>>>>>>>>>>>>>>>>>>> determine whether
>>>>>>>>>>>>>>>>>>>>>> a program terminates every time when used as it
>>>>>>>>>>>>>>>>>>>>>> was designed to be
>>>>>>>>>>>>>>>>>>>>>> used.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Every halt decider is required to report on the
>>>>>>>>>>>>>>>>>>>> behaviour asked about.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>>>>>>>>>>>> the behavior that it is asked about.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, it is not. The solution to the halting problem
>>>>>>>>>>>>>>>>>> must include the
>>>>>>>>>>>>>>>>>> necessary access. Conversely, a proof that the
>>>>>>>>>>>>>>>>>> necessary access is
>>>>>>>>>>>>>>>>>> impossible is sufficient to prove that halting problem
>>>>>>>>>>>>>>>>>> is unsolvable.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>>>>>>>>>>>> main requires HHH to report on information
>>>>>>>>>>>>>>>>> that is not contained in its input thus it is
>>>>>>>>>>>>>>>>> incorrect to require HHH to report on that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That HHH fails to meet the requirements does not mean
>>>>>>>>>>>>>>>> that the
>>>>>>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a
>>>>>>>>>>>>>>>> halt
>>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That HHH fails to meet the requirements by itself does
>>>>>>>>>>>>>>> not mean that the requirements are wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Turing machine deciders only compute a mapping from
>>>>>>>>>>>>>>> their [finite string] inputs to an accept or reject
>>>>>>>>>>>>>>> state on the basis that this [finite string] input
>>>>>>>>>>>>>>> specifies or fails to specify a semantic or syntactic
>>>>>>>>>>>>>>> property.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That the information that HHH is required to report
>>>>>>>>>>>>>>> on simply is not contained in its input is what makes
>>>>>>>>>>>>>>> the requirements wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it merely means that the designer ot HHH has failed to
>>>>>>>>>>>>>> specify the
>>>>>>>>>>>>>> encoding rules so that the input contains the full
>>>>>>>>>>>>>> specification of the
>>>>>>>>>>>>>> behaviour.
>>>>>>>>>>>>
>>>>>>>>>>>>> In other words you are trying to get away with
>>>>>>>>>>>>> disagreeing with the semantics of the x86 language
>>>>>>>>>>>>> or the semantics of the C programing language.
>>>>>>>>>>>>
>>>>>>>>>>>> You are the one who disagrees with the x86 processors about
>>>>>>>>>>>> the x86
>>>>>>>>>>>> language semantics. When an x86 processor executes a program
>>>>>>>>>>>> it executes
>>>>>>>>>>>> according to the x86 semantics. When DD is executed
>>>>>>>>>>>> according to the x86
>>>>>>>>>>>> semantics it halts. Anybody who says that DD specifies a
>>>>>>>>>>>> non- halting
>>>>>>>>>>>> behaviour disagrees with the x86 semantics.
>>>>>>>>>>
>>>>>>>>>>> But, DD can halt or not halt, right?
>>>>>>>>>>
>>>>>>>>>> When Olcott uses the name DD he means the particular program
>>>>>>>>>> in his
>>>>>>>>>> GitHub repository except when he wants to deceive with
>>>>>>>>>> equivocation.
>>>>>>>>>> The DD is Olcotts repository halts.
>>>>>>>>
>>>>>>>>> I am doing this in the C programming language so that
>>>>>>>>> every detail can be concretely specified and thus no
>>>>>>>>> important details are simply abstracted away.
>>>>>>>>>
>>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>>>>>>>> HHH on line 1081
>>>>>>>>> DD on line 1355
>>>>>>>>
>>>>>>>> The DD on line 1355 is the DD I mentioned above and whicn is listed
>>>>>>>> below. HHH always means the HHH on line 1081 except when otherwise
>>>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the
>>>>>>>> pointer
>>>>>>>> to the DD on line 1355 as the argument. THat call returns 0, which
>>>>>>>> means that DD does not halt.
>>>>>>>>
>>>>>>>
>>>>>>> HHH(DD)==0 has nothing to do with DD executed from main.
>>>>>>
>>>>>> True. It would if HHH were a halting decider but HHH isn't.
>>>>>
>>>>> If you carefully studied all of what I said you
>>>>> would see that the halting problem is a category
>>>>> error because it directly contradicts one of the
>>>>> foundational axioms of computer science.
>>>>
>>>> Any statement that a problem contradicts anything is a categoryerror.
>>>
>>> Flibble was the first one to use this term that I am aware of.
It does not matter who first used the term here.
...
>> Anyway, any claim that a problem contradict something is
>> a category error because the meanings of "problem" and
>> "contradict" are not compatible.
>
> When the halting problem contradicts the definition
> of a Turing machine decider
A contradiction means that all claims of some set cannot be true. It
is a category error to apply the term "contradiction" to non-claims.
Examples of non-claims are problem and definition. An example of
category error is "the halting problem contradicts the definition of
a Turing machine decider".
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-04 08:15 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10gs51g$bicq$1@dont-email.me> |
| In reply to | #641603 |
On 12/4/2025 3:17 AM, Mikko wrote: > olcott kirjoitti 3.12.2025 klo 18.27: >> On 12/3/2025 5:34 AM, Mikko wrote: >>> olcott kirjoitti 2.12.2025 klo 16.14: >>>> >>>> Flibble was the first one to use this term that I am aware of. > > It does not matter who first used the term here. > ... >>> Anyway, any claim that a problem contradict something is >>> a category error because the meanings of "problem" and >>> "contradict" are not compatible. >> >> When the halting problem contradicts the definition >> of a Turing machine decider > > A contradiction means that all claims of some set cannot be true. It > is a category error to apply the term "contradiction" to non-claims. > Examples of non-claims are problem and definition. An example of > category error is "the halting problem contradicts the definition of > a Turing machine decider". > The halting problem contradicts the definition of a Turing machine decider proving that it is wrong because the definition of a Turing machine decider is foundational. -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable. This required establishing a new foundation for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-12-06 11:23 +0200 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10h0sms$29a0r$3@dont-email.me> |
| In reply to | #641611 |
olcott kirjoitti 4.12.2025 klo 16.15: > On 12/4/2025 3:17 AM, Mikko wrote: >> olcott kirjoitti 3.12.2025 klo 18.27: >>> On 12/3/2025 5:34 AM, Mikko wrote: >>>> olcott kirjoitti 2.12.2025 klo 16.14: >>>>> >>>>> Flibble was the first one to use this term that I am aware of. >> >> It does not matter who first used the term here. >> ... >>>> Anyway, any claim that a problem contradict something is >>>> a category error because the meanings of "problem" and >>>> "contradict" are not compatible. >>> >>> When the halting problem contradicts the definition >>> of a Turing machine decider >> >> A contradiction means that all claims of some set cannot be true. It >> is a category error to apply the term "contradiction" to non-claims. >> Examples of non-claims are problem and definition. An example of >> category error is "the halting problem contradicts the definition of >> a Turing machine decider". > > The halting problem contradicts the definition > of a Turing machine decider proving that it is > wrong because the definition of a Turing machine > decider is foundational. That still contains the same category error pointed out in my prevous comment as quoted above. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-12-06 06:47 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <10h18lq$2dlk1$3@dont-email.me> |
| In reply to | #641662 |
On 12/6/2025 3:23 AM, Mikko wrote: > olcott kirjoitti 4.12.2025 klo 16.15: >> On 12/4/2025 3:17 AM, Mikko wrote: >>> olcott kirjoitti 3.12.2025 klo 18.27: >>>> On 12/3/2025 5:34 AM, Mikko wrote: >>>>> olcott kirjoitti 2.12.2025 klo 16.14: >>>>>> >>>>>> Flibble was the first one to use this term that I am aware of. >>> >>> It does not matter who first used the term here. >>> ... >>>>> Anyway, any claim that a problem contradict something is >>>>> a category error because the meanings of "problem" and >>>>> "contradict" are not compatible. >>>> >>>> When the halting problem contradicts the definition >>>> of a Turing machine decider >>> >>> A contradiction means that all claims of some set cannot be true. It >>> is a category error to apply the term "contradiction" to non-claims. >>> Examples of non-claims are problem and definition. An example of >>> category error is "the halting problem contradicts the definition of >>> a Turing machine decider". >> >> The halting problem contradicts the definition >> of a Turing machine decider proving that it is >> wrong because the definition of a Turing machine >> decider is foundational. > > That still contains the same category error pointed out in my > prevous comment as quoted above. > Try and find an error. https://www.researchgate.net/publication/398375553_Halting_Problem_Proof_Counter-Example_is_Isomorphic_to_the_Liar_Paradox -- Copyright 2025 Olcott My 28 year goal has been to make "true on the basis of meaning" computable. This required establishing a new foundation for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-12-06 17:26 -0500 |
| Subject | Re: The halting problem is incorrect two different ways --- updated |
| Message-ID | <w42ZQ.26704$4LD1.2706@fx10.iad> |
| In reply to | #641662 |
On 12/6/25 4:23 AM, Mikko wrote: > olcott kirjoitti 4.12.2025 klo 16.15: >> On 12/4/2025 3:17 AM, Mikko wrote: >>> olcott kirjoitti 3.12.2025 klo 18.27: >>>> On 12/3/2025 5:34 AM, Mikko wrote: >>>>> olcott kirjoitti 2.12.2025 klo 16.14: >>>>>> >>>>>> Flibble was the first one to use this term that I am aware of. >>> >>> It does not matter who first used the term here. >>> ... >>>>> Anyway, any claim that a problem contradict something is >>>>> a category error because the meanings of "problem" and >>>>> "contradict" are not compatible. >>>> >>>> When the halting problem contradicts the definition >>>> of a Turing machine decider >>> >>> A contradiction means that all claims of some set cannot be true. It >>> is a category error to apply the term "contradiction" to non-claims. >>> Examples of non-claims are problem and definition. An example of >>> category error is "the halting problem contradicts the definition of >>> a Turing machine decider". >> >> The halting problem contradicts the definition >> of a Turing machine decider proving that it is >> wrong because the definition of a Turing machine >> decider is foundational. > > That still contains the same category error pointed out in my > prevous comment as quoted above. > Part of his problem is that his claim of the error in the problem turns out to be isomorphic with the claim that a Universal Turing Machine can't exist, and if that is true, then his whole foundation crumbles. The key is he ways that the input can't mean the behavior of the machine it describes when actually run, but if you can have UTMs, then there *IS* a way to make an input that fully describes the full behavior of the machine when actually run. If the encoding his machine can't do that, then the error is in the encoding that his machine takes. You can't prove non-existance by showing one example doesn't work. But then, that is the sort of error he always makes, that you can prove a universal with an example, because he just doesn't understand what the terms mean.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-27 09:21 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- faking ignorance |
| Message-ID | <10g9qa3$1h4d5$1@dont-email.me> |
| In reply to | #641297 |
On 11/27/2025 1:49 AM, Mikko wrote:
> olcott kirjoitti 26.11.2025 klo 17.17:
>> On 11/26/2025 4:01 AM, Mikko wrote:
>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>
>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto to
>>>>>>>>>>>>>>>>>>>>>>>>> the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell whether
>>>>>>>>>>>>>>>>>>> test.c halts is not
>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect
>>>>>>>>>>>>>>>>>>> answer is not even
>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D)
>>>>>>>>>>>>>>>>>>> with the same
>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or
>>>>>>>>>>>>>>>>>>> do whatever H would
>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D)
>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies. According to
>>>>>>>>>>>>>>>>> C semantics
>>>>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If that happens then H does not return and therefore is
>>>>>>>>>>>>>>>>> not a decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That seems to confirm that the definition of "decider" is
>>>>>>>>>>>>> over your head.
>>>>>>>>>>>>
>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>
>>>>>>>>>>> The termination problem is not about specifying "to its
>>>>>>>>>>> termination
>>>>>>>>>>> analyzer". Instead the termination problem is to determine
>>>>>>>>>>> whether
>>>>>>>>>>> a program terminates every time when used as it was designed
>>>>>>>>>>> to be
>>>>>>>>>>> used.
>>>>>>>>>>
>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>
>>>>>>>>> Every halt decider is required to report on the behaviour asked
>>>>>>>>> about.
>>>>>>>>
>>>>>>>> And this is incorrect when it has not access to
>>>>>>>> the behavior that it is asked about.
>>>>>>>
>>>>>>> No, it is not. The solution to the halting problem must include the
>>>>>>> necessary access. Conversely, a proof that the necessary access is
>>>>>>> impossible is sufficient to prove that halting problem is
>>>>>>> unsolvable.
>>>>>>
>>>>>> Reporing on the behavior of DD() executed from
>>>>>> main requires HHH to report on information
>>>>>> that is not contained in its input thus it is
>>>>>> incorrect to require HHH to report on that.
>>>>>
>>>>> That HHH fails to meet the requirements does not mean that the
>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>> decider.
>>>>>
>>>>
>>>> That HHH fails to meet the requirements by itself does
>>>> not mean that the requirements are wrong.
>>>>
>>>> Turing machine deciders only compute a mapping from
>>>> their [finite string] inputs to an accept or reject
>>>> state on the basis that this [finite string] input
>>>> specifies or fails to specify a semantic or syntactic
>>>> property.
>>>>
>>>> That the information that HHH is required to report
>>>> on simply is not contained in its input is what makes
>>>> the requirements wrong.
>>>
>>> No, it merely means that the designer ot HHH has failed to specify the
>>> encoding rules so that the input contains the full specification of the
>>> behaviour.
>
>> In other words you are trying to get away with
>> disagreeing with the semantics of the x86 language
>> or the semantics of the C programing language.
>
> You are the one who disagrees with the x86 processors about the x86
> language semantics. When an x86 processor executes a program it executes
> according to the x86 semantics. When DD is executed according to the x86
> semantics it halts. Anybody who says that DD specifies a non-halting
> behaviour disagrees with the x86 semantics.
>
The DD that halts is not the same DD that is
an input to HHH(DD). The input to HHH(DD)
specifies non-halting behavior that HHH
recognizes and terminates.
Certainly you are no so ignorant that you
honestly believe that the caller of a function
is exactly one-and-the-same-thing as an
argument to this same function.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2025-11-27 10:40 -0500 |
| Subject | Re: The halting problem is incorrect two different ways --- faking ignorance |
| Message-ID | <4i_VQ.76647$YX2e.6335@fx14.iad> |
| In reply to | #641313 |
On 11/27/25 10:21 AM, olcott wrote:
> On 11/27/2025 1:49 AM, Mikko wrote:
>> olcott kirjoitti 26.11.2025 klo 17.17:
>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>
>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto
>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell whether
>>>>>>>>>>>>>>>>>>>> test.c halts is not
>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect
>>>>>>>>>>>>>>>>>>>> answer is not even
>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D)
>>>>>>>>>>>>>>>>>>>> with the same
>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or
>>>>>>>>>>>>>>>>>>>> do whatever H would
>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D)
>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies. According to
>>>>>>>>>>>>>>>>>> C semantics
>>>>>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If that happens then H does not return and therefore
>>>>>>>>>>>>>>>>>> is not a decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That seems to confirm that the definition of "decider" is
>>>>>>>>>>>>>> over your head.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>
>>>>>>>>>>>> The termination problem is not about specifying "to its
>>>>>>>>>>>> termination
>>>>>>>>>>>> analyzer". Instead the termination problem is to determine
>>>>>>>>>>>> whether
>>>>>>>>>>>> a program terminates every time when used as it was designed
>>>>>>>>>>>> to be
>>>>>>>>>>>> used.
>>>>>>>>>>>
>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>
>>>>>>>>>> Every halt decider is required to report on the behaviour
>>>>>>>>>> asked about.
>>>>>>>>>
>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>> the behavior that it is asked about.
>>>>>>>>
>>>>>>>> No, it is not. The solution to the halting problem must include the
>>>>>>>> necessary access. Conversely, a proof that the necessary access is
>>>>>>>> impossible is sufficient to prove that halting problem is
>>>>>>>> unsolvable.
>>>>>>>
>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>> main requires HHH to report on information
>>>>>>> that is not contained in its input thus it is
>>>>>>> incorrect to require HHH to report on that.
>>>>>>
>>>>>> That HHH fails to meet the requirements does not mean that the
>>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>>> decider.
>>>>>>
>>>>>
>>>>> That HHH fails to meet the requirements by itself does
>>>>> not mean that the requirements are wrong.
>>>>>
>>>>> Turing machine deciders only compute a mapping from
>>>>> their [finite string] inputs to an accept or reject
>>>>> state on the basis that this [finite string] input
>>>>> specifies or fails to specify a semantic or syntactic
>>>>> property.
>>>>>
>>>>> That the information that HHH is required to report
>>>>> on simply is not contained in its input is what makes
>>>>> the requirements wrong.
>>>>
>>>> No, it merely means that the designer ot HHH has failed to specify the
>>>> encoding rules so that the input contains the full specification of the
>>>> behaviour.
>>
>>> In other words you are trying to get away with
>>> disagreeing with the semantics of the x86 language
>>> or the semantics of the C programing language.
>>
>> You are the one who disagrees with the x86 processors about the x86
>> language semantics. When an x86 processor executes a program it executes
>> according to the x86 semantics. When DD is executed according to the x86
>> semantics it halts. Anybody who says that DD specifies a non-halting
>> behaviour disagrees with the x86 semantics.
>>
>
> The DD that halts is not the same DD that is
> an input to HHH(DD). The input to HHH(DD)
> specifies non-halting behavior that HHH
> recognizes and terminates.
Then somebody is lying.
As DD is supposed to call HHH with a representation of itself.
>
> Certainly you are no so ignorant that you
> honestly believe that the caller of a function
> is exactly one-and-the-same-thing as an
> argument to this same function.
>
But it can be the representation of it.
The fact that you are so stupid as to not understand the nature of
representation doesn't make the concept wrong, it just makes you wrong.
All you are doing is proving how ignorant and stupid you are, and that
you don't care about truth, but are just a pathological liar.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-27 18:37 +0000 |
| Subject | Re: The halting problem is incorrect two different ways --- faking ignorance |
| Message-ID | <20251127102426.781@kylheku.com> |
| In reply to | #641315 |
On 2025-11-27, Richard Damon <Richard@Damon-Family.org> wrote:
> On 11/27/25 10:21 AM, olcott wrote:
>> The DD that halts is not the same DD that is
>> an input to HHH(DD). The input to HHH(DD)
>> specifies non-halting behavior that HHH
>> recognizes and terminates.
>
> Then somebody is lying.
Yes; Olcott lying to himself through code.
HHH makes this function call:
u32 Root = Init_Halts_HH(&Aborted, &execution_trace, &decoded, &code_end, (u32)P,
&master_state, &slave_state, &slave_stack);
execution_trace is pointlessly doubly indirected; it holds a pointer
aimed at a static area right inside the coe of HHH. The above function
deos this:
if (**execution_trace == 0x90909090)
{
**Aborted = 0;
**execution_trace = (u32)Allocate(sizeof(Decoded_Line_Of_Code) * 10000);
Output((char*)"\nBegin Local Halt Decider Simulation "
"Execution Trace Stored at:", **execution_trace);
return 1;
}
return 0;
(You can see here that the argument should just be execution_trace,
and the allocation *execution_trace = ...; Ths execution_trace points
into the code of HHH.)
So the first call to HHH allocates the execution trace and changes
the static value in the code space from 0x90909090 to a different value.
In ths case 1 is returned. Otherwise nothing is allocated and 0 is
returned.
This return value is captured as Root and changes the behavior of the
first HHH instance compared to the others.
The first HHH instance performs the abort check. The other instances
are free running simulation steppers.
This changes DD from non-terminating to terminating. When HHH changes
its behavior form aborting and returning 0, to indefinitely simulating,
then DD changes its behavior from terminating to nonterminating.
> As DD is supposed to call HHH with a representation of itself.
Unfortunately, DD's representation is tied up that of HHH,
and HHH is self-modifying code.
Needless to say, you cannot do that; you can't use self-modifying code
to change a terminating test case to non-terminating and then claim that
0 is the correct return value.
--
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 | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-27 18:24 +0000 |
| Subject | Re: The halting problem is incorrect two different ways --- faking ignorance |
| Message-ID | <20251127101931.514@kylheku.com> |
| In reply to | #641313 |
On 2025-11-27, olcott <polcott333@gmail.com> wrote: > The DD that halts is not the same DD that is > an input to HHH(DD). The input to HHH(DD) > specifies non-halting behavior that HHH > recognizes and terminates. That is completely retarded, insane, and easily proven wrong by taking the very simulation that HHH(DD) incompletely conducted and showing that it proceeds toward termination (HHH wrongly decided 0). You have no valid counterargument, only angry sputtering. The Halting Theorem shows you are wrong. Correctly implemented test cases (using pure functions) in your onw apparatus show that you are wrong. The only way that the DD that is the input to HHH can be different is if HHH alters its behavior with static state to become a different function. And that is exactly what you coded in your idiotic Halt7. The HHH which is called first and sees execution_trace == 0x90909090 behaves differently from the one which sees a different value. Once HHH starts behaving differently, that changes DD to a different test case because DD is built out of HHH. Your picture should be freatured next to "idiot" and "imbecile" entries to in any illustrated dictionary. -- 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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2025-11-28 10:18 +0200 |
| Subject | Re: The halting problem is incorrect two different ways --- faking ignorance |
| Message-ID | <10gblt0$27ocf$1@dont-email.me> |
| In reply to | #641313 |
olcott kirjoitti 27.11.2025 klo 17.21:
> On 11/27/2025 1:49 AM, Mikko wrote:
>> olcott kirjoitti 26.11.2025 klo 17.17:
>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>
>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>
>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto
>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell whether
>>>>>>>>>>>>>>>>>>>> test.c halts is not
>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect
>>>>>>>>>>>>>>>>>>>> answer is not even
>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return from H(D)
>>>>>>>>>>>>>>>>>>>> with the same
>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or
>>>>>>>>>>>>>>>>>>>> do whatever H would
>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D)
>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies. According to
>>>>>>>>>>>>>>>>>> C semantics
>>>>>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D)
>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If that happens then H does not return and therefore
>>>>>>>>>>>>>>>>>> is not a decider.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That seems to confirm that the definition of "decider" is
>>>>>>>>>>>>>> over your head.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>
>>>>>>>>>>>> The termination problem is not about specifying "to its
>>>>>>>>>>>> termination
>>>>>>>>>>>> analyzer". Instead the termination problem is to determine
>>>>>>>>>>>> whether
>>>>>>>>>>>> a program terminates every time when used as it was designed
>>>>>>>>>>>> to be
>>>>>>>>>>>> used.
>>>>>>>>>>>
>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>
>>>>>>>>>> Every halt decider is required to report on the behaviour
>>>>>>>>>> asked about.
>>>>>>>>>
>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>> the behavior that it is asked about.
>>>>>>>>
>>>>>>>> No, it is not. The solution to the halting problem must include the
>>>>>>>> necessary access. Conversely, a proof that the necessary access is
>>>>>>>> impossible is sufficient to prove that halting problem is
>>>>>>>> unsolvable.
>>>>>>>
>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>> main requires HHH to report on information
>>>>>>> that is not contained in its input thus it is
>>>>>>> incorrect to require HHH to report on that.
>>>>>>
>>>>>> That HHH fails to meet the requirements does not mean that the
>>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>>> decider.
>>>>>>
>>>>>
>>>>> That HHH fails to meet the requirements by itself does
>>>>> not mean that the requirements are wrong.
>>>>>
>>>>> Turing machine deciders only compute a mapping from
>>>>> their [finite string] inputs to an accept or reject
>>>>> state on the basis that this [finite string] input
>>>>> specifies or fails to specify a semantic or syntactic
>>>>> property.
>>>>>
>>>>> That the information that HHH is required to report
>>>>> on simply is not contained in its input is what makes
>>>>> the requirements wrong.
>>>>
>>>> No, it merely means that the designer ot HHH has failed to specify the
>>>> encoding rules so that the input contains the full specification of the
>>>> behaviour.
>>
>>> In other words you are trying to get away with
>>> disagreeing with the semantics of the x86 language
>>> or the semantics of the C programing language.
>>
>> You are the one who disagrees with the x86 processors about the x86
>> language semantics. When an x86 processor executes a program it executes
>> according to the x86 semantics. When DD is executed according to the x86
>> semantics it halts. Anybody who says that DD specifies a non-halting
>> behaviour disagrees with the x86 semantics.
> The DD that halts is not the same DD that is
> an input to HHH(DD).
You didn't say "another DD" or anything else that would mean that "DD"
does not mean the same as usually, which is the DD stored in your GitHub
repository. Therefore what you said is said about the same DD. That you
now claim you were deceiving with equivocation does not alter what you
said earlier.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-28 08:52 -0600 |
| Subject | Re: The halting problem is incorrect two different ways --- faking ignorance |
| Message-ID | <10gcd02$2gevj$1@dont-email.me> |
| In reply to | #641328 |
On 11/28/2025 2:18 AM, Mikko wrote:
> olcott kirjoitti 27.11.2025 klo 17.21:
>> On 11/27/2025 1:49 AM, Mikko wrote:
>>> olcott kirjoitti 26.11.2025 klo 17.17:
>>>> On 11/26/2025 4:01 AM, Mikko wrote:
>>>>> olcott kirjoitti 17.11.2025 klo 15.31:
>>>>>> On 11/17/2025 2:43 AM, Mikko wrote:
>>>>>>> On 2025-11-17 00:12:14 +0000, olcott said:
>>>>>>>
>>>>>>>> On 11/16/2025 3:18 AM, Mikko wrote:
>>>>>>>>> On 2025-11-15 16:12:49 +0000, olcott said:
>>>>>>>>>
>>>>>>>>>> On 11/15/2025 4:15 AM, Mikko wrote:
>>>>>>>>>>> On 2025-11-14 15:00:09 +0000, olcott said:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/14/2025 3:21 AM, Mikko wrote:
>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11/13/2025 2:48 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11/12/2025 1:09 AM, Mikko wrote:
>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11/11/2025 2:59 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11/10/2025 3:43 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11/9/2025 4:22 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 11/8/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/7/2025 2:05 AM, Mikko wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> D simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> That is merely a defect in H and irrelevanto
>>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other
>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> That's a stupid statement.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Stupid is better than false.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> It is stupidly false because you didn't bother
>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A statement about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that
>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches
>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt
>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive
>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Have you ever done any actual programming?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A question about me is off topic in comp.theory.
>>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> *This is my key foundational point*
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int H(char* P);
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int D()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(D);
>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The above is in test.c
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> simulate.exe implements a C interpreter.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> simulate test.c
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> runs the interpreter on the above source file
>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any program that does not correctly tell whether
>>>>>>>>>>>>>>>>>>>>> test.c halts is not
>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an incorrect
>>>>>>>>>>>>>>>>>>>>> answer is not even
>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When this interpreter sees the call to H(D)
>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> According to C semanttics it should simulate H(D),
>>>>>>>>>>>>>>>>>>>>> either simultating
>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return from
>>>>>>>>>>>>>>>>>>>>> H(D) with the same
>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if executed, or
>>>>>>>>>>>>>>>>>>>>> do whatever H would
>>>>>>>>>>>>>>>>>>>>> do if H would not not return.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That is not the behavior that the input to H(D)
>>>>>>>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>>>>>>>> simulator.exe simulates Test.c. This simulates D that
>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It is the behavour C semantics specifies. According
>>>>>>>>>>>>>>>>>>> to C semantics
>>>>>>>>>>>>>>>>>>> any other behavour that produces the same result is
>>>>>>>>>>>>>>>>>>> equally valid.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So D remains stuck in recursive simulation never being
>>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling
>>>>>>>>>>>>>>>>>>>> H(D)
>>>>>>>>>>>>>>>>>>>> again and again.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If that happens then H does not return and therefore
>>>>>>>>>>>>>>>>>>> is not a decider.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Maybe my work is over your head.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Maybe the definition of "decider" is over your head.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> typedef int (*ptr)();
>>>>>>>>>>>>>>>> int HHH(ptr P);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int DD()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> int Halt_Status = HHH(DD);
>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> HHH(DD);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> People here have consistently lied about
>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return"
>>>>>>>>>>>>>>>> statement final halt state for three years.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You yourself have not told the truth about
>>>>>>>>>>>>>>>> this even once.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That seems to confirm that the definition of "decider" is
>>>>>>>>>>>>>>> over your head.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am just talking at the level of the execution
>>>>>>>>>>>>>> trace of C functions. D does specify non-halting
>>>>>>>>>>>>>> behavior to its termination analyzer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The termination problem is not about specifying "to its
>>>>>>>>>>>>> termination
>>>>>>>>>>>>> analyzer". Instead the termination problem is to determine
>>>>>>>>>>>>> whether
>>>>>>>>>>>>> a program terminates every time when used as it was
>>>>>>>>>>>>> designed to be
>>>>>>>>>>>>> used.
>>>>>>>>>>>>
>>>>>>>>>>>> The halting problem requires that a halt decider
>>>>>>>>>>>> correctly report on the behavior of its caller
>>>>>>>>>>>> and no halt decider can even see its actual caller.
>>>>>>>>>>>
>>>>>>>>>>> Every halt decider is required to report on the behaviour
>>>>>>>>>>> asked about.
>>>>>>>>>>
>>>>>>>>>> And this is incorrect when it has not access to
>>>>>>>>>> the behavior that it is asked about.
>>>>>>>>>
>>>>>>>>> No, it is not. The solution to the halting problem must include
>>>>>>>>> the
>>>>>>>>> necessary access. Conversely, a proof that the necessary access is
>>>>>>>>> impossible is sufficient to prove that halting problem is
>>>>>>>>> unsolvable.
>>>>>>>>
>>>>>>>> Reporing on the behavior of DD() executed from
>>>>>>>> main requires HHH to report on information
>>>>>>>> that is not contained in its input thus it is
>>>>>>>> incorrect to require HHH to report on that.
>>>>>>>
>>>>>>> That HHH fails to meet the requirements does not mean that the
>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
>>>>>>> decider.
>>>>>>>
>>>>>>
>>>>>> That HHH fails to meet the requirements by itself does
>>>>>> not mean that the requirements are wrong.
>>>>>>
>>>>>> Turing machine deciders only compute a mapping from
>>>>>> their [finite string] inputs to an accept or reject
>>>>>> state on the basis that this [finite string] input
>>>>>> specifies or fails to specify a semantic or syntactic
>>>>>> property.
>>>>>>
>>>>>> That the information that HHH is required to report
>>>>>> on simply is not contained in its input is what makes
>>>>>> the requirements wrong.
>>>>>
>>>>> No, it merely means that the designer ot HHH has failed to specify the
>>>>> encoding rules so that the input contains the full specification of
>>>>> the
>>>>> behaviour.
>>>
>>>> In other words you are trying to get away with
>>>> disagreeing with the semantics of the x86 language
>>>> or the semantics of the C programing language.
>>>
>>> You are the one who disagrees with the x86 processors about the x86
>>> language semantics. When an x86 processor executes a program it executes
>>> according to the x86 semantics. When DD is executed according to the x86
>>> semantics it halts. Anybody who says that DD specifies a non-halting
>>> behaviour disagrees with the x86 semantics.
>> The DD that halts is not the same DD that is
>> an input to HHH(DD).
>
> You didn't say "another DD" or anything else that would mean that "DD"
> does not mean the same as usually, which is the DD stored in your GitHub
> repository. Therefore what you said is said about the same DD. That you
> now claim you were deceiving with equivocation does not alter what you
> said earlier.
>
That DD simulated by HHH never stops running
unless aborted by HHH proves that the input
to HHH(DD) specifies non halting behavior.
The caller of a function is never an argument to
this same function. The DD executed in main that
calls HHH(DD) is not the same DD as the one that
HHH simulates.
--
Copyright 2025 Olcott
My 28 year goal has been to make
"true on the basis of meaning" computable.
This required establishing a new foundation
for correct reasoning.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | sci.math
csiph-web