Op 24.apr.2025 om 05:22 schreef polcott333:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y)
{return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand how >>>>>>>>> these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct
execution of DD when you are not telling it one damn thing about >>>>>>>>> this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its inputs >>>>>>> correctly.

The key thing here is that Olcott consistently does not understand >>>>>> that
HHH is given a finite string input that according to the semantics of >>>>>> the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt decider,
not even
for DD only.

People here stupidly assume that the outputs are not required to
correspond to the inputs.

But the direct execution of DD is computable from its description.

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the

*finite*

recursive emulation> of DD including HHH emulating itself emulating

DD when

one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

You can't pop any other execution trace from the input
to HHH(DD) than that.

You can't abort a halting sequence and claim that it does not halt.
You can't claim a incorrectly coded program to be correct only it does
what its code specifies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/23/25 11:22 PM, polcott333 wrote:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y)
{return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand how >>>>>>>>> these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct
execution of DD when you are not telling it one damn thing about >>>>>>>>> this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its inputs >>>>>>> correctly.

The key thing here is that Olcott consistently does not understand >>>>>> that
HHH is given a finite string input that according to the semantics of >>>>>> the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt decider,
not even
for DD only.

People here stupidly assume that the outputs are not required to
correspond to the inputs.

But the direct execution of DD is computable from its description.

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

Yes, the input specifies FINITE recusive PARTIAL emulation, as the HHH
that DD calls will emulate only a few instructions of DD and then return,

Of course, part of the problem is that in your input you exclude the
code for HHH, and try to make it only implicit, which isn't allowed. HHH
can not assume behavior for the HHH it sees except by what is defined in
the input, or by the rules of the environment.

You can't pop any other execution trace from the input
to HHH(DD) than that.

You can get *ANY* trace of the input beyond the call to HHH, as HHH
isn't defined in the input.

If you include HHH in the input, then the actual execution trace of the
input, as exactly shown by an actual correct emulation of it, will see
that DD calls HHH(DD), which will emulated its input for a while then
stop and return 0, and then DD will halt.

Now, HHH's problem is it stops before it get there, as that is what its
code says to do, as seen in what is now part of the input you have
defined, and thus it needs to "guess" as to the answer, and DD is
programmed so what ever HHH guesses will be wrong.

Your problem is you just don't undetstand the fundamental of the
problem, logic, or truth,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 24.apr.2025 om 17:21 schreef olcott:

On 4/24/2025 3:07 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 05:22 schreef polcott333:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>> {return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand how >>>>>>>>>>> these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>> execution of DD when you are not telling it one damn thing about >>>>>>>>>>> this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its inputs >>>>>>>>> correctly.

The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt decider,
not even
for DD only.

People here stupidly assume that the outputs are not required to >>>>>>> correspond to the inputs.

But the direct execution of DD is computable from its description. >>>>>>

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the

*finite*

recursive emulation> of DD including HHH emulating itself emulating

DD when

one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

You can't pop any other execution trace from the input
to HHH(DD) than that.

You can't abort a halting sequence and claim that it does not halt.

Halting means reaching its own final halt state

when not prevented to reach its final state by an abort.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 24.apr.2025 om 19:13 schreef olcott:

On 4/24/2025 11:32 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 17:21 schreef olcott:

On 4/24/2025 3:07 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 05:22 schreef polcott333:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>>>> {return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand >>>>>>>>>>>>> how these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>>>> execution of DD when you are not telling it one damn thing >>>>>>>>>>>>> about
this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its >>>>>>>>>>> inputs
correctly.

The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt
decider, not even
for DD only.

People here stupidly assume that the outputs are not required to >>>>>>>>> correspond to the inputs.

But the direct execution of DD is computable from its description. >>>>>>>>

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the

*finite*

recursive emulation> of DD including HHH emulating itself

emulating DD when

one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

You can't pop any other execution trace from the input
to HHH(DD) than that.

You can't abort a halting sequence and claim that it does not halt.

Halting means reaching its own final halt state

when not prevented to reach its final state by an abort.

*It is not prevented from reaching its own final state by abort*

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is only a
finite recursion, so that no abort is needed to reach the end of the
halting program.
Mathematical induction shows that each HHH simulating N steps fails to
see that there is only a finite recursion, so it is proven that all HHH
that abort have the same failure.
But we agree that no algorithm exists that can determine for all
possible inputs whether the input specifies a program that (according to
the semantics of the machine language) halts when directly executed.
Correct?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is only
a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

Again a lot of text, but no rebuttal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 11:21 AM, olcott wrote:

On 4/24/2025 3:07 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 05:22 schreef polcott333:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>> {return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand how >>>>>>>>>>> these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>> execution of DD when you are not telling it one damn thing about >>>>>>>>>>> this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its inputs >>>>>>>>> correctly.

The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt decider,
not even
for DD only.

People here stupidly assume that the outputs are not required to >>>>>>> correspond to the inputs.

But the direct execution of DD is computable from its description. >>>>>>

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the

*finite*

recursive emulation> of DD including HHH emulating itself emulating

DD when

one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

You can't pop any other execution trace from the input
to HHH(DD) than that.

You can't abort a halting sequence and claim that it does not halt.

Halting means reaching its own final halt state.
Mathematical induction proves that DD emulated
by HHH according to finite string transformation
rules of the x86 language cannot possibly reach
its own final halt state even after an infinite
number of steps.

No, you can't do your induction, becuase HHH can't be changed to do it.

Sorry you checkmated your argument by fixing HHH to be the one in Halt7.c

And, even when you can change HHH, you have the problem that each input
is a seperate input, so while you can prove that no verison of HHH can correctly emulate its input to the final state, you haven't proved that
a correct and complete emulation of any of those input will not.

You just are proving you don't know what you are talking about.

You can't claim a incorrectly coded program to be correct only it does
what its code specifies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 1:13 PM, olcott wrote:

On 4/24/2025 11:32 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 17:21 schreef olcott:

On 4/24/2025 3:07 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 05:22 schreef polcott333:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>>>> {return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand >>>>>>>>>>>>> how these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>>>> execution of DD when you are not telling it one damn thing >>>>>>>>>>>>> about
this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its >>>>>>>>>>> inputs
correctly.

The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt
decider, not even
for DD only.

People here stupidly assume that the outputs are not required to >>>>>>>>> correspond to the inputs.

But the direct execution of DD is computable from its description. >>>>>>>>

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the

*finite*

recursive emulation> of DD including HHH emulating itself

emulating DD when

one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

You can't pop any other execution trace from the input
to HHH(DD) than that.

You can't abort a halting sequence and claim that it does not halt.

Halting means reaching its own final halt state

when not prevented to reach its final state by an abort.

*It is not prevented from reaching its own final state by abort*

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, it doesn't, because it fails to obey the requiremet of looking at
THIS input, which includes the ORIGINAL HHH, as defined in Halt7.c, not
the non-existant hypothetical one you want to talk about.

You are just proving you are just a stupid liar that doesn't know what
he is talking about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 3:41 PM, olcott wrote:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is only
a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

When the defined finite string trasnsformation rules, thos of the x86
language, are applied to this input, completed with the definitions from Halt7.c as stipulated, we see that DD calls HHH(DD), that it will spend
some time emulating DDm then it will give up and return 0 to DD which
will then halt.

THe fact that HHH doesn't complete this operation, doesn't mean that it
isn't what the x86 language says will happen, just that HHH doesn't know
that is what happens.

THus, HHH just fails to know what to do, and because you were so stupid
as to program it with unsound logic, it gets that wrong answer.

Your problem is you confuse the partial, and thus INCORRECT emulatation
done by HHH with the correct and complete emulation specified by the x86 language and the full input which includes the code of HHH from Halt7.c

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 5:01 PM, olcott wrote:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

Again a lot of text, but no rebuttal.

*This rebuttal is over-your-head*

All computations must be finite string transformations
to finite string inputs.

Right

When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

No, HHH just stops performing those before it get to the end.

The transformation, which by definition of the x86 language, don't just
stop in the middle, continue to the point where the emulated HHH aborts
its emulation and returns 0 to the emulated DD which the halts.

That fact you confuse the partial emulation of HHH with the actual
factual definition of the x86 language just shows your ignorance of what
you talk about, that you don't understand the nature of logic or truth,
and that you are nothing but a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 5:13 PM, olcott wrote:

On 4/24/2025 5:59 AM, Richard Damon wrote:

On 4/23/25 11:22 PM, polcott333 wrote:

On 4/23/2025 9:41 PM, Richard Damon wrote:

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

You continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>> {return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand how >>>>>>>>>>> these
things fundamentally work.

It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>> execution of DD when you are not telling it one damn thing about >>>>>>>>>>> this direct execution.

What else is it missing that the processor uses to execute it? >>>>>>>>>>

libx86emu <is> a correct x86 processor and does emulate its inputs >>>>>>>>> correctly.

The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,

That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt decider,
not even
for DD only.

People here stupidly assume that the outputs are not required to >>>>>>> correspond to the inputs.

But the direct execution of DD is computable from its description. >>>>>>

Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.

The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

Yes, the input specifies FINITE recusive PARTIAL emulation, as the HHH
that DD calls will emulate only a few instructions of DD and then return,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input.

The CORRECT transformation, as defined by the x86 language, goes through
the call HHH to the code of HHH defined in Halt7.c, which WILL emulate a
few insturctions and then abort its emulation, as that is what the code defines, and then return 0 to DD which will then halt.

The fact that HHH gives up, doesn't make the CORRECT emulation stop, and
there is nothing a mere program can do to redefine the rules of the x86 language to make it stop.

The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.

THEY DIFFER BY THE EMULATED DD REACHES RECURSIVE EMULATION
AND THE DIRECTLY EXECUTED DD NEVER DOES.

But it does, as explaimed about. The recusion is finite because the only
HHH that exists gives up, and returns the wrong answer.

The actual defined transformation continues, and can not be stopped,
until it see the emulation do the same thing and the emulated HHH return
0 to the emulated DD which reaches its final state.

You are just too stupid to understand this,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 8:03 PM, olcott wrote:

On 4/24/2025 6:10 PM, Richard Damon wrote:

On 4/24/25 5:01 PM, olcott wrote:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations >>>>>>> specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

Again a lot of text, but no rebuttal.

*This rebuttal is over-your-head*

All computations must be finite string transformations
to finite string inputs.

Right

When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

No, HHH just stops performing those before it get to the end.

The transformation, which by definition of the x86 language, don't
just stop in the middle, continue to the point where the emulated HHH
aborts its emulation and returns 0 to the emulated DD which the halts.

Mathematical induction proves that DD emulated by HHH
cannot possibly reach its own final state in an infinite
number of steps and it does this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Try to show it.

Remember, HHH is DEFINED to do what it does, and thus you can't use
induction to make it be something else.

THe input BY DEFINITION calls the origianl HHH, and thus when you
imagine a different machine that emulates one step farther, you CAN'T
put it at the memory location of HHH, as that has already been defined,
so you get effectivel HHH1, which shows the input halts.

Your "proof" is based on LYING by conviently forgetting that HHH is
fixed and defined and can't be changed.

Sorry, you are just proving that you are just a stupid pathological liar.

Try to write you your induction that falls within your stipulation that
your exist Halt7.c is defined and in the problem.

You don't get to change it, or you are admtting that you are creating a DIFFERENT input, and thus the induction falls appart.

Sorry, you have put yourself in checkmate, and you lying won't get you
out, just prove how stupid you are.

That fact you confuse the partial emulation of HHH with the actual
factual definition of the x86 language just shows your ignorance of
what you talk about, that you don't understand the nature of logic or
truth, and that you are nothing but a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/24/25 10:50 PM, olcott wrote:

On 4/24/2025 6:07 PM, Richard Damon wrote:

On 4/24/25 3:41 PM, olcott wrote:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

When the defined finite string trasnsformation rules, thos of the x86
language, are applied to this input, completed with the definitions
from Halt7.c as stipulated, we see that DD calls HHH(DD), that it will
spend some time emulating DDm then it will

Correctly determine that DD emulated by HHH can never possibly
reach its final halt state even after an infinite number of
steps are emulated. Many C programmers have attested to this.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

When the smart knowledgeable people here disagree it seems
far too implausible to construe this as any honest mistake.

Your are forgetting your stipulation, that Halt7.c is part of the input,
and thus *THAT* definition of HHH is what you are stuck with, and that
ALWAYS aborts at the point it does.

Thus, HHH *NEVER* correctly emulates the input, and you criteria is just
a category error and you are proving your "logic" is based on LIES and
ERRORS.

The fact that you can't see this just shows how stupid you are, and that
you mind can't see its own errors.

I'm sorry, but you are just proving your utter stupdity.

You can't change what you have already defined.

How does that code in Halt7.c do what you claim it does, do you not
understand how programs work?

Do you not realize you are stuck with your stipulations?

That you are just showing that nothing you say can be taken for what you
say, as you disagree with yourself.

Sorry, you are just proving you are just a pathological liar that
doesn't have an bit of understand of what you are talking about.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 24.apr.2025 om 23:01 schreef olcott:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

Again a lot of text, but no rebuttal.

*This rebuttal is over-your-head*

All computations must be finite string transformations
to finite string inputs.

When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

Take a better look at your code in Halt7.c. This shows that HHH will
return to DD and DD will reach its final state. But the simulating HHH
does not see that, because it does not even look at the code in Halt7.c, because of a premature abort.
This bug in HHH does not say anything about the behaviour of DD.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/25 12:53 AM, olcott wrote:

On 4/24/2025 10:00 PM, dbush wrote:

On 4/24/2025 10:50 PM, olcott wrote:

On 4/24/2025 6:07 PM, Richard Damon wrote:

On 4/24/25 3:41 PM, olcott wrote:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that
DD emulated by HHH (according to the finite string transformations >>>>>>> specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

When the defined finite string trasnsformation rules, thos of the
x86 language, are applied to this input, completed with the
definitions from Halt7.c as stipulated, we see that DD calls
HHH(DD), that it will spend some time emulating DDm then it will

Correctly determine that DD emulated by HHH can never possibly
reach its final halt state even after an infinite number of
steps are emulated.

Category error.  The fixed code of algorithm HHH, which is part of the
input as you agreed, emulates for a fixed number of steps.  Therefore
there is no infinite number of steps emulated by algorithm HHH.

You are flat out stupid about hypothetical possibilities.

No, you are. You can only properly hypothetize about things that might
be possible, and normally it is done to prove that they are not. Using
things assumed true doesn't prove something to be true, as the arguement
is based on an unfounded assumption.

Of every possible HHH/DD pair where DD calls HHH(DD) and
DD is emulated by HHH according to the finite string transformation
rules of the x86 language no DD ever reaches its own final halt state.

Because your system has DEFINED what HHH is, there is only ONE HHH/DD
pair. PERIOD, and that one fails to fuly emulate DD, and thus doesn't
show that the CORECT emulation of that input doesn't reach the final state.

Even if we ignore your definition of HHH for what decider we give the
input to, DD must still call the orginal HHH or you are changing the
input, and thus nothing of your logic is talking about THAT DD.

If DD doesn't call that specific HHH, then but whatever HHH you are
imagining, then DD just isn't a program, and you proof is just a
catergory error.

Your argument is "isomorphic" to waling 25 feet along a path, and then stopping, and them proudly proclaiming that this path must be never
ending in length, because you couldn't walk it to the end.

Ultimately, all you are doing is showning you just don't understand what
you are talking about.

And the fact that you never even try to rebute the errors pointed out in
your argument, it shows that at a base level, you KNOW you are without
grounds, or are just so stupid you don't understand how any of this
logic works, and think it is just a debating society where people can
say anything they want to persuade people, be it correct or lies.

However, UTM(DD) emulates the same input which includes HHH as part if
it for a finite number of steps and reaches a final state.  The
instructions emulated by UTM are exactly the same as those emulated by
HHH up to the point that it aborts, showing that the fixed code of HHH
is incorrect in showing non-halting.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

On 4/24/2025 6:10 PM, Richard Damon wrote:

On 4/24/25 5:01 PM, olcott wrote:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that DD
emulated by HHH (according to the finite string transformations
specified by the x86 language) cannot possibly reach its final
halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is
only a finite recursion,

When the finite string transformation rules of the x86 language are
applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an >>>>> infinite number of emulated steps.

Again a lot of text, but no rebuttal.

When the finite string transformation rules of the x86 language are
applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an
infinite number of emulated steps.

No, HHH just stops performing those before it get to the end.
The transformation, which by definition of the x86 language, don't just
stop in the middle, continue to the point where the emulated HHH aborts
its emulation and returns 0 to the emulated DD which the halts.

Mathematical induction proves that DD emulated by HHH cannot possibly
reach its own final state in an infinite number of steps and it does
this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the contradictory
part of DD, only with it being simulated by the same simulator it calls.
The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/25 2:31 PM, olcott wrote:

On 4/25/2025 7:02 AM, dbush wrote:

On 4/25/2025 12:53 AM, olcott wrote:

On 4/24/2025 10:00 PM, dbush wrote:

On 4/24/2025 10:50 PM, olcott wrote:

On 4/24/2025 6:07 PM, Richard Damon wrote:

On 4/24/25 3:41 PM, olcott wrote:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that >>>>>>>>> DD emulated by HHH (according to the finite string transformations >>>>>>>>> specified by the x86 language) cannot possibly reach its final >>>>>>>>> halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is >>>>>>>> only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

When the defined finite string trasnsformation rules, thos of the
x86 language, are applied to this input, completed with the
definitions from Halt7.c as stipulated, we see that DD calls
HHH(DD), that it will spend some time emulating DDm then it will

Correctly determine that DD emulated by HHH can never possibly
reach its final halt state even after an infinite number of
steps are emulated.

Category error.  The fixed code of algorithm HHH, which is part of
the input as you agreed, emulates for a fixed number of steps.
Therefore there is no infinite number of steps emulated by algorithm
HHH.

You are flat out stupid about hypothetical possibilities.
Of every possible HHH/DD pair where DD calls HHH(DD) and
DD is emulated by HHH according to the finite string transformation
rules of the x86 language no DD ever reaches its own final halt state.

In other words, you're hypothesizing changing the input.

Changing the input, hypothetically or otherwise, is not allowed.

I am only saying the ALL X are Y.
Only Trolls would have difficulty with this.

But you don't define correctly what your X and Y are, or even if they
can logically exist.

And HHH that isn't the HHH you have defined is a logical contradiction,
so your argument is based on a fallicy.

However, UTM(DD) emulates the same input which includes HHH as part
if it for a finite number of steps and reaches a final state.  The
instructions emulated by UTM are exactly the same as those emulated
by HHH up to the point that it aborts, showing that the fixed code
of HHH is incorrect in showing non-halting.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/25 2:51 PM, olcott wrote:

On 4/25/2025 1:39 PM, dbush wrote:

On 4/25/2025 2:31 PM, olcott wrote:

On 4/25/2025 7:02 AM, dbush wrote:

On 4/25/2025 12:53 AM, olcott wrote:

On 4/24/2025 10:00 PM, dbush wrote:

On 4/24/2025 10:50 PM, olcott wrote:

On 4/24/2025 6:07 PM, Richard Damon wrote:

On 4/24/25 3:41 PM, olcott wrote:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that >>>>>>>>>>> DD emulated by HHH (according to the finite string
transformations
specified by the x86 language) cannot possibly reach its final >>>>>>>>>>> halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there >>>>>>>>>> is only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

When the defined finite string trasnsformation rules, thos of
the x86 language, are applied to this input, completed with the >>>>>>>> definitions from Halt7.c as stipulated, we see that DD calls
HHH(DD), that it will spend some time emulating DDm then it will >>>>>>>

Correctly determine that DD emulated by HHH can never possibly
reach its final halt state even after an infinite number of
steps are emulated.

Category error.  The fixed code of algorithm HHH, which is part of >>>>>> the input as you agreed, emulates for a fixed number of steps.
Therefore there is no infinite number of steps emulated by
algorithm HHH.

You are flat out stupid about hypothetical possibilities.
Of every possible HHH/DD pair where DD calls HHH(DD) and
DD is emulated by HHH according to the finite string transformation
rules of the x86 language no DD ever reaches its own final halt state. >>>>>

In other words, you're hypothesizing changing the input.

Changing the input, hypothetically or otherwise, is not allowed.

I am only saying the ALL X are Y.
Only Trolls would have difficulty with this.

No, you're saying that

For every possible HHH/DD pair where HHH emulates 0 to ∞

But those don't exist, because HHH has been stipulated to be the ONE
machine defined in Halt7.c

Sorry, you are not allowed to change it without giving up that
stipulation, and if you do then you hit the problem that DD now isn't
defined, as you don't have a single definition of the HHH that it calls.

instructions of DD (according to the finite string
transformation rules specified by the x86 language)
no DD ever reaches its final halt state.

But since you have retracted you definition of Halt7.c, then either your definition of DD changes for every different HHH you are thinking of,
and thus you argument breaks as it isn't trying to look at the same
input, or the input just doesn't have behavior.

You can't do induction on a criteria that changes for each n.

Sorry, you are just proving your ignorance of what you are talking about.

When ALL X are Y then zero X are not Y, Trolls may disagree.

But if there is only 1 X, then there is only 1 Y, and X's claim that it
is correctly emulating its input is a lie, as no induction has been done.

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

It is still a FACT that if HHH has been defined to do what you say, DD
will halt. and the correect emulation of DD by a emulator that actually
does a complete emulation will halt, and it is a fact that NONE of your
HHH's in the full infinte set ever did that emulation.

Your arguement is basically like saying if we define M to be N+1, that M
must be infinite, because there is no finte number N where N > M.

The problme is you can't do the induction over N to look at the changing M.

You are just showing your utter stupidity,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 25 Apr 2025 16:21:30 -0500 schrieb olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot possibly
reach its own final state in an infinite number of steps and it does
this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory part of DD,

Sure it does. The contradictory part of DD has always been unreachable
thus only a ruse.

Then it can't be due to that. It even works with HHH(HHH)!

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

This is not, but behaves the same:

The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH.

HHH cannot possibly do this without violating the rules of the x86
language.
The finite string transformation rules of the x86 language applied to
the input to HHH(DD) only correctly derive not halting.

No, the rules applied to DD (which is the input to HHH) derive "halting",
but HHH is like any simulator incapable of simulating itself to
completion.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/25 5:21 PM, olcott wrote:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

On 4/24/2025 6:10 PM, Richard Damon wrote:

On 4/24/25 5:01 PM, olcott wrote:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that DD >>>>>>>>> emulated by HHH (according to the finite string transformations >>>>>>>>> specified by the x86 language) cannot possibly reach its final >>>>>>>>> halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is >>>>>>>> only a finite recursion,

When the finite string transformation rules of the x86 language are >>>>>>> applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an >>>>>>> infinite number of emulated steps.

Again a lot of text, but no rebuttal.

When the finite string transformation rules of the x86 language are
applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an >>>>> infinite number of emulated steps.

No, HHH just stops performing those before it get to the end.
The transformation, which by definition of the x86 language, don't just >>>> stop in the middle, continue to the point where the emulated HHH aborts >>>> its emulation and returns 0 to the emulated DD which the halts.

Mathematical induction proves that DD emulated by HHH cannot possibly
reach its own final state in an infinite number of steps and it does
this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

But it *IS* reachable, just not by HHH, as it gives up simulating too soon.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

No, the Halting Problem counter-example calls the Halt Decider that this particular Input is designed to prove wrong.

You can't make a computation that calls the decider that is deciding on it.

The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH.

HHH cannot possibly do this without violating the rules of
the x86 language.

Sure it can, as shown by HHH1. It is just that it doesn't, and this
input exploits that error.

The finite string transformation rules of the x86 language
applied to the input to HHH(DD) only correctly derive not halting.
*It is like you are trying to get away with disagreeing with arithmetic*

Really, then why does running it make it halt, as they both do the EXACT
SAME transformation, that *IS* what correct simulation is defined by.
The problem is that HHH doesn't actually follow all the x86
transformation rules, but deviates by choosing to abort its operation
becuase it is afraid that it will get stuck.

But, since the input is defined to use the version of HHH that is in
Halt7.c that does this abort, the decider looking at it doesn't need to
abort, but of course, HHH does since that was what its code said to do,
even though that was the wrong thing to do.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/25 5:52 PM, olcott wrote:

On 4/25/2025 4:42 PM, joes wrote:

Am Fri, 25 Apr 2025 16:21:30 -0500 schrieb olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot possibly >>>>> reach its own final state in an infinite number of steps and it does >>>>> this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory part of DD,

Sure it does. The contradictory part of DD has always been unreachable
thus only a ruse.

Then it can't be due to that. It even works with HHH(HHH)!

When the finite string transformation rules of any
concrete (thus fully specified) computer language
are applied to the input to any conventional Halting
Problem proof the contradictory part is always unreachable.

No, because the input defined in that Halting Problem proof is always
built on the one specific decider that it is designed to prove wrong.

The UTM machine is not one of those machines, so there is nothing that
makes that machine unable to simulate the input.

This works for C, for x86, and for Turing Machines.

Right, and they ALL show that if the Halt Decider that the Input was
built on returns a value, (and if it doesn't, it isn't a decideer), then
the UTM or other complete simulator for the input will get to that final decision and see the proof program get its answer from its copy of that decider, and then act the opposite.

Your problem is your computer model is just incorrect, and what you call
the input, isn't actually valid, but then you fix that problem by your
implied inclusion of Halt7.c which then defines the one decider that the
input will be built on and makes wrong.

You are just to ignorant and stupid to understand this issue, The input
doesn't (and can't) call whatever decider it trying to decide it, it
MUST call the one specific decider it was built on, and thus it HAS a
actual correct simulation, and if the decider returns 0 for that input,
that behavior WILL halt.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/25/25 5:07 PM, olcott wrote:

On 4/25/2025 2:07 PM, Richard Damon wrote:

On 4/25/25 2:51 PM, olcott wrote:

On 4/25/2025 1:39 PM, dbush wrote:

On 4/25/2025 2:31 PM, olcott wrote:

On 4/25/2025 7:02 AM, dbush wrote:

On 4/25/2025 12:53 AM, olcott wrote:

On 4/24/2025 10:00 PM, dbush wrote:

On 4/24/2025 10:50 PM, olcott wrote:

On 4/24/2025 6:07 PM, Richard Damon wrote:

On 4/24/25 3:41 PM, olcott wrote:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that >>>>>>>>>>>>> DD emulated by HHH (according to the finite string
transformations
specified by the x86 language) cannot possibly reach its final >>>>>>>>>>>>> halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that >>>>>>>>>>>> there is only a finite recursion,

*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.

When the defined finite string trasnsformation rules, thos of >>>>>>>>>> the x86 language, are applied to this input, completed with >>>>>>>>>> the definitions from Halt7.c as stipulated, we see that DD >>>>>>>>>> calls HHH(DD), that it will spend some time emulating DDm then >>>>>>>>>> it will

Correctly determine that DD emulated by HHH can never possibly >>>>>>>>> reach its final halt state even after an infinite number of
steps are emulated.

Category error.  The fixed code of algorithm HHH, which is part >>>>>>>> of the input as you agreed, emulates for a fixed number of
steps. Therefore there is no infinite number of steps emulated >>>>>>>> by algorithm HHH.

You are flat out stupid about hypothetical possibilities.
Of every possible HHH/DD pair where DD calls HHH(DD) and
DD is emulated by HHH according to the finite string transformation >>>>>>> rules of the x86 language no DD ever reaches its own final halt
state.

In other words, you're hypothesizing changing the input.

Changing the input, hypothetically or otherwise, is not allowed.

I am only saying the ALL X are Y.
Only Trolls would have difficulty with this.

No, you're saying that

For every possible HHH/DD pair where HHH emulates 0 to ∞

But those don't exist, because HHH has been stipulated to be the ONE
machine defined in Halt7.c

*It is really not that hard*
Many C programmers said they get this (two of them
with masters degrees in computer science)

Is there any hypothetical HHH that emulates 0 to ∞
steps of DD where DD reaches its final halt state?
No !!!

But none of them are allowed in your system, as you have already defined
what HHH is.

You aren't allowed to hypotosize somethint contradictory to a
stipulation you have made.

Sorry, you are just showing that you just don't know what you are
talking about or how logic actually works.

Yes, you can change your definition, and remove the fixed definition of
Halt7.c (which you object strongly when I imply that you are doing) but
then everything you said I had wrong is not right, and the input just
isn't a program any more as it doesn't include the code for the decider,
unless you add it back, but then you no longer have *A* input, but an
infinite number of them, each given to just one machine, so your
"induction" doesn't work except to prove that every one of those version
is incorrect, and thus none are correct.

Sorry, you have checkmated your system, and sunk it to the bottom of
that lake of fire, where you will join it shortly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

On 4/24/2025 6:10 PM, Richard Damon wrote:

On 4/24/25 5:01 PM, olcott wrote:

On 4/24/2025 2:59 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 21:41 schreef olcott:

On 4/24/2025 2:12 PM, Fred. Zwarts wrote:

Op 24.apr.2025 om 19:13 schreef olcott:

HHH correctly determines through mathematical induction that DD >>>>>>>>> emulated by HHH (according to the finite string transformations >>>>>>>>> specified by the x86 language) cannot possibly reach its final >>>>>>>>> halt state in an infinite number of steps.

No, HHH has a bug which makes that it fails to see that there is >>>>>>>> only a finite recursion,

When the finite string transformation rules of the x86 language are >>>>>>> applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an >>>>>>> infinite number of emulated steps.

Again a lot of text, but no rebuttal.

When the finite string transformation rules of the x86 language are
applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE not even after an >>>>> infinite number of emulated steps.

No, HHH just stops performing those before it get to the end.
The transformation, which by definition of the x86 language, don't just >>>> stop in the middle, continue to the point where the emulated HHH aborts >>>> its emulation and returns 0 to the emulated DD which the halts.

Mathematical induction proves that DD emulated by HHH cannot possibly
reach its own final state in an infinite number of steps and it does
this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH.

HHH cannot possibly do this without violating the rules of
the x86 language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot possibly >>>>> reach its own final state in an infinite number of steps and it does >>>>> this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH. >>>>

HHH cannot possibly do this without violating the rules of
the x86 language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated

It has been pointed out many times. It is against the rules of the x86
language to abort a halting function. We see that simulators that do not
abort have no problem to reach the end of this halting program.
Why do you ignore this? Is that because you already know that HHH does
violate the rules and you are only playing trollish head games.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sat, 26 Apr 2025 14:46:12 -0500 schrieb olcott:

On 4/26/2025 1:22 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

The program EE(){ HHH(EE); } also halts and cannot be simulated by >>>>>> HHH.

HHH cannot possibly do this without violating the rules of the x86
language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules of the x86 language yet no
one can point out which rules are violated

It has been pointed out many times. It is against the rules of the x86
language to abort a halting function.

You remains stupidly wrong about this because you refuse to show what
step of DD is not emulated by HHH according to the finite string transformation rules specified by the x86 language.

All instructions after the abort are not emulated.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/26/25 1:28 PM, olcott wrote:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot possibly >>>>> reach its own final state in an infinite number of steps and it does >>>>> this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

The program EE(){ HHH(EE); } also halts and cannot be simulated by HHH. >>>>

HHH cannot possibly do this without violating the rules of
the x86 language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated because they already
know that HHH does not violate any rules and
they are only playing trollish head games.

Becuse in the general documentation for ALL instructions, is the
definition that after a given instruction is executed, the instruction
at the new value of the program counter WILL be executed.

That means that HHH stopping is a violation of that requirement.

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

DD emulated by HHH according to the finite
string transformation rules of the x86 language
does emulate [00002133] through [0000213c] which
causes HHH to emulate itself emulating DD again
in recursive emulation repeating the cycle of
[00002133] through [0000213c].

No, HHH doesn't emulate fully by the rules of the x86 language, so your criteria is just a self-contadiction and thus a category error.

When DD is actually emulated by that rule, it reaches its final state
since your HHH(DD) will return 0 after some number of steps.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/26/25 3:45 PM, olcott wrote:

On 4/26/2025 1:22 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot
possibly
reach its own final state in an infinite number of steps and it does >>>>>>> this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

The program EE(){ HHH(EE); } also halts and cannot be simulated by >>>>>> HHH.

HHH cannot possibly do this without violating the rules of
the x86 language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated

It has been pointed out many times. It is against the rules of the x86
language to abort a halting function.

You remains stupidly wrong about this because
you refuse to show what step of DD is not emulated
by HHH according to the finite string transformation
rules specified by the x86 language.

The steps of HHH after HHH stops its emulation.

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

You refuse to show the incorrect step because you
know that you are clueless about the x86 language
and provide your "rebuttal" entirely on the basis
of pure bluster. In other words pure Troll behavior
on your part.

No, YOU are the one that refuses to show the step where the direct
exectution and your claimed correct emulation differ to allow HHH to say
that it must be correct to call its behavior non-halting.

Sorry, YOU have the burden of proof of that claim, and you have
effective admited to just being a pathological liar by refusing to even
attempt that demonstration.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/26/25 4:41 PM, olcott wrote:

On 4/26/2025 3:23 PM, joes wrote:

Am Sat, 26 Apr 2025 14:46:12 -0500 schrieb olcott:

On 4/26/2025 1:22 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

The program EE(){ HHH(EE); } also halts and cannot be simulated by >>>>>>>> HHH.

HHH cannot possibly do this without violating the rules of the x86 >>>>>>> language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules of the x86 language yet no >>>>> one can point out which rules are violated

It has been pointed out many times. It is against the rules of the x86 >>>> language to abort a halting function.

You remains stupidly wrong about this because you refuse to show what
step of DD is not emulated by HHH according to the finite string
transformation rules specified by the x86 language.

All instructions after the abort are not emulated.

Still stupidly wrong.

*The best selling author of theory of computation textbooks*

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D

    until H correctly determines that its simulated D would never
    stop running unless aborted then

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

Correct emulation is defined as applying the finite
string transformation rules specified by the x86
language to the input to HHH(DD).

Then HHH determines that DD would never stop running
unless aborted.

But your problem is that your Decider H doesn't meet that definition of corre3ct emulation since it stops, and it is a fact that the correectly emulated D *WILL* reach the end, because you H DOES abort and return 0.

Since H never correctly determined that it could correctly abort, the
aborting that it does has no basis to be claimed to be correct, and thus
the fact that the actual correct emulation halts shows it WAS wrong.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/26/25 5:15 PM, olcott wrote:

On 4/26/2025 3:45 PM, dbush wrote:

On 4/26/2025 4:41 PM, olcott wrote:

On 4/26/2025 3:23 PM, joes wrote:

Am Sat, 26 Apr 2025 14:46:12 -0500 schrieb olcott:

On 4/26/2025 1:22 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

The program EE(){ HHH(EE); } also halts and cannot be
simulated by
HHH.

HHH cannot possibly do this without violating the rules of the x86 >>>>>>>>> language.

HHH already violates the rules of the x86 language by prematurely >>>>>>>> aborting the halting program.

Everyone claims that HHH violates the rules of the x86 language
yet no
one can point out which rules are violated

It has been pointed out many times. It is against the rules of the >>>>>> x86
language to abort a halting function.

You remains stupidly wrong about this because you refuse to show what >>>>> step of DD is not emulated by HHH according to the finite string
transformation rules specified by the x86 language.

All instructions after the abort are not emulated.

Still stupidly wrong.

*The best selling author of theory of computation textbooks*

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D

     until H correctly determines that its simulated D would never
     stop running unless aborted then

     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

But not to what you think he agreed to:

I don't give a rat's ass about other people's
opinions of what he agreed to.

You should, becuaee you are too ignorant of the field to know what he said.

Other people keep trying to dishonesty get
away with disagreeing with the finite string
transformations specified by the x86 language.

No, you don't understand the not-stopping part of that defintion.

This seems to prove that these "other people"
are liars.

No., it proves that you are a stupid liar that can't see your own stupdity.

Note, the fact that you answer to anyone point out an error is to just
say they are wrong and repeat your position.

That is very strong evidence that you actually have no basis for your
claims but your own guesses as to what should be.

Truth can explain itself in more details. Lies hit a point when they
can't break themselves down simpler without being to obvious ablut their errors.

You have reached that point, which is why you can't actually reply to
the errors pointed out, and resort to fallacies like deflection and
asking for proofs you are wrong.

Now that I just came up with the idea that all
Turing Machine computable functions must apply
finite string transformations to their inputs
to derive their outputs

??? That is a fundamental property of the operation of a Turing Machine.
Each step of a Turing Machine does a simple finite string operation, and
these are cascaded by their algorithm to create their results.

The problem is they can ONLY do transformation that can be broken down
into those simple steps.

The stupid nonsense that HHH must report on the
direct execution of DD is conclusively proved
to be stupid nonsense.

What is wrong about that? You don't seem to understand the difference
between ability and requirements.

Of course, you have many such things you just don't understand, because
you have many fundamental errors in the basics of logic.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 26.apr.2025 om 21:45 schreef olcott:

On 4/26/2025 1:22 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot
possibly
reach its own final state in an infinite number of steps and it does >>>>>>> this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

The program EE(){ HHH(EE); } also halts and cannot be simulated by >>>>>> HHH.

HHH cannot possibly do this without violating the rules of
the x86 language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated

It has been pointed out many times. It is against the rules of the x86
language to abort a halting function.

You remains stupidly wrong about this because
you refuse to show what step of DD is not emulated
by HHH according to the finite string transformation
rules specified by the x86 language.

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

You refuse to show the incorrect step because you
know that you are clueless about the x86 language
and provide your "rebuttal" entirely on the basis
of pure bluster. In other words pure Troll behavior
on your part.

No new information, no rebuttal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 26.apr.2025 om 21:46 schreef olcott:

On 4/26/2025 1:22 PM, Fred. Zwarts wrote:

Op 26.apr.2025 om 19:28 schreef olcott:

On 4/26/2025 3:58 AM, Fred. Zwarts wrote:

Op 25.apr.2025 om 23:21 schreef olcott:

On 4/25/2025 8:56 AM, joes wrote:

Am Thu, 24 Apr 2025 19:03:34 -0500 schrieb olcott:

Mathematical induction proves that DD emulated by HHH cannot
possibly
reach its own final state in an infinite number of steps and it does >>>>>>> this with one recursive emulation.
There is a repeating pattern that every C programmer can see.

Like Fred wrote months ago, that has nothing to do with the
contradictory
part of DD,

Sure it does. The contradictory part of DD has always
been unreachable thus only a ruse.

only with it being simulated by the same simulator it calls.

That <is> the Halting Problem counter-example input.

The program EE(){ HHH(EE); } also halts and cannot be simulated by >>>>>> HHH.

HHH cannot possibly do this without violating the rules of
the x86 language.

HHH already violates the rules of the x86 language by prematurely
aborting the halting program.

Everyone claims that HHH violates the rules
of the x86 language yet no one can point out
which rules are violated

It has been pointed out many times. It is against the rules of the x86
language to abort a halting function.

You remains stupidly wrong about this because
you refuse to show what step of DD is not emulated
by HHH according to the finite string transformation
rules specified by the x86 language.

_DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

You refuse to show the incorrect step because you
know that you are clueless about the x86 language
and provide your "rebuttal" entirely on the basis
of pure bluster. In other words pure Troll behavior
on your part.

No new information. No rebuttal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)