H and H1 are identical except that D does not call H1.
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of functions.
(The idea that two otherwise identical functions with different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of functions.
(The idea that two otherwise identical functions with different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
*From the bottom of page 319 has been adapted to this*
don't fucking erase it in your reply
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of functions. >>> (The idea that two otherwise identical functions with different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of
functions.
(The idea that two otherwise identical functions with different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical
maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of
functions.
(The idea that two otherwise identical functions with different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
But, yes, come to think of it, the diagonal halting situation
can be worked without names.
Using a construction known as the Y combinator, we can pass
a function to itself as an argument without giving it
a defined name.
The decider can also be passed in as a lambda.
We can eliminate parameter names. using De Bruijn indices.
So there you have homework: look up lambda calculus, Y combinator,
De Bruijn indices.
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is different between H(D) and UTM(D), if we just at /just/ the instructions
of the simulated D, those are the same.
In the case of H, the
simulation is left incomplete,
but the instructions up to the point
where it is are the same as those for UTM(D), and so from there it
continues to be the same.
You obviously don't understand this and are taking guesses
without making any specific references to specific code.
Brian Kernighan wrote that debugging is twice as hard as writing the
code, so if you are as clever as you can be when writing the code, you
are not clever enough to debug it.
It is painfully obvious that you were as clever as you can be when constructing the x86utm and Halt7 materials.
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
In the case of H, the
simulation is left incomplete,
In the same way that the simulation of
void Infinite_Recursion()
{
 Infinite_Recursion();
 return;
}
void Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
is left incomplete in that an infinite simulation
any of the by H cannot possibly reach their own
simulated "return" statement final halt state.
but the instructions up to the point
where it is are the same as those for UTM(D), and so from there it
continues to be the same.
Not at all. at the point where D calls H(D) they
diverge.
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical >>>>>>> maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of
functions.
(The idea that two otherwise identical functions with different names >>>>> are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same up to
the point that H aborts
as shown in the side by side trace posted by--
Mike, and Kaz's code show that if the simulation aborted by H is
continued that it will match up with the simulation performed by H and
halt.
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical >>>>>>>> maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of
functions.
(The idea that two otherwise identical functions with different names >>>>>> are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same up
to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D) and in the above repeats
five times. Whereas D never calls H1 thus never
repeats at all.
Its not that hard you guys are acting like freaking morons.
as shown in the side by side trace posted by Mike, and Kaz's code show
that if the simulation aborted by H is continued that it will match up
with the simulation performed by H and halt.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the instructions >>> of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one that matters) exactly once, just like the top level H1.
On 10/30/2025 9:10 PM, dbush wrote:
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one that
matters) exactly once, just like the top level H1.
And I only have one dollar in my pocket
because the other fifty don't matter.
Lame and stupid rebuttal.
The point is the D simulated by H cannot possibly
stop running on its own and D simulated by H1 does
stop on its own. Because I have said this so many
times I will add: dip shit !!!
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical >>>>>>>> maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of
functions.
(The idea that two otherwise identical functions with different names >>>>>> are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same up
to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
On 10/30/2025 9:10 PM, dbush wrote:
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one that
matters) exactly once, just like the top level H1.
And I only have one dollar in my pocket
because the other fifty don't matter.
Lame and stupid rebuttal.
The point is the D simulated by H cannot possiblyProven false by Kaz's code which demonstrates that it does.
stop running on its own
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical >>>>>>>>> maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of
functions.
(The idea that two otherwise identical functions with different >>>>>>> names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same up
to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the second, etc.
So both the same up the point that H aborts.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the instructions >>> of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one that matters)
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical >>>>>>>>>> maturity of a toddler.
Function names are not significant in the mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of >>>>>>>> functions.
(The idea that two otherwise identical functions with different >>>>>>>> names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same up >>>> to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the second,
etc.
So both the same up the point that H aborts.
Not at all.
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one that
matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both top-
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1.
This is idiotic and exposes you as someone with the mathematical >>>>>>>>>>> maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of >>>>>>>>> functions.
(The idea that two otherwise identical functions with different >>>>>>>>> names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same
up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the
second, etc.
So both the same up the point that H aborts.
Not at all.
level simulations up to the point that the top level H aborts.
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is >>>>> different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one that
matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both top-
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
H and H1 are identical except that D does not call H1. >>>>>>>>>>>>This is idiotic and exposes you as someone with the
mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of >>>>>>>>>> functions.
(The idea that two otherwise identical functions with
different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same >>>>>> up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the
second, etc.
So both the same up the point that H aborts.
Not at all.
level simulations up to the point that the top level H aborts.
That is not the point fuckhead.
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is >>>>>> different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one
that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both top-
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>
This is idiotic and exposes you as someone with the >>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence of >>>>>>>>>>> functions.
(The idea that two otherwise identical functions with
different names
are different functions.)
There is no such preposterious garbage in the theory of
recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the same >>>>>>> up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the
second, etc.
So both the same up the point that H aborts.
Not at all.
level simulations up to the point that the top level H aborts.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz showed that continuing the aborted simulation results in it reaching its final
state, proving that the answer provided by H is wrong.
I don't think that is the shell game. PO really /has/ an H--
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 10/30/2025 9:50 PM, dbush wrote:No you're not. These are not the same machine:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is >>>>>> different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one
that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>
This is idiotic and exposes you as someone with the >>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence >>>>>>>>>>>> of functions.
(The idea that two otherwise identical functions with >>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>> recursive functions, or pretty much anywhere in math.
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the >>>>>>>> same up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the
second, etc.
So both the same up the point that H aborts.
Not at all.
top- level simulations up to the point that the top level H aborts.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz showed that
continuing the aborted simulation results in it reaching its final
state, proving that the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is >>>>>>> different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one
that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
These are not the same machine:
int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
int DD()
{
  int Halt_Status = UTM(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire
scenario is
different between H(D) and UTM(D), if we just at /just/ the
instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one >>>>>> that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>>
This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit?
The diagonal test case does not depend on name equivalence >>>>>>>>>>>>> of functions.
(The idea that two otherwise identical functions with >>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the >>>>>>>>> same up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the
second, etc.
So both the same up the point that H aborts.
Not at all.
top- level simulations up to the point that the top level H aborts.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz showed that
continuing the aborted simulation results in it reaching its final
state, proving that the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully operational code that proves you wrong.
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:That is not the point fuckhead.
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both >>>>>> top- level simulations up to the point that the top level H aborts. >>>>>
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
The diagonal test case does not depend on name equivalence >>>>>>>>>>>>>> of functions.On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>>>
This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>
(The idea that two otherwise identical functions with >>>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works
without names dip shit!
I didn't say "without names", but "without an entity
being considered two different entities juwst because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the >>>>>>>>>> same up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the >>>>>>>> second, etc.
So both the same up the point that H aborts.
Not at all.
That is exactly the point. It's also the point that Kaz showed that >>>> continuing the aborted simulation results in it reaching its final
state, proving that the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
On 10/30/2025 11:01 PM, olcott wrote:
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire
scenario is
different between H(D) and UTM(D), if we just at /just/ the >>>>>>>>> instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one >>>>>>> that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
Then you admit that when you change the code of the function H that you
no longer have algorithm H and algorithm D, which are the decider
algorithm and algorithm to be decided on respectively.
On 10/30/2025 10:03 PM, dbush wrote:
On 10/30/2025 11:01 PM, olcott wrote:
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire
scenario is
different between H(D) and UTM(D), if we just at /just/ the >>>>>>>>>> instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only one >>>>>>>> that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
Then you admit that when you change the code of the function H that
you no longer have algorithm H and algorithm D, which are the decider
algorithm and algorithm to be decided on respectively.
H must correctly predict
predict
predict
predict
predict
predict
predict
predict
predict
whether continuing to simulate D will cause
its own non-termination.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:That is not the point fuckhead.
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both >>>>>>> top- level simulations up to the point that the top level H aborts. >>>>>>
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
The diagonal test case does not depend on nameOn 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>>>>
This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>
equivalence of functions.
(The idea that two otherwise identical functions with >>>>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the >>>>>>>>>>> same up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the >>>>>>>>> second, etc.
So both the same up the point that H aborts.
Not at all.
That is exactly the point. It's also the point that Kaz showed
that continuing the aborted simulation results in it reaching its
final state, proving that the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
I don't think that is the shell game. PO really /has/ an H--
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 10/30/2025 11:05 PM, olcott wrote:
On 10/30/2025 10:03 PM, dbush wrote:
On 10/30/2025 11:01 PM, olcott wrote:
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire >>>>>>>>>>> scenario is
different between H(D) and UTM(D), if we just at /just/ the >>>>>>>>>>> instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only >>>>>>>>> one that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
Then you admit that when you change the code of the function H that
you no longer have algorithm H and algorithm D, which are the decider
algorithm and algorithm to be decided on respectively.
H must correctly predict
predict
predict
predict
predict
predict
predict
predict
predict
whether continuing to simulate D will cause
its own non-termination.
In other words, instead of reporting on its input:
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:That is not the point fuckhead.
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between both >>>>>>>> top- level simulations up to the point that the top level H aborts. >>>>>>>
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote:
The diagonal test case does not depend on name >>>>>>>>>>>>>>>> equivalence of functions.On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>>>>>
This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck
can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions with >>>>>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly the >>>>>>>>>>>> same up to the point that H aborts
*Mike never did get this and I know that he is honest*
The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then the >>>>>>>>>> second, etc.
So both the same up the point that H aborts.
Not at all.
That is exactly the point. It's also the point that Kaz showed
that continuing the aborted simulation results in it reaching its >>>>>> final state, proving that the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
On 10/30/2025 10:06 PM, dbush wrote:
On 10/30/2025 11:05 PM, olcott wrote:
On 10/30/2025 10:03 PM, dbush wrote:
On 10/30/2025 11:01 PM, olcott wrote:
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire >>>>>>>>>>>> scenario is
different between H(D) and UTM(D), if we just at /just/ the >>>>>>>>>>>> instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only >>>>>>>>>> one that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
Then you admit that when you change the code of the function H that
you no longer have algorithm H and algorithm D, which are the
decider algorithm and algorithm to be decided on respectively.
H must correctly predict
predict
predict
predict
predict
predict
predict
predict
predict
whether continuing to simulate D will cause
its own non-termination.
In other words, instead of reporting on its input:
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
It reports that it must abort its simulation
of its input to prevent is own non-termination
shit head.
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you wrong. >>>
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between >>>>>>>>> both top- level simulations up to the point that the top level >>>>>>>>> H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>>>>>>
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>> equivalence of functions.This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the mathematics of >>>>>>>>>>>>>>>>>>> recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions with >>>>>>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly >>>>>>>>>>>>> the same up to the point that H aborts
*Mike never did get this and I know that he is honest* >>>>>>>>>>>> The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then >>>>>>>>>>> the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz showed >>>>>>> that continuing the aborted simulation results in it reaching its >>>>>>> final state, proving that the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
Failure to do so in your next reply or within one hour of your next post
in this newsgroup will be taken as your official on-the-record admission that Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
On 10/30/2025 11:16 PM, olcott wrote:
On 10/30/2025 10:06 PM, dbush wrote:
On 10/30/2025 11:05 PM, olcott wrote:
On 10/30/2025 10:03 PM, dbush wrote:
On 10/30/2025 11:01 PM, olcott wrote:
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire >>>>>>>>>>>>> scenario is
different between H(D) and UTM(D), if we just at /just/ the >>>>>>>>>>>>> instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
False. D is simulated by the top level H (which is the only >>>>>>>>>>> one that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
Then you admit that when you change the code of the function H that >>>>> you no longer have algorithm H and algorithm D, which are the
decider algorithm and algorithm to be decided on respectively.
H must correctly predict
predict
predict
predict
predict
predict
predict
predict
predict
whether continuing to simulate D will cause
its own non-termination.
In other words, instead of reporting on its input:
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
It reports that it must abort its simulation
of its input to prevent is own non-termination
shit head.
i.e. it reports on this non-input:
int D()
{
 int Halt_Status = UTM(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between >>>>>>>>>> both top- level simulations up to the point that the top level >>>>>>>>>> H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not call H1. >>>>>>>>>>>>>>>>>>>>
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>> equivalence of functions.This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions with >>>>>>>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly >>>>>>>>>>>>>> the same up to the point that H aborts
*Mike never did get this and I know that he is honest* >>>>>>>>>>>>> The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then >>>>>>>>>>>> the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz showed >>>>>>>> that continuing the aborted simulation results in it reaching >>>>>>>> its final state, proving that the answer provided by H is wrong. >>>>>>>>
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
wrong.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your next
post in this newsgroup will be taken as your official on-the-record
admission that Kaz's code correctly demonstrates that the D simulated
by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
In the case of H, the
simulation is left incomplete,
In the same way that the simulation of
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
is left incomplete in that an infinite simulation
but the instructions up to the point
where it is are the same as those for UTM(D), and so from there it
continues to be the same.
Not at all. at the point where D calls H(D) they
diverge.
You obviously don't understand this and are taking guesses
without making any specific references to specific code.
That is such a ridiculously stupid thing to say that
I cannot imagine that it is not simply a damned lie.
On 10/30/2025 10:20 PM, dbush wrote:
On 10/30/2025 11:16 PM, olcott wrote:
On 10/30/2025 10:06 PM, dbush wrote:
On 10/30/2025 11:05 PM, olcott wrote:
On 10/30/2025 10:03 PM, dbush wrote:
On 10/30/2025 11:01 PM, olcott wrote:
On 10/30/2025 9:58 PM, dbush wrote:
On 10/30/2025 10:56 PM, olcott wrote:
On 10/30/2025 9:50 PM, dbush wrote:
On 10/30/2025 10:48 PM, olcott wrote:
On 10/30/2025 9:10 PM, dbush wrote:Strawman. Then you're not longer talking about H and D.
On 10/30/2025 10:07 PM, olcott wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire >>>>>>>>>>>>>> scenario is
different between H(D) and UTM(D), if we just at /just/ >>>>>>>>>>>>>> the instructions
of the simulated D, those are the same.
No not even that. D is simulated by H more than once >>>>>>>>>>>>> and only simulated by H1 once.
False. D is simulated by the top level H (which is the only >>>>>>>>>>>> one that matters)
What the fuck kind of lame bullshit is this dip shit?
Unless H aborts
Yes I am you stupid fuck.
No you're not.
The that only leaves damned liar.
These are not the same machine:
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
int DD()
{
   int Halt_Status = UTM(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
I will admit that you are right when you are
right. (immediately above you are correct)
You seem to be too much of a fuckhead to do that.
Then you admit that when you change the code of the function H
that you no longer have algorithm H and algorithm D, which are the >>>>>> decider algorithm and algorithm to be decided on respectively.
H must correctly predict
predict
predict
predict
predict
predict
predict
predict
predict
whether continuing to simulate D will cause
its own non-termination.
In other words, instead of reporting on its input:
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
It reports that it must abort its simulation
of its input to prevent is own non-termination
shit head.
i.e. it reports on this non-input:
int D()
{
  int Halt_Status = UTM(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
Halt deciders
must predict whether
or not their simulated input can reach
its simulated final halt state.
*I tried being nice and you took that as weakness*
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the instructions >>> of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
In the case of H, the
simulation is left incomplete,
In the same way that the simulation of
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
is left incomplete in that an infinite simulation
Yes, those are also incomplete. More steps of them can be performed; but
of course they can never be completed.
D is a terminating procedure of which a simulation is left incomplete.
but the instructions up to the point
where it is are the same as those for UTM(D), and so from there it
continues to be the same.
Not at all. at the point where D calls H(D) they
diverge.
You have not showed with code that they do.
I don't think that is the shell game. PO really /has/ an H--
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between >>>>>>>>>>> both top- level simulations up to the point that the top >>>>>>>>>>> level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not call >>>>>>>>>>>>>>>>>>>>>> H1.
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>> equivalence of functions.
This is idiotic and exposes you as someone with the >>>>>>>>>>>>>>>>>>>>> mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions with >>>>>>>>>>>>>>>>>>> different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly >>>>>>>>>>>>>>> the same up to the point that H aborts
*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>> The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then >>>>>>>>>>>>> the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz showed >>>>>>>>> that continuing the aborted simulation results in it reaching >>>>>>>>> its final state, proving that the answer provided by H is wrong. >>>>>>>>>
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
wrong.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your next
post in this newsgroup will be taken as your official on-the-record
admission that Kaz's code correctly demonstrates that the D simulated
by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show where
Kaz's code is wrong. Therefore, as per the above criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you >>>>>> wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between >>>>>>>>>>>> both top- level simulations up to the point that the top >>>>>>>>>>>> level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:
On 10/30/2025 4:15 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not >>>>>>>>>>>>>>>>>>>>>>> call H1.
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>> equivalence of functions.
This is idiotic and exposes you as someone with >>>>>>>>>>>>>>>>>>>>>> the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions >>>>>>>>>>>>>>>>>>>> with different names
are different functions.)
There is no such preposterious garbage in the theory of >>>>>>>>>>>>>>>>>>>> recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are exactly >>>>>>>>>>>>>>>> the same up to the point that H aborts
*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>> The simulations are exactly the same up to the
point where D calls H(D)
After which both simulate the first instruction of H, then >>>>>>>>>>>>>> the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>> showed that continuing the aborted simulation results in it >>>>>>>>>> reaching its final state, proving that the answer provided by >>>>>>>>>> H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully
operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your next
post in this newsgroup will be taken as your official on-the-record
admission that Kaz's code correctly demonstrates that the D
simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show where
Kaz's code is wrong. Therefore, as per the above criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
That might get you condemned to actual Hell
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you >>>>>>> wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between >>>>>>>>>>>>> both top- level simulations up to the point that the top >>>>>>>>>>>>> level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>> point where D calls H(D)
On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not >>>>>>>>>>>>>>>>>>>>>>>> call H1.
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>> equivalence of functions.
This is idiotic and exposes you as someone with >>>>>>>>>>>>>>>>>>>>>>> the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions >>>>>>>>>>>>>>>>>>>>> with different names
are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>
After which both simulate the first instruction of H, >>>>>>>>>>>>>>> then the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>> showed that continuing the aborted simulation results in it >>>>>>>>>>> reaching its final state, proving that the answer provided by >>>>>>>>>>> H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully >>>>>>>>> operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your next >>>>> post in this newsgroup will be taken as your official on-the-record >>>>> admission that Kaz's code correctly demonstrates that the D
simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show where
Kaz's code is wrong. Therefore, as per the above criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under penalty of making the above admission.
You chose not to show where Kaz's code is--
wrong, therefore your above admission has been entered into the official record.
On 10/30/2025 10:29 PM, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is
different between H(D) and UTM(D), if we just at /just/ the instructions >>>> of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
In the case of H, the
simulation is left incomplete,
In the same way that the simulation of
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
is left incomplete in that an infinite simulation
Yes, those are also incomplete. More steps of them can be performed; but
of course they can never be completed.
D is a terminating procedure of which a simulation is left incomplete.
but the instructions up to the point
where it is are the same as those for UTM(D), and so from there it
continues to be the same.
Not at all. at the point where D calls H(D) they
diverge.
You have not showed with code that they do.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H1 simulates D --- ONCE
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
H simulates D --- SIX TIMES
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
You can't be that stupid.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your next post
in this newsgroup will be taken as your official on-the-record admission
that Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
Kaz's code is a break from reality
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves >>>>>>>> you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence >>>>>>>>>>>>>> between both top- level simulations up to the point that >>>>>>>>>>>>>> the top level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>>> point where D calls H(D)
On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not >>>>>>>>>>>>>>>>>>>>>>>>> call H1.
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>>> equivalence of functions.
This is idiotic and exposes you as someone with >>>>>>>>>>>>>>>>>>>>>>>> the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions >>>>>>>>>>>>>>>>>>>>>> with different names
are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>
After which both simulate the first instruction of H, >>>>>>>>>>>>>>>> then the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>>> showed that continuing the aborted simulation results in it >>>>>>>>>>>> reaching its final state, proving that the answer provided >>>>>>>>>>>> by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully >>>>>>>>>> operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your
next post in this newsgroup will be taken as your official on-the- >>>>>> record admission that Kaz's code correctly demonstrates that the D >>>>>> simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show where
Kaz's code is wrong. Therefore, as per the above criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H
will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under penalty of
making the above admission.
That is not how reality works.
You are the one that is backed into a corner here and no amount
of pure bluster will get you out. Failing to provide the requested
steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your above
admission has been entered into the official record.
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves >>>>>>>>> you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>> between both top- level simulations up to the point that >>>>>>>>>>>>>>> the top level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>> point where D calls H(D)
On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>>>> equivalence of functions.H and H1 are identical except that D does not >>>>>>>>>>>>>>>>>>>>>>>>>> call H1.
This is idiotic and exposes you as someone with >>>>>>>>>>>>>>>>>>>>>>>>> the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions >>>>>>>>>>>>>>>>>>>>>>> with different names
are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere in >>>>>>>>>>>>>>>>>>>>>>> math.
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>
After which both simulate the first instruction of H, >>>>>>>>>>>>>>>>> then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>>>> showed that continuing the aborted simulation results in it >>>>>>>>>>>>> reaching its final state, proving that the answer provided >>>>>>>>>>>>> by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully >>>>>>>>>>> operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your
next post in this newsgroup will be taken as your official on-
the- record admission that Kaz's code correctly demonstrates that >>>>>>> the D simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show where >>>>> Kaz's code is wrong. Therefore, as per the above criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H
will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under penalty
of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. And as
you yourself said:
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount
of pure bluster will get you out. Failing to provide the requested
steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your above
admission has been entered into the official record.
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
My code is correct pee (not pea) brain.
Your beliefs and claims about your code do not match your code.
Also, your "Root" variable is not working in what is almost certainly
the intended manner.
Failure to do so in your next reply or within one hour of your next post >>> in this newsgroup will be taken as your official on-the-record admission >>> that Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
Kaz's code is a break from reality
Which line, which function?
What does it mean to break from reality, of code that compiles
and executes?
Can you show a small C example which you believe similarly
breaks from reality?
Can you give even a smidgeon of evidence for anything you say?
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves >>>>>>>>>> you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>>> between both top- level simulations up to the point that >>>>>>>>>>>>>>>> the top level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>> point where D calls H(D)
On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>>>>> equivalence of functions.H and H1 are identical except that D does not >>>>>>>>>>>>>>>>>>>>>>>>>>> call H1.
This is idiotic and exposes you as someone >>>>>>>>>>>>>>>>>>>>>>>>>> with the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions >>>>>>>>>>>>>>>>>>>>>>>> with different names
are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere in >>>>>>>>>>>>>>>>>>>>>>>> math.
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>>
After which both simulate the first instruction of H, >>>>>>>>>>>>>>>>>> then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>>>>> showed that continuing the aborted simulation results in >>>>>>>>>>>>>> it reaching its final state, proving that the answer >>>>>>>>>>>>>> provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully >>>>>>>>>>>> operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your >>>>>>>> next post in this newsgroup will be taken as your official on- >>>>>>>> the- record admission that Kaz's code correctly demonstrates
that the D simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show
where Kaz's code is wrong. Therefore, as per the above criteria: >>>>>>
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H
will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under penalty
of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. And as
you yourself said:
When the conclusion is categorically impossible
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount
of pure bluster will get you out. Failing to provide the requested
steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your
above admission has been entered into the official record.
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 10:29 PM, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
On 10/30/2025 7:22 PM, Kaz Kylheku wrote:
On 2025-10-30, olcott <polcott333@gmail.com> wrote:
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
While the overall sequence of instructions in the entire scenario is >>>>> different between H(D) and UTM(D), if we just at /just/ the instructions >>>>> of the simulated D, those are the same.
No not even that. D is simulated by H more than once
and only simulated by H1 once.
In the case of H, the
simulation is left incomplete,
In the same way that the simulation of
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
is left incomplete in that an infinite simulation
Yes, those are also incomplete. More steps of them can be performed; but >>> of course they can never be completed.
D is a terminating procedure of which a simulation is left incomplete.
but the instructions up to the point
where it is are the same as those for UTM(D), and so from there it
continues to be the same.
Not at all. at the point where D calls H(D) they
diverge.
You have not showed with code that they do.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H1 simulates D --- ONCE
that calls H(D) to simulate D
then H(D) returns 0 to caller D
... that D returns and ...
then H1 returns 1;
H simulates D --- SIX TIMES
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
I've not seen a test case which goes six deep;
Maybe you had such at some some point?
It is possible tweak the abort criteria so that a depth of six has to be seen; it will take a considerably large execution trace buffer (even
my sliding window modification may not help; some filtering will
have to be added to only record those events that are needed for
the abort decision).
There is an interpretation factor at each level; it takes many
instructions at one level to run one complete DebugStep cycle and the
rest of the loop around it, which achieves just one instruction at the
level below.
Let's say that the factor is 100: 100 instructions.
To have these levels:
H simulates D --- SIX TIMES (10000000000 instructions)
that calls H(D) to simulate D (100000000 instructions)
that calls H(D) to simulate D (1000000 instructions)
that calls H(D) to simulate D (10000 instructions)
that calls H(D) to simulate D (100 instructions)
that calls H(D) to simulate D (1 instruction)
With all these levels, one instruction at the most nested level takes
ten billion instructions (under an in terpretation factor of 100, which
seems conservative for the x86emu and the DebugStep and Decide_Halting wrappers around it.) Every DebugStep does a LoadState and SaveState and
such. It all costs cycles; the real interpretation factor is probably
much higher, probably several hundred? We can add instrumentation
to figure that out.
You must have run this 6-stack sandwich for days and days ...
You can't be that stupid.
The only thing stupid about me is giving this any time at all.
There are talented devs out there who can't get anyone to try
their application. You are ungrateful.
On 10/31/2025 7:55 AM, olcott wrote:
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves >>>>>>>>>>> you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:In other words, you don't have the guts to look at his >>>>>>>>>>>>> fully operational code that proves you wrong.
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>>>> between both top- level simulations up to the point >>>>>>>>>>>>>>>>> that the top level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>>> point where D calls H(D)
On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
H and H1 are identical except that D does >>>>>>>>>>>>>>>>>>>>>>>>>>>> not call H1.
This is idiotic and exposes you as someone >>>>>>>>>>>>>>>>>>>>>>>>>>> with the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed >>>>>>>>>>>>>>>>>>>>>>>>>> nitwit?
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>>>>>> equivalence of functions.
(The idea that two otherwise identical >>>>>>>>>>>>>>>>>>>>>>>>> functions with different names >>>>>>>>>>>>>>>>>>>>>>>>> are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere in >>>>>>>>>>>>>>>>>>>>>>>>> math.
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>>>>>>> being considered two different entities juwst >>>>>>>>>>>>>>>>>>>>>>> because
it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern >>>>>>>>>>>>>>>>>>>>>> Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>>>
After which both simulate the first instruction of H, >>>>>>>>>>>>>>>>>>> then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>>>>>> showed that continuing the aborted simulation results in >>>>>>>>>>>>>>> it reaching its final state, proving that the answer >>>>>>>>>>>>>>> provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid. >>>>>>>>>>>>>
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your >>>>>>>>> next post in this newsgroup will be taken as your official on- >>>>>>>>> the- record admission that Kaz's code correctly demonstrates >>>>>>>>> that the D simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show
where Kaz's code is wrong. Therefore, as per the above criteria: >>>>>>>
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H >>>>>>> will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under penalty >>>>> of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. And
as you yourself said:
When the conclusion is categorically impossible
Nope. The code proves it, but you're too scared to look at it.
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount
of pure bluster will get you out. Failing to provide the requested
steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your
above admission has been entered into the official record.
On 10/31/2025 7:08 AM, dbush wrote:
On 10/31/2025 7:55 AM, olcott wrote:
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that >>>>>>>>>>>> proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:In other words, you don't have the guts to look at his >>>>>>>>>>>>>> fully operational code that proves you wrong.
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>>>>> between both top- level simulations up to the point >>>>>>>>>>>>>>>>>> that the top level H aborts.
On 10/30/2025 10:14 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>> On 10/30/2025 7:13 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 5:49 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>>>> point where D calls H(D)On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
H and H1 are identical except that D does >>>>>>>>>>>>>>>>>>>>>>>>>>>>> not call H1.
This is idiotic and exposes you as someone >>>>>>>>>>>>>>>>>>>>>>>>>>>> with the mathematical
maturity of a toddler. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed >>>>>>>>>>>>>>>>>>>>>>>>>>> nitwit?
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>>>>>>> equivalence of functions.
(The idea that two otherwise identical >>>>>>>>>>>>>>>>>>>>>>>>>> functions with different names >>>>>>>>>>>>>>>>>>>>>>>>>> are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere >>>>>>>>>>>>>>>>>>>>>>>>>> in math.
Then show me how the fuck that this Linz case >>>>>>>>>>>>>>>>>>>>>>>>> works
without names dip shit!
I didn't say "without names", but "without an >>>>>>>>>>>>>>>>>>>>>>>> entity
being considered two different entities juwst >>>>>>>>>>>>>>>>>>>>>>>> because
it is referenced by two names". >>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern >>>>>>>>>>>>>>>>>>>>>>> Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>>>>
After which both simulate the first instruction of >>>>>>>>>>>>>>>>>>>> H, then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>>>>>>> showed that continuing the aborted simulation results in >>>>>>>>>>>>>>>> it reaching its final state, proving that the answer >>>>>>>>>>>>>>>> provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid. >>>>>>>>>>>>>>
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your >>>>>>>>>> next post in this newsgroup will be taken as your official on- >>>>>>>>>> the- record admission that Kaz's code correctly demonstrates >>>>>>>>>> that the D simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show >>>>>>>> where Kaz's code is wrong. Therefore, as per the above criteria: >>>>>>>>
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H >>>>>>>> will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under
penalty of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. And >>>> as you yourself said:
When the conclusion is categorically impossible
Nope. The code proves it, but you're too scared to look at it.
It won't stop you from being a Jackass if I look
at it and point out its mistake. You will simply
say that I am wrong about the mistake and still
be a Jackass.
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount
of pure bluster will get you out. Failing to provide the requested >>>> Â > steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your
above admission has been entered into the official record.
H can recognize a call to itself in
its input. The whole input is the
text of the function D. The executable
interpreters are named H.exe and H1.exe.
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
H and H1 are simulating termination
analyzers anchored in a C interpreter
that takes a finite string input
On 30/10/2025 14:49, olcott wrote:
H and H1 are simulating termination
analyzers anchored in a C interpreter
that takes a finite string input
How should we interpret "anchored" here? I feel it is crucial to
resolving a missing piece vis-a-vis that the symbol "H" is not defined
in the input text "D".
Should we take it that the program component that is a C interpreter
includes the C text that defines "H"?
--
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.
On 10/31/2025 8:30 AM, olcott wrote:
On 10/31/2025 7:08 AM, dbush wrote:
On 10/31/2025 7:55 AM, olcott wrote:
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that >>>>>>>>>>>>> proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:In other words, you don't have the guts to look at his >>>>>>>>>>>>>>> fully operational code that proves you wrong.
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>>>>>> between both top- level simulations up to the point >>>>>>>>>>>>>>>>>>> that the top level H aborts.
On 10/30/2025 10:14 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 7:13 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 5:49 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
*Mike never did get this and I know that he is >>>>>>>>>>>>>>>>>>>>>> honest*On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>> <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not call H1.
This is idiotic and exposes you as someone >>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the mathematical >>>>>>>>>>>>>>>>>>>>>>>>>>>>> maturity of a toddler. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed >>>>>>>>>>>>>>>>>>>>>>>>>>>> nitwit?
The diagonal test case does not depend on >>>>>>>>>>>>>>>>>>>>>>>>>>> name equivalence of functions. >>>>>>>>>>>>>>>>>>>>>>>>>>> (The idea that two otherwise identical >>>>>>>>>>>>>>>>>>>>>>>>>>> functions with different names >>>>>>>>>>>>>>>>>>>>>>>>>>> are different functions.) >>>>>>>>>>>>>>>>>>>>>>>>>>>
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere >>>>>>>>>>>>>>>>>>>>>>>>>>> in math.
Then show me how the fuck that this Linz case >>>>>>>>>>>>>>>>>>>>>>>>>> works
without names dip shit!
I didn't say "without names", but "without an >>>>>>>>>>>>>>>>>>>>>>>>> entity
being considered two different entities juwst >>>>>>>>>>>>>>>>>>>>>>>>> because
it is referenced by two names". >>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern >>>>>>>>>>>>>>>>>>>>>>>> Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D >>>>>>>>>>>>>>>>>>>>>>>> then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>>>>>
The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>>>>> point where D calls H(D)
After which both simulate the first instruction of >>>>>>>>>>>>>>>>>>>>> H, then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that >>>>>>>>>>>>>>>>> Kaz showed that continuing the aborted simulation >>>>>>>>>>>>>>>>> results in it reaching its final state, proving that >>>>>>>>>>>>>>>>> the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid. >>>>>>>>>>>>>>>
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of >>>>>>>>>>> your next post in this newsgroup will be taken as yourKaz's code is a break from reality
official on- the- record admission that Kaz's code correctly >>>>>>>>>>> demonstrates that the D simulated by H will reach a final state. >>>>>>>>>>
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show >>>>>>>>> where Kaz's code is wrong. Therefore, as per the above criteria: >>>>>>>>>
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by >>>>>>>>> H will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under
penalty of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. And >>>>> as you yourself said:
When the conclusion is categorically impossible
Nope. The code proves it, but you're too scared to look at it.
It won't stop you from being a Jackass if I look
at it and point out its mistake. You will simply
say that I am wrong about the mistake and still
be a Jackass.
If you correctly point out an actual mistake I'll be happy to say so,
and I'm sure Kaz would be happy to know if there's a mistake so he could
fix it.
Likewise, if what you point out is not an actual mistake, I'll say so
and explain why.
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount
of pure bluster will get you out. Failing to provide the requested >>>>> Â > steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your >>>>>>> above admission has been entered into the official record.
On 10/31/2025 7:33 AM, dbush wrote:
On 10/31/2025 8:30 AM, olcott wrote:
On 10/31/2025 7:08 AM, dbush wrote:
On 10/31/2025 7:55 AM, olcott wrote:
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that >>>>>>>>>>>>>> proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:In other words, you don't have the guts to look at his >>>>>>>>>>>>>>>> fully operational code that proves you wrong.
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>> On 10/30/2025 9:33 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 10:14 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 7:13 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 5:49 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>>>>>>> between both top- level simulations up to the point >>>>>>>>>>>>>>>>>>>> that the top level H aborts.*Mike never did get this and I know that he is >>>>>>>>>>>>>>>>>>>>>>> honest*On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not call H1.
This is idiotic and exposes you as someone >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with the mathematical >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maturity of a toddler. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed >>>>>>>>>>>>>>>>>>>>>>>>>>>>> nitwit?
The diagonal test case does not depend on >>>>>>>>>>>>>>>>>>>>>>>>>>>> name equivalence of functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>> (The idea that two otherwise identical >>>>>>>>>>>>>>>>>>>>>>>>>>>> functions with different names >>>>>>>>>>>>>>>>>>>>>>>>>>>> are different functions.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>
There is no such preposterious garbage in >>>>>>>>>>>>>>>>>>>>>>>>>>>> the theory of
recursive functions, or pretty much anywhere >>>>>>>>>>>>>>>>>>>>>>>>>>>> in math.
Then show me how the fuck that this Linz case >>>>>>>>>>>>>>>>>>>>>>>>>>> works
without names dip shit!
I didn't say "without names", but "without an >>>>>>>>>>>>>>>>>>>>>>>>>> entity
being considered two different entities juwst >>>>>>>>>>>>>>>>>>>>>>>>>> because
it is referenced by two names". >>>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
  int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>   if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>> until H sees this repeating pattern >>>>>>>>>>>>>>>>>>>>>>>>> Then H returns 0;
H1 simulates D
that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>> then H(D) returns 0 to caller D >>>>>>>>>>>>>>>>>>>>>>>>> then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>>>>>>
The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>>>>>> point where D calls H(D)
After which both simulate the first instruction of >>>>>>>>>>>>>>>>>>>>>> H, then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that >>>>>>>>>>>>>>>>>> Kaz showed that continuing the aborted simulation >>>>>>>>>>>>>>>>>> results in it reaching its final state, proving that >>>>>>>>>>>>>>>>>> the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid. >>>>>>>>>>>>>>>>
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of >>>>>>>>>>>> your next post in this newsgroup will be taken as your >>>>>>>>>>>> official on- the- record admission that Kaz's code correctly >>>>>>>>>>>> demonstrates that the D simulated by H will reach a final >>>>>>>>>>>> state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show >>>>>>>>>> where Kaz's code is wrong. Therefore, as per the above criteria: >>>>>>>>>>
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by >>>>>>>>>> H will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under
penalty of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't.
And as you yourself said:
When the conclusion is categorically impossible
Nope. The code proves it, but you're too scared to look at it.
It won't stop you from being a Jackass if I look
at it and point out its mistake. You will simply
say that I am wrong about the mistake and still
be a Jackass.
If you correctly point out an actual mistake I'll be happy to say so,
and I'm sure Kaz would be happy to know if there's a mistake so he
could fix it.
Likewise, if what you point out is not an actual mistake, I'll say so
and explain why.
No you won't you have conclusively proven to
only be a troll. No matter what I say you
will say that I am wrong.
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount >>>>>> Â > of pure bluster will get you out. Failing to provide the requested >>>>>> Â > steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your >>>>>>>> above admission has been entered into the official record.
On 10/31/2025 10:02 AM, olcott wrote:
On 10/31/2025 7:33 AM, dbush wrote:
On 10/31/2025 8:30 AM, olcott wrote:
On 10/31/2025 7:08 AM, dbush wrote:
On 10/31/2025 7:55 AM, olcott wrote:
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that >>>>>>>>>>>>>>> proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:In other words, you don't have the guts to look at his >>>>>>>>>>>>>>>>> fully operational code that proves you wrong. >>>>>>>>>>>>>>>>>
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 9:33 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 10:14 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 7:13 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 5:49 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
False. There is an exact one-to-one correspondence >>>>>>>>>>>>>>>>>>>>> between both top- level simulations up to the point >>>>>>>>>>>>>>>>>>>>> that the top level H aborts.*Mike never did get this and I know that he is >>>>>>>>>>>>>>>>>>>>>>>> honest*On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>> <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not call H1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>I didn't say "without names", but "without an >>>>>>>>>>>>>>>>>>>>>>>>>>> entity
This is idiotic and exposes you as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> someone with the mathematical >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maturity of a toddler. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nitwit?
The diagonal test case does not depend on >>>>>>>>>>>>>>>>>>>>>>>>>>>>> name equivalence of functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> (The idea that two otherwise identical >>>>>>>>>>>>>>>>>>>>>>>>>>>>> functions with different names >>>>>>>>>>>>>>>>>>>>>>>>>>>>> are different functions.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
There is no such preposterious garbage in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the theory of
recursive functions, or pretty much >>>>>>>>>>>>>>>>>>>>>>>>>>>>> anywhere in math.
Then show me how the fuck that this Linz >>>>>>>>>>>>>>>>>>>>>>>>>>>> case works
without names dip shit! >>>>>>>>>>>>>>>>>>>>>>>>>>>
being considered two different entities juwst >>>>>>>>>>>>>>>>>>>>>>>>>>> because
it is referenced by two names". >>>>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
  int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>   if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>> until H sees this repeating pattern >>>>>>>>>>>>>>>>>>>>>>>>>> Then H returns 0;
H1 simulates D
that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>> then H(D) returns 0 to caller D >>>>>>>>>>>>>>>>>>>>>>>>>> then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 >>>>>>>>>>>>>>>>>>>>>>>>> are exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>>>>>>>>>
The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>>>>>>> point where D calls H(D)
After which both simulate the first instruction >>>>>>>>>>>>>>>>>>>>>>> of H, then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>>>>>>
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that >>>>>>>>>>>>>>>>>>> Kaz showed that continuing the aborted simulation >>>>>>>>>>>>>>>>>>> results in it reaching its final state, proving that >>>>>>>>>>>>>>>>>>> the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid. >>>>>>>>>>>>>>>>>
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of >>>>>>>>>>>>> your next post in this newsgroup will be taken as your >>>>>>>>>>>>> official on- the- record admission that Kaz's code
correctly demonstrates that the D simulated by H will reach >>>>>>>>>>>>> a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show >>>>>>>>>>> where Kaz's code is wrong. Therefore, as per the above >>>>>>>>>>> criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated >>>>>>>>>>> by H will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under >>>>>>>>> penalty of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. >>>>>>> And as you yourself said:
When the conclusion is categorically impossible
Nope. The code proves it, but you're too scared to look at it.
It won't stop you from being a Jackass if I look
at it and point out its mistake. You will simply
say that I am wrong about the mistake and still
be a Jackass.
If you correctly point out an actual mistake I'll be happy to say so,
and I'm sure Kaz would be happy to know if there's a mistake so he
could fix it.
Likewise, if what you point out is not an actual mistake, I'll say so
and explain why.
No you won't you have conclusively proven to
only be a troll. No matter what I say you
will say that I am wrong.
It only appears that way because almost everything you say is in fact wrong. That you don't understand that is not my mistake.
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount >>>>>>> Â > of pure bluster will get you out. Failing to provide therequested
steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore your >>>>>>>>> above admission has been entered into the official record.
On 10/31/2025 9:15 AM, dbush wrote:
On 10/31/2025 10:02 AM, olcott wrote:
On 10/31/2025 7:33 AM, dbush wrote:
On 10/31/2025 8:30 AM, olcott wrote:
On 10/31/2025 7:08 AM, dbush wrote:
On 10/31/2025 7:55 AM, olcott wrote:
On 10/31/2025 6:22 AM, dbush wrote:
On 10/31/2025 12:06 AM, olcott wrote:
On 10/30/2025 11:00 PM, dbush wrote:
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that >>>>>>>>>>>>>>>> proves you wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:In other words, you don't have the guts to look at his >>>>>>>>>>>>>>>>>> fully operational code that proves you wrong. >>>>>>>>>>>>>>>>>>
On 10/30/2025 10:54 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>> On 10/30/2025 9:49 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 10:45 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 9:33 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 10:14 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 7:13 PM, dbush wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 5:49 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
That is not the point fuckhead.False. There is an exact one-to-one >>>>>>>>>>>>>>>>>>>>>> correspondence between both top- level simulations >>>>>>>>>>>>>>>>>>>>>> up to the point that the top level H aborts. >>>>>>>>>>>>>>>>>>>>>Nope. The simulations performed by H and H1 >>>>>>>>>>>>>>>>>>>>>>>>>> are exactly the same up to the point that H >>>>>>>>>>>>>>>>>>>>>>>>>> abortsOn 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not call H1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>I didn't say "without names", but "without >>>>>>>>>>>>>>>>>>>>>>>>>>>> an entity
The diagonal test case does not depend on >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> name equivalence of functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (The idea that two otherwise identical >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functions with different names >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are different functions.) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>This is idiotic and exposes you as >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> someone with the mathematical >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maturity of a toddler. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Function names are not significant in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the mathematics of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive functions. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constructed nitwit? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
There is no such preposterious garbage in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the theory of
recursive functions, or pretty much >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anywhere in math.
Then show me how the fuck that this Linz >>>>>>>>>>>>>>>>>>>>>>>>>>>>> case works
without names dip shit! >>>>>>>>>>>>>>>>>>>>>>>>>>>>
being considered two different entities >>>>>>>>>>>>>>>>>>>>>>>>>>>> juwst because
it is referenced by two names". >>>>>>>>>>>>>>>>>>>>>>>>>>>>
int D()
{
  int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>   if (Halt_Status)
    HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>   return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>> }
H simulates D
that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>>> that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>>> until H sees this repeating pattern >>>>>>>>>>>>>>>>>>>>>>>>>>> Then H returns 0;
H1 simulates D
that calls H(D) to simulate D >>>>>>>>>>>>>>>>>>>>>>>>>>> then H(D) returns 0 to caller D >>>>>>>>>>>>>>>>>>>>>>>>>>> then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF >>>>>>>>>>>>>>>>>>>>>>>>>>> INSTRUCTIONS DIP SHIT !!! >>>>>>>>>>>>>>>>>>>>>>>>>>
*Mike never did get this and I know that he is >>>>>>>>>>>>>>>>>>>>>>>>> honest*
The simulations are exactly the same up to the >>>>>>>>>>>>>>>>>>>>>>>>> point where D calls H(D)
After which both simulate the first instruction >>>>>>>>>>>>>>>>>>>>>>>> of H, then the second, etc.
So both the same up the point that H aborts. >>>>>>>>>>>>>>>>>>>>>>>>
Not at all.
That is exactly the point. It's also the point that >>>>>>>>>>>>>>>>>>>> Kaz showed that continuing the aborted simulation >>>>>>>>>>>>>>>>>>>> results in it reaching its final state, proving that >>>>>>>>>>>>>>>>>>>> the answer provided by H is wrong.
I can't imagine how Kaz can possibly be that stupid. >>>>>>>>>>>>>>>>>>
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of >>>>>>>>>>>>>> your next post in this newsgroup will be taken as your >>>>>>>>>>>>>> official on- the- record admission that Kaz's code >>>>>>>>>>>>>> correctly demonstrates that the D simulated by H will >>>>>>>>>>>>>> reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to >>>>>>>>>>>> show where Kaz's code is wrong. Therefore, as per the above >>>>>>>>>>>> criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated >>>>>>>>>>>> by H will reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under >>>>>>>>>> penalty of making the above admission.
That is not how reality works.
Nope. If I was wrong you could have shown how but you didn't. >>>>>>>> And as you yourself said:
When the conclusion is categorically impossible
Nope. The code proves it, but you're too scared to look at it.
It won't stop you from being a Jackass if I look
at it and point out its mistake. You will simply
say that I am wrong about the mistake and still
be a Jackass.
If you correctly point out an actual mistake I'll be happy to say
so, and I'm sure Kaz would be happy to know if there's a mistake so
he could fix it.
Likewise, if what you point out is not an actual mistake, I'll say
so and explain why.
No you won't you have conclusively proven to
only be a troll. No matter what I say you
will say that I am wrong.
It only appears that way because almost everything you say is in fact
wrong. That you don't understand that is not my mistake.
You may be condemning yourself to actual Hell
by your lies. Disbelieving this won't actually
help if such a place actually exists.
On 6/15/2024 1:39 PM, olcott wrote:
You are the one that is backed into a corner here and no amount >>>>>>>> Â > of pure bluster will get you out. Failing to provide therequested
steps *is construed as your admission that I am correct*
You chose not to show where Kaz's code is wrong, therefore >>>>>>>>>> your above admission has been entered into the official record. >>>>>>>>>
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
Imagine
H and H1 are simulating termination
analyzers anchored in a C interpreter
that takes a finite string input
H can recognize a call to itself in
its input. The whole input is the
text of the function D. The executable
interpreters are named H.exe and H1.exe.
On 10/30/25 10:49 AM, olcott wrote:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
I am switching this to a C interpreter.
Can you give even a smidgeon of evidence for anything you say?
*nothing*
I am switching this to a C interpreter.
On 10/31/2025 11:17 AM, Richard Damon wrote:
On 10/30/25 10:49 AM, olcott wrote:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
Unless you give this a fair review and not the usual
"I am wrong no matter what I say" I may never speak to
you again. This is the first time I spoke to you in
many months so you know that I mean it.
It turns out that this point is the key element
of the theory of computation that I have overturned.
Even the LLMs freaked out over this and just would
not believe me until after I proved it.
Unlike people LLMs are not so full of themselves
that they utterly will not face the actual facts.
The fact that
(a) Deciders only compute the mapping from the behavior
   that their input actually specifies
(b) A correct way to measure the behavior that their
   input actually specifies is D simulated by H
(c) Proves that H(D)==0 is correct and
(d) The requirement for H to report on anything else
   has always been a category error out-of-scope for
   Turing machine deciders since the beginning of the
   halting problem back in 1936.
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
between the behavior that the input specifies as different
than the behavior of the direct execution.
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
*Bottom line is this crucial verified fact*
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
H and H1 are both C interpreters named H.exe and H1.exe
respectively. When they see they see the name H or the name
H1 they know to calls themselves with the argument.
D.input_to_H
specifies different behavior than
D.input_to_H1.
How?
Same string, so same meaning?
H and H1 are both C interpreters named H.exe and H1.exe
respectively.
On 31/10/2025 16:17, Richard Damon wrote:
D.input_to_H
specifies different behavior than
D.input_to_H1.
How?
Same string, so same meaning?
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look closely.
--
Tristan Wibberley
On 30/10/2025 14:49, olcott wrote:
[snip]
H can recognize a call to itself in
its input. The whole input is the
text of the function D. The executable
interpreters are named H.exe and H1.exe.
Thank you for posting this. It is *super* interesting.
On 10/31/2025 7:48 AM, Tristan Wibberley wrote:
On 30/10/2025 14:49, olcott wrote:
H and H1 are simulating termination
analyzers anchored in a C interpreter
that takes a finite string input
How should we interpret "anchored" here? I feel it is crucial to
resolving a missing piece vis-a-vis that the symbol "H" is not defined
in the input text "D".
H and H1 are both C interpreters named H.exe and H1.exe
respectively. When they see they see the name H or the name
H1 they know to calls themselves with the argument.
D calls H(D) in recursive simulation.
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0 to reject its input as non-halting.
Should we take it that the program component that is a C interpreter
includes the C text that defines "H"?
H is like an operating system call. We only see
the execution trace of the input C textfile.
On 31/10/2025 13:58, olcott wrote:
H and H1 are both C interpreters named H.exe and H1.exe
respectively. When they see they see the name H or the name
H1 they know to calls themselves with the argument.
Are H.exe and H1.exe PECOFF executable files for Microsoft Windows?
If so, then there's some mixing up of terminology and concepts here.
Mixing "call" and "execute" as well as using C-call syntax to express execution of an interpreter, for example. Also you say "know to
calls[sic] themselves" and I think it should be "know to call each
other, as respectively named, " - perhaps that's not what you mean, in
which case the situation is very much less clear. Furthermore, further
review would also be too much effort for me even with clarifications.
--
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.
On 10/31/25 12:51 PM, olcott wrote:
On 10/31/2025 11:17 AM, Richard Damon wrote:
On 10/30/25 10:49 AM, olcott wrote:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
Unless you give this a fair review and not the usual
"I am wrong no matter what I say" I may never speak to
you again. This is the first time I spoke to you in
many months so you know that I mean it.
So, do you disagree that Semantic Properties are Objective Properties?
Your problem is you insist on redefining what words mean, which means everything you have done that you claim to be part of Computation Theory
is just a lie.
If you want to work with changed definitions, admit it, fully formally define what you mean and state the axiomatic basis for your new system,
and show what it can do.
Your problem here, is it seems you don't understand enough to do this,
so you are stuck just lying about what you are doing as you are too
ignorant (intentionally it seems) to know what things actually mean.
It turns out that this point is the key element
of the theory of computation that I have overturned.
How? By breaking the definition?
You can't overturn "Definitions" except by destroying semanitic meaning.
Even the LLMs freaked out over this and just would
not believe me until after I proved it.
LLM's don't "freak out". They don't think.
It seems this goes back to your fundamental lack of understand about
what "thinking" actually is about, perhaps because you can't really do
it well.
Unlike people LLMs are not so full of themselves
that they utterly will not face the actual facts.
LLMs are just deterministic machines. They are too complecated for us to reason about to determine what answer they will give, but are just
really fancy pattern matching machines. The have no ability to actually THINK, and prompts to try to force them to "think" tend to make them
produce hallucinations.
Note, their training, somewhat intentionally, trained them to be good
liars that could hide their lies, as training instructions for most of
them were to NOT base the grading on actual factual accuracy, but on how accurate the answer SEEMED to be. Did it fit with the plausable understanding of general culture.
They have no idea of what is "true", only what has been said.
The fact that
(a) Deciders only compute the mapping from the behavior
    that their input actually specifies
So? And what about the execution trace of a correct simulation of the
input isn't part of the input?
If the input doesn't contain the information to allow something (not necessarily the decider) to determine that results, the input is just incorect. The existance of actual UTMs means it *IS* possible to encode
any actual computation into an input.
The fact that YOUR input excludes some of the needed information, just
says what you consider your input is incorrect. The fact that you can
build a simulation based on both the direct and indirect information
passed, says there is enough indirect information to determine the
result, you just try to exclude it from what you want to call the "input".
This is all just evidence that you don't understand what you are talking about, and you argument is just full of category errors.
(b) A correct way to measure the behavior that their
    input actually specifies is D simulated by H
*NO* as that is a SUBJECTIVE property, and thus not something that is actually true.
All you are doing is trying to define that the truth of the execution of
a program isn't the truth.
(c) Proves that H(D)==0 is correct and
No it doesn't as you have just admitted that you weren't answering the actual question.
(d) The requirement for H to report on anything else
    has always been a category error out-of-scope for
    Turing machine deciders since the beginning of the
    halting problem back in 1936.
No, it isn't, and just shows your ignorance of the facts.
Part of the problem is your representation of the program "D" is
incorrect, as it needs to include *ALL* the code it uses, and thus the
code of the specific H that it calls.
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
between the behavior that the input specifies as different
than the behavior of the direct execution.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
Which is just a category error if that is all the input, as it isn't a complete program.
*Bottom line is this crucial verified fact*
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
No, your "crucial verifed fact" is just a LIE based on misdefining the terms, because you just refuse to learn the facts.
Kaz's code is a break from reality
and you know it you lying bass turd.
On 10/30/2025 11:49 PM, olcott wrote:
On 10/30/2025 10:28 PM, dbush wrote:
On 10/30/2025 11:25 PM, olcott wrote:
On 10/30/2025 10:19 PM, dbush wrote:
On 10/30/2025 11:15 PM, olcott wrote:
On 10/30/2025 10:04 PM, dbush wrote:Then show where the code is wrong.
On 10/30/2025 11:03 PM, olcott wrote:
On 10/30/2025 10:00 PM, dbush wrote:Agreement doesn't overrule fully operational code that proves you >>>>>>> wrong.
On 10/30/2025 10:59 PM, olcott wrote:
On 10/30/2025 9:56 PM, dbush wrote:
On 10/30/2025 10:54 PM, olcott wrote:
On 10/30/2025 9:49 PM, dbush wrote:
On 10/30/2025 10:45 PM, olcott wrote:
On 10/30/2025 9:33 PM, dbush wrote:False. There is an exact one-to-one correspondence between >>>>>>>>>>>>> both top- level simulations up to the point that the top >>>>>>>>>>>>> level H aborts.
On 10/30/2025 10:14 PM, olcott wrote:
On 10/30/2025 7:13 PM, dbush wrote:
On 10/30/2025 5:49 PM, olcott wrote:*Mike never did get this and I know that he is honest* >>>>>>>>>>>>>>>> The simulations are exactly the same up to the >>>>>>>>>>>>>>>> point where D calls H(D)
On 10/30/2025 4:15 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:42 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>> On 10/30/2025 3:11 PM, Kaz Kylheku wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-10-30, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> H and H1 are identical except that D does not >>>>>>>>>>>>>>>>>>>>>>>> call H1.
The diagonal test case does not depend on name >>>>>>>>>>>>>>>>>>>>> equivalence of functions.
This is idiotic and exposes you as someone with >>>>>>>>>>>>>>>>>>>>>>> the mathematical
maturity of a toddler.
Function names are not significant in the >>>>>>>>>>>>>>>>>>>>>>> mathematics of
recursive functions.
Sure they are nitwit otherwise how the fuck >>>>>>>>>>>>>>>>>>>>>> can to do-the-opposite case be constructed nitwit? >>>>>>>>>>>>>>>>>>>>>
(The idea that two otherwise identical functions >>>>>>>>>>>>>>>>>>>>> with different names
are different functions.)
There is no such preposterious garbage in the >>>>>>>>>>>>>>>>>>>>> theory of
recursive functions, or pretty much anywhere in math. >>>>>>>>>>>>>>>>>>>>>
Then show me how the fuck that this Linz case works >>>>>>>>>>>>>>>>>>>> without names dip shit!
I didn't say "without names", but "without an entity >>>>>>>>>>>>>>>>>>> being considered two different entities juwst because >>>>>>>>>>>>>>>>>>> it is referenced by two names".
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
THERE IS A DIFFERENT FUCKING SEQUENCE OF
INSTRUCTIONS DIP SHIT !!!
Nope. The simulations performed by H and H1 are >>>>>>>>>>>>>>>>> exactly the same up to the point that H aborts >>>>>>>>>>>>>>>>
After which both simulate the first instruction of H, >>>>>>>>>>>>>>> then the second, etc.
So both the same up the point that H aborts.
Not at all.
That is not the point fuckhead.
That is exactly the point. It's also the point that Kaz >>>>>>>>>>> showed that continuing the aborted simulation results in it >>>>>>>>>>> reaching its final state, proving that the answer provided by >>>>>>>>>>> H is wrong.
I can't imagine how Kaz can possibly be that stupid.
In other words, you don't have the guts to look at his fully >>>>>>>>> operational code that proves you wrong.
I proved that Ben agreed with me on this
point you damned liar.
So you are an atheist then. No one else would
risk such a bald-faced lie.
My code is correct pee (not pea) brain.
Failure to do so in your next reply or within one hour of your next >>>>> post in this newsgroup will be taken as your official on-the-record >>>>> admission that Kaz's code correctly demonstrates that the D
simulated by H will reach a final state.
Kaz's code is a break from reality
and you know it you lying bass turd.
Let the record show that Peter Olcott made no attempt to show where
Kaz's code is wrong. Therefore, as per the above criteria:
Let The Record Show
That Peter Olcott
Has *Officially* Admitted:
That Kaz's code correctly demonstrates that the D simulated by H will
reach a final state.
That might get you condemned to actual Hell
You were challenged to show where Kaz's code is wrong under penalty of making the above admission. You chose not to show where Kaz's code is wrong, therefore your above admission has been entered into the official record.
It won't stop you from being a Jackass if I look
at it and point out its mistake.
You will simply
say that I am wrong about the mistake and still
be a Jackass.
An algorithm recognizing the presence of itself in its input is an undecidable problem.
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
The key point is that the input needs to include the code of H to be
correct.
Note, H and H1 are SUPPOSED to be Halt Deciders. They might use a "C
On 10/31/2025 12:42 PM, Richard Damon wrote:
So, do you disagree that Semantic Properties are Objective Properties?
No, your "crucial verifed fact" is just a LIE based on misdefining the
terms, because you just refuse to learn the facts.
The exact and precise meaning of those terms proves
that I am correct. I didn't even glance at the rest
of what you said. *That was your last chance*
without sufficient conventional contextual distinction], which means[My] problem is you insist on [switching between meanings for words
everything you have done that you claim to be part of Computation
Theory is just a [troll].
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look closely.
What changed?
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look closely. >>What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Olcott?
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Olcott?
No, actually. Although I haven't thought my theory about dynamic closure through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
On 31/10/2025 18:45, olcott wrote:
On 10/31/2025 12:42 PM, Richard Damon wrote:
So, do you disagree that Semantic Properties are Objective Properties?
which gives some context to the below:
No, your "crucial verifed fact" is just a LIE based on misdefining the
terms, because you just refuse to learn the facts.
The exact and precise meaning of those terms proves
that I am correct. I didn't even glance at the rest
of what you said. *That was your last chance*
Because if their semantics were objective there would have been no
problem XD
But also, Mr. Damon would be correct in advising you if we adjust
"Your", "redefining what words mean" and "lie" to what I replaced them
with between [] below:
without sufficient conventional contextual distinction], which means[My] problem is you insist on [switching between meanings for words
everything you have done that you claim to be part of Computation
Theory is just a [troll].
I thank you both for your attention to this matter.
--
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.
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Olcott?
No, actually. Although I haven't thought my theory about dynamic closure through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
--
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.
On 10/31/2025 3:43 PM, Tristan Wibberley wrote:
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say "define" >>>> but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Olcott?
No, actually. Although I haven't thought my theory about dynamic closure
through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what
changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
D simulated by H calls H(D) to simulate itself
in recursive simulation. This simulated D cannot
possibly reach its own "return" statement.
D simulated by H1 does not call H1 at all
thus reaches its own "return" statement and halts.
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Olcott?
No, actually. Although I haven't thought my theory about dynamic closure through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
On 30/10/2025 14:49, olcott wrote:
[snip]
H can recognize a call to itself in
its input. The whole input is the
text of the function D. The executable
interpreters are named H.exe and H1.exe.
Thank you for posting this. It is *super* interesting.
An algorithm recognizing the presence of itself in its input is an undecidable problem.
Equivalence of algoirthms is undecidable; i.e. the function
equal_functions(f1, f2)
is incomputable.
Olcott's "x86utm" and "Halt7" code uses machine address equivalence as a substitute for function equivalence.
He has two functions HHH and HHH1 which are absolutely identical
except for their name.
Yet, they trigger a different behavior,
because the abort check in his simulation assumes that if two
code addresses are unequal, they are different functions.
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
H and H1 are both C interpreters named H.exe and H1.exe
respectively.
Give the URL or they don't exist, and we won't mention them again.
On 10/31/2025 12:49 PM, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
H and H1 are both C interpreters named H.exe and H1.exe
respectively.
Give the URL or they don't exist, and we won't mention them again.
I am in the process of writing them in the mean
time you could try to not be too stupid to
understand this:
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression
of itself is not.
On 10/31/2025 1:00 PM, Kaz Kylheku wrote:
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
On 30/10/2025 14:49, olcott wrote:
[snip]
H can recognize a call to itself in
its input. The whole input is the
text of the function D. The executable
interpreters are named H.exe and H1.exe.
Thank you for posting this. It is *super* interesting.
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
Equivalence of algoirthms is undecidable; i.e. the function
equal_functions(f1, f2)
is incomputable.
Olcott's "x86utm" and "Halt7" code uses machine address equivalence as a
substitute for function equivalence.
He has two functions HHH and HHH1 which are absolutely identical
except for their name.
void DDD() // a dumbed down version of D.
{
HHH(DDD);
return;
}
No dumb bunny DDD only calls one of them and this
changes everything.
Since I have told you this
hundreds of times you are far far worse than a
dumb bunny.
If it were not for the fact that I've been here for 30 years, I might
suspect you are the dumbest fuck ever to seriously participate in
a comp.* newsgroup.
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look closely. >>What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Worth thinking very deeply about. Very worth it.
On 10/31/2025 7:16 PM, Kaz Kylheku wrote:
If it were not for the fact that I've been here for 30 years, I might
suspect you are the dumbest fuck ever to seriously participate in
a comp.* newsgroup.
Really? I can't imagine worse...
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression
of itself is not.
--
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.
On 10/31/2025 1:00 PM, Kaz Kylheku wrote:
On 2025-10-31, Tristan Wibberley
<tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
On 30/10/2025 14:49, olcott wrote:
[snip]
H can recognize a call to itself in
its input. The whole input is the
text of the function D. The executable
interpreters are named H.exe and H1.exe.
Thank you for posting this. It is *super* interesting.
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
Equivalence of algoirthms is undecidable; i.e. the function
 equal_functions(f1, f2)
is incomputable.
Olcott's "x86utm" and "Halt7" code uses machine address equivalence as a
substitute for function equivalence.
He has two functions HHH and HHH1 which are absolutely identical
except for their name.
void DDD()Â Â // a dumbed down version of D.
{
 HHH(DDD);
 return;
}
No dumb bunny DDD only calls one of them and this
changes everything. Since I have told you this
hundreds of times you are far far worse than a
dumb bunny.
 Yet, they trigger a different behavior,
because the abort check in his simulation assumes that if two
code addresses are unequal, they are different functions.
On 10/31/2025 12:43 PM, Tristan Wibberley wrote:
On 31/10/2025 13:58, olcott wrote:
H and H1 are both C interpreters named H.exe and H1.exe
respectively. When they see they see the name H or the name
H1 they know to calls themselves with the argument.
Are H.exe and H1.exe PECOFF executable files for Microsoft Windows?
They don't physically exist just yet.
When they do they will run under Windows
and Linux command prompt.
If so, then there's some mixing up of terminology and concepts here.
Mixing "call" and "execute" as well as using C-call syntax to express
execution of an interpreter, for example. Also you say "know to
calls[sic] themselves" and I think it should be "know to call each
other, as respectively named, " - perhaps that's not what you mean, in
which case the situation is very much less clear. Furthermore, further
review would also be too much effort for me even with clarifications.
This is a whole different thing than I have been
talking about for several years. It will be a
C interpreter that takes C source code as input
and produces an execution trace in C as output.
I am adapting a C interpreter so that when it
sees H(D) it will interpret D with another
instance of itself.
I am trying to make this generic so that whenever
it sees H(anything) it will interpret "anything"
with another instance of itself. It will be as
much as possible just like my x86utm system except
at the C level because x86 is over everyone's heads.
If there is no call to itself then it will just
interpret the C input file. It will have both
an H and an H1.
--
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.
On 31/10/2025 18:06, Richard Damon wrote:
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
Really? even in K&R C?
The key point is that the input needs to include the code of H to be
correct.
Note, H and H1 are SUPPOSED to be Halt Deciders. They might use a "C
"are supposed" as in, somebody somewhere supposes it? That somebody is
you. I don't think I or Olcott suppose it.
I suppose it's a loop decider for ... some fixedpoint of something
involving the expression "specific class of loop". The class that is programmed in specifically because it's the class of loop that is easy
to decide.
--
Tristan Wibberley
On 10/31/2025 12:42 PM, Richard Damon wrote:
On 10/31/25 12:51 PM, olcott wrote:
On 10/31/2025 11:17 AM, Richard Damon wrote:
On 10/30/25 10:49 AM, olcott wrote:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who
they are being asked.
Unless you give this a fair review and not the usual
"I am wrong no matter what I say" I may never speak to
you again. This is the first time I spoke to you in
many months so you know that I mean it.
So, do you disagree that Semantic Properties are Objective Properties?
Your problem is you insist on redefining what words mean, which means
everything you have done that you claim to be part of Computation
Theory is just a lie.
If you want to work with changed definitions, admit it, fully formally
define what you mean and state the axiomatic basis for your new
system, and show what it can do.
Your problem here, is it seems you don't understand enough to do this,
so you are stuck just lying about what you are doing as you are too
ignorant (intentionally it seems) to know what things actually mean.
It turns out that this point is the key element
of the theory of computation that I have overturned.
How? By breaking the definition?
You can't overturn "Definitions" except by destroying semanitic meaning.
Even the LLMs freaked out over this and just would
not believe me until after I proved it.
LLM's don't "freak out". They don't think.
It seems this goes back to your fundamental lack of understand about
what "thinking" actually is about, perhaps because you can't really do
it well.
Unlike people LLMs are not so full of themselves
that they utterly will not face the actual facts.
LLMs are just deterministic machines. They are too complecated for us
to reason about to determine what answer they will give, but are just
really fancy pattern matching machines. The have no ability to
actually THINK, and prompts to try to force them to "think" tend to
make them produce hallucinations.
Note, their training, somewhat intentionally, trained them to be good
liars that could hide their lies, as training instructions for most of
them were to NOT base the grading on actual factual accuracy, but on
how accurate the answer SEEMED to be. Did it fit with the plausable
understanding of general culture.
They have no idea of what is "true", only what has been said.
The fact that
(a) Deciders only compute the mapping from the behavior
    that their input actually specifies
So? And what about the execution trace of a correct simulation of the
input isn't part of the input?
If the input doesn't contain the information to allow something (not
necessarily the decider) to determine that results, the input is just
incorect. The existance of actual UTMs means it *IS* possible to
encode any actual computation into an input.
The fact that YOUR input excludes some of the needed information, just
says what you consider your input is incorrect. The fact that you can
build a simulation based on both the direct and indirect information
passed, says there is enough indirect information to determine the
result, you just try to exclude it from what you want to call the
"input".
This is all just evidence that you don't understand what you are
talking about, and you argument is just full of category errors.
(b) A correct way to measure the behavior that their
    input actually specifies is D simulated by H
*NO* as that is a SUBJECTIVE property, and thus not something that is
actually true.
All you are doing is trying to define that the truth of the execution
of a program isn't the truth.
(c) Proves that H(D)==0 is correct and
No it doesn't as you have just admitted that you weren't answering the
actual question.
(d) The requirement for H to report on anything else
    has always been a category error out-of-scope for
    Turing machine deciders since the beginning of the
    halting problem back in 1936.
No, it isn't, and just shows your ignorance of the facts.
Part of the problem is your representation of the program "D" is
incorrect, as it needs to include *ALL* the code it uses, and thus the
code of the specific H that it calls.
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
between the behavior that the input specifies as different
than the behavior of the direct execution.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
Which is just a category error if that is all the input, as it isn't a
complete program.
*Bottom line is this crucial verified fact*
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
No, your "crucial verifed fact" is just a LIE based on misdefining the
terms, because you just refuse to learn the facts.
The exact and precise meaning of those terms proves
that I am correct. I didn't even glance at the rest
of what you said. *That was your last chance*
On 2025-10-31, dbush <dbush.mobile@gmail.com> wrote:
On 10/31/2025 7:16 PM, Kaz Kylheku wrote:
If it were not for the fact that I've been here for 30 years, I might
suspect you are the dumbest fuck ever to seriously participate in
a comp.* newsgroup.
Really? I can't imagine worse...
Oh, the names escape me now. Here are a few: Ioannis Vranos, G Moore,
Scott Nudds, "Aminer", E. Robert Tisdale, Rick C. Hodgin, "fir",
Bill Cunningham, Edward G. Nilges (spinoza1111), Bonita Montero,
CBfalconer, Alicia Carla Longstreet, ...
On 01/11/2025 01:05, Kaz Kylheku wrote:
On 2025-10-31, dbush <dbush.mobile@gmail.com> wrote:
On 10/31/2025 7:16 PM, Kaz Kylheku wrote:
If it were not for the fact that I've been here for 30 years, I might
suspect you are the dumbest fuck ever to seriously participate in
a comp.* newsgroup.
Really? I can't imagine worse...
Oh, the names escape me now. Here are a few: Ioannis Vranos, G Moore,
Scott Nudds, "Aminer", E. Robert Tisdale, Rick C. Hodgin, "fir",
Bill Cunningham, Edward G. Nilges (spinoza1111), Bonita Montero,
CBfalconer, Alicia Carla Longstreet, ...
ISTR that Ioannis Vranos (the mouse who thought he was a cat) eventually clued up?
You're being a tad harsh on Chuck F, too; no way was he as bad as Olcott.
But apart from those, the list looks pretty solid. Possibly add "bart"?
(The modern one, not the 1990s one.)
On 10/31/2025 3:10 PM, Tristan Wibberley wrote:
On 31/10/2025 18:45, olcott wrote:
On 10/31/2025 12:42 PM, Richard Damon wrote:
So, do you disagree that Semantic Properties are Objective Properties?
which gives some context to the below:
No, your "crucial verifed fact" is just a LIE based on misdefining the >>>> terms, because you just refuse to learn the facts.
The exact and precise meaning of those terms proves
that I am correct. I didn't even glance at the rest
of what you said. *That was your last chance*
Because if their semantics were objective there would have been no
problem XD
But also, Mr. Damon would be correct in advising you if we adjust
"Your", "redefining what words mean" and "lie" to what I replaced them
with between [] below:
These are the words where their conventional meaning
means exactly what I say. I spent many months carefully
crafting them.
*Bottom line is this crucial verified fact*
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
Mr. Damon *always* makes sure
to twist the meaning of the words that I say so that
he can do a strawman rebuttal. That is one of two reasons
that I have not spoken with him in six months and may
never speak to him again. He is also a very mean person.
without sufficient conventional contextual distinction], which means[My] problem is you insist on [switching between meanings for words
everything you have done that you claim to be part of Computation
Theory is just a [troll].
I thank you both for your attention to this matter.
--
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.
Nominal equivalence is not good enough if you're trying to prove
something about halting.
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look closely. >>What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Worth thinking very deeply about. Very worth it.
--
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.
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say "define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Olcott?
No, actually. Although I haven't thought my theory about dynamic closure through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
--
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.
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression
of itself is not.
But who says the copy has the same nominal expression?
And, WHICH of the expression of the decider are you comparing to?
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression
of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
And, WHICH of the expression of the decider are you comparing to?
The one and only one he gave in the input string "H". There's no other
to consider.
The situation statement describes one in which the input string
specifies calling H(D), and provides for a C interpreter in which the
call remains recognisable.
It does not provide for any generality in the decision that there's a
loop of more than 5 calls.
If there is a challenge for us, it is to notice that those are the facts
of this particular situation 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.
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression
of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
On 31/10/2025 18:06, Richard Damon wrote:
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
Really? even in K&R C?
On 31/10/2025 23:10, Kaz Kylheku wrote:
Nominal equivalence is not good enough if you're trying to prove
something about halting.
Suppose that's not what his situation statement for the current topic is
for? I do.
--
Tristan Wibberley
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression
of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
And, WHICH of the expression of the decider are you comparing to?
The one and only one he gave in the input string "H". There's no other
to consider.
The situation statement describes one in which the input string
specifies calling H(D), and provides for a C interpreter in which the
call remains recognisable.
It does not provide for any generality in the decision that there's a
loop of more than 5 calls.
If there is a challenge for us, it is to notice that those are the facts
of this particular situation statement.
--
Tristan Wibberley
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an
undecidable problem.
An algorithm recognizing the presence of a specific nominal expression >>>> of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
And, WHICH of the expression of the decider are you comparing to?
The one and only one he gave in the input string "H". There's no other
to consider.
The situation statement describes one in which the input string
specifies calling H(D), and provides for a C interpreter in which the
call remains recognisable.
It does not provide for any generality in the decision that there's a
loop of more than 5 calls.
If there is a challenge for us, it is to notice that those are the facts
of this particular situation statement.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an >>>>>> undecidable problem.
An algorithm recognizing the presence of a specific nominal expression >>>>> of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
And, WHICH of the expression of the decider are you comparing to?
The one and only one he gave in the input string "H". There's no other
to consider.
The situation statement describes one in which the input string
specifies calling H(D), and provides for a C interpreter in which the
call remains recognisable.
It does not provide for any generality in the decision that there's a
loop of more than 5 calls.
If there is a challenge for us, it is to notice that those are the facts >>> of this particular situation statement.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
On 10/31/2025 11:23 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an >>>>>>> undecidable problem.
An algorithm recognizing the presence of a specific nominal expression >>>>>> of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
And, WHICH of the expression of the decider are you comparing to?
The one and only one he gave in the input string "H". There's no other >>>> to consider.
The situation statement describes one in which the input string
specifies calling H(D), and provides for a C interpreter in which the
call remains recognisable.
It does not provide for any generality in the decision that there's a
loop of more than 5 calls.
If there is a challenge for us, it is to notice that those are the facts >>>> of this particular situation statement.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
That is the same as this one that has been dumbed down
You can't possible provide a correct execution trace
in C because you know that will prove you stupidly wrong.
H simulates D that calls H(D)
and according to your magic proof somehow
reaches its own simulated return instruction.
You cannot show the steps in C only because
you know that you are a liar.
On 10/31/2025 6:28 AM, Mikko wrote:
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
It turns out that my big discovery the overturns
part of the foundation of computer science is that
the semantic property can be relative to the decider.
It actually always relative to the decider yet this
has never made any difference with non-self-referential
inputs. H(D) != UTM(D) == H1(D)
The halting problem has always been an issue where
the halt decider has never been smart enough to
figure out halting for self-contradictory inputs.
That never has been the real issue.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
With a simulating halt decider D simulated by
H never reaches the contradictory part. It
stays stuck on its first line.
H and D do get stuck in recursive simulation. H
can and does see this. H does abort its own simulation
of D to prevent its own non-termination.
The real issue (that could not be seen until I created
the notion of a simulating halt decider in 2016) is
that the halting problem requires H to report on
behavior other than the behavior that its actual input
actually specifies.
int sum(int x, int y){ return x + y; }
this is the same as requiring sum(3,4) to report on
the sum of 5 + 6.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
On 10/31/2025 3:43 PM, Tristan Wibberley wrote:Because D calls H which doesn’t halt.
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look
closely.
What changed?
The dynamic closure they define for the evaluation of D. I say
"define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
No, actually. Although I haven't thought my theory about dynamicD simulated by H calls H(D) to simulate itself in recursive simulation.
closure through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what
changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
This simulated D cannot possibly reach its own "return" statement.
D simulated by H1 does not call H1 at all thus reaches its own "return" statement and halts.
On 10/31/2025 3:10 PM, Tristan Wibberley wrote:
On 10/31/2025 12:42 PM, Richard Damon wrote:
So, do you disagree that Semantic Properties are Objective
Properties?
Because if their semantics were objective there would have been no
problem XD
D simulated by H according to the semantics of C programming language
(until H sees the repeating pattern) does enable H to report that its simulated input cannot possibly reach its own simulated "return"
statement final halt state.
On 10/31/2025 11:17 AM, Richard Damon wrote:This would mean *every* simulator is correct at whatever it does, even
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
(b) A correct way to measure the behavior that their
input actually specifies is D simulated by H
Without my innovation of a simulating halt decider back in 2016 thereUtter nonsense. It was not an innovation, and every simulator would have
was no basis to see the difference between the behavior that the input specifies as different than the behavior of the direct execution.
Am Fri, 31 Oct 2025 16:06:03 -0500 schrieb olcott:
On 10/31/2025 3:43 PM, Tristan Wibberley wrote:
On 31/10/2025 20:26, Chris M. Thomasson wrote:
On 10/31/2025 1:16 PM, Tristan Wibberley wrote:
On 31/10/2025 17:57, Richard Damon wrote:
On 10/31/25 1:46 PM, Tristan Wibberley wrote:
"D.input_to_H" and "D.input_to_H1" are /different/ strings. Look >>>>>>> closely.
What changed?
The dynamic closure they define for the evaluation of D. I say
"define"
but, in fact it's a more complex situation vis-a-vis "D.input_to_H".
Because D calls H which doesn’t halt.No, actually. Although I haven't thought my theory about dynamicD simulated by H calls H(D) to simulate itself in recursive simulation.
closure through fully so maybe you'll decide I am.
Now that I think about it, maybe /you're/ your nemsis - you ask "what
changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
This simulated D cannot possibly reach its own "return" statement.
D simulated by H1 does not call H1 at all thus reaches its own "return"
statement and halts.
Am Fri, 31 Oct 2025 16:00:02 -0500 schrieb olcott:
On 10/31/2025 3:10 PM, Tristan Wibberley wrote:
On 10/31/2025 12:42 PM, Richard Damon wrote:
So, do you disagree that Semantic Properties are Objective
Properties?
Because if their semantics were objective there would have been no
problem XD
D simulated by H according to the semantics of C programming language
(until H sees the repeating pattern) does enable H to report that its
simulated input cannot possibly reach its own simulated "return"
statement final halt state.
It’s true that D hasn’t halted yet at the point where H aborts.
Am Fri, 31 Oct 2025 11:51:26 -0500 schrieb olcott:
On 10/31/2025 11:17 AM, Richard Damon wrote:
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
(b) A correct way to measure the behavior that theirThis would mean *every* simulator is correct at whatever it does, even
input actually specifies is D simulated by H
if it contradicted C semantics, just by virtue of doing anything at all.
Without my innovation of a simulating halt decider back in 2016 there
was no basis to see the difference between the behavior that the input
specifies as different than the behavior of the direct execution.
Utter nonsense. It was not an innovation, and every simulator would have
its own behaviour in your interpretation (only that the correct ones
all agree).
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 10/31/2025 11:23 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
On 01/11/2025 02:13, Richard Damon wrote:
On 10/31/25 3:46 PM, Tristan Wibberley wrote:
On 31/10/2025 18:00, Kaz Kylheku wrote:
An algorithm recognizing the presence of itself in its input is an >>>>>>>> undecidable problem.
An algorithm recognizing the presence of a specific nominal expression >>>>>>> of itself is not.
But who says the copy has the same nominal expression?
The author of the situation statement.
And, WHICH of the expression of the decider are you comparing to?
The one and only one he gave in the input string "H". There's no other >>>>> to consider.
The situation statement describes one in which the input string
specifies calling H(D), and provides for a C interpreter in which the >>>>> call remains recognisable.
It does not provide for any generality in the decision that there's a >>>>> loop of more than 5 calls.
If there is a challenge for us, it is to notice that those are the facts >>>>> of this particular situation statement.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
That is the same as this one that has been dumbed down
You can't possible provide a correct execution trace
in C because you know that will prove you stupidly wrong.
H simulates D that calls H(D)
and according to your magic proof somehow
reaches its own simulated return instruction.
You cannot show the steps in C only because
you know that you are a liar.
/I/ cannot show the steps in C only precisely because /you/ cannot show
the steps in C only.
On 11/1/2025 7:10 AM, joes wrote:
This would mean *every* simulator is correct at whatever it does, evenWhen D calls H(D) this makes this sequence of steps specified by the
if it contradicted C semantics, just by virtue of doing anything at
all.
input to H a different sequence of steps than the sequence of steps
specified by the input to H1(D). This cannot be ignored. It must be
accounted for.
Utter nonsense. It was not an innovation, and every simulator would
have its own behaviour in your interpretation (only that the correct
ones all agree).
On 2025-10-31 12:44:17 +0000, olcott said:
On 10/31/2025 6:28 AM, Mikko wrote:
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
It turns out that my big discovery the overturns
part of the foundation of computer science is that
the semantic property can be relative to the decider.
It actually always relative to the decider yet this
has never made any difference with non-self-referential
inputs. H(D) != UTM(D) == H1(D)
The halting problem has always been an issue where
the halt decider has never been smart enough to
figure out halting for self-contradictory inputs.
That never has been the real issue.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
With a simulating halt decider D simulated by
H never reaches the contradictory part. It
stays stuck on its first line.
H and D do get stuck in recursive simulation. H
can and does see this. H does abort its own simulation
of D to prevent its own non-termination.
The real issue (that could not be seen until I created
the notion of a simulating halt decider in 2016) is
that the halting problem requires H to report on
behavior other than the behavior that its actual input
actually specifies.
int sum(int x, int y){ return x + y; }
this is the same as requiring sum(3,4) to report on
the sum of 5 + 6.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
The above confirms that H and H1 give different results for the same
input. By the meanngs of the words H and H1 are not equivalent.
On 11/1/2025 6:55 AM, joes wrote:
Am Fri, 31 Oct 2025 16:06:03 -0500 schrieb olcott:
On 10/31/2025 3:43 PM, Tristan Wibberley wrote:
D calls H(D) making the simulated D and the simulated H both stuck in recursive simulation until the executed H sees this.Because D calls H which doesn’t halt.Now that I think about it, maybe /you're/ your nemsis - you ask "whatD simulated by H calls H(D) to simulate itself in recursive
changed?" regarding the difference between these two strings:
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
simulation.
This simulated D cannot possibly reach its own "return" statement.
D simulated by H1 does not call H1 at all thus reaches its own
"return"
statement and halts.
D simulated by H measures the semantic property of the actual input as opposed to and contrast with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
We can tell an input from a non-input because an input is an argument to
the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to simulate
D that calls H(D) to simulate D that calls H(D) to simulate D that calls
H(D) to simulate D until H sees this repeating pattern Then H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to
caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a C interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is the
text of the function D. The executable interpreters are named H.exe and H1.exe.
On 11/1/2025 7:10 AM, joes wrote:Proven false by the fact that the simulations performed by the top-level
Am Fri, 31 Oct 2025 11:51:26 -0500 schrieb olcott:
On 10/31/2025 11:17 AM, Richard Damon wrote:This would mean *every* simulator is correct at whatever it does, even
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they
are being asked.
(b) A correct way to measure the behavior that their
     input actually specifies is D simulated by H
if it contradicted C semantics, just by virtue of doing anything at all.
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D).
On 11/1/2025 3:42 AM, Mikko wrote:
On 2025-10-31 12:44:17 +0000, olcott said:
On 10/31/2025 6:28 AM, Mikko wrote:
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
It turns out that my big discovery the overturns
part of the foundation of computer science is that
the semantic property can be relative to the decider.
It actually always relative to the decider yet this
has never made any difference with non-self-referential
inputs. H(D) != UTM(D) == H1(D)
The halting problem has always been an issue where
the halt decider has never been smart enough to
figure out halting for self-contradictory inputs.
That never has been the real issue.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
With a simulating halt decider D simulated by
H never reaches the contradictory part. It
stays stuck on its first line.
H and D do get stuck in recursive simulation. H
can and does see this. H does abort its own simulation
of D to prevent its own non-termination.
The real issue (that could not be seen until I created
the notion of a simulating halt decider in 2016) is
that the halting problem requires H to report on
behavior other than the behavior that its actual input
actually specifies.
int sum(int x, int y){ return x + y; }
this is the same as requiring sum(3,4) to report on
the sum of 5 + 6.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
The above confirms that H and H1 give different results for the same
input. By the meanngs of the words H and H1 are not equivalent.
I never claimed that the were equivalent.
I claimed that HD)==0 and H1(D)==1 proving
that they are not equivalent.
The key thing here is that they are both reporting
on the actual sequence of steps that their actual
input actually specifies.
Anything more than this is outside of the scope
of deciders in general.
Am Sat, 01 Nov 2025 08:18:42 -0500 schrieb olcott:
On 11/1/2025 7:10 AM, joes wrote:
This would mean *every* simulator is correct at whatever it does, evenWhen D calls H(D) this makes this sequence of steps specified by the
if it contradicted C semantics, just by virtue of doing anything at
all.
input to H a different sequence of steps than the sequence of steps
specified by the input to H1(D). This cannot be ignored. It must be
accounted for.
Utter nonsense. It was not an innovation, and every simulator would
have its own behaviour in your interpretation (only that the correct
ones all agree).
As I said, the same applies to literally any simulator in existence.
H is not special in that regard.
Am Sat, 01 Nov 2025 08:12:39 -0500 schrieb olcott:
On 11/1/2025 6:55 AM, joes wrote:
Am Fri, 31 Oct 2025 16:06:03 -0500 schrieb olcott:
On 10/31/2025 3:43 PM, Tristan Wibberley wrote:
D calls H(D) making the simulated D and the simulated H both stuck inBecause D calls H which doesn’t halt.Now that I think about it, maybe /you're/ your nemsis - you ask "what >>>>> changed?" regarding the difference between these two strings:D simulated by H calls H(D) to simulate itself in recursive
"D.input_to_H"
"D.input_to_H1"
compare
strlen("D.input_to_H")
strlen("D.input_to_H1")
simulation.
This simulated D cannot possibly reach its own "return" statement.
D simulated by H1 does not call H1 at all thus reaches its own
"return"
statement and halts.
recursive simulation until the executed H sees this.
No, the simulated H is not stuck. It has the same code, meaning
it will abort after simulating two levels. Yes, that won’t be
simulated. Not simulating it doesn’t mean it runs forever.
On Thu, 30 Oct 2025 09:49:08 -0500, olcott wrote:
D simulated by H measures the semantic property of the actual input as
opposed to and contrast with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
We can tell an input from a non-input because an input is an argument to
the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to simulate
D that calls H(D) to simulate D that calls H(D) to simulate D that calls
H(D) to simulate D until H sees this repeating pattern Then H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to
caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a C
interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is the
text of the function D. The executable interpreters are named H.exe and
H1.exe.
D halts if H reports non-halting ergo H is wrong.
/Flibble
On 11/1/2025 8:44 AM, Mr Flibble wrote:
On Thu, 30 Oct 2025 09:49:08 -0500, olcott wrote:D simulated by H according to the semantics of C programming language
D simulated by H measures the semantic property of the actual input as
opposed to and contrast with the semantic property of a non-input. H
and H1 are identical except that D does not call H1.
We can tell an input from a non-input because an input is an argument
to the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to
simulate D that calls H(D) to simulate D that calls H(D) to simulate D
that calls H(D) to simulate D until H sees this repeating pattern Then
H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to
caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a C
interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is the
text of the function D. The executable interpreters are named H.exe
and H1.exe.
D halts if H reports non-halting ergo H is wrong.
/Flibble
(until H sees the repeating pattern) does enable H to report that its simulated input cannot possibly reach its own simulated "return"
statement final halt state.
*H is a correct termination analyzer for D*
/I/ cannot show the steps in C only precisely because /you/ cannot show
the steps in C only.
I did show the execution trace in C and then
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
On Sat, 01 Nov 2025 08:57:23 -0500, olcott wrote:
On 11/1/2025 8:44 AM, Mr Flibble wrote:
On Thu, 30 Oct 2025 09:49:08 -0500, olcott wrote:D simulated by H according to the semantics of C programming language
D simulated by H measures the semantic property of the actual input as >>>> opposed to and contrast with the semantic property of a non-input. H
and H1 are identical except that D does not call H1.
We can tell an input from a non-input because an input is an argument
to the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to
simulate D that calls H(D) to simulate D that calls H(D) to simulate D >>>> that calls H(D) to simulate D until H sees this repeating pattern Then >>>> H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to
caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a C
interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is the
text of the function D. The executable interpreters are named H.exe
and H1.exe.
D halts if H reports non-halting ergo H is wrong.
/Flibble
(until H sees the repeating pattern) does enable H to report that its
simulated input cannot possibly reach its own simulated "return"
statement final halt state.
*H is a correct termination analyzer for D*
D halts if H reports non-halting ergo H is wrong.
/Flibble
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
Insipid liar, you did not invent a fucking thing.
In a 1972 issue (September, Volume 4) of a journal calledf _Computing Surveys_, Tony Hoare and D. C. S. Allison explore the topic of halting.
They make use of a function Interpret, which simulates code.
Quote:
Let us specify a Boolean function "interpret" which takes as arguments
two items of data, z and y. If z is the representation of some Boolean
function f, interpret (z, y) delivers the same Boolean value as f(y);
otherwise it gives the value false. Further more, if f (y) does not
terminate, then neither does interpret (R(f), y)."
You clearly do not have a good overview of prior academic work
in this area which allows you to delude yourself that you have
original ideas.
On 11/1/2025 12:10 PM, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:It is more technically a simulating termination analyzer applied to the halting problem counter-example input.
Without my innovation of a simulating halt decider back in 2016 there
was no basis to see the difference
Insipid liar, you did not invent a fucking thing.
Every other case that I am aware of rejected this out-of-hand without
review.
In a 1972 issue (September, Volume 4) of a journal calledf _Computingint D()
Surveys_, Tony Hoare and D. C. S. Allison explore the topic of halting.
They make use of a function Interpret, which simulates code.
Quote:
Let us specify a Boolean function "interpret" which takes as
arguments two items of data, z and y. If z is the representation of
some Boolean function f, interpret (z, y) delivers the same Boolean
value as f(y); otherwise it gives the value false. Further more, if
f (y) does not terminate, then neither does interpret (R(f), y)."
You clearly do not have a good overview of prior academic work in this
area which allows you to delude yourself that you have original ideas.
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C programming language
(until H sees the repeating pattern) does enable H to report that its simulated input cannot possibly reach its own simulated "return"
statement final halt state.
*H is a correct termination analyzer for D*
Refutes that work.
On 11/1/2025 11:07 AM, Mr Flibble wrote:
On Sat, 01 Nov 2025 08:57:23 -0500, olcott wrote:I say that 5 > 3 and your rebuttal is that no I am wrong 3 is not
On 11/1/2025 8:44 AM, Mr Flibble wrote:
On Thu, 30 Oct 2025 09:49:08 -0500, olcott wrote:D simulated by H according to the semantics of C programming language
D simulated by H measures the semantic property of the actual input
as opposed to and contrast with the semantic property of a
non-input. H and H1 are identical except that D does not call H1.
We can tell an input from a non-input because an input is an
argument to the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to
simulate D that calls H(D) to simulate D that calls H(D) to simulate >>>>> D that calls H(D) to simulate D until H sees this repeating pattern
Then H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to
caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a
C interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is
the text of the function D. The executable interpreters are named
H.exe and H1.exe.
D halts if H reports non-halting ergo H is wrong.
/Flibble
(until H sees the repeating pattern) does enable H to report that its
simulated input cannot possibly reach its own simulated "return"
statement final halt state.
*H is a correct termination analyzer for D*
D halts if H reports non-halting ergo H is wrong.
/Flibble
greater than 7.
D simulated by H not any other damn thing D simulated by H not any other
damn thing D simulated by H not any other damn thing D simulated by H
not any other damn thing D simulated by H not any other damn thing
On Sat, 01 Nov 2025 12:15:15 -0500, olcott wrote:
On 11/1/2025 12:10 PM, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:It is more technically a simulating termination analyzer applied to the
Without my innovation of a simulating halt decider back in 2016 there
was no basis to see the difference
Insipid liar, you did not invent a fucking thing.
halting problem counter-example input.
Every other case that I am aware of rejected this out-of-hand without
review.
In a 1972 issue (September, Volume 4) of a journal calledf _Computingint D()
Surveys_, Tony Hoare and D. C. S. Allison explore the topic of halting.
They make use of a function Interpret, which simulates code.
Quote:
Let us specify a Boolean function "interpret" which takes as
arguments two items of data, z and y. If z is the representation of
some Boolean function f, interpret (z, y) delivers the same Boolean
value as f(y); otherwise it gives the value false. Further more, if
f (y) does not terminate, then neither does interpret (R(f), y)."
You clearly do not have a good overview of prior academic work in this
area which allows you to delude yourself that you have original ideas.
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
D simulated by H according to the semantics of C programming language
(until H sees the repeating pattern) does enable H to report that its
simulated input cannot possibly reach its own simulated "return"
statement final halt state.
*H is a correct termination analyzer for D*
Refutes that work.
If H reports non-halting then D halts ergo H is wrong.
/Flibble
On Sat, 01 Nov 2025 12:07:07 -0500, olcott wrote:
On 11/1/2025 11:07 AM, Mr Flibble wrote:
On Sat, 01 Nov 2025 08:57:23 -0500, olcott wrote:I say that 5 > 3 and your rebuttal is that no I am wrong 3 is not
On 11/1/2025 8:44 AM, Mr Flibble wrote:
On Thu, 30 Oct 2025 09:49:08 -0500, olcott wrote:D simulated by H according to the semantics of C programming language
D simulated by H measures the semantic property of the actual input >>>>>> as opposed to and contrast with the semantic property of a
non-input. H and H1 are identical except that D does not call H1.
We can tell an input from a non-input because an input is an
argument to the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to
simulate D that calls H(D) to simulate D that calls H(D) to simulate >>>>>> D that calls H(D) to simulate D until H sees this repeating pattern >>>>>> Then H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to >>>>>> caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a >>>>>> C interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is
the text of the function D. The executable interpreters are named
H.exe and H1.exe.
D halts if H reports non-halting ergo H is wrong.
/Flibble
(until H sees the repeating pattern) does enable H to report that its
simulated input cannot possibly reach its own simulated "return"
statement final halt state.
*H is a correct termination analyzer for D*
D halts if H reports non-halting ergo H is wrong.
/Flibble
greater than 7.
D simulated by H not any other damn thing D simulated by H not any other
damn thing D simulated by H not any other damn thing D simulated by H
not any other damn thing D simulated by H not any other damn thing
If H reports non-halting than D halts ego H is wrong.
/Flibble
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot show
the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
I can write a C interpreter which can interpret itself.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
(If the steps of the simulated D are different,
then it cannot be the case that both H and H1
are correctly simulating.)
The D steps under H though are left incomplete.
That is not a big problem; the simulation state
exists and can be continued to show that the
steps of that D match the one under H1.
Glossary:
H - Aborting decider which returns 0 for H(D)
H1 - Simulator, H1(D) is same as UTM(D)
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
Insipid liar, you did not invent a fucking thing.
In a 1972 issue (September, Volume 4) of a journal calledf _Computing Surveys_, Tony Hoare and D. C. S. Allison explore the topic of halting.
You clearly do not have a good overview of prior academic work
... NOTHING he talks about is actualy about
halting, as he just ignores the definitons needed to talk about halting.
He wants someone to say something that he can misuse to try to support
his theory to claim it is actually about halting, when it never was.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the facts >>> of this particular situation statement.
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the facts >>>> of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation straightforward.
--
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.
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the
facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
Kaz continues to reference something much more
complex so that he can get away with his "proof"
that D simulated by H reaches its own simulated
"return" statement.
On 11/1/2025 2:38 PM, olcott wrote:
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the >>>>>> facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation statement >>> with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
In other words, as everyone can tell, you're trying to deflect away from your code which is proven wrong by Kaz's code.
I can write a C interpreter which can interpret itself.
On 11/1/2025 1:45 PM, dbush wrote:Everyone knows you're doing this because you can't prove his code wrong.
On 11/1/2025 2:38 PM, olcott wrote:
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are
the facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation
statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
In other words, as everyone can tell, you're trying to deflect away
from your code which is proven wrong by Kaz's code.
<deflection>
On 11/1/2025 3:01 PM, olcott wrote:
On 11/1/2025 1:45 PM, dbush wrote:Everyone knows you're doing this because you can't prove his code wrong.
On 11/1/2025 2:38 PM, olcott wrote:
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are >>>>>>>> the facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation
statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
In other words, as everyone can tell, you're trying to deflect away
from your code which is proven wrong by Kaz's code.
<deflection>
On 11/1/2025 12:26 PM, Mr Flibble wrote:
On Sat, 01 Nov 2025 12:07:07 -0500, olcott wrote:
On 11/1/2025 11:07 AM, Mr Flibble wrote:
On Sat, 01 Nov 2025 08:57:23 -0500, olcott wrote:I say that 5 > 3 and your rebuttal is that no I am wrong 3 is not
On 11/1/2025 8:44 AM, Mr Flibble wrote:
On Thu, 30 Oct 2025 09:49:08 -0500, olcott wrote:D simulated by H according to the semantics of C programming language >>>>> (until H sees the repeating pattern) does enable H to report that its >>>>> simulated input cannot possibly reach its own simulated "return"
D simulated by H measures the semantic property of the actual input >>>>>>> as opposed to and contrast with the semantic property of a
non-input. H and H1 are identical except that D does not call H1. >>>>>>>
We can tell an input from a non-input because an input is an
argument to the function H.
D.input_to_H specifies different behavior than D.input_to_H1.
int D()
{
     int Halt_Status = H(D);
     if (Halt_Status)
       HERE: goto HERE;
     return Halt_Status;
}
H simulates D that calls H(D) to simulate D that calls H(D) to
simulate D that calls H(D) to simulate D that calls H(D) to simulate >>>>>>> D that calls H(D) to simulate D until H sees this repeating pattern >>>>>>> Then H returns 0;
H1 simulates D that calls H(D) to simulate D then H(D) returns 0 to >>>>>>> caller D then H1 returns 1;
Imagine H and H1 are simulating termination analyzers anchored in a >>>>>>> C interpreter that takes a finite string input
H can recognize a call to itself in its input. The whole input is >>>>>>> the text of the function D. The executable interpreters are named >>>>>>> H.exe and H1.exe.
D halts if H reports non-halting ergo H is wrong.
/Flibble
statement final halt state.
*H is a correct termination analyzer for D*
D halts if H reports non-halting ergo H is wrong.
/Flibble
greater than 7.
D simulated by H not any other damn thing D simulated by H not any other >>> damn thing D simulated by H not any other damn thing D simulated by H
not any other damn thing D simulated by H not any other damn thing
If H reports non-halting than D halts ego H is wrong.
/Flibble
Do you want to get *plonked*Â Chris is already
*plonked* All of his messages have been erased
and I won't ever see any new ones.
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the
facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
On 01/11/2025 04:14, Richard Damon wrote:
... NOTHING he talks about is actualy about
halting, as he just ignores the definitons needed to talk about halting.
It doesn't have to be about halting, it's comp.theory not halt.theory.
He wants someone to say something that he can misuse to try to support
his theory to claim it is actually about halting, when it never was.
Suppose for a moment, if you can bring yourself to do so, that he's
normal; then he will have multiple topics of research at once: they and
their number will vary over time.
... The input to both H(D) and H1(D), i.e. finite string D, is the description of machine D and therefore is stipulated to specify all
semantic properties of machine D, including the fact that machine D
halts when executed directly.
Suppose for a moment, if you can bring yourself to do so, that he's
normal; then he will have multiple topics of research at once: they and
their number will vary over time.
Are you sure your not Olcott? Humm...
On 01/11/2025 13:51, dbush wrote:
... The input to both H(D) and H1(D), i.e. finite string D, is the
description of machine D and therefore is stipulated to specify all
semantic properties of machine D, including the fact that machine D
halts when executed directly.
Is D a machine?
I think H(D) might be, except that it's an imperative program for the prevailing publicly discussed type of system in the last few decades so
H and H1 will provide a closure to it somehow.
That closure can be different because of the different levels of
simulation (do we call it "levels of inception" now because of the
movie) because H1 and H themselves both need closure, one of which is provided by the physical machine and one by the simulation.
--
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.
...On 2025-11-01, olcott <polcott333@gmail.com> wrote a new situation statement
[... new situation statement snipped ...]
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
Kaz continues to reference something much more
complex
I am only referring to the C code right here...
int D()... [snip] ...> *H is a correct termination analyzer for D*
On 01/11/2025 18:38, olcott wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote a new situation statement
[... new situation statement snipped ...]
I changed it to D and H with a single argument...
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
Kaz continues to reference something much more
complex
I am only referring to the C code right here...
int D()... [snip] ...> *H is a correct termination analyzer for D*
That looks to me like a different situation statement than the one that started the current topic/thread.
[news:///10dvtt6$3oelt$1@dont-email.me]
I think it is the conventional meaning of "am" in usenet posts to refer
to a broad time interval with fuzzy edges.
Some references to specific posts will help, and all participants
noticing the very very big ambiguity in "am" due to different
perspectives of the participants given the forum.
--
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.
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
*That you liked about this does not make your lie true*
On 10/31/25 3:57 PM, Tristan Wibberley wrote:
On 31/10/2025 18:06, Richard Damon wrote:
[H and H1] fail to be correct C
interpreters, as the code has a required diagnostic.
Really? even in K&R C?
Yep, the link step will fail as H and H1 are not defined.
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
On 10/31/2025 12:49 PM, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
H and H1 are both C interpreters named H.exe and H1.exe
respectively.
Give the URL or they don't exist, and we won't mention them again.
I am in the process of writing them in the mean
You are in the process of /saying/ you are writing them, that's all.
I suspect you've not even done the googling regarding whose
C interpreter you are going to use.
Because you need a tower of interpreters, the interpreter will have to
be complete and reliable enough to interpret its own code.
time you could try to not be too stupid to
understand this:
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
You simply don't know your ass from a hole in the ground at this point.
I can write a C interpreter which can interpret itself.
On 01/11/2025 17:10, Kaz Kylheku wrote:
On 2025-10-31, olcott <polcott333@gmail.com> wrote:
Without my innovation of a simulating halt decider
back in 2016 there was no basis to see the difference
Insipid liar, you did not invent a fucking thing.
In a 1972 issue (September, Volume 4) of a journal calledf _Computing
Surveys_, Tony Hoare and D. C. S. Allison explore the topic of halting.
Yup. We already told him about this.
On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
I think H(D) might be [a machine], except that it's an imperative program for the
prevailing publicly discussed type of system in the last few decades so
H and H1 will provide a closure to it somehow.
Its C code that can be construed as a virtual machine.
On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
On 01/11/2025 13:51, dbush wrote:
... The input to both H(D) and H1(D), i.e. finite string D, is the
description of machine D and therefore is stipulated to specify all
semantic properties of machine D, including the fact that machine D
halts when executed directly.
Is D a machine?
I have been saying that D is this C code for weeks now.
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
I think H(D) might be, except that it's an imperative program for the
prevailing publicly discussed type of system in the last few decades so
H and H1 will provide a closure to it somehow.
Its C code that can be construed as a virtual machine.
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot show >>>> the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
On 01/11/2025 19:53, Chris M. Thomasson wrote:
Suppose for a moment, if you can bring yourself to do so, that he's
normal; then he will have multiple topics of research at once: they and
their number will vary over time.
Are you sure your not Olcott? Humm...
A decider CMT accepts usenet posts as input and reports "No TW is not Olcott."
On 01/11/2025 20:18, olcott wrote:
On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
I think H(D) might be [a machine], except that it's an imperative program for the
prevailing publicly discussed type of system in the last few decades so
H and H1 will provide a closure to it somehow.
Its C code that can be construed as a virtual machine.
Welll... not really, the machine provides the closures that D requires.
I think it might normally be said to be in this case, perhaps, a conditionally fault-injecting C-machine emulator.
Outside of your quotes I discuss the ultimate closure from a real
machine required to make the virtual machines.
--
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.
On 11/1/2025 3:53 PM, Tristan Wibberley wrote:
On 01/11/2025 20:18, olcott wrote:I have no idea what you are saying.
On 11/1/2025 3:12 PM, Tristan Wibberley wrote:
I think H(D) might be [a machine], except that it's an imperativeIts C code that can be construed as a virtual machine.
program for the prevailing publicly discussed type of system in the
last few decades so H and H1 will provide a closure to it somehow.
Welll... not really, the machine provides the closures that D requires.
I think it might normally be said to be in this case, perhaps, a
conditionally fault-injecting C-machine emulator.
Outside of your quotes I discuss the ultimate closure from a real
machine required to make the virtual machines.
The C programming language does seem to define a virtual machine that C interpreters implement.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
I am only concerned with D simulated by H showing the execution trace in
C.
I haven't gotten a straight answer to that simple question from anyone
here in three years of daily posts.
--
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.
Thanks for responding. My initial estimate
is that you are very competent.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot show >>>>> the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
We need an impementation of H to show the detailed trace.
Let's assume that we have primitives built into the
framework for managing simulations: interp_create,
interp_step.
Let's start with a non-aborting H:
On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot >>>>>> show
the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
int D()
{
   int Halt_Status = H(D);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
H simulates D then D calls H(D) then what?
We need an impementation of H to show the detailed trace.
Let's assume that we have primitives built into the
framework for managing simulations: interp_create,
interp_step.
Let's start with a non-aborting H:
Just the C and nothing else.
int D()
{
 int Halt_Status = H(D);
 if (Halt_Status)
   HERE: goto HERE;
 return Halt_Status;
}
H simulates D then D calls H(D) then what?
I know that you are trying to make it as
confusing as possible. I will not tolerate that.
.. [stuff I think is about the invalidity of not completing execution] isn't a valid definition ...
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
D, however, is a procedure which reaches its return statement.
H proclaims that it is not necessary to simulate D further
because D does not terminate.
That is mistaken; D terminates.
On 10/31/25 4:43 PM, Tristan Wibberley wrote:
"D.input_to_H"
"D.input_to_H1"
But those are not the string in question, just the meta-description of
them.
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
Pretending that an entity is two entities when referenced by two
different names isn't thinking.
D is DEFINED by the problem to be a complete program, and thus doesn't
need a closure.
On 01/11/2025 00:38, Kaz Kylheku wrote:
On 2025-10-31, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
Pretending that an entity is two entities when referenced by two
different names isn't thinking.
But it /is/ knowledge gathering. I hope I spotted some terminology used
in compsci that resolves that issue (closure, and dynamic closure).
--
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.
On 01/11/2025 02:49, Richard Damon wrote:
D is DEFINED by the problem to be a complete program, and thus doesn't
need a closure.
I checked the situation statement. I can't see how D is so defined,
neither by definition nor by any obvious inference, it seems to be
pretty clear its a C "function".
--
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.
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the facts >>>>> of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
Kaz continues to reference something much more
complex so that he can get away with his "proof"
that D simulated by H reaches its own simulated
"return" statement.
I am only referring to the C code right here
and Kaz keeps switching it to something else
to be deliberately misleading.
On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot show >>>>>> the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
We need an impementation of H to show the detailed trace.
Let's assume that we have primitives built into the
framework for managing simulations: interp_create,
interp_step.
Let's start with a non-aborting H:
Just the C and nothing else.
I know that you are trying to make it as
confusing as possible. I will not tolerate that.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:int D()
On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot show >>>>>>> the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
We need an impementation of H to show the detailed trace.
Let's assume that we have primitives built into the
framework for managing simulations: interp_create,
interp_step.
Let's start with a non-aborting H:
Just the C and nothing else.
I have no idea what you are asking for;
On 11/1/2025 1:45 PM, dbush wrote:
On 11/1/2025 2:38 PM, olcott wrote:
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are the >>>>>>> facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual
situation statement.
Quite why he replied to a discussion about his other situation statement >>>> with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
In other words, as everyone can tell, you're trying to deflect away from
your code which is proven wrong by Kaz's code.
If that was true then Kaz could perform his
same "proof" on this much simpler essence
of D simulated by H showing the trace in C.
He could show the mental trace in C showing
how D simulated by H reaches its own simulated
"return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
He does not show this trace in C because he knows
that this proves that he is wrong.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
Exactly how does D simulated by H reach
its own simulated "return" statement?
*Here is my claim*
D simulated by H according to the semantics of C
programming language (until H sees the repeating
pattern) does enable H to report that its simulated
input cannot possibly reach its own simulated
"return" statement final halt state.
*H is a correct termination analyzer for D*
I spoke with Richard for several years.^^^^
I gave up when I figured out that he is
only a troll.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
To trace D, we need a definition of H.
On 01/11/2025 22:19, Kaz Kylheku wrote:
To trace D, we need a definition of H.
The situation statement is a constraint on H, it almost defines a puzzle which may have solutions in H. Given the phrasing and the newsgroup I
think that's what Olcott was going for.
That is /you/ the /puzzled/ provides the H!
Or /I/ the /aloof/ provides generally superior criticism.
--
Tristan Wibberley
I can write a C interpreter which can interpret itself.
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.
Everyone knows you're doing this because you can't prove his code wrong.
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
When I insist that Kaz do this in C he
knows everyone here can spot his lie.
On 11/1/2025 9:18 AM, olcott wrote:
On 11/1/2025 7:10 AM, joes wrote:Proven false by the fact that the simulations performed by the top-level
Am Fri, 31 Oct 2025 11:51:26 -0500 schrieb olcott:
On 10/31/2025 11:17 AM, Richard Damon wrote:This would mean *every* simulator is correct at whatever it does, even
No, it doesn't.
Semantic Properties are OBJECTIVE, and thus do not depend on who they >>>>> are being asked.
(b) A correct way to measure the behavior that their
     input actually specifies is D simulated by H
if it contradicted C semantics, just by virtue of doing anything at all. >>>
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D).
H and the top-level H1 are exactly the same up to the point that H
aborts, and Kaz's code proves that if the simulation performed by H is continued that it will reach a finite state.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong. >>>
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
On 01/11/2025 22:19, Kaz Kylheku wrote:
To trace D, we need a definition of H.
The situation statement is a constraint on H, it almost defines a puzzle which may have solutions in H. Given the phrasing and the newsgroup I
think that's what Olcott was going for.
That is /you/ the /puzzled/ provides the H!
On 2025-11-01, Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> wrote:
On 01/11/2025 22:19, Kaz Kylheku wrote:
To trace D, we need a definition of H.
The situation statement is a constraint on H, it almost defines a puzzle
which may have solutions in H. Given the phrasing and the newsgroup I
think that's what Olcott was going for.
That is /you/ the /puzzled/ provides the H!
Coming up with the tracing H which aborts its simulation is
Olcott's job.
He did that with the "x86utm", and that has been shot down.
He's now saying that working with C and x86 is too complicated; I (or someone) must implement all his work using a pure C interpreter and then
show the same result.
While he does nothing.
Imagine you wrote a C program, and people found bugs in it, exposed
by some small amount of testing/exploratory code which uses that
program's internal interfaces.
And you then claimed that C is too hard to understand;
I can write a C interpreter which can interpret itself.
you don't believe
the report, and your program must be correct, until the entire scenario
and concept is worked in Python --- and that bbeing the burden of the
bug reporters.
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
D simulated by H cannot possibly reach its simulated
"return" statement as I have said hundreds and hundreds
of times in the last six months and every time damned
liars change my words as their rebuttal.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape measure.
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong. >>>>
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
On 11/1/2025 5:11 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:int D()
On 11/1/2025 3:59 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:54 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
/I/ cannot show the steps in C only precisely because /you/ cannot show
the steps in C only.
I did show the execution trace in C and then
You positively did not; you showed something you wrote by hand.
Anyone with these credentials could certainly show the
execution trace in C of the steps of how D simulated
by H reaches its own simulated "return" statement.
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) then what?
We need an impementation of H to show the detailed trace.
Let's assume that we have primitives built into the
framework for managing simulations: interp_create,
interp_step.
Let's start with a non-aborting H:
Just the C and nothing else.
I have no idea what you are asking for;
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
You have no idea that: H simulates D comes next?
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong. >>>>>
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting.
D simulated by an incompletely simulating H, such that H(D) terminates
and returns zero, is halting.
I have no idea why you are celebrating.
This is why you have to specify H in every detail.
On 11/1/2025 6:33 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to
the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape
measure.
When machine M can't possibly reach its own final
halt state is this is a conventional definition
of non-halting M.
Non-terminating *INPUT* I defined as I simulated
by H such that I cannot possibly reach its own
"return" statement final halt state.
D simulated by H distinguishes the behavior specified
by the *INPUT* as opposed to and contrast with
any other behavior of anything else.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:33 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to >>>>> the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape
measure.
When machine M can't possibly reach its own final
halt state is this is a conventional definition
of non-halting M.
"When we trace a straight line from a wall, perpendicular to it, and it cannot possibly strike another wall or other obstacle, that is the conventional definition of infinity."
Non-terminating *INPUT* I defined as I simulated
by H such that I cannot possibly reach its own
"return" statement final halt state.
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
D simulated by H distinguishes the behavior specified
by the *INPUT* as opposed to and contrast with
any other behavior of anything else.
"The 10 foot tape measure distinguishes distance as specified
by the displacement away from the wall and nothing else.
It is a correct, accurate tape."
On 11/1/2025 6:47 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong. >>>>>>
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting.
D simulated by an incompletely simulating H, such that H(D) terminates
and returns zero, is halting.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
Do you think that when H totally stops simulating
any of these D's that these totally dead D's pop
their own stack and return?
On 11/1/2025 6:58 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:33 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to >>>>>> the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape
measure.
When machine M can't possibly reach its own final
halt state is this is a conventional definition
of non-halting M.
"When we trace a straight line from a wall, perpendicular to it, and it
cannot possibly strike another wall or other obstacle, that is the
conventional definition of infinity."
Non-terminating *INPUT* I defined as I simulated
by H such that I cannot possibly reach its own
"return" statement final halt state.
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
D simulated by H distinguishes the behavior specified
by the *INPUT* as opposed to and contrast with
any other behavior of anything else.
"The 10 foot tape measure distinguishes distance as specified
by the displacement away from the wall and nothing else.
It is a correct, accurate tape."
So you have turned into a troll.
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:47 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong.
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting.
D simulated by an incompletely simulating H, such that H(D) terminates
and returns zero, is halting.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
What comes next is that H performs a /step/ of D.
Then H checks whether D has terminated. If so,
it breaks the loop and return 1.
Otherwise H inserts the instruction of D
(or decoded information about it) into a trace
buffer, at least if that instruction meets certain
interesting criteria.
On 2025-11-02, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:58 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:33 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to >>>>>>> the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape >>>>> measure.
When machine M can't possibly reach its own final
halt state is this is a conventional definition
of non-halting M.
"When we trace a straight line from a wall, perpendicular to it, and it
cannot possibly strike another wall or other obstacle, that is the
conventional definition of infinity."
Non-terminating *INPUT* I defined as I simulated
by H such that I cannot possibly reach its own
"return" statement final halt state.
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
D simulated by H distinguishes the behavior specified
by the *INPUT* as opposed to and contrast with
any other behavior of anything else.
"The 10 foot tape measure distinguishes distance as specified
by the displacement away from the wall and nothing else.
It is a correct, accurate tape."
So you have turned into a troll.
How do your bizarre claims make more sense than the tape measure
example?
You're literally saying that when a length measurement arbitrarily comes to an end, the value must be estimated as infinite
The measurement is not just the map, it is the territory!
On 11/1/2025 7:12 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:47 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong.
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting. >>>>
D simulated by an incompletely simulating H, such that H(D) terminates >>>> and returns zero, is halting.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
What comes next is that H performs a /step/ of D.
Then H checks whether D has terminated. If so,
it breaks the loop and return 1.
Otherwise H inserts the instruction of D
(or decoded information about it) into a trace
buffer, at least if that instruction meets certain
interesting criteria.
Only trace the simulated instructions of D.
I want you directly see that when 0 to infinity
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:33 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to >>>>> the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape
measure.
When machine M can't possibly reach its own final
halt state is this is a conventional definition
of non-halting M.
"When we trace a straight line from a wall, perpendicular to it, and it cannot possibly strike another wall or other obstacle, that is the conventional definition of infinity."
Non-terminating *INPUT* I defined as I simulated
by H such that I cannot possibly reach its own
"return" statement final halt state.
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
On 2025-11-02, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 7:12 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:47 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong.
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting. >>>>>
D simulated by an incompletely simulating H, such that H(D) terminates >>>>> and returns zero, is halting.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
What comes next is that H performs a /step/ of D.
Then H checks whether D has terminated. If so,
it breaks the loop and return 1.
Otherwise H inserts the instruction of D
(or decoded information about it) into a trace
buffer, at least if that instruction meets certain
interesting criteria.
Only trace the simulated instructions of D.
The first damned thing D does is call H(D).
So in order to trace D, we immediately need a definition of H to trace.
I want you directly see that when 0 to infinity
The only way anyone is going to "see" your retarded hypotheses is if
they gouge their eyes out with a fork, and huff a clump of rags soaked
in paint thinner.
I can write a C interpreter which can interpret itself.
On 01/11/2025 23:58, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:33 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 11:59 AM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
When D calls H(D) this makes this sequence of steps
specified by the input to H a different sequence of
steps than the sequence of steps specified by the
input to H1(D). This cannot be ignored. It must be
accounted for.
The steps of H and H1 are certainly different.
The steps of the simulated D are not different.
The difference is that D simulated by H cannot possibly
reach its own "return" statement and D simulated by H1
does reach its own "return" statement.
Umm, no. Under H, the /simulation of D/ certainly does not proceed to >>>>>> the point where D reaches its return statement.
Thus the input to H(D) specifies a non-terminating
sequence when measured by D simulated by H.
Sure, and a 12 foot room is infinite, when measured by a 10 foot tape
measure.
When machine M can't possibly reach its own final
halt state is this is a conventional definition
of non-halting M.
"When we trace a straight line from a wall, perpendicular to it, and it
cannot possibly strike another wall or other obstacle, that is the
conventional definition of infinity."
Non-terminating *INPUT* I defined as I simulated
by H such that I cannot possibly reach its own
"return" statement final halt state.
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
I stretched out the tape measure, and it wouldn't reach the other wall -
the room is clearly "exhibiting infinite length behaviour" !!
So I bought a longer tape measure - a 20 foot measure. But it seems
I've been put me in a new room constructed by architects with access to
my tape measure, and blow me down: when I measure the length of the room
it still won't reach; it's a good couple of feet short! Again, it is obvious even to school children that the tape measure /cannot/ reach
from one wall to the opposite wall - Again, THE ROOMÂ IS EXHIBITING INFINITE LENGTH!
No matter how long a tape measure I buy, IT CAN *NEVER* REACH "THE
OPPOSITE WALL", which establishes beyond doubt that "the room" is indeed INFINITE, and so I'm correct when I announce it is infinite.
Well, that convinces me! [NOT]   :)
Mike.
ps. seems we've hit upon a proof of the "Room Measuring Problem": is
there a tape measure which can measure the length of any room?
On 11/1/2025 6:13 PM, Mike Terry wrote:<..snip..>
On 01/11/2025 23:58, Kaz Kylheku wrote:
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
I stretched out the tape measure, and it wouldn't reach the other wall - the room is clearly
"exhibiting infinite length behaviour" !!
So I bought a longer tape measure - a 20 foot measure. But it seems I've been put me in a new
room constructed by architects with access to my tape measure, and blow me down: when I measure
the length of the room it still won't reach; it's a good couple of feet short! Again, it is
obvious even to school children that the tape measure /cannot/ reach from one wall to the opposite
wall - Again, THE ROOM IS EXHIBITING INFINITE LENGTH!
No matter how long a tape measure I buy, IT CAN *NEVER* REACH "THE OPPOSITE WALL", which
establishes beyond doubt that "the room" is indeed INFINITE, and so I'm correct when I announce it
is infinite.
Well, that convinces me! [NOT] :)
Mike.
ps. seems we've hit upon a proof of the "Room Measuring Problem": is there a tape measure which
can measure the length of any room?
The measure of tape would need to know how long to make itself in order be the correct length for
say the diagonal of any rect.
On 11/1/2025 2:05 PM, dbush wrote:
On 11/1/2025 3:01 PM, olcott wrote:
On 11/1/2025 1:45 PM, dbush wrote:Everyone knows you're doing this because you can't prove his code wrong.
On 11/1/2025 2:38 PM, olcott wrote:
On 11/1/2025 1:14 PM, Tristan Wibberley wrote:
On 01/11/2025 04:23, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:[snip]
On 10/31/2025 9:53 PM, Tristan Wibberley wrote:
If there is a challenge for us, it is to notice that those are >>>>>>>>> the facts
of this particular situation statement.
[... new situation statement snipped ...]
You have used up the name H for something else already;
do not confuse things by claiming H just simulates now!
H can be an indeterminate in general, determined by each individual >>>>>> situation statement.
Quite why he replied to a discussion about his other situation
statement
with another that is from among a group of them that is confusing
everyone /is/ problematic.
I would advise not responding to such to keep the conversation
straightforward.
I changed it to D and H with a single argument
that do not exist in my repository, yet this
is too straightforward to form any rebuttal.
In other words, as everyone can tell, you're trying to deflect away
from your code which is proven wrong by Kaz's code.
<deflection>
If I am wrong Kaz can show it
When I insist that Kaz do this in CYou dishonestly dodge that his code proves you wrong.
On 02/11/2025 01:27, Chris M. Thomasson wrote:
On 11/1/2025 6:13 PM, Mike Terry wrote:<..snip..>
On 01/11/2025 23:58, Kaz Kylheku wrote:
"When 10 foot tape measure H measures the 12 foot room D, it cannot
possibly strike the other wall. Therefore, the room is infinite!"
I stretched out the tape measure, and it wouldn't reach the other
wall - the room is clearly "exhibiting infinite length behaviour" !!
So I bought a longer tape measure - a 20 foot measure. But it seems
I've been put me in a new room constructed by architects with access
to my tape measure, and blow me down: when I measure the length of
the room it still won't reach; it's a good couple of feet short!
Again, it is obvious even to school children that the tape measure /
cannot/ reach from one wall to the opposite wall - Again, THE ROOM
IS EXHIBITING INFINITE LENGTH!
No matter how long a tape measure I buy, IT CAN *NEVER* REACH "THE
OPPOSITE WALL", which establishes beyond doubt that "the room" is
indeed INFINITE, and so I'm correct when I announce it is infinite.
Well, that convinces me! [NOT]   :)
Mike.
ps. seems we've hit upon a proof of the "Room Measuring Problem": is
there a tape measure which can measure the length of any room?
The measure of tape would need to know how long to make itself in
order be the correct length for say the diagonal of any rect.
You've got to get the order of things right.
1. I buy my new tape measure.
   [I'd like one long enough to measure /any/ room, please!
   But nobody seems to stock those, so I buy the best they've got...] 2. Those infernal architiects somehow know how long my new tape measure is!
   They build me a new room to test it on.
3. And when I try it out, my tape measure is not big enough - £18.99 wasted!
People are trying to tell me this means my quest for a universal tape measure was doomed from the start. But I've confounded them by saying
it is correct for me to say the room is infinite, and my patented measurement process concretely confirms the same. So I do in fact have
a tape measure that can measure "the architects diagonal room"! It is a demonstrated FACT.
[NOT]Â Â :)
Mike.
On 11/1/2025 7:50 PM, Kaz Kylheku wrote:
On 2025-11-02, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 7:12 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:47 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong.
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting. >>>>>>
D simulated by an incompletely simulating H, such that H(D) terminates >>>>>> and returns zero, is halting.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
What comes next is that H performs a /step/ of D.
Then H checks whether D has terminated. If so,
it breaks the loop and return 1.
Otherwise H inserts the instruction of D
(or decoded information about it) into a trace
buffer, at least if that instruction meets certain
interesting criteria.
Only trace the simulated instructions of D.
The first damned thing D does is call H(D).
So in order to trace D, we immediately need a definition of H to trace.
The definition of H is that H simulates D.
The entire definition of H at this point is that H simulates D
On 2025-11-02, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 7:50 PM, Kaz Kylheku wrote:
On 2025-11-02, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 7:12 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 6:47 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
On 11/1/2025 5:46 PM, Kaz Kylheku wrote:
On 2025-11-01, olcott <polcott333@gmail.com> wrote:
Everyone knows you're doing this because you can't prove his code wrong.
If I am wrong Kaz can show it more simply
otherwise I am not wrong.
You backed down on claiming that D simulated by H
reaches its own "return" statement final halt state.
I've always agreed that D simulated by H (i.e. H == UTM) is nonhalting. >>>>>>>
D simulated by an incompletely simulating H, such that H(D) terminates >>>>>>> and returns zero, is halting.
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
H simulates D then D calls H(D) what comes next?
What comes next is that H performs a /step/ of D.
Then H checks whether D has terminated. If so,
it breaks the loop and return 1.
Otherwise H inserts the instruction of D
(or decoded information about it) into a trace
buffer, at least if that instruction meets certain
interesting criteria.
Only trace the simulated instructions of D.
The first damned thing D does is call H(D).
So in order to trace D, we immediately need a definition of H to trace.
The definition of H is that H simulates D.
The entire definition of H at this point is that H simulates D
You must quit your habit of making "definitions at this point",
and constantly changing it.
When you say "simulates D", always be clear whether it is partially,
with aborting or indefinitely.
The possibilities are hardly limitless. Enumerate what they all
are, assign them function names and stick with those.
I can write a C interpreter which can interpret itself.
On 01/11/2025 22:19, Kaz Kylheku wrote:
To trace D, we need a definition of H.
The situation statement is a constraint on H, it almost defines a puzzle which may have solutions in H. Given the phrasing and the newsgroup I
think that's what Olcott was going for.
That is /you/ the /puzzled/ provides the H!
Or /I/ the /aloof/ provides generally superior criticism.
... we can ... move on
to the next step of my proof
H simulates D that should be baby stuff for this guy:
On 10/31/2025 7:44 PM, Kaz Kylheku wrote:
I can write a C interpreter which can interpret itself.
On 11/1/2025 3:42 AM, Mikko wrote:
On 2025-10-31 12:44:17 +0000, olcott said:
On 10/31/2025 6:28 AM, Mikko wrote:
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
It turns out that my big discovery the overturns
part of the foundation of computer science is that
the semantic property can be relative to the decider.
It actually always relative to the decider yet this
has never made any difference with non-self-referential
inputs. H(D) != UTM(D) == H1(D)
The halting problem has always been an issue where
the halt decider has never been smart enough to
figure out halting for self-contradictory inputs.
That never has been the real issue.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
With a simulating halt decider D simulated by
H never reaches the contradictory part. It
stays stuck on its first line.
H and D do get stuck in recursive simulation. H
can and does see this. H does abort its own simulation
of D to prevent its own non-termination.
The real issue (that could not be seen until I created
the notion of a simulating halt decider in 2016) is
that the halting problem requires H to report on
behavior other than the behavior that its actual input
actually specifies.
int sum(int x, int y){ return x + y; }
this is the same as requiring sum(3,4) to report on
the sum of 5 + 6.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
The above confirms that H and H1 give different results for the same
input. By the meanngs of the words H and H1 are not equivalent.
I never claimed that the were equivalent.
On 01/11/2025 22:50, olcott wrote:
... we can ... move on
to the next step of my proof
of what theorem?
--
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.
On 2025-11-01 13:25:41 +0000, olcott said:
On 11/1/2025 3:42 AM, Mikko wrote:
On 2025-10-31 12:44:17 +0000, olcott said:
On 10/31/2025 6:28 AM, Mikko wrote:
On 2025-10-30 14:49:08 +0000, olcott said:
D simulated by H measures the semantic property
of the actual input as opposed to and contrast
with the semantic property of a non-input. H and
H1 are identical except that D does not call H1.
Being identical means that H and H1 compute the same semantic
property.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
It turns out that my big discovery the overturns
part of the foundation of computer science is that
the semantic property can be relative to the decider.
It actually always relative to the decider yet this
has never made any difference with non-self-referential
inputs. H(D) != UTM(D) == H1(D)
The halting problem has always been an issue where
the halt decider has never been smart enough to
figure out halting for self-contradictory inputs.
That never has been the real issue.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
With a simulating halt decider D simulated by
H never reaches the contradictory part. It
stays stuck on its first line.
H and D do get stuck in recursive simulation. H
can and does see this. H does abort its own simulation
of D to prevent its own non-termination.
The real issue (that could not be seen until I created
the notion of a simulating halt decider in 2016) is
that the halting problem requires H to report on
behavior other than the behavior that its actual input
actually specifies.
int sum(int x, int y){ return x + y; }
this is the same as requiring sum(3,4) to report on
the sum of 5 + 6.
We can tell an input from a non-input because an
input is an argument to the function H.
D.input_to_H
specifies different behavior than
D.input_to_H1.
int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}
H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern
Then H returns 0;
H1 simulates D
that calls H(D) to simulate D
then H(D) returns 0 to caller D
then H1 returns 1;
As H and H1 return different values for the same input they are
found to be non-identical, contrary to the initial claim.
The above confirms that H and H1 give different results for the same
input. By the meanngs of the words H and H1 are not equivalent.
I never claimed that the were equivalent.
You said they be identical. If they are not equivlaent they can't
be identical.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,075 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 90:35:02 |
| Calls: | 13,798 |
| Calls today: | 1 |
| Files: | 186,989 |
| D/L today: |
5,331 files (1,536M bytes) |
| Messages: | 2,438,212 |