From Newsgroup: comp.theory

On 28/10/2025 21:40, olcott wrote:

H simulates D
that calls H(D) to simulate D

... 4 repetitions snipped ...

until H sees this repeating pattern.

I'm beginning to suspect you mean literally, as in H counts calls to
H(D) four levels of H-on-D-simulation deep and is defined to thereupon halt.

Tell Kaz you already know everything you need to about the Y combinator,
that specification is pure perfection and is most easily created /using/
the Y combinator to compose the statement of the situation.

--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 9:48 AM, Tristan Wibberley wrote:

On 28/10/2025 21:40, olcott wrote:

H simulates D
that calls H(D) to simulate D

... 4 repetitions snipped ...

until H sees this repeating pattern.

I'm beginning to suspect you mean literally, as in H counts calls to
H(D) four levels of H-on-D-simulation deep and is defined to thereupon halt.

If I repeat it the proper number times people
never bother to notice that it repeats.

As soon as H has simulated D twice then it can
recognize the repeating pattern and reject its
input as specifying a non-halting sequence of
configurations.

Tell Kaz you already know everything you need to about the Y combinator,
that specification is pure perfection and is most easily created /using/
the Y combinator to compose the statement of the situation.

Kaz doesn't even seem to notice that D simulated by H
according to the semantics of the C language cannot
possibly reach its own simulated return statement.

--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 9:48 AM, Tristan Wibberley wrote:

On 28/10/2025 21:40, olcott wrote:

H simulates D
that calls H(D) to simulate D

... 4 repetitions snipped ...

until H sees this repeating pattern.

I'm beginning to suspect you mean literally, as in H counts calls to
H(D) four levels of H-on-D-simulation deep and is defined to thereupon halt. >>

If I repeat it the proper number times people
never bother to notice that it repeats.

As soon as H has simulated D twice then it can
recognize the repeating pattern and reject its
input as specifying a non-halting sequence of
configurations.

Unless you put cheats into the code, /every/ H at every
simulation level also monitors for two simulations of D
(the one it is simulatingl, plus one more). And /every/ H
returns 0 to its respective D.

Tell Kaz you already know everything you need to about the Y combinator,
that specification is pure perfection and is most easily created /using/
the Y combinator to compose the statement of the situation.

Kaz doesn't even seem to notice that D simulated by H
according to the semantics of the C language cannot
possibly reach its own simulated return statement.

/D/ reaches its simulated return statement.

The /simulation of D/ while it is conducted by H, doesn't
execute D far enough for that.

I've shown with code that the simulation does reach
the return statement when it is stepped after H
has abandoned with.

Code beats your lying nonsense.

Mostly it's /your/ code. It's your LoadState and SaveState
functions that are used, your DebugStep.

I just added what you needed to do yourself.

It is not honest to allow a decider to report a 0
result, without inspecting the evidence.

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 9:48 AM, Tristan Wibberley wrote:

On 28/10/2025 21:40, olcott wrote:

H simulates D
that calls H(D) to simulate D

... 4 repetitions snipped ...

until H sees this repeating pattern.

I'm beginning to suspect you mean literally, as in H counts calls to
H(D) four levels of H-on-D-simulation deep and is defined to thereupon halt.

If I repeat it the proper number times people
never bother to notice that it repeats.

As soon as H has simulated D twice then it can
recognize the repeating pattern and reject its
input as specifying a non-halting sequence of
configurations.

Unless you put cheats into the code, /every/ H at every
simulation level also monitors for two simulations of D
(the one it is simulatingl, plus one more). And /every/ H
returns 0 to its respective D.

You have never understood when there is a waiting
line of people that they don't all get to the head
of the line at the same time.

Tell Kaz you already know everything you need to about the Y combinator, >>> that specification is pure perfection and is most easily created /using/ >>> the Y combinator to compose the statement of the situation.

Kaz doesn't even seem to notice that D simulated by H
according to the semantics of the C language cannot
possibly reach its own simulated return statement.

/D/ reaches its simulated return statement.

void DDD()
{
HHH(DDD);
return;
}


Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what? DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*

Do you know C well enough to answer this in C?

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD) then what?

DDD dances the jig and jumps straight to its return instruction?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 9:48 AM, Tristan Wibberley wrote:

On 28/10/2025 21:40, olcott wrote:

H simulates D
that calls H(D) to simulate D

... 4 repetitions snipped ...

until H sees this repeating pattern.

I'm beginning to suspect you mean literally, as in H counts calls to
H(D) four levels of H-on-D-simulation deep and is defined to thereupon halt.

If I repeat it the proper number times people
never bother to notice that it repeats.

As soon as H has simulated D twice then it can
recognize the repeating pattern and reject its
input as specifying a non-halting sequence of
configurations.

Unless you put cheats into the code, /every/ H at every
simulation level also monitors for two simulations of D
(the one it is simulatingl, plus one more). And /every/ H
returns 0 to its respective D.

You have never understood when there is a waiting
line of people that they don't all get to the head
of the line at the same time.

Tell Kaz you already know everything you need to about the Y combinator, >>>> that specification is pure perfection and is most easily created /using/ >>>> the Y combinator to compose the statement of the situation.

Kaz doesn't even seem to notice that D simulated by H
according to the semantics of the C language cannot
possibly reach its own simulated return statement.

/D/ reaches its simulated return statement.

void DDD()
{
HHH(DDD);
return;
}

Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what? DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?

Yes. Well, actually I worked this in C++, but mostly C-like C++.

DDD in your latest Halt.obj, simulated by HHH, specifies
a terminating process which reaches address 0002183

Two nested simulations of DDD appear. When the inner one calls HHH, the abort criterion is triggered, and the directly executed HHH returns.

Then we take stock of the simulation state, and DebugStep it.

More simulations of DDD appear, and the simulated HHH hits the abort criteria, like its parent. It returns to the simulated DDD which ignores the return value and quits.

I understand you didn't intend for this to happen. You put in a forbidden
to try to have only the outer HHH perform aborting, not the nested ones.

Be that as it may, your cheat isn't correctly implemented, so
we get a facsimile of the correct behavior: simulated HHH(DDD) behaving
as it should be, the same like the directly executed one (as far
as returning 0).

$ ./x86utm_exe Halt7.obj | head
Convert_to_Sourcefile_Name[Halt7.c]
Read: 14364 bytes from "Halt7.obj"
Is an x86 based COFF Object File!
Section_Number(4): .text$mn
Section_Number(3): .data

[ ... ]

Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc
RECK: newly executing: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00002172
[00002172][001138bc][001138c0] 55 push ebp [00002173][001138bc][001138c0] 8bec mov ebp,esp [00002175][001138b8][00002172] 6872210000 push 00002172 [0000217a][001138b4][0000217f] e853f4ffff call 000015d2
New slave_stack at:14e2ec
RECK: newly executing: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 0014E2B0, EIP == 00002172
[00002172][0015e2e4][0015e2e8] 55 push ebp [00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp [00002175][0015e2e0][00002172] 6872210000 push 00002172 [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[0000219f][00103820][00000000] 83c404 add esp,+04 [000021a2][0010381c][00000000] 50 push eax [000021a3][00103818][00000743] 6843070000 push 00000743 [000021a8][00103818][00000743] e8b5e5ffff call 00000762
Input_Halts = 0
[000021ad][00103820][00000000] 83c408 add esp,+08 [000021b0][00103820][00000000] 33c0 xor eax,eax [000021b2][00103824][00000018] 5d pop ebp [000021b3][00103828][00000000] c3 ret
Number of Instructions Executed(10069) == 150 Pages
RECK: ---------------
RECK: simulations for these function still exist:
RECK: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00001216
RECK: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 0014E2B0, EIP == 000015D2
RECK: ---------------
RECK: continuing simulation of entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00001216
New slave_stack at:15e38c

Begin Local Halt Decider Simulation Execution Trace Stored at:16e394
RECK: newly executing: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 0015E350, EIP == 00002172
New slave_stack at:1a8db4
RECK: newly executing: entry == 00002172 (_DDD), code_end == 00002183, slave_state == 001A8D78, EIP == 00002172
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

RECK: simulation of entry == 00002172 (_DDD), code_end == 00002183, slave_state == 00103888, EIP == 00002183 reached code_end!
RECK: ---------------
RECK: reckoning completed
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 7:31 PM, Kaz Kylheku wrote:

void DDD()
{
HHH(DDD);
return;
}


Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what? DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?

Yes. Well, actually I worked this in C++, but mostly C-like C++.

DDD in your latest Halt.obj,

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?

Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
Do you know C well enough to answer this in C?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

*That is fucking ridiculous and you know it*

It's implemented and working; point to the lines of code you think are ridiculous.

*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*

Do you know C well enough to answer this in C?

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD) then what?

What is the definition of HHH? This does not compile.

Do you know C well enough to know that every external name that
is referenced referenced must be defined, once?

Since you don't define HHH, I'm going by the compiled one in Halt7.obj.

The DDD is the same as above.

I have detailed execution traces, thanks to some C++ code I added.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

Answer this in C
Answer this in C
Answer this in C
Answer this in C
Answer this in C

Answer this in C
Answer this in C
Answer this in C
Answer this in C
Answer this in C

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD) then what?
DDD dances the jig and jumps straight to its return instruction?

Answer that in C
Answer that in C
Answer that in C
Answer that in C
Answer that in C

Answer that in C
Answer that in C
Answer that in C
Answer that in C
Answer that in C
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 8:08 PM, olcott wrote:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*

Not at all. It's how we verify whether aborting was correct.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 01/11/2025 00:31, Kaz Kylheku wrote:

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

<snip>

void DDD()
{
HHH(DDD);
return;
}


Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what? DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?

Yes. Well, actually I worked this in C++, but mostly C-like C++.

Olcott's got a nerve. This is like Mrs Cunningham asking
Fonzarelli if he knows motorbikes well enough to fix one.

<snip>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 7:37 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

*That is fucking ridiculous and you know it*

It's implemented and working; point to the lines of code you think are ridiculous.

*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*

Do you know C well enough to answer this in C?

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD) then what?

What is the definition of HHH? This does not compile.

HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH

HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH

HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH

HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH

HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
HHH simulates DDD is the entire definition of HHH
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 7:31 PM, Kaz Kylheku wrote:

void DDD()
{
HHH(DDD);
return;
}


Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what? DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?

Yes. Well, actually I worked this in C++, but mostly C-like C++.

DDD in your latest Halt.obj,

Do you know C well enough to answer this in C?

I can write a C interpreter which can interpret itself.

I understand you currently think you need something like that, in order
to work the HHH/DD scenario entirely in source code.

My hourly rate for that is $175 USD.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 7:42 PM, Richard Heathfield wrote:

On 01/11/2025 00:31, Kaz Kylheku wrote:

On 2025-10-31, olcott <polcott333@gmail.com> wrote:

<snip>

void DDD()
{
    HHH(DDD);
    return;
}


Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what?  DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?

Yes. Well, actually I worked this in C++, but mostly C-like C++.

Olcott's got a nerve. This is like Mrs Cunningham asking Fonzarelli if
he knows motorbikes well enough to fix one.

<snip>

You have not been following how stupidly Kaz has been acting.

Chris has been acting so stupidly for so long that I made
a Thunderbird filter to *plonk* him. It erased everything
that he ever said.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 7:31 PM, Kaz Kylheku wrote:

void DDD()
{
HHH(DDD);
return;
}


Let's dumb this down as much as possible.

HHH simulates DDD then DDD calls HHH(DDD)
then what? DDD dances the jig and jumps
straight to its return instruction?

Do you know C well enough to answer this in C?

Yes. Well, actually I worked this in C++, but mostly C-like C++.

DDD in your latest Halt.obj,

Do you know C well enough to answer this in C?

I can write a C interpreter which can interpret itself.

I already have one that does that.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 7:37 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

*That is fucking ridiculous and you know it*

It's implemented and working; point to the lines of code you think are
ridiculous.

*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*

Do you know C well enough to answer this in C?

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD) then what?

What is the definition of HHH? This does not compile.

HHH simulates DDD is the entire definition of HHH

That doesn't look like C.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates, but
monitors the simulation for certain criteria based on which it stops simulating.

Pick another name.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 8:25 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 7:37 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

H says "I'm abandoning this simulation because the subject
inside it is non-terminating".

We then say, "is that so?" And keep the simulation going.
It naturally terminates, showing that H was mistaken.

*That is fucking ridiculous and you know it*

It's implemented and working; point to the lines of code you think are
ridiculous.

*That is fucking ridiculous and you know it*
*That is fucking ridiculous and you know it*

Do you know C well enough to answer this in C?

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD) then what?

What is the definition of HHH? This does not compile.

HHH simulates DDD is the entire definition of HHH

That doesn't look like C.

Over your head ?
You have no fucking idea what a simulator is
when you just said you could write one?

As a liar you may actually be literally damned
(condemned to actual Hell) even if you don't
believe in such things.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

but
monitors the simulation for certain criteria based on which it stops simulating.

Pick another name.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to refer
to something very much distinct from a UTM.

André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to refer
to something very much distinct from a UTM.

André

I posted a list of trustworthy reviewers and you were on it.
I had to dumb this down a whole lot because although

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

He pretends to have no idea how to answer this question:

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD)
what comes next?

He has been trying to get away with saying
that DDD simulated by HHH reaches its own
"return" statement and he got some other
liars involved.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to refer
to something very much distinct from a UTM.

André

*These are good reviewers*
Alan Mackenzie
André G. Isaak
Mikko
Ben Bacarisse
Mike Terry
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 10:49 PM, olcott wrote:

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to
refer to something very much distinct from a UTM.

André

I posted a list of trustworthy reviewers and you were on it.
I had to dumb this down a whole lot because although

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

He pretends to have no idea how to answer this question:

void DDD()
{
  HHH(DDD);
  return;
}

HHH simulates DDD then DDD calls HHH(DDD)
what comes next?

He has been trying to get away with saying
that DDD simulated by HHH reaches its own
"return" statement and he got some other
liars involved.

He has source code that proves it. That means you're disagreeing with
source code. And as you yourself said:

On 2/8/2025 9:59 AM, olcott wrote:

Disagreeing with source-code is not a smart thing to do.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 7:49 PM, olcott wrote:

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to
refer to something very much distinct from a UTM.

André

I posted a list of trustworthy reviewers and you were on it.
I had to dumb this down a whole lot because although

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

He pretends to have no idea how to answer this question:

void DDD()
{
  HHH(DDD);
  return;
}

that is basically, HHH crap aside:

HHH_Blow() { D_Blow_Stack(); }

D_Blow_Stack() { HHH_Blow(); }

You must just add in an artificial recursion threshold, and say, it's
never going to halt... Sigh, this is nothing new, and you cannot use
that as a general thing that works with all other programs under consideration. When you detect non-termination in DD, and DD does not
halt, you are totally wrong because DD can halt. D_Blow_Stack/HHH_Blow
here is just runaway. You have to make a new contrived bug ridden
HHHHH.., per whatever for your DDD,DD,D, DDD_moron, dDD, ect... to say
here it works now. Then still get it wrong?

HHH simulates DDD then DDD calls HHH(DDD)
what comes next?

He has been trying to get away with saying
that DDD simulated by HHH reaches its own
"return" statement and he got some other
liars involved.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 7:53 PM, olcott wrote:

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to
refer to something very much distinct from a UTM.

André

*These are good reviewers*
Alan Mackenzie
André G. Isaak
Mikko
Ben Bacarisse
Mike Terry

You forgot Kaz! He actually coded up something than can help you find
your bugs.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Pick a set of names for all your digital offsprings,
your Dicks and Harrys.

Document that set of names, and stick with it from then on.

You have sort of done that; you defined a bunch of them in Halt7.c.

When-so-ever you use any of the names D, DD, H, HH, H1, HHH, HHH1
and whatnot, they shall be interpreted as the definitions in
Halt7.c.

Not just any old Halt7.c, but this one:

commit 48b4cbfeb3f486507276a5fc4e9b10875ab24dbf
Author: plolcott <59188130+plolcott@users.noreply.github.com>
Date: Sat Feb 15 18:44:02 2025 -0600

Add files via upload

That file doesn't have a UTM(), so I don't know what that
is. Is HHH1 a close enouch facsimile to be served as UTM?

If so, pose the question in terms of HHH1.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 10:09 PM, dbush wrote:

On 10/31/2025 10:49 PM, olcott wrote:

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to
refer to something very much distinct from a UTM.

André

I posted a list of trustworthy reviewers and you were on it.
I had to dumb this down a whole lot because although

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

He pretends to have no idea how to answer this question:

void DDD()
{
   HHH(DDD);
   return;
}

HHH simulates DDD then DDD calls HHH(DDD)
what comes next?

He has been trying to get away with saying
that DDD simulated by HHH reaches its own
"return" statement and he got some other
liars involved.

He has source code that proves it.

If he has source that proves the impossible
then that source must be incorrect.

There is a proof that 1==0 too.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to refer
to something very much distinct from a UTM.

André

I posted a list of trustworthy reviewers and you were on it.
I had to dumb this down a whole lot because although

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

He pretends to have no idea how to answer this question:

void DDD()
{
HHH(DDD);
return;
}

HHH simulates DDD then DDD calls HHH(DDD)
what comes next?

In this thread, you've been insisting that HHH is UTM, a pure
simulator.

That's not how it is defined in Halt7.c, and so please stop trying to
confuse things by playing "musical names" with all your definitions.

He has been trying to get away with saying
that DDD simulated by HHH reaches its own

The HHH which is in the Halt7.obj is not UTM. It has the abort check.
DDD calls that HHH, and that DDD simulated by /that/ HHH terminates.

I have no reason to accept any other definition for HHH, other
than the one you formally documented in code.

I have not made any claim that a fictitious DDD, which calls UTM(DDD), is terminating. (I believe such a DDD would be nonterminating; but
it must not be called by the name DDD, which is taken.

"return" statement and he got some other
liars involved.

Since that was published, you have reduced yourself to a name-calling
automaton with zero substance.

(It wasn't a big drop; you probably didn't even have to bend your knees
to soften the landing.)

The problem is that while you call people liars, anyone
can clone the code and reproduce the same traces.

You will not convince anyone that the code's behavior is fabricated,
simply by name calling, with zero specifics.

It's a small amount of code that mostly calls into /your/ code:
your pieces like LoadState and DebugStep.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 10:15 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Pick a set of names for all your digital offsprings,
your Dicks and Harrys.

Document that set of names, and stick with it from then on.

You have sort of done that; you defined a bunch of them in Halt7.c.

When-so-ever you use any of the names D, DD, H, HH, H1, HHH, HHH1
and whatnot, they shall be interpreted as the definitions in
Halt7.c.

Not just any old Halt7.c, but this one:

commit 48b4cbfeb3f486507276a5fc4e9b10875ab24dbf
Author: plolcott <59188130+plolcott@users.noreply.github.com>
Date: Sat Feb 15 18:44:02 2025 -0600

Add files via upload

That file doesn't have a UTM(), so I don't know what that
is. Is HHH1 a close enouch facsimile to be served as UTM?

If so, pose the question in terms of HHH1.

I didn't expect that I would have to dumb it
down that much for a guy that makes this claim:

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

That can only be that you are a damned liar on
one of these two claims.

void D5()
{
H5(D5);
return;
}

H5 simulates D5 that calls H5(D5)
What the fuck comes next IN C

In C In C In C In C In C In C
In C In C In C In C In C In C
In C In C In C In C In C In C
In C In C In C In C In C In C
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

I didn't expect that I would have to dumb it
down that much for a guy that makes this claim:

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

That can only be that you are a damned liar on
one of these two claims.

void D5()
{
H5(D5);
return;
}

H5 simulates D5 that calls H5(D5)
What the fuck comes next IN C

In C In C In C In C In C In C
In C In C In C In C In C In C
In C In C In C In C In C In C
In C In C In C In C In C In C
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/31/2025 11:22 PM, olcott wrote:

On 10/31/2025 10:09 PM, dbush wrote:

On 10/31/2025 10:49 PM, olcott wrote:

On 10/31/2025 9:43 PM, André G. Isaak wrote:

On 2025-10-31 19:38, olcott wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Then why call it HHH rather than UTM? You've already used "HHH" to
refer to something very much distinct from a UTM.

André

I posted a list of trustworthy reviewers and you were on it.
I had to dumb this down a whole lot because although

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

He pretends to have no idea how to answer this question:

void DDD()
{
   HHH(DDD);
   return;
}

HHH simulates DDD then DDD calls HHH(DDD)
what comes next?

He has been trying to get away with saying
that DDD simulated by HHH reaches its own
"return" statement and he got some other
liars involved.

He has source code that proves it.

If he has source

On 2/8/2025 9:59 AM, olcott wrote:

Disagreeing with source-code is not a smart thing to do.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 10:15 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

On 10/31/2025 8:28 PM, Kaz Kylheku wrote:

On 2025-11-01, olcott <polcott333@gmail.com> wrote:

HHH simulates DDD then DDD calls HHH(DDD) then what?

The name HHH is taken for a function which not only simulates,

Not in this case you are far too much of a liar
to trust you with more than one tiny detail.

HHH is UTM.

Pick a set of names for all your digital offsprings,
your Dicks and Harrys.

Document that set of names, and stick with it from then on.

You have sort of done that; you defined a bunch of them in Halt7.c.

When-so-ever you use any of the names D, DD, H, HH, H1, HHH, HHH1
and whatnot, they shall be interpreted as the definitions in
Halt7.c.

Not just any old Halt7.c, but this one:

commit 48b4cbfeb3f486507276a5fc4e9b10875ab24dbf
Author: plolcott <59188130+plolcott@users.noreply.github.com>
Date: Sat Feb 15 18:44:02 2025 -0600

Add files via upload

That file doesn't have a UTM(), so I don't know what that
is. Is HHH1 a close enouch facsimile to be served as UTM?

If so, pose the question in terms of HHH1.

I didn't expect that I would have to dumb it
down that much for a guy that makes this claim:

Precisely defining what you mean by every single name like HHH,
and then sticking to that definition henceforth, is
an activity which does not whatsoever meet any reaosnable
definition of "dumbing down".

On 10/31/2025 7:44 PM, Kaz Kylheku wrote:

I can write a C interpreter which can interpret itself.

That can only be that you are a damned liar on
one of these two claims.

void D5()
{
H5(D5);
return;
}

H5 simulates D5 that calls H5(D5)

OK, you have chosen different names. that's fine for the present, but do
you want to commit to these definitions of H5 going forward?

Anyway, in this thread only, let us supose that H5 is just a simulator;
it simulates to completion.

D5 is as above.

D5 calls H5, which initiates an exhaustive simulation of D5.
The simulated D5 calls H5 which again initiates a simulation.

In this scenario, no invocation of any H5 at any simulation
level returns to its D5.

Why are we still discussing it? You need to keep better
track of who agreed with what.

I and multiple others have already agreed with all this numerous times.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Fri, 31 Oct 2025 18:05:17 -0500 schrieb olcott:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

Unless you put cheats into the code, /every/ H at every simulation
level also monitors for two simulations of D (the one it is
simulatingl, plus one more). And /every/ H returns 0 to its respective
D.

You have never understood when there is a waiting line of people that
they don't all get to the head of the line at the same time.

Of course not at the same time, only after the first one. Yes, I know
that the line stops being served at that point; that doesn’t make the
line go away.

/D/ reaches its simulated return statement.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 11/1/2025 6:52 AM, joes wrote:

Am Fri, 31 Oct 2025 18:05:17 -0500 schrieb olcott:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

Unless you put cheats into the code, /every/ H at every simulation
level also monitors for two simulations of D (the one it is
simulatingl, plus one more). And /every/ H returns 0 to its respective
D.

You have never understood when there is a waiting line of people that
they don't all get to the head of the line at the same time.

Of course not at the same time, only after the first one. Yes, I know
that the line stops being served at that point; that doesn’t make the
line go away.

The line is infinitely long.
As soon as H sees this it stops serving.

/D/ reaches its simulated return statement.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 11/1/2025 9:10 AM, olcott wrote:

On 11/1/2025 6:52 AM, joes wrote:

Am Fri, 31 Oct 2025 18:05:17 -0500 schrieb olcott:

On 10/31/2025 5:54 PM, Kaz Kylheku wrote:

Unless you put cheats into the code, /every/ H at every simulation
level also monitors for two simulations of D (the one it is
simulatingl, plus one more). And /every/ H returns 0 to its respective >>>> D.

You have never understood when there is a waiting line of people that
they don't all get to the head of the line at the same time.

Of course not at the same time, only after the first one. Yes, I know
that the line stops being served at that point; that doesn’t make the
line go away.

The line is infinitely long.
As soon as H sees this it stops serving.

Except that we're not asking whether or not the line is infinitely long.
We're asking whether or not it takes an infinite amount of time to
serve each individual person.

/D/ reaches its simulated return statement.

--- Synchronet 3.21a-Linux NewsLink 1.2