Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #133775 > unrolled thread
| Started by | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| First post | 2025-10-26 05:29 +0000 |
| Last post | 2025-11-05 10:56 -0600 |
| Articles | 20 on this page of 115 — 8 participants |
Back to article view | Back to comp.theory
x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 05:29 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-10-26 09:52 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 15:20 +0000
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 12:37 -0700
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 20:30 +0000
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 13:43 -0700
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 13:49 -0700
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-26 21:46 +0000
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 22:16 -0700
Re: x86utm with "reckoning" code: git repo with published commit. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-10-26 22:17 -0700
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-31 04:51 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 05:18 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-31 15:38 +0000
Re: x86utm with "reckoning" code: git repo with published commit. olcott <polcott333@gmail.com> - 2025-10-31 11:14 -0500
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-10-31 16:35 +0000
Re: x86utm with "reckoning" code: git repo with published commit. olcott <polcott333@gmail.com> - 2025-10-31 11:55 -0500
Re: x86utm with "reckoning" code: git repo with published commit. Richard Damon <Richard@Damon-Family.org> - 2025-10-31 13:51 -0400
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 18:03 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Richard Damon <Richard@Damon-Family.org> - 2025-10-31 14:10 -0400
Re: x86utm with "reckoning" code: git repo with published commit. olcott <polcott333@gmail.com> - 2025-10-31 11:23 -0500
Re: x86utm with "reckoning" code: git repo with published commit. Richard Damon <Richard@Damon-Family.org> - 2025-10-31 13:19 -0400
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-10-31 17:37 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-04 18:04 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 18:36 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-04 18:59 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 19:36 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-04 21:03 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-04 21:58 +0000
Re: x86utm with "reckoning" code: git repo with published commit. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-05 01:20 +0000
Kaz does not understand his own code. olcott <polcott333@gmail.com> - 2025-11-04 20:14 -0600
Re: Kaz does not understand his own code. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 02:43 +0000
Re: Kaz does not understand his own code. olcott <polcott333@gmail.com> - 2025-11-04 21:06 -0600
Re: Kaz does not understand his own code. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 03:33 +0000
Re: Kaz does not understand his own code. joes <noreply@example.org> - 2025-11-05 07:47 +0000
Re: Kaz does not understand his own code --- I AM PROVED EXACTLY CORRECT olcott <polcott333@gmail.com> - 2025-11-04 21:51 -0600
Re: Kaz does not understand his own code --- I AM PROVED EXACTLY CORRECT Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 05:12 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-04 23:23 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 07:01 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 08:55 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 17:35 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 12:17 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 13:43 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:24 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 20:39 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:43 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 01:56 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 20:21 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 04:36 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 23:12 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 07:54 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 09:19 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-06 16:39 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 11:10 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 17:16 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 11:26 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 12:34 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 11:58 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 13:01 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 12:04 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-06 13:15 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 18:37 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-06 20:03 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:24 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:16 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:39 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 22:10 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:04 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 20:45 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:57 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 18:14 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 12:27 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 18:46 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 14:10 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-06 21:03 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:54 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 21:08 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 20:24 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 22:05 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 21:15 -0600
Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:18 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:27 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:32 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:38 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:39 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:50 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 22:53 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 19:57 -0800
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 21:57 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 23:04 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 22:15 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-05 23:25 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-05 23:00 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 07:51 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 09:16 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 10:22 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 10:08 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 11:26 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 10:49 -0600
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear dbush <dbush.mobile@gmail.com> - 2025-11-06 11:56 -0500
Re: Olcott proves he's not interested in an honest dialogue by actively avoiding being clear olcott <polcott333@gmail.com> - 2025-11-06 11:16 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 13:49 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. joes <noreply@example.org> - 2025-11-05 18:55 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:23 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. joes <noreply@example.org> - 2025-11-06 14:33 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-06 09:13 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-05 21:38 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:15 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 19:41 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. dbush <dbush.mobile@gmail.com> - 2025-11-05 20:45 -0500
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 18:39 -0800
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-05 12:04 -0800
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. joes <noreply@example.org> - 2025-11-05 07:42 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 05:33 -0600
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2025-11-05 16:43 +0000
Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. olcott <polcott333@gmail.com> - 2025-11-05 10:56 -0600
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 12:17 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eg4b3$j7jt$1@dont-email.me> |
| In reply to | #135072 |
On 11/5/2025 11:35 AM, Kaz Kylheku wrote: > On 2025-11-05, olcott <polcott333@gmail.com> wrote: >> On 11/5/2025 1:01 AM, Kaz Kylheku wrote: >>> On 2025-11-05, olcott <polcott333@gmail.com> wrote: >>>> On 11/4/2025 8:43 PM, Kaz Kylheku wrote: >>>>>> The whole point is that D simulated by H >>>>>> cannot possibly reach its own simulated >>>>>> "return" statement no matter what H does. >>>>> >>>>> Yes; this doesn't happen while H is running. >>>>> >>>> >>>> *That is the definition of non-halting input* >>> >>> Well, anyway, there you go; that's how the "D simulated by H" is the >>> same halting D as the directly executed one. >> >> The whole point is that D simulated by H >> cannot possibly reach its own simulated >> "return" statement no matter what H does. >> >> The semantic halting property of the input >> to H(D) has been proven to be non-halting. > > So you are saying that no simulating decider could ever be wrong about > its D-like diagonal input case, if it conducts an incomplete (but > otherwise correct) simulation of its input and then returns false for > any reason whatsoever (such as "if the input is taking more than three > steps, it must be nonterminating"). > Boy is that an intentionally deceptive and moronically stupid paraphrase of what I have been saying for years. Here is the essence of what I am proposing some details are left out because with too many details and people get confused. On 11/4/2025 8:43 PM, Kaz Kylheku wrote: > On 2025-11-05, olcott <polcott333@gmail.com> wrote: >> >> The whole point is that D simulated by H >> cannot possbly reach its own simulated >> "return" statement no matter what H does. > > Yes; this doesn't happen while H is running. > > So while H does /something/, no matter what H does, > that D simulation won't reach the return statement. > Kaz finally affirmed the key element of my proof after waiting three years for this. This is the key element of my semantic properties of FINITE STRING INPUTS. This is a correction and an elaboration of Rice's theorem semantic properties of programs. It seems (and this is not totally verified) that Rice is talking at an abstract level that ignores that Turing machines only take finite string inputs and not other actual Turing Machines. His proof seem seems to assume actual Turing machines as inputs. I correct that error. Second Semantic Properties of Finite String Inputs (SPoFSI) are stipulated to be measured on the basis of the behavior of an input P simulated by a decider** H on the basis of H simulating N instructions of input P according to the semantics of the specification language of P. ** Technically H is a partial decider or a termination analyzer. > And you believe that this will get you written into the history books as > the researcher who showed that the halting problem is all wrong. > > You think that math/CS academia will see it from your perspective and > just agree that when H detaches from D, the question of whether the > abandoned simulation is terminating becomes off-limits (like some sort > "inadmissible evidence")? > This whole aspect of what you have been saying has been refuted. When you resume the simulation from the exact same machine state where H.i == 3 then you get the same result. When you do it differently then this then it is not any actual resumption. > But at least hopefully you did see that the simulation of D started by H > can be completed, resulting in the same total 11 wsteps as a directly > executed D. (It just cannot all happen while H is running; H obviously > cannot be the sole driver which pushes the simulation to completion, > since it only pushes the first three steps.) > Only when you cheat and do not resume at the exact same machine state where H.i == 3. > I and others have not lied or been mistaken in any observations about > what is going on. Everyone agrees that H returned false after certain > steps that were correct up to that point, that the input didn't reach > its return statement while simulated by H, and that there is an > unfinished simulation that can be continued and has been correctly shown > to reach its return statemnt. > Because the same not reached the "return" statement would occur for an infinite number of simulated steps any case of D reaching its "return" instruction is some sort of cheating by not resuming at the exact same machine state where H rejected D. > Your whole position is that if a simluation does not reach > termination /while being simulated by the decider/ then it > is correct to call it nonterminating. When H correctly predicts that if it simulated D an infinite number of steps that its simulated D would never reach its own simulated "return" statement then H is necessarily correct to reject D on the basis of Semantic Properties of Finite String Inputs (SPoFSI). > (If not absolutely then > at least in situations when the input is the diagonal case). > -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-05 13:43 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eg5t1$jgbh$1@dont-email.me> |
| In reply to | #135074 |
On 11/5/2025 1:17 PM, olcott wrote:
>
> When H correctly predicts that if it simulated D an infinite
> number of steps that its simulated D would never reach its own
> simulated "return" statement
In other words, H reports on the following non-input:
int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 19:24 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10egtd6$qecj$2@dont-email.me> |
| In reply to | #135075 |
On 11/5/2025 12:43 PM, dbush wrote:
> On 11/5/2025 1:17 PM, olcott wrote:
>>
>> When H correctly predicts that if it simulated D an infinite
>> number of steps that its simulated D would never reach its own
>> simulated "return" statement
>
> In other words, H reports on the following non-input:
>
> int D()
> {
> int Halt_Status = UTM(D);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
>
>
I am not going to *plonk* you yet.
Very rarely you do say some things
that are not nonsense.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-05 20:39 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10egu8e$pn3p$1@dont-email.me> |
| In reply to | #135089 |
On 11/5/2025 8:24 PM, olcott wrote:
> On 11/5/2025 12:43 PM, dbush wrote:
>> On 11/5/2025 1:17 PM, olcott wrote:
>>>
>>> When H correctly predicts that if it simulated D an infinite
>>> number of steps that its simulated D would never reach its own
>>> simulated "return" statement
>>
>> In other words, H reports on the following non-input:
>>
>> int D()
>> {
>> int Halt_Status = UTM(D);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return Halt_Status;
>> }
>>
>>
>
> I am not going to *plonk* you yet.
> Very rarely you do say some things
> that are not nonsense.
>
And it is clearly not nonsense that H is reporting on the above code
which is not the code it was given.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 19:43 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10egufu$qlco$2@dont-email.me> |
| In reply to | #135091 |
On 11/5/2025 7:39 PM, dbush wrote:
> On 11/5/2025 8:24 PM, olcott wrote:
>> On 11/5/2025 12:43 PM, dbush wrote:
>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>
>>>> When H correctly predicts that if it simulated D an infinite
>>>> number of steps that its simulated D would never reach its own
>>>> simulated "return" statement
>>>
>>> In other words, H reports on the following non-input:
>>>
>>> int D()
>>> {
>>> int Halt_Status = UTM(D);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return Halt_Status;
>>> }
>>>
>>>
>>
>> I am not going to *plonk* you yet.
>> Very rarely you do say some things
>> that are not nonsense.
>>
>
> And it is clearly not nonsense that H is reporting on the above code
> which is not the code it was given.
It is not 100% nonsense, only about 50%.
H sees that D is stuck in recursive simulation.
That people here did not immediately see this
three years ago seems to indicate that people
here are terrible at actual programming.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-06 01:56 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251105175404.486@kylheku.com> |
| In reply to | #135094 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
> On 11/5/2025 7:39 PM, dbush wrote:
>> On 11/5/2025 8:24 PM, olcott wrote:
>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>
>>>>> When H correctly predicts that if it simulated D an infinite
>>>>> number of steps that its simulated D would never reach its own
>>>>> simulated "return" statement
>>>>
>>>> In other words, H reports on the following non-input:
>>>>
>>>> int D()
>>>> {
>>>> int Halt_Status = UTM(D);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return Halt_Status;
>>>> }
>>>>
>>>>
>>>
>>> I am not going to *plonk* you yet.
>>> Very rarely you do say some things
>>> that are not nonsense.
>>>
>>
>> And it is clearly not nonsense that H is reporting on the above code
>> which is not the code it was given.
>
> It is not 100% nonsense, only about 50%.
> H sees that D is stuck in recursive simulation.
Even 0.1% nonsense damns your result, if that bit of nonsense
is a necessary step in your chain of logic.
E.g. one bad derivation in a 1000 step proof is roughly 0.1%
nonsense.
If you want to go down in history as a computer science
researcher who redefined the halting problem,
your game has to be 100% nonsense-free.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 20:21 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eh0no$r76u$1@dont-email.me> |
| In reply to | #135097 |
On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>> On 11/5/2025 7:39 PM, dbush wrote:
>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>
>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>> number of steps that its simulated D would never reach its own
>>>>>> simulated "return" statement
>>>>>
>>>>> In other words, H reports on the following non-input:
>>>>>
>>>>> int D()
>>>>> {
>>>>> int Halt_Status = UTM(D);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
>>>>>
>>>>>
>>>>
>>>> I am not going to *plonk* you yet.
>>>> Very rarely you do say some things
>>>> that are not nonsense.
>>>>
>>>
>>> And it is clearly not nonsense that H is reporting on the above code
>>> which is not the code it was given.
>>
>> It is not 100% nonsense, only about 50%.
>> H sees that D is stuck in recursive simulation.
>
> Even 0.1% nonsense damns your result, if that bit of nonsense
> is a necessary step in your chain of logic.
>
> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
> nonsense.
>
> If you want to go down in history as a computer science
> researcher who redefined the halting problem,
> your game has to be 100% nonsense-free.
>
People (not LLMs) are so sure that I
must be wrong that they find it impossible
to see when I have actually proved my point.
LLMs give me lots of pushback that I address.
Then they revise their views. People can't do
that.
They start with the idea that I am wrong
and nothing can ever change this view.
Their whole foundation is Olcott is wrong.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-06 04:36 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251105202835.363@kylheku.com> |
| In reply to | #135101 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
> On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>> On 11/5/2025 7:39 PM, dbush wrote:
>>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>>
>>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>>> number of steps that its simulated D would never reach its own
>>>>>>> simulated "return" statement
>>>>>>
>>>>>> In other words, H reports on the following non-input:
>>>>>>
>>>>>> int D()
>>>>>> {
>>>>>> int Halt_Status = UTM(D);
>>>>>> if (Halt_Status)
>>>>>> HERE: goto HERE;
>>>>>> return Halt_Status;
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>> I am not going to *plonk* you yet.
>>>>> Very rarely you do say some things
>>>>> that are not nonsense.
>>>>>
>>>>
>>>> And it is clearly not nonsense that H is reporting on the above code
>>>> which is not the code it was given.
>>>
>>> It is not 100% nonsense, only about 50%.
>>> H sees that D is stuck in recursive simulation.
>>
>> Even 0.1% nonsense damns your result, if that bit of nonsense
>> is a necessary step in your chain of logic.
>>
>> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
>> nonsense.
>>
>> If you want to go down in history as a computer science
>> researcher who redefined the halting problem,
>> your game has to be 100% nonsense-free.
>>
>
> People (not LLMs) are so sure that I
> must be wrong that they find it impossible
> to see when I have actually proved my point.
If you think you've proven your point, but nobody here sees it,
then maybe you need to take it somewhere else, like the
next step --- establishing some academic contacts wwith a view
toward publishing.
Time is ticking away. You are on a trajectory of pissing it all away in
Usenet arguments, rather than on the trajectory of publishing and
becoming famous for dismantling the halting problem.
> LLMs give me lots of pushback that I address.
> Then they revise their views. People can't do
> that.
Language models do not have "views". They have context windows full of
input tokens, and a trained network full of weights for predicting
output tokens.
>
> They start with the idea that I am wrong
> and nothing can ever change this view.
> Their whole foundation is Olcott is wrong.
You are ignoring all the times someone has agreed with
you on some point.
You can't expect smart, informed people to agree with
you when you are wrong.
Repeating the wrong point may work with token-predicting slot machines;
it won't work with informed, thinking people.
People are much better at recognizing that you are rephrasing the same
thing in slightly different ways.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 23:12 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10ehaog$th3q$1@dont-email.me> |
| In reply to | #135125 |
On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>> On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>> On 11/5/2025 7:39 PM, dbush wrote:
>>>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>>>
>>>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>>>> number of steps that its simulated D would never reach its own
>>>>>>>> simulated "return" statement
>>>>>>>
>>>>>>> In other words, H reports on the following non-input:
>>>>>>>
>>>>>>> int D()
>>>>>>> {
>>>>>>> int Halt_Status = UTM(D);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I am not going to *plonk* you yet.
>>>>>> Very rarely you do say some things
>>>>>> that are not nonsense.
>>>>>>
>>>>>
>>>>> And it is clearly not nonsense that H is reporting on the above code
>>>>> which is not the code it was given.
>>>>
>>>> It is not 100% nonsense, only about 50%.
>>>> H sees that D is stuck in recursive simulation.
>>>
>>> Even 0.1% nonsense damns your result, if that bit of nonsense
>>> is a necessary step in your chain of logic.
>>>
>>> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
>>> nonsense.
>>>
>>> If you want to go down in history as a computer science
>>> researcher who redefined the halting problem,
>>> your game has to be 100% nonsense-free.
>>>
>>
>> People (not LLMs) are so sure that I
>> must be wrong that they find it impossible
>> to see when I have actually proved my point.
>
> If you think you've proven your point, but nobody here sees it,
> then maybe you need to take it somewhere else, like the
> next step --- establishing some academic contacts wwith a view
> toward publishing.
>
It took me three years to get anyone to agree to
the dead obvious truth that D simulated by H
cannot possibly reach its own simulated "return"
statement final halt state because all people
here make disagreement their highest priority.
If we could switch to an actual honest dialogue
things would go much more quickly. I just made
more progress with Clause AI than I made with
everyone here for the last 22 years.
> Time is ticking away. You are on a trajectory of pissing it all away in
> Usenet arguments, rather than on the trajectory of publishing and
> becoming famous for dismantling the halting problem.
>
>> LLMs give me lots of pushback that I address.
>> Then they revise their views. People can't do
>> that.
>
> Language models do not have "views". They have context windows full of
> input tokens, and a trained network full of weights for predicting
> output tokens.
>
Clearly you have not spoken to them lately.
>>
>> They start with the idea that I am wrong
>> and nothing can ever change this view.
>> Their whole foundation is Olcott is wrong.
>
> You are ignoring all the times someone has agreed with
> you on some point.
>
> You can't expect smart, informed people to agree with
> you when you are wrong.
>
> Repeating the wrong point may work with token-predicting slot machines;
> it won't work with informed, thinking people.
>
> People are much better at recognizing that you are rephrasing the same
> thing in slightly different ways.
>
I was able to get Claude AI to understand how I
proved that the halting problem is isomorphic to
the Liar Paradox when we pay attention to rather
than totally ignore "who is asked the question".
Computer science people ignore this assuming that
everything outside of their field is irrelevant to
it. Claude AI understood all of these fields and
how they fit together.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-06 07:54 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10ei5pj$14i1k$2@dont-email.me> |
| In reply to | #135127 |
On 11/6/2025 12:12 AM, olcott wrote:
> On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>> On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/5/2025 7:39 PM, dbush wrote:
>>>>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>>>>> number of steps that its simulated D would never reach its own
>>>>>>>>> simulated "return" statement
>>>>>>>>
>>>>>>>> In other words, H reports on the following non-input:
>>>>>>>>
>>>>>>>> int D()
>>>>>>>> {
>>>>>>>> int Halt_Status = UTM(D);
>>>>>>>> if (Halt_Status)
>>>>>>>> HERE: goto HERE;
>>>>>>>> return Halt_Status;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I am not going to *plonk* you yet.
>>>>>>> Very rarely you do say some things
>>>>>>> that are not nonsense.
>>>>>>>
>>>>>>
>>>>>> And it is clearly not nonsense that H is reporting on the above code
>>>>>> which is not the code it was given.
>>>>>
>>>>> It is not 100% nonsense, only about 50%.
>>>>> H sees that D is stuck in recursive simulation.
>>>>
>>>> Even 0.1% nonsense damns your result, if that bit of nonsense
>>>> is a necessary step in your chain of logic.
>>>>
>>>> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
>>>> nonsense.
>>>>
>>>> If you want to go down in history as a computer science
>>>> researcher who redefined the halting problem,
>>>> your game has to be 100% nonsense-free.
>>>>
>>>
>>> People (not LLMs) are so sure that I
>>> must be wrong that they find it impossible
>>> to see when I have actually proved my point.
>>
>> If you think you've proven your point, but nobody here sees it,
>> then maybe you need to take it somewhere else, like the
>> next step --- establishing some academic contacts wwith a view
>> toward publishing.
>>
>
> It took me three years to get anyone to agree to
> the dead obvious truth that D simulated by H
> cannot possibly reach its own simulated "return"
> statement final halt state because all people
> here make disagreement their highest priority.
>
> If we could switch to an actual honest dialogue
Then you would clarify this sentence:
> H correctly predicts the finite string D simulated by
> H cannot possibly reach its own final
> halt state.
By prefixing all instances of "D" and "H" in the above sentence with
exactly one of:
* algorithm
* C function
* finite string
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-06 09:19 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eiea6$1731j$1@dont-email.me> |
| In reply to | #135137 |
On 11/6/2025 6:54 AM, dbush wrote:
> On 11/6/2025 12:12 AM, olcott wrote:
>> On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>> On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/5/2025 7:39 PM, dbush wrote:
>>>>>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>>>>>> number of steps that its simulated D would never reach its own
>>>>>>>>>> simulated "return" statement
>>>>>>>>>
>>>>>>>>> In other words, H reports on the following non-input:
>>>>>>>>>
>>>>>>>>> int D()
>>>>>>>>> {
>>>>>>>>> int Halt_Status = UTM(D);
>>>>>>>>> if (Halt_Status)
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> return Halt_Status;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I am not going to *plonk* you yet.
>>>>>>>> Very rarely you do say some things
>>>>>>>> that are not nonsense.
>>>>>>>>
>>>>>>>
>>>>>>> And it is clearly not nonsense that H is reporting on the above code
>>>>>>> which is not the code it was given.
>>>>>>
>>>>>> It is not 100% nonsense, only about 50%.
>>>>>> H sees that D is stuck in recursive simulation.
>>>>>
>>>>> Even 0.1% nonsense damns your result, if that bit of nonsense
>>>>> is a necessary step in your chain of logic.
>>>>>
>>>>> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
>>>>> nonsense.
>>>>>
>>>>> If you want to go down in history as a computer science
>>>>> researcher who redefined the halting problem,
>>>>> your game has to be 100% nonsense-free.
>>>>>
>>>>
>>>> People (not LLMs) are so sure that I
>>>> must be wrong that they find it impossible
>>>> to see when I have actually proved my point.
>>>
>>> If you think you've proven your point, but nobody here sees it,
>>> then maybe you need to take it somewhere else, like the
>>> next step --- establishing some academic contacts wwith a view
>>> toward publishing.
>>>
>>
>> It took me three years to get anyone to agree to
>> the dead obvious truth that D simulated by H
>> cannot possibly reach its own simulated "return"
>> statement final halt state because all people
>> here make disagreement their highest priority.
>>
>> If we could switch to an actual honest dialogue
>
> Then you would clarify this sentence:
>
> > H correctly predicts the finite string D simulated by
> > H cannot possibly reach its own final
> > halt state.
>
Call it a C interpreter. I will see if I can write one.
> By prefixing all instances of "D" and "H" in the above sentence with
> exactly one of:
> * algorithm
> * C function
> * finite string
>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-06 16:39 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eiiv7$18k90$1@dont-email.me> |
| In reply to | #135142 |
On 06/11/2025 15:19, olcott wrote:
> On 11/6/2025 6:54 AM, dbush wrote:
>> On 11/6/2025 12:12 AM, olcott wrote:
>>> On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/5/2025 7:39 PM, dbush wrote:
>>>>>>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>>>>>>> number of steps that its simulated D would never reach its own
>>>>>>>>>>> simulated "return" statement
>>>>>>>>>>
>>>>>>>>>> In other words, H reports on the following non-input:
>>>>>>>>>>
>>>>>>>>>> int D()
>>>>>>>>>> {
>>>>>>>>>> int Halt_Status = UTM(D);
>>>>>>>>>> if (Halt_Status)
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> return Halt_Status;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am not going to *plonk* you yet.
>>>>>>>>> Very rarely you do say some things
>>>>>>>>> that are not nonsense.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And it is clearly not nonsense that H is reporting on the above code
>>>>>>>> which is not the code it was given.
>>>>>>>
>>>>>>> It is not 100% nonsense, only about 50%.
>>>>>>> H sees that D is stuck in recursive simulation.
>>>>>>
>>>>>> Even 0.1% nonsense damns your result, if that bit of nonsense
>>>>>> is a necessary step in your chain of logic.
>>>>>>
>>>>>> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
>>>>>> nonsense.
>>>>>>
>>>>>> If you want to go down in history as a computer science
>>>>>> researcher who redefined the halting problem,
>>>>>> your game has to be 100% nonsense-free.
>>>>>>
>>>>>
>>>>> People (not LLMs) are so sure that I
>>>>> must be wrong that they find it impossible
>>>>> to see when I have actually proved my point.
>>>>
>>>> If you think you've proven your point, but nobody here sees it,
>>>> then maybe you need to take it somewhere else, like the
>>>> next step --- establishing some academic contacts wwith a view
>>>> toward publishing.
>>>>
>>>
>>> It took me three years to get anyone to agree to
>>> the dead obvious truth that D simulated by H
>>> cannot possibly reach its own simulated "return"
>>> statement final halt state because all people
>>> here make disagreement their highest priority.
>>>
>>> If we could switch to an actual honest dialogue
>>
>> Then you would clarify this sentence:
>>
>> > H correctly predicts the finite string D simulated by
>> > H cannot possibly reach its own final
>> > halt state.
>>
>
> Call it a C interpreter. I will see if I can write one.
>
If you like doing that kind of thing, go ahead. You should spend your time on stuff you enjoy doing.
As long as you're not thinking that such an interpreter will help you in making your arguments about
HP! If that is your reason, you are deluding yourself yet again. [Remember what people said before
you wrote your acyclic graph notation parser (I can't remember what you called it) and before you
wrote x86utm. They pointed out that those efforts would not aid you in making arguments you were
proposing at the time, and they were right!]
Mike.
>> By prefixing all instances of "D" and "H" in the above sentence with exactly one of:
>> * algorithm
>> * C function
>> * finite string
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-06 11:10 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eikqn$198ik$1@dont-email.me> |
| In reply to | #135146 |
On 11/6/2025 10:39 AM, Mike Terry wrote:
> On 06/11/2025 15:19, olcott wrote:
>> On 11/6/2025 6:54 AM, dbush wrote:
>>> On 11/6/2025 12:12 AM, olcott wrote:
>>>> On 11/5/2025 10:36 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/5/2025 7:56 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 11/5/2025 7:39 PM, dbush wrote:
>>>>>>>>> On 11/5/2025 8:24 PM, olcott wrote:
>>>>>>>>>> On 11/5/2025 12:43 PM, dbush wrote:
>>>>>>>>>>> On 11/5/2025 1:17 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> When H correctly predicts that if it simulated D an infinite
>>>>>>>>>>>> number of steps that its simulated D would never reach its own
>>>>>>>>>>>> simulated "return" statement
>>>>>>>>>>>
>>>>>>>>>>> In other words, H reports on the following non-input:
>>>>>>>>>>>
>>>>>>>>>>> int D()
>>>>>>>>>>> {
>>>>>>>>>>> int Halt_Status = UTM(D);
>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> return Halt_Status;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am not going to *plonk* you yet.
>>>>>>>>>> Very rarely you do say some things
>>>>>>>>>> that are not nonsense.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And it is clearly not nonsense that H is reporting on the above
>>>>>>>>> code
>>>>>>>>> which is not the code it was given.
>>>>>>>>
>>>>>>>> It is not 100% nonsense, only about 50%.
>>>>>>>> H sees that D is stuck in recursive simulation.
>>>>>>>
>>>>>>> Even 0.1% nonsense damns your result, if that bit of nonsense
>>>>>>> is a necessary step in your chain of logic.
>>>>>>>
>>>>>>> E.g. one bad derivation in a 1000 step proof is roughly 0.1%
>>>>>>> nonsense.
>>>>>>>
>>>>>>> If you want to go down in history as a computer science
>>>>>>> researcher who redefined the halting problem,
>>>>>>> your game has to be 100% nonsense-free.
>>>>>>>
>>>>>>
>>>>>> People (not LLMs) are so sure that I
>>>>>> must be wrong that they find it impossible
>>>>>> to see when I have actually proved my point.
>>>>>
>>>>> If you think you've proven your point, but nobody here sees it,
>>>>> then maybe you need to take it somewhere else, like the
>>>>> next step --- establishing some academic contacts wwith a view
>>>>> toward publishing.
>>>>>
>>>>
>>>> It took me three years to get anyone to agree to
>>>> the dead obvious truth that D simulated by H
>>>> cannot possibly reach its own simulated "return"
>>>> statement final halt state because all people
>>>> here make disagreement their highest priority.
>>>>
>>>> If we could switch to an actual honest dialogue
>>>
>>> Then you would clarify this sentence:
>>>
>>> > H correctly predicts the finite string D simulated by
>>> > H cannot possibly reach its own final
>>> > halt state.
>>>
>>
>> Call it a C interpreter. I will see if I can write one.
>>
>
> If you like doing that kind of thing, go ahead. You should spend your
> time on stuff you enjoy doing.
>
> As long as you're not thinking that such an interpreter will help you in
> making your arguments about HP! If that is your reason, you are
> deluding yourself yet again. [Remember what people said before you
> wrote your acyclic graph notation parser (I can't remember what you
> called it) and before you wrote x86utm. They pointed out that those
> efforts would not aid you in making arguments you were proposing at the
> time, and they were right!]
>
>
> Mike.
>
*I just need everyone to understand this*
On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>>
>> The whole point is that D simulated by H
>> cannot possbly reach its own simulated
>> "return" statement no matter what H does.
>
> Yes; this doesn't happen while H is running.
>
> So while H does /something/, no matter what H does,
> that D simulation won't reach the return statement.
>
Kaz didn't need and of that screwy prefix stuff.
>
>>> By prefixing all instances of "D" and "H" in the above sentence with
>>> exactly one of:
>>> * algorithm
>>> * C function
>>> * finite string
>>>
>>
>>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-06 17:16 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106091138.54@kylheku.com> |
| In reply to | #135142 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote: > Call it a C interpreter. I will see if I can write one. What for? Abstract C interpretation shows the same issue that was reproduced using the x86utm. We can pick up abandoned simulations and continue them to show that the decider is incorrect. The only reason to rework things into a new C interpreter framework would be to show that the problem was somehow caused by the x86utm. Since you've chosen to deny the issue, you might as well stick to the x86utm, since you've denied it for all possible platforms. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-06 11:26 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eilo6$19had$1@dont-email.me> |
| In reply to | #135151 |
On 11/6/2025 11:16 AM, Kaz Kylheku wrote: > On 2025-11-06, olcott <polcott333@gmail.com> wrote: >> Call it a C interpreter. I will see if I can write one. > > What for? Abstract C interpretation shows the same issue that was > reproduced using the x86utm. We can pick up abandoned simulations and > continue them to show that the decider is incorrect. You got confused about resuming an aborted simulation by trying to start it in a different machine state. > > The only reason to rework things into a new C interpreter framework > would be to show that the problem was somehow caused by the x86utm. > Not at all. The details of x86 have proven to be over everyone's head. That is the ONLY reason to switch to a C interpreter. > Since you've chosen to deny the issue, you might as well stick > to the x86utm, since you've denied it for all possible platforms. > -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-06 12:34 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eim68$16eb4$4@dont-email.me> |
| In reply to | #135152 |
On 11/6/2025 12:26 PM, olcott wrote: > On 11/6/2025 11:16 AM, Kaz Kylheku wrote: >> On 2025-11-06, olcott <polcott333@gmail.com> wrote: >>> Call it a C interpreter. I will see if I can write one. >> >> What for? Abstract C interpretation shows the same issue that was >> reproduced using the x86utm. We can pick up abandoned simulations and >> continue them to show that the decider is incorrect. > > You got confused about resuming an aborted simulation > by trying to start it in a different machine state. No, you got confused by not understanding that the directly executed H is not part of the simulation and therefore not part of the machine state. > >> >> The only reason to rework things into a new C interpreter framework >> would be to show that the problem was somehow caused by the x86utm. >> > > Not at all. The details of x86 have proven to be > over everyone's head. That is the ONLY reason to > switch to a C interpreter. Translation: My x86 code has been proven to be in error by Kaz's modifications so I have to use something else to hide my errors. > >> Since you've chosen to deny the issue, you might as well stick >> to the x86utm, since you've denied it for all possible platforms. >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-06 11:58 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eink7$1a377$1@dont-email.me> |
| In reply to | #135153 |
On 11/6/2025 11:34 AM, dbush wrote: > On 11/6/2025 12:26 PM, olcott wrote: >> On 11/6/2025 11:16 AM, Kaz Kylheku wrote: >>> On 2025-11-06, olcott <polcott333@gmail.com> wrote: >>>> Call it a C interpreter. I will see if I can write one. >>> >>> What for? Abstract C interpretation shows the same issue that was >>> reproduced using the x86utm. We can pick up abandoned simulations and >>> continue them to show that the decider is incorrect. >> >> You got confused about resuming an aborted simulation >> by trying to start it in a different machine state. > > No, you got confused by not understanding that the directly executed H > is not part of the simulation and therefore not part of the machine state. > When D is simulated by H this requires H to simulate itself simulating D. >> >>> >>> The only reason to rework things into a new C interpreter framework >>> would be to show that the problem was somehow caused by the x86utm. >>> >> >> Not at all. The details of x86 have proven to be >> over everyone's head. That is the ONLY reason to >> switch to a C interpreter. > > Translation: My x86 code has been proven to be in error by Kaz's > modifications so I have to use something else to hide my errors. > Kaz has gotten confused even by his own C code. He does not understand that resuming the simulation must begin at the total machine state when H.i==3 and H has just returned false. >> >>> Since you've chosen to deny the issue, you might as well stick >>> to the x86utm, since you've denied it for all possible platforms. >>> >> >> > -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-06 13:01 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10einqa$19lq6$1@dont-email.me> |
| In reply to | #135154 |
On 11/6/2025 12:58 PM, olcott wrote: > On 11/6/2025 11:34 AM, dbush wrote: >> On 11/6/2025 12:26 PM, olcott wrote: >>> On 11/6/2025 11:16 AM, Kaz Kylheku wrote: >>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote: >>>>> Call it a C interpreter. I will see if I can write one. >>>> >>>> What for? Abstract C interpretation shows the same issue that was >>>> reproduced using the x86utm. We can pick up abandoned simulations and >>>> continue them to show that the decider is incorrect. >>> >>> You got confused about resuming an aborted simulation >>> by trying to start it in a different machine state. >> >> No, you got confused by not understanding that the directly executed H >> is not part of the simulation and therefore not part of the machine >> state. >> > > When D is simulated by H this requires H to simulate > itself simulating D. And when that simulation is continued by something else, it picks up where the directly executed H left off which may be in the simulated H. > >>> >>>> >>>> The only reason to rework things into a new C interpreter framework >>>> would be to show that the problem was somehow caused by the x86utm. >>>> >>> >>> Not at all. The details of x86 have proven to be >>> over everyone's head. That is the ONLY reason to >>> switch to a C interpreter. >> >> Translation: My x86 code has been proven to be in error by Kaz's >> modifications so I have to use something else to hide my errors. >> > > Kaz has gotten confused even by his own C code. > He does not understand that resuming the simulation > must begin at the total machine state when H.i==3 > and H has just returned false. Nope, that's the directly executed H which is not part of the simulation and therefore not part of the state. > >>> >>>> Since you've chosen to deny the issue, you might as well stick >>>> to the x86utm, since you've denied it for all possible platforms. >>>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-06 12:04 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10einv5$1a60a$1@dont-email.me> |
| In reply to | #135155 |
On 11/6/2025 12:01 PM, dbush wrote: > On 11/6/2025 12:58 PM, olcott wrote: >> On 11/6/2025 11:34 AM, dbush wrote: >>> On 11/6/2025 12:26 PM, olcott wrote: >>>> On 11/6/2025 11:16 AM, Kaz Kylheku wrote: >>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote: >>>>>> Call it a C interpreter. I will see if I can write one. >>>>> >>>>> What for? Abstract C interpretation shows the same issue that was >>>>> reproduced using the x86utm. We can pick up abandoned simulations and >>>>> continue them to show that the decider is incorrect. >>>> >>>> You got confused about resuming an aborted simulation >>>> by trying to start it in a different machine state. >>> >>> No, you got confused by not understanding that the directly executed >>> H is not part of the simulation and therefore not part of the machine >>> state. >>> >> >> When D is simulated by H this requires H to simulate >> itself simulating D. > > And when that simulation is continued by something else, This is cheating. There is "no something else" in the control flow path. > it picks up > where the directly executed H left off which may be in the simulated H. > >> >>>> >>>>> >>>>> The only reason to rework things into a new C interpreter framework >>>>> would be to show that the problem was somehow caused by the x86utm. >>>>> >>>> >>>> Not at all. The details of x86 have proven to be >>>> over everyone's head. That is the ONLY reason to >>>> switch to a C interpreter. >>> >>> Translation: My x86 code has been proven to be in error by Kaz's >>> modifications so I have to use something else to hide my errors. >>> >> >> Kaz has gotten confused even by his own C code. >> He does not understand that resuming the simulation >> must begin at the total machine state when H.i==3 >> and H has just returned false. > > Nope, that's the directly executed H which is not part of the simulation > and therefore not part of the state. > To resume a computation requires that exact same total machine state be restored. >> >>>> >>>>> Since you've chosen to deny the issue, you might as well stick >>>>> to the x86utm, since you've denied it for all possible platforms. >>>>> >>>> >>>> >>> >> >> > -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-06 13:15 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eioj6$19lq6$2@dont-email.me> |
| In reply to | #135156 |
On 11/6/2025 1:04 PM, olcott wrote: > On 11/6/2025 12:01 PM, dbush wrote: >> On 11/6/2025 12:58 PM, olcott wrote: >>> On 11/6/2025 11:34 AM, dbush wrote: >>>> On 11/6/2025 12:26 PM, olcott wrote: >>>>> On 11/6/2025 11:16 AM, Kaz Kylheku wrote: >>>>>> On 2025-11-06, olcott <polcott333@gmail.com> wrote: >>>>>>> Call it a C interpreter. I will see if I can write one. >>>>>> >>>>>> What for? Abstract C interpretation shows the same issue that was >>>>>> reproduced using the x86utm. We can pick up abandoned simulations and >>>>>> continue them to show that the decider is incorrect. >>>>> >>>>> You got confused about resuming an aborted simulation >>>>> by trying to start it in a different machine state. >>>> >>>> No, you got confused by not understanding that the directly executed >>>> H is not part of the simulation and therefore not part of the >>>> machine state. >>>> >>> >>> When D is simulated by H this requires H to simulate >>> itself simulating D. >> >> And when that simulation is continued by something else, > > This is cheating. There is "no something else" in the control flow path. Nope, since the directly executed H is not part of the simulation and therefore not part of the control flow path. That's how we verify whether the decision by H is correct. > >> it picks up where the directly executed H left off which may be in the >> simulated H. >> >>> >>>>> >>>>>> >>>>>> The only reason to rework things into a new C interpreter framework >>>>>> would be to show that the problem was somehow caused by the x86utm. >>>>>> >>>>> >>>>> Not at all. The details of x86 have proven to be >>>>> over everyone's head. That is the ONLY reason to >>>>> switch to a C interpreter. >>>> >>>> Translation: My x86 code has been proven to be in error by Kaz's >>>> modifications so I have to use something else to hide my errors. >>>> >>> >>> Kaz has gotten confused even by his own C code. >>> He does not understand that resuming the simulation >>> must begin at the total machine state when H.i==3 >>> and H has just returned false. >> >> Nope, that's the directly executed H which is not part of the >> simulation and therefore not part of the state. >> > > To resume a computation requires that > exact same total machine state be restored. Which means the state of the machine being simulated, not the state of the machine doing the simulation. In the case of Kaz's D and H, that would be inside of the first simulated H at the start of the "for" loop with i=0. And that's where the simulation would continue from. > >>> >>>>> >>>>>> Since you've chosen to deny the issue, you might as well stick >>>>>> to the x86utm, since you've denied it for all possible platforms. >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.theory
csiph-web