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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-11-06 18:37 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106101506.504@kylheku.com> |
| In reply to | #135154 |
On 2025-11-06, olcott <polcott333@gmail.com> 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.
The simulation of D doesn't require H. It just happens that H is
initially conducting it.
H is initially conducting the simulation it in order to be able to
monitor it in detail, so that it can make a decision about D.
The simulation is not complete when it makes that decision.
At that point, another agent (such as the surrounding framework)
can take over the responsibility of making the interp_step calls
on the simulation object to continue the simulation.
You are confused by thinking that the simulation belongs to H,
and so H has to be rewound back and resumed.
Nothing like that must be done.
I'm going to propose a new API for simulating deciders,
which makes it clear:
bool H(void (*p)(void), interp *si)
{
// Same example "three step" logic as before
for (i = 0; i < 3; i++) {
if (iter_step(s))
return true;
}
return false;
}
The main driver program then is this:
int main(void)
{
interp *s = interp_create(D);
bool result = H(D, s);
printf("Input halts = %s.\n", result ? "true" : "false");
// reckoning: do we hang in this loop? Or will it halt?
while (!interp_step(s)) { /* nothing */ }
prinf("Input halted!\n");
// If H had returned false, "incorrect" is printed.
printf("H was %s about D.\n", result ? "correct" : "incorrect");
}
The simulating decider receives two arguments: the pointer to the
function, and a ready-made simulation on that function.
We are not restoring any context; we are simply making more interp_step
calls on the simulation after H returns.
This is the same as before, except we are not relying on the framework
to keep track of the unfinished simulation "under the hood".
We have made it an explicit parameter.
H's job is to decide whether P terminates using the simulation.
If there are any unfinished steps in the simuation after H is done,
step those to see whether H was correct.
The "under the hood" business was only needed in the context of the
x86utm, so that we could work in the "reckoning" logic without changing
the test cases in any way. The "reckoning" logic works with Halt7.obj
files that were compiled before it was developed.
--
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 | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2025-11-06 20:03 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eiuug$1cikf$1@dont-email.me> |
| In reply to | #135160 |
On 06/11/2025 18:37, Kaz Kylheku wrote: > On 2025-11-06, olcott <polcott333@gmail.com> 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. > > The simulation of D doesn't require H. It just happens that H is > initially conducting it. > > H is initially conducting the simulation it in order to be able to > monitor it in detail, so that it can make a decision about D. You're assuming that PO understands fundamentally "what a simulation is". Simulation is an abstract concept, as is the more basic idea of "computation", and I've said many times (not to you especially) that PO's brain wiring means he can't do "abstract" concepts and reasoning - at least not in the way that "normal" people naturally handle such concepts from a young age. For PO, it's all just his initial intuitions, and then repeating his claims over and over using slightly different words. As for the current situation - we know that PO often claims that the behaviour of a simulation is dependent on who is performing the simulation. So it comes as no surprise that PO now thinks that to resume the simulation you have to also restore the simulator to the same point! :( To us that is just silly, but imagine it really was the case that the behaviour changes with the simulator? Anyhow, to set PO on the correct path of recognising his errors, you would need to correct his understanding of "simulation", but in doing that it would turn out that he didn't understand "computation", and then that he didn't properly understand "halting", and "TM" and "function" and "decision problem" and so on and so on. Your focus on an infinite tower of simulations, and resuming abandonned simulations is intersesting - probably it's the only genuinely new approach to convincing PO that's come along in the last couple of years! But in the end it is all just too abstract for him. FIRST PO needs to be convinced that a computation only has one behaviour (in terms of the computation's steps) and that simulations are just evaluations of that one computation behaviour. I can't see any signs of even that much happening! Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-06 14:24 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10ej056$1cu3v$1@dont-email.me> |
| In reply to | #135162 |
On 11/6/2025 2:03 PM, Mike Terry wrote: > On 06/11/2025 18:37, Kaz Kylheku wrote: >> On 2025-11-06, olcott <polcott333@gmail.com> 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. >> >> The simulation of D doesn't require H. It just happens that H is >> initially conducting it. >> >> H is initially conducting the simulation it in order to be able to >> monitor it in detail, so that it can make a decision about D. > > You're assuming that PO understands fundamentally "what a simulation > is". Simulation is an abstract concept, as is the more basic idea of > "computation", and I've said many times (not to you especially) that > PO's brain wiring means he can't do "abstract" concepts and reasoning - I translate the abstract (that always has key details abstracted away) and transform this into the concrete that fills in these missing details that resulted in false assumptions at the abstract level. > at least not in the way that "normal" people naturally handle such "normal" people assume that textbooks and other foundations are infallible. I double check and found out "not so much". > concepts from a young age. For PO, it's all just his initial > intuitions, and then repeating his claims over and over using slightly > different words. > The conventional terms of the art make the actual truth inexpressible. > As for the current situation - we know that PO often claims that the > behaviour of a simulation is dependent on who is performing the > simulation. I am proven this and it is dead obvious that D simulated by H includes H simulating itself simulated D and D simulated by H1 does not require this. Is everyone here brain damaged? > So it comes as no surprise that PO now thinks that to > resume the simulation you have to also restore the simulator to the same > point! :( To us that is just silly, but imagine it really was the case > that the behaviour changes with the simulator? > > > Anyhow, to set PO on the correct path of recognising his errors, you > would need to correct his understanding of "simulation", but in doing > that it would turn out that he didn't understand "computation", and then > that he didn't properly understand "halting", and "TM" and "function" > and "decision problem" and so on and so on. > > Your focus on an infinite tower of simulations, and resuming abandonned > simulations is intersesting - probably it's the only genuinely new > approach to convincing PO that's come along in the last couple of > years! But in the end it is all just too abstract for him. FIRST PO > needs to be convinced that a computation only has one behaviour (in > terms of the computation's steps) and that simulations are just > evaluations of that one computation behaviour. I can't see any signs of > even that much happening! > > > Mike. > -- 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 21:16 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106131204.490@kylheku.com> |
| In reply to | #135166 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
> On 11/6/2025 2:03 PM, Mike Terry wrote:
>> As for the current situation - we know that PO often claims that the
>> behaviour of a simulation is dependent on who is performing the
>> simulation.
>
> I am proven this and it is dead obvious that D simulated
> by H includes H simulating itself simulated D and D simulated
That's a different instance of H, conducting a different instance
of the simulation (different "level").
No simulation level N requires the previous N-1 level to be
conducted specifically by H.
Any code which calls the simulation API can conduct a simulation,
either from start to finish, or taking it over from other code.
> by H1 does not require this. Is everyone here brain damaged?
By H1 I understand a procedure which simulates forever, until
the subject halts by itself.
When H1 simulates D (where D calls H), it will likewise use
interp_step(s) to move the simulation forward. It does so forever,
until that function returns true indicating halting, at which
point it returns true:
I.e. in H1 we have:
while (iterp_step(s)) { }
return true;
Thus, H1 does not leave behind an abandoned simulation in which more
steps are possible. While more steps are possible, H1 does not return.
--
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-06 21:39 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106131736.573@kylheku.com> |
| In reply to | #135175 |
On 2025-11-06, Kaz Kylheku <643-408-1753@kylheku.com> wrote: > On 2025-11-06, olcott <polcott333@gmail.com> wrote: >> On 11/6/2025 2:03 PM, Mike Terry wrote: >>> As for the current situation - we know that PO often claims that the >>> behaviour of a simulation is dependent on who is performing the >>> simulation. >> >> I am proven this and it is dead obvious that D simulated >> by H includes H simulating itself simulated D and D simulated > > That's a different instance of H, conducting a different instance > of the simulation (different "level"). > > No simulation level N requires the previous N-1 level to be > conducted specifically by H. > > Any code which calls the simulation API can conduct a simulation, > either from start to finish, or taking it over from other code. > >> by H1 does not require this. Is everyone here brain damaged? > > By H1 I understand a procedure which simulates forever, until > the subject halts by itself. Or, wait; did we want H1 to be the same as H? In that case, H1 will conduct three steps of D, just like H, and return false. That will be incorrect. In that case, H1 will leave behind an unfinished simulation which can be stepped to show that it terminates. H1 and H are indistinguishable because we have not performed any name or pointer-based comparison of functions. I.e. we have not executed any test like fptr1 == fptr2 of two function pointers where we conclude that H and H1 are different functions. That would be a wrong thing to do, and if we don't do such a thing, there is no difference between H and H1 if they have the same parameter list and body. In the Halt7.c test case for the x86utm, there is a difference between function like HHH1 and HHH because the analysis which looks for the abort pattern does look at whether the same function is being called; it is using pointer equality for functions and under pointer equality, two different top-level definitions may be the same (unless the compiler de-duplicates identical functions: not the case in the Halt7.obj file.) -- 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-06 22:10 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106140811.47@kylheku.com> |
| In reply to | #135166 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote: > "normal" people assume that textbooks and other foundations > are infallible. I double check and found out "not so much". Are any of those "normal" people here? And if so, how come they are not assuming that /you/ are infallible? Are you saying that people only find books to be flawed when those books are 100% correct? Just like they find you flawed when you are 100% correct? People only find books infallible when the books are wrong? For instance, if you were to write a book, they would not find /that/ book infallible, because that book would would be the 100% correct work of a genius? -- 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 14:04 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eiv0k$1cig6$1@dont-email.me> |
| In reply to | #135160 |
On 11/6/2025 12:37 PM, Kaz Kylheku wrote:
> On 2025-11-06, olcott <polcott333@gmail.com> 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.
>
> The simulation of D doesn't require H. It just happens that H is
> initially conducting it.
>
Counter-factual
> void D(void)
> {
> if (H(D)) { for (;;); }
> return;
> }
--
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 20:45 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106123930.937@kylheku.com> |
| In reply to | #135163 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
> On 11/6/2025 12:37 PM, Kaz Kylheku wrote:
>> On 2025-11-06, olcott <polcott333@gmail.com> 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.
>>
>> The simulation of D doesn't require H. It just happens that H is
>> initially conducting it.
>>
>
> Counter-factual
> > void D(void)
> > {
> > if (H(D)) { for (;;); }
> > return;
> > }
Again, you are deliberately trying to muddle the conversation.
D incorporates the H(D) calculation and its behavior depends on it.
That's /obviously/ not what I mean when I say "simulation of D does not
require H".
The simulation itself of D requires H because D incorporates it.
The act of performing the simulation does not require H to be doing it.
The simulation can be performed by any calling context whatsoever,
which is able to call interp_step on the handle previously created
by interp_create(D).
--
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 14:57 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10ej23e$1df8p$1@dont-email.me> |
| In reply to | #135168 |
On 11/6/2025 2:45 PM, Kaz Kylheku wrote:
> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>> On 11/6/2025 12:37 PM, Kaz Kylheku wrote:
>>> On 2025-11-06, olcott <polcott333@gmail.com> 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.
>>>
>>> The simulation of D doesn't require H. It just happens that H is
>>> initially conducting it.
>>>
>>
>> Counter-factual
>>> void D(void)
>>> {
>>> if (H(D)) { for (;;); }
>>> return;
>>> }
>
> Again, you are deliberately trying to muddle the conversation.
>
> D incorporates the H(D) calculation and its behavior depends on it.
>
>>> The simulation of D doesn't require H. It just happens that H is
>>> initially conducting it.
So Mike is wrong.
> That's /obviously/ not what I mean when I say "simulation of D does not
> require H".
>
> The simulation itself of D requires H because D incorporates it.
>
> The act of performing the simulation does not require H to be doing it.
>
> The simulation can be performed by any calling context whatsoever,
> which is able to call interp_step on the handle previously created
> by interp_create(D).
>
--
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 18:14 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106094124.377@kylheku.com> |
| In reply to | #135152 |
On 2025-11-06, olcott <polcott333@gmail.com> 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. The point is that whether these remarks are true or not, the situation is the same in x86utm-side work as in the abstract pseudo-interpretation exercise. Now, the remarks are not true. You have misunderstood the technique. The simulation of D is represented by a bunch of state (which in the abstract exercise is represened by an "interp *s" handle; in the x86utm Halt7 test case it is several objects, tracked by pointers with names like slave_state and slave_stack). Conducting that simulation does not specifically require H. It requires /something/ to make repeated calls to interp_step(s). None of the simulation state is inside H: it is all encapsualted inside the "interp" object. After any interp_step(s) call made by H, that simulation could be handed off to another agent to make subsequent calls to interp_step; the result of stepping the simulation would be the same. When H walks away from the interpretation and returns false, we are not interested in resuming H from the point where it made the decision. (Which lies sometime between the most recent interp_step call and the return false statement). To resume D, all we need is the "interp *s" API handle, and to start making interp_step(s) calls. We do not need to do anythning with H; that doesn't make sense. H, and the simulation of D, are like separate threads. We only care about the D thread. After H detaches from that thread, is the remaining execution of that thread terminating. >> 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's simply untrue. People have built your code and meaningfully experimented with it. What is your evidence for the belief that it was over anyone's head? It's easy to work with; the compiled x86 functions are mostly small, and a complete disassembly is given of the entire test case when it is run so things are easy to follow. That said, neither interpreted nor compiled C is the best mode of presentation of this material to academia; switching from one to the other is mostly a lateral, unproductive move. -- 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 12:27 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eipb8$1al85$1@dont-email.me> |
| In reply to | #135157 |
On 11/6/2025 12:14 PM, Kaz Kylheku wrote: > On 2025-11-06, olcott <polcott333@gmail.com> 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. > > The point is that whether these remarks are true or not, the situation > is the same in x86utm-side work as in the abstract pseudo-interpretation > exercise. > No you are confused on the C side and confused on the x86 side it is much more difficult to show your mistake on the x86 side because no one here (besides me) understands the x86 side. If you resume your C code at the same total machine state where H.i==3 and H has returned then you get the exact same result. If you do this differently then you didn't actually resume. > Now, the remarks are not true. You have misunderstood the technique. > > The simulation of D is represented by a bunch of state (which in > the abstract exercise is represened by an "interp *s" handle; > in the x86utm Halt7 test case it is several objects, tracked by pointers with > names like slave_state and slave_stack). > > Conducting that simulation does not specifically require H. It requires > /something/ to make repeated calls to interp_step(s). None of the simulation > state is inside H: it is all encapsualted inside the "interp" object. After any > interp_step(s) call made by H, that simulation could be handed off to another > agent to make subsequent calls to interp_step; the result of stepping > the simulation would be the same. > > When H walks away from the interpretation and returns false, we are not > interested in resuming H from the point where it made the decision. > (Which lies sometime between the most recent interp_step call and the > return false statement). > > To resume D, all we need is the "interp *s" API handle, and to start > making interp_step(s) calls. > > We do not need to do anythning with H; that doesn't make sense. > > H, and the simulation of D, are like separate threads. We only care > about the D thread. After H detaches from that thread, is the remaining > execution of that thread terminating. > >>> 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's simply untrue. People have built your code and meaningfully > experimented with it. > > What is your evidence for the belief that it was over anyone's head? > > It's easy to work with; the compiled x86 functions are mostly small, and > a complete disassembly is given of the entire test case when it is run > so things are easy to follow. > > That said, neither interpreted nor compiled C is the best mode of presentation > of this material to academia; switching from one to the other is mostly a > lateral, unproductive move. > -- 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 18:46 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106103813.507@kylheku.com> |
| In reply to | #135159 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote: > On 11/6/2025 12:14 PM, Kaz Kylheku wrote: >> On 2025-11-06, olcott <polcott333@gmail.com> 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. >> >> The point is that whether these remarks are true or not, the situation >> is the same in x86utm-side work as in the abstract pseudo-interpretation >> exercise. >> > > No you are confused on the C side and confused > on the x86 side it is much more difficult to > show your mistake on the x86 side because no > one here (besides me) understands the x86 side. So, let's get this straight: Because ... I ... supposedly do not understand the x86 side (and neither does anyone else besides you) .... you ... are not able to show the mistake? Is this how you interacted with your colleagues, managers and customers in your career as coding technician? What /ATTEMPT/ have you made to show what is wrong on the x86 side? People who /CAN/ show that something is wrong are generally not concerned with whether the mistaken party understands it, as a first priority, before showing anything at all. They show what is wrong, and then if it is not understood they try to explain it. If I'm wrong, it's not even important that I understand it; it's important that you show that to the /WORLD/ to defend your work against a wrong claim. > If you resume your C code at the same total machine > state where H.i==3 and H has returned then you get > the exact same result. If you do this differently > then you didn't actually resume. No, we do not want to roll back the H control flow to an earlier state. Nothing like that is going on. Just code other than H picks up the interp object and makes more interp_step calls on it. The post I just made, specifying a different API for simulating deciders, makes everything as clear as it can possibly be. -- 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 14:10 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eivb8$1cn54$1@dont-email.me> |
| In reply to | #135161 |
On 11/6/2025 12:46 PM, Kaz Kylheku wrote: > On 2025-11-06, olcott <polcott333@gmail.com> wrote: >> On 11/6/2025 12:14 PM, Kaz Kylheku wrote: >>> On 2025-11-06, olcott <polcott333@gmail.com> 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. >>> >>> The point is that whether these remarks are true or not, the situation >>> is the same in x86utm-side work as in the abstract pseudo-interpretation >>> exercise. >>> >> >> No you are confused on the C side and confused >> on the x86 side it is much more difficult to >> show your mistake on the x86 side because no >> one here (besides me) understands the x86 side. > > So, let's get this straight: > > Because ... I ... supposedly do not understand the x86 side (and neither > does anyone else besides you) .... you ... are not able to show the > mistake? > I will not tolerate going through any convoluted mess. The C code I can spot the error in less than a minute. > Is this how you interacted with your colleagues, managers and customers > in your career as coding technician? > These people did not lie to disparage me. > What /ATTEMPT/ have you made to show what is wrong on the x86 side? > > People who /CAN/ show that something is wrong are generally not concerned > with whether the mistaken party understands it, as a first priority, > before showing anything at all. They show what is wrong, and then if it > is not understood they try to explain it. > > If I'm wrong, it's not even important that I understand it; it's > important that you show that to the /WORLD/ to defend your work > against a wrong claim. > >> If you resume your C code at the same total machine >> state where H.i==3 and H has returned then you get >> the exact same result. If you do this differently >> then you didn't actually resume. > > No, we do not want to roll back the H control flow to an earlier > state. Nothing like that is going on. > you didn't actually resume the simulation you cheated instead. > Just code other than H picks up the interp object and makes more > interp_step calls on it. > > The post I just made, specifying a different API for simulating > deciders, makes everything as clear as it can possibly be. > -- 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 21:03 +0000 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <20251106124608.200@kylheku.com> |
| In reply to | #135164 |
On 2025-11-06, olcott <polcott333@gmail.com> wrote:
> On 11/6/2025 12:46 PM, Kaz Kylheku wrote:
>> On 2025-11-06, olcott <polcott333@gmail.com> wrote:
>>> On 11/6/2025 12:14 PM, Kaz Kylheku wrote:
>>>> On 2025-11-06, olcott <polcott333@gmail.com> 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.
>>>>
>>>> The point is that whether these remarks are true or not, the situation
>>>> is the same in x86utm-side work as in the abstract pseudo-interpretation
>>>> exercise.
>>>>
>>>
>>> No you are confused on the C side and confused
>>> on the x86 side it is much more difficult to
>>> show your mistake on the x86 side because no
>>> one here (besides me) understands the x86 side.
>>
>> So, let's get this straight:
>>
>> Because ... I ... supposedly do not understand the x86 side (and neither
>> does anyone else besides you) .... you ... are not able to show the
>> mistake?
>>
>
> I will not tolerate going through any convoluted mess.
Because you are not competent as a software engineer?
My reckoning.cpp source file is substantially more cleanly coded
than just about everything else in the x86utm.
It's a total of 215 lines of code, including all the #include
statements, declarations, blank lines and lines with only
curly braces.
Could you even pass a technical interview for job today
if you can't wrap your head around 200 lines of clear code,
which references API's in your own work?
> The C code I can spot the error in less than a minute.
In a way that makes zero sense.
>> Is this how you interacted with your colleagues, managers and customers
>> in your career as coding technician?
>>
>
> These people did not lie to disparage me.
No, they lied not to create trouble, allowing you to believe
you are more competent than you actually are.
Professional settings are often quite opposite to Usenet in
that regard.
It's not unusual to even get a good (or at least okay) reference from a
former job where you screwed up. They are just glad you're not there,
and don't have anything to lose by avoiding negativity.
>> What /ATTEMPT/ have you made to show what is wrong on the x86 side?
>>
>> People who /CAN/ show that something is wrong are generally not concerned
>> with whether the mistaken party understands it, as a first priority,
>> before showing anything at all. They show what is wrong, and then if it
>> is not understood they try to explain it.
>>
>> If I'm wrong, it's not even important that I understand it; it's
>> important that you show that to the /WORLD/ to defend your work
>> against a wrong claim.
>>
>>> If you resume your C code at the same total machine
>>> state where H.i==3 and H has returned then you get
>>> the exact same result. If you do this differently
>>> then you didn't actually resume.
>>
>> No, we do not want to roll back the H control flow to an earlier
>> state. Nothing like that is going on.
>
> you didn't actually resume the simulation
> you cheated instead.
I admit there is some implicit behavior going on: the assumption that
the framework can identify the abandoned simulation and take it over.
I did it that way because it was done that way in the x86utm work.
(out of necessity, due to not wanting to touch the
Halt7.obj test case in any way).
I have simplified it to avoid the hidden behavior.
Please identify what you believe to be wrong in the version below.
The simulating decider H takes the simulation as a parameter.
It is now explicit how the "reckoning" code knows about the
simulation object and where that takes place (in main).
Assume D() is as before.
#include <interp.h>
void D(void);
bool H(void (*p)(void), interp *si)
{
for (i = 0; i < 3; i++) {
if (iter_step(s))
return true;
}
return false;
}
void D(void)
{
interp *s = interp_create(D);
if (H(D, s)) { for (;;); }
return;
}
int main(void)
{
interp *s = interp_create(D);
bool result = H(D, s);
printf("Input halts = %s.\n", result ? "true" : "false");
// reckoning: do we hang in this loop? Or will it halt?
while (!interp_step(s)) { /* nothing */ }
prinf("Input halted!\n");
// If H had returned false, "incorrect" is printed.
printf("H was %s about D.\n", result ? "correct" : "incorrect");
}
The continued simulation of abandoned D is explicitly carried out by the
while loop in main; we are no longer relying on the framework to know
about the "interp *s" handle behind the scenes and doing this loop after
the test case.
>> Just code other than H picks up the interp object and makes more
>> interp_step calls on it.
>>
>> The post I just made, specifying a different API for simulating
>> deciders, makes everything as clear as it can possibly be.
You snipped it, but there it is above again.
--
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 19:54 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10egv4l$qpl9$1@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.
Its only 50% nonsense which is better than
Chris ever did. Flibble used to say things
that made good sense.
H correctly predicts the D simulated by
H cannot possibly reach its own final
halt state.
--
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 21:08 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10egvuk$pn3p$4@dont-email.me> |
| In reply to | #135096 |
On 11/5/2025 8:54 PM, olcott 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.
>
> Its only 50% nonsense which is better than
> Chris ever did. Flibble used to say things
> that made good sense.
>
> H correctly predicts the D simulated by
> H cannot possibly reach its own final
> halt state.
>
Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
could refer to an algorithm, a C function, or a finite string, and would
have different meaning depending on which one.
Clarify the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 20:24 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eh0sg$r76u$2@dont-email.me> |
| In reply to | #135098 |
On 11/5/2025 8:08 PM, dbush wrote:
> On 11/5/2025 8:54 PM, olcott 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.
>>
>> Its only 50% nonsense which is better than
>> Chris ever did. Flibble used to say things
>> that made good sense.
>>
>> H correctly predicts the D simulated by
>> H cannot possibly reach its own final
>> halt state.
>>
>
> Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
> could refer to an algorithm, a C function, or a finite string, and would
> have different meaning depending on which one.
>
> Clarify the above sentence by prefixing all instances of "H" and "D"
> with exactly one of:
> * algorithm
> * C function
> * finite string
>>>>> int D()
>>>>> {
>>>>> int Halt_Status = UTM(D);
>>>>> if (Halt_Status)
>>>>> HERE: goto HERE;
>>>>> return Halt_Status;
>>>>> }
Liar !!!
--
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 22:05 -0500 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eh3ab$rkcc$1@dont-email.me> |
| In reply to | #135102 |
On 11/5/2025 9:24 PM, olcott wrote:
> On 11/5/2025 8:08 PM, dbush wrote:
>> On 11/5/2025 8:54 PM, olcott 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.
>>>
>>> Its only 50% nonsense which is better than
>>> Chris ever did. Flibble used to say things
>>> that made good sense.
>>>
>>> H correctly predicts the D simulated by
>>> H cannot possibly reach its own final
>>> halt state.
>>>
>>
>> Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
>> could refer to an algorithm, a C function, or a finite string, and
>> would have different meaning depending on which one.
>>
>> Clarify the above sentence by prefixing all instances of "H" and "D"
>> with exactly one of:
>> * algorithm
>> * C function
>> * finite string
>
> >>>>> int D()
> >>>>> {
> >>>>> int Halt_Status = UTM(D);
> >>>>> if (Halt_Status)
> >>>>> HERE: goto HERE;
> >>>>> return Halt_Status;
> >>>>> }
>
>
> Liar !!!
>
I clearly stated that the problem was with your sentence about the above
code, not the code itself.
You're obviously actively avoiding being clear, proving that you're not
interested in an honest dialogue.
But I'm feeling generous and will assume that you simply have abysmal
reading comprehension skills. So to reiterate:
The following sentence is rejected out-of-hand as unclear:
>>> H correctly predicts the D simulated by
>>> H cannot possibly reach its own final
>>> halt state.
Prove that you're actually interested in an honest dialogue by
clarifying the above sentence by prefixing all instances of "H" and "D"
with exactly one of:
* algorithm
* C function
* finite string
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2025-11-05 21:15 -0600 |
| Subject | Re: Kaz does not understand his own code. --- I AM PROVED EXACTLY CORRECT. |
| Message-ID | <10eh3sm$rt48$1@dont-email.me> |
| In reply to | #135109 |
On 11/5/2025 9:05 PM, dbush wrote:
> On 11/5/2025 9:24 PM, olcott wrote:
>> On 11/5/2025 8:08 PM, dbush wrote:
>>> On 11/5/2025 8:54 PM, olcott 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.
>>>>
>>>> Its only 50% nonsense which is better than
>>>> Chris ever did. Flibble used to say things
>>>> that made good sense.
>>>>
>>>> H correctly predicts the D simulated by
>>>> H cannot possibly reach its own final
>>>> halt state.
>>>>
>>>
>>> Rejected out-of-hand as unclear, as "D" and "H" in the above sentence
>>> could refer to an algorithm, a C function, or a finite string, and
>>> would have different meaning depending on which one.
>>>
>>> Clarify the above sentence by prefixing all instances of "H" and "D"
>>> with exactly one of:
>>> * algorithm
>>> * C function
>>> * finite string
>>
>> >>>>> int D()
>> >>>>> {
>> >>>>> int Halt_Status = UTM(D);
>> >>>>> if (Halt_Status)
>> >>>>> HERE: goto HERE;
>> >>>>> return Halt_Status;
>> >>>>> }
>>
>>
>> Liar !!!
>>
>
> I clearly stated that the problem was with your sentence about the above
> code, not the code itself.
>
Unless you start doing better you will be on the *plonked* list
> You're obviously actively avoiding being clear, proving that you're not
> interested in an honest dialogue.
>
> But I'm feeling generous and will assume that you simply have abysmal
> reading comprehension skills. So to reiterate:
>
> The following sentence is rejected out-of-hand as unclear:
>
> >>> H correctly predicts the D simulated by
> >>> H cannot possibly reach its own final
> >>> halt state.
>
> Prove that you're actually interested in an honest dialogue by
> clarifying the above sentence by prefixing all instances of "H" and "D"
> 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 | dbush <dbush.mobile@gmail.com> |
|---|---|
| Date | 2025-11-05 22:18 -0500 |
| Subject | Olcott proves he's not interested in an honest dialogue by actively avoiding being clear |
| Message-ID | <10eh42h$rkcc$2@dont-email.me> |
| In reply to | #135111 |
On 11/5/2025 10:15 PM, olcott wrote:
> On 11/5/2025 9:05 PM, dbush wrote:
>> On 11/5/2025 9:24 PM, olcott wrote:
>>> On 11/5/2025 8:08 PM, dbush wrote:
>>>> On 11/5/2025 8:54 PM, olcott 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.
>>>>>
>>>>> Its only 50% nonsense which is better than
>>>>> Chris ever did. Flibble used to say things
>>>>> that made good sense.
>>>>>
>>>>> H correctly predicts the D simulated by
>>>>> H cannot possibly reach its own final
>>>>> halt state.
>>>>>
>>>>
>>>> Rejected out-of-hand as unclear, as "D" and "H" in the above
>>>> sentence could refer to an algorithm, a C function, or a finite
>>>> string, and would have different meaning depending on which one.
>>>>
>>>> Clarify the above sentence by prefixing all instances of "H" and "D"
>>>> with exactly one of:
>>>> * algorithm
>>>> * C function
>>>> * finite string
>>>
>>> >>>>> int D()
>>> >>>>> {
>>> >>>>> int Halt_Status = UTM(D);
>>> >>>>> if (Halt_Status)
>>> >>>>> HERE: goto HERE;
>>> >>>>> return Halt_Status;
>>> >>>>> }
>>>
>>>
>>> Liar !!!
>>>
>>
>> I clearly stated that the problem was with your sentence about the
>> above code, not the code itself.
>>
>
> Unless you start doing better you will be on the *plonked* list
In other words, you don't know how to answer my question without making
your lies obvious.
>
>> You're obviously actively avoiding being clear, proving that you're
>> not interested in an honest dialogue.
>>
>> But I'm feeling generous and will assume that you simply have abysmal
>> reading comprehension skills. So to reiterate:
>>
>> The following sentence is rejected out-of-hand as unclear:
>>
>> >>> H correctly predicts the D simulated by
>> >>> H cannot possibly reach its own final
>> >>> halt state.
>>
>> Prove that you're actually interested in an honest dialogue by
>> clarifying the above sentence by prefixing all instances of "H" and "D"
>> with exactly one of:
>> * algorithm
>> * C function
>> * finite string
>
>
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.theory
csiph-web