On 2/20/25 7:25 PM, olcott wrote:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

[ .... ]

I have given everyone here all of the complete source code for a few >>>>> years

True but irrelevant. OP did not specify that HHH means that particular >>>> code.

Every post that I have been talking about for two or
more years has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting something new
and fresh.

As soon as people fully address rather than endlessly dodge
my key points I will be done.

We aren't doing a "dodge", but pointing out the fundamental error in
your statement.

Let's start with a root point.
All of the other points validate this root point.

*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Nope, since DD halts.

*According to the UTPTO patent law practice I am incorporating*
*the following paper and source-code by reference* https://www.uspto.gov/web/offices/pac/mpep/s217.html

And thus you admit that there is only one HHH in existance, and that incorrectly simulated its input of DD, since it aborts it,

Simulating Termination Analyzer H is Not Fooled by Pathological Input D https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Which just repeats your error

918-1156  // All of the lines of termination analyzer HHH
1355-1370 // DD() through main()

https://github.com/plolcott/x86utm/blob/master/Halt7.c

Which thuys say that HHH is, on only is that code, that WILL abort its emulaiton of DD, and thus the phrase "unless HHH aborts" is a lie, since
HHH can only abort, and thus an HHH that doesn't abort can not be in
view except by lying.

Sorry, your logic is inconsistent with the definition of Computation THeory.

Your refusal to see that just proves your stupidity.

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

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

Op 21.feb.2025 om 01:25 schreef olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

[ .... ]

I have given everyone here all of the complete source code for a few >>>>> years

True but irrelevant. OP did not specify that HHH means that particular >>>> code.

Every post that I have been talking about for two or
more years has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting something new
and fresh.

As soon as people fully address rather than endlessly dodge
my key points I will be done.

Let's start with a root point.
All of the other points validate this root point.

*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

It could be correct if this status was interpreted as the not-yet-halted status, because it aborts the simulation and in that way misses the
halting behaviour of the input. HHH can only report wat it sees, not
what it does not see.

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

On Thu, 20 Feb 2025 18:25:27 -0600, olcott <polcott333@gmail.com>
wrote:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

[ .... ]

I have given everyone here all of the complete source code for a few >>>>> years

True but irrelevant. OP did not specify that HHH means that particular >>>> code.

Every post that I have been talking about for two or
more years has referred to variations of that same code.

Yes. It would be a relief if you could move on to posting something new
and fresh.

As soon as people fully address rather than endlessly dodge
my key points I will be done.

Let's start with a root point.
All of the other points validate this root point.

*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

*According to the UTPTO patent law practice I am incorporating*
*the following paper and source-code by reference* >https://www.uspto.gov/web/offices/pac/mpep/s217.html

Simulating Termination Analyzer H is Not Fooled by Pathological Input D >https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

918-1156 // All of the lines of termination analyzer HHH
1355-1370 // DD() through main()

https://github.com/plolcott/x86utm/blob/master/Halt7.c

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

If you attempt to patent your so called halt decider then I will
challenge it as you are stealing my idea of returning a third result
of pathological input.

/Flibble

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

On 2/21/25 7:09 AM, Mr Flibble wrote:

On Thu, 20 Feb 2025 18:25:27 -0600, olcott <polcott333@gmail.com>
wrote:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

[ .... ]

I have given everyone here all of the complete source code for a few >>>>>> years

True but irrelevant. OP did not specify that HHH means that particular >>>>> code.

Every post that I have been talking about for two or
more years has referred to variations of that same code.

Yes. It would be a relief if you could move on to posting something new >>> and fresh.

As soon as people fully address rather than endlessly dodge
my key points I will be done.

Let's start with a root point.
All of the other points validate this root point.

*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

*According to the UTPTO patent law practice I am incorporating*
*the following paper and source-code by reference*
https://www.uspto.gov/web/offices/pac/mpep/s217.html

Simulating Termination Analyzer H is Not Fooled by Pathological Input D
https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D


918-1156 // All of the lines of termination analyzer HHH
1355-1370 // DD() through main()

https://github.com/plolcott/x86utm/blob/master/Halt7.c

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius >>>> hits a target no one else can see." Arthur Schopenhauer

If you attempt to patent your so called halt decider then I will
challenge it as you are stealing my idea of returning a third result
of pathological input.

/Flibble

He isn't claiming to be able to patent, just use the concept of
incorpoate by reference (which isn't unique to patent law).

The problem with incorporate by reference, is you need to do it at the
begining of each separate work, and you are stuck with that reference.

If HHH is defined by the reference, then it can not be changed, and thus
there is no "unless HHH aborts", since it always does.

His problem is logic doesn't accept that reality exists and things do
what they do, but he presumes that the non-happening can be assumed to
happen, and the false to be true.

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

On 2/21/25 6:09 PM, olcott wrote:

On 2/21/2025 6:21 AM, Richard Damon wrote:

On 2/21/25 7:09 AM, Mr Flibble wrote:

On Thu, 20 Feb 2025 18:25:27 -0600, olcott <polcott333@gmail.com>
wrote:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

[ .... ]

I have given everyone here all of the complete source code for a >>>>>>>> few
years

True but irrelevant. OP did not specify that HHH means that
particular
code.

Every post that I have been talking about for two or
more years has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting
something new
and fresh.

As soon as people fully address rather than endlessly dodge
my key points I will be done.

Let's start with a root point.
All of the other points validate this root point.

*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

*According to the UTPTO patent law practice I am incorporating*
*the following paper and source-code by reference*
https://www.uspto.gov/web/offices/pac/mpep/s217.html

Simulating Termination Analyzer H is Not Fooled by Pathological Input D >>>> https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D


918-1156  // All of the lines of termination analyzer HHH
1355-1370 // DD() through main()

https://github.com/plolcott/x86utm/blob/master/Halt7.c

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

If you attempt to patent your so called halt decider then I will
challenge it as you are stealing my idea of returning a third result
of pathological input.

/Flibble

He isn't claiming to be able to patent, just use the concept of
incorpoate by reference (which isn't unique to patent law).

The problem with incorporate by reference, is you need to do it at the
begining of each separate work, and you are stuck with that reference.

If HHH is defined by the reference, then it can not be changed, and
thus there is no "unless HHH aborts", since it always does.

Now no one has any excuse to say that that have no idea
of which code that I am referring to.

Of course we do, as you can't actually explain it.

Is Halt7.c part of the logic system?

If so, then you have as an established fact that HHH *WILL* abort its simulation of DD, and thus DD will be a halting program. This means any statement asking about what happens if HHH doesn't act that way is
asking about what happens in a LIE. Any results conditioned on it is
unsound and invalid.

If not, then DD isn't a program, and thus your whole arguement is built
on a fabrication.

You continue to not answer question about the basis of your claims,
because you know your basis is just lies and foolishness.

You can define HHH, then then change it, except by LYING and proving
that you just don't understand what you are talking about.

And then we have the fact, that your code you presents shows that you
have always been lying about HHH, as it isn't the REQUIRED computation /
pure function, as it DOES look at things that are clearly not part of
its "input".

And then you run into the problem that even if you fixed that, by trying
to claim that only the "C" Function for DD is the input, that isn't a
program as it depends on something outside of itself that isn't an input
(the function HHH) and HHH evalutes something that wasn't part of its
input when it traces the code after the call HHH in DD.

Sorry, you are just proving that your world is based on LIES and FRAUD
and that you have no idea how logic is supposed to work.

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

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for a few >>>>> years

True but irrelevant. OP did not specify that HHH means that
particular code.

Every post that I have been talking about for two or more years has
referred to variations of that same code.

Yes. It would be a relief if you could move on to posting something
new and fresh.

As soon as people fully address rather than endlessly dodge my key
points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

--
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 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for a few >>>>>>> years

True but irrelevant. OP did not specify that HHH means that
particular code.

Every post that I have been talking about for two or more years has
referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting something
new and fresh.

As soon as people fully address rather than endlessly dodge my key
points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man
deception aside:

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

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

On 2/22/25 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for >>>>>>>>> a few
years

True but irrelevant. OP did not specify that HHH means that
particular code.

Every post that I have been talking about for two or more years has >>>>>>> referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting something >>>>>> new and fresh.

As soon as people fully address rather than endlessly dodge my key
points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man
deception aside:

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Only because that statement is based on a false premise.

Since HHH doesn't correctly simulate its input, your statement is just
a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified*

Right, and since every instruction (except the final return) specifies
to execute the next instruction, it is NEVER a "correct simulation" to
abort the simulaition unless the instruction will cause your computer to actually lock up or self-distruct.

It cannot mean imagining a different sequence than the one that the
machine code specifies. That most people here are clueless about
x86 machine code is far less than no rebuttal at all.

Right, so the simulation of the input below requires that the call at
address 0000213c to be followed by the simulation of the contents of the
memory location 000015c3.

Since you exclude that as part of the input, such a simulation is
impossible, or at least a violtion of the requirements to be a pure
function.

If you include that memory as part of the input, then the code for HHH
is fixed, and you can't change it when asking your "what if" question,
so the "alternate HHH" needs to see that exact same input, so the
alternate HHH needs to be put at some other address, like HHH1, which
shows that the simulation of the input COULD be completed, it is just
that HHH fails to do so.

This makes you "claims" just blantent pathological lies.

_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]

When DD emulated by HHH calls HHH(DD) this call cannot
possibly return to the emulator, conclusively proving
that

Sure it can, if the emulator is a correct emulator, since the HHH that
DD calls was defined to abort its emulation and return 0.

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Assuming that it does return is simply stupid.

The problem is you base your logic on bald face lies, since your HHH
doesn't do a correct simulation.

All you are doing is proving you are an idiot, and are too stupid to see
your error.

If I was wrong, you could point out the exact point I made an error.

Your biggest problem seems to be that you don't understand the meaning
of the word "correct", but think that being wrong is allowed to still be
called correct if you can give an excuse why you couldn't do what was
needed.

Sorry, but that attitude will just get you the failing grade in life.

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

On 2025-02-23 00:45:06 +0000, olcott said:

When DD emulated by HHH calls HHH(DD) this call cannot
possibly return to the emulator,

Calls don't return to the emulator. They return to the calling
program.

--
Mikko

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

Am Sat, 22 Feb 2025 18:45:06 -0600 schrieb olcott:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for a >>>>>>>>> few years

True but irrelevant. OP did not specify that HHH means that
particular code.

Every post that I have been talking about for two or more years
has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting
something new and fresh.

As soon as people fully address rather than endlessly dodge my key
points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man deception
aside:
DD correctly simulated by HHH cannot possibly terminate normally by
reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is just
a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* It
cannot mean imagining a different sequence than the one that the machine
code specifies. That most people here are clueless about x86 machine
code is far less than no rebuttal at all.

It's not about the machine code. The machine code of HHH specifies a
sequence where simulation is aborted, but you simulate the non-input
of a non-aborting HHH. This is not the HHH that does the simulation.

When DD emulated by HHH calls HHH(DD) this call cannot possibly return
to the emulator, conclusively proving that

That's bad. A decider like HHH is supposed to return.

--
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)

Am Sun, 23 Feb 2025 11:47:44 -0600 schrieb olcott:

On 2/23/2025 5:52 AM, joes wrote:

Am Sat, 22 Feb 2025 18:45:06 -0600 schrieb olcott:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for >>>>>>>>>>> a few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>> particular code.

Every post that I have been talking about for two or more years >>>>>>>>> has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting
something new and fresh.

As soon as people fully address rather than endlessly dodge my key >>>>>>> points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man
deception aside:
DD correctly simulated by HHH cannot possibly terminate normally by
reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is
just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* It
cannot mean imagining a different sequence than the one that the
machine code specifies. That most people here are clueless about x86
machine code is far less than no rebuttal at all.

It's not about the machine code. The machine code of HHH specifies a
sequence where simulation is aborted, but you simulate the non-input of
a non-aborting HHH. This is not the HHH that does the simulation.

When DD emulated by HHH calls HHH(DD) this call cannot possibly return
to the emulator, conclusively proving that

That's bad. A decider like HHH is supposed to return.

When a decider itself is called in an infinite loop then it cannot
possibly terminate unless a version of itself its emulating this
instance of itself.
In this case the infinite loop instance MUST BE ABORTED.

A decider that aborts doesn't need to be aborted.

When DD is correctly simulated by HHH according to the behavior that the above machine code specifies then the call from DD to HHH(DD) cannot
possibly return making it impossible for DD emulated by HHH to terminate normally.

If HHH doesn't return, it is not a decider.

--
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 2/23/25 12:47 PM, olcott wrote:

On 2/23/2025 5:52 AM, joes wrote:

Am Sat, 22 Feb 2025 18:45:06 -0600 schrieb olcott:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for a >>>>>>>>>>> few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>> particular code.

Every post that I have been talking about for two or more years >>>>>>>>> has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting
something new and fresh.

As soon as people fully address rather than endlessly dodge my key >>>>>>> points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man deception >>>>> aside:
DD correctly simulated by HHH cannot possibly terminate normally by
reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is just >>>> a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* It
cannot mean imagining a different sequence than the one that the machine >>> code specifies. That most people here are clueless about x86 machine
code is far less than no rebuttal at all.

It's not about the machine code. The machine code of HHH specifies a
sequence where simulation is aborted, but you simulate the non-input
of a non-aborting HHH. This is not the HHH that does the simulation.

When DD emulated by HHH calls HHH(DD) this call cannot possibly return
to the emulator, conclusively proving that

That's bad. A decider like HHH is supposed to return.

When a decider itself is called in an infinite loop
then it cannot possibly terminate unless a version
of itself its emulating this instance of itself.

But the loop is not infinite if it is a decider.

The fact that HHH DOES abort its simulation and returns an answer means
that HHH needs to determine that answer to make the correct decision.

If it can't, then it just fails to get the right answer.

In this case the infinite loop instance MUST BE ABORTED.

_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]

When DD is correctly simulated by HHH according to the behavior
that the above machine code specifies then the call from DD
to HHH(DD) cannot possibly return making it impossible for DD
emulated by HHH to terminate normally.

But DD is NOT correctly simulated by HHH since the machine that runs DD
doesn't self-distruct at the point that HHH aborts its simulation.

Your problem is you don't undetstand the meaning of "correct" and only partially right is wrong.

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

On 2/23/25 8:17 PM, olcott wrote:

On 2/23/2025 12:21 PM, joes wrote:

Am Sun, 23 Feb 2025 11:47:44 -0600 schrieb olcott:

On 2/23/2025 5:52 AM, joes wrote:

Am Sat, 22 Feb 2025 18:45:06 -0600 schrieb olcott:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for >>>>>>>>>>>>> a few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more years >>>>>>>>>>> has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting >>>>>>>>>> something new and fresh.

As soon as people fully address rather than endlessly dodge my key >>>>>>>>> points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man
deception aside:
DD correctly simulated by HHH cannot possibly terminate normally by >>>>>>> reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is
just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* It >>>>> cannot mean imagining a different sequence than the one that the
machine code specifies. That most people here are clueless about x86 >>>>> machine code is far less than no rebuttal at all.

It's not about the machine code. The machine code of HHH specifies a
sequence where simulation is aborted, but you simulate the non-input of >>>> a non-aborting HHH. This is not the HHH that does the simulation.

When DD emulated by HHH calls HHH(DD) this call cannot possibly return >>>>> to the emulator, conclusively proving that

That's bad. A decider like HHH is supposed to return.

When a decider itself is called in an infinite loop then it cannot
possibly terminate unless a version of itself its emulating this
instance of itself.
In this case the infinite loop instance MUST BE ABORTED.

A decider that aborts doesn't need to be aborted.

When DD is correctly simulated by HHH according to the behavior that the >>> above machine code specifies then the call from DD to HHH(DD) cannot
possibly return making it impossible for DD emulated by HHH to terminate >>> normally.

If HHH doesn't return, it is not a decider.

I am only talking about termination analyzers.
Any actual code that is invoked in an actual
infinite loop will not terminate no matter what.
If anyone assumes otherwise they are clueless.

Wrong, since the DEFINITION of a termination analyser is about the
behavior of the PROGRAM that is given as the input, and when we just run
DD it will terminate noramally, then HHH is just incorrect.

The problem is that since HHH is DEFINED by its code, and that code says
it WILL abort its emulation of DD and return to its caller, it is
incorrect of HHH to assume something different, and think that the code
for the HHH that is actually there will never abort.

Your problem is you just lie to yourself about what it needs to do,
because you are so stupid you beleive your own lies, even in the face of
the truth being pointed out, because you have decide to just ignore the
truth since you are nothing but a pathological liar.

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

Am Sun, 23 Feb 2025 21:36:14 -0600 schrieb olcott:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code >>>>>>>>>>>>> for a few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more >>>>>>>>>>> years has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting >>>>>>>>>> something new and fresh.

As soon as people fully address rather than endlessly dodge my >>>>>>>>> key points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man
deception aside:
DD correctly simulated by HHH cannot possibly terminate normally >>>>>>> by reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is
just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified*
It cannot mean imagining a different sequence than the one that the
machine code specifies. That most people here are clueless about x86 >>>>> machine code is far less than no rebuttal at all.
When DD emulated by HHH calls HHH(DD) this call cannot possibly
return to the emulator, conclusively proving that
DD correctly simulated by HHH cannot possibly terminate normally by
reaching its own "return" instruction.
Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls F(0)
this call cannot possibly return to the emulator, conclusively
proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the
emulation didn't abort (but doing it by the hypothetical of NOT
changing the HHH that DD calls, since that must be the original HHH).
Your problem is you have lied to yourself about what is a "correct
emulation"

In other words you "believe" that the call from DD to HHH(DD) returns
when the above DD is emulated by HHH.
This is proven to be counter-factual by anyone that understands the
above code.

The code is wrong. The call to HHH should return, because we know that
HHH is a decider. You incorrectly turn off the abort check.

--
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 2/23/25 10:36 PM, olcott wrote:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code >>>>>>>>>>>>> for a few
years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more >>>>>>>>>>> years has
referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting >>>>>>>>>> something
new and fresh.

As soon as people fully address rather than endlessly dodge my key >>>>>>>>> points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man
deception aside:

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Only because that statement is based on a false premise.

Since HHH doesn't correctly simulate its input, your statement is
just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified*
It cannot mean imagining a different sequence than the one that the
machine code specifies. That most people here are clueless about
x86 machine code is far less than no rebuttal at all.

_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]

When DD emulated by HHH calls HHH(DD) this call cannot
possibly return to the emulator, conclusively proving
that

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls F(0)
this call cannot possibly return to the emulator, conclusively
proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the
emulation didn't abort (but doing it by the hypothetical of NOT
changing the HHH that DD calls, since that must be the original HHH).

Your problem is you have lied to yourself about what is a "correct
emulation"

In other words you "believe" that the call from DD to HHH(DD)
returns when the above DD is emulated by HHH.

What happens in an incorrect emulation doesn't matter, and since HHH
aborts its emulation, it is not a correct emulation.

What matters is what happens when we run or actually correctly simulate it.

When KNOW that it returns then, as you have posted the traces of it
happening.

That you don't beleive your own evidince shows your own stupidity, and
the level of pathology in your lying.

You literally don't know what truth is.

This is proven to be counter-factual by anyone that understands
the above code.

No, it is beleived counter-factual by people so stupid they believe
themselves over reality.

The fact that you don't even know and understand the actual meaning of
the words you use (and don't care about them) just shows that you are
nothing but a pathological liar.

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

On 2/24/25 6:38 PM, olcott wrote:

On 2/24/2025 3:32 AM, joes wrote:

Am Sun, 23 Feb 2025 21:36:14 -0600 schrieb olcott:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code >>>>>>>>>>>>>>> for a few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more >>>>>>>>>>>>> years has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting >>>>>>>>>>>> something new and fresh.

As soon as people fully address rather than endlessly dodge my >>>>>>>>>>> key points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines* >>>>>>>>>>> *the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man >>>>>>>>> deception aside:
DD correctly simulated by HHH cannot possibly terminate normally >>>>>>>>> by reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is >>>>>>>> just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* >>>>>>> It cannot mean imagining a different sequence than the one that the >>>>>>> machine code specifies. That most people here are clueless about x86 >>>>>>> machine code is far less than no rebuttal at all.
When DD emulated by HHH calls HHH(DD) this call cannot possibly
return to the emulator, conclusively proving that
DD correctly simulated by HHH cannot possibly terminate normally by >>>>>>> reaching its own "return" instruction.
Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls F(0) >>>>>> this call cannot possibly return to the emulator, conclusively
proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the
emulation didn't abort (but doing it by the hypothetical of NOT
changing the HHH that DD calls, since that must be the original HHH).
Your problem is you have lied to yourself about what is a "correct
emulation"

In other words you "believe" that the call from DD to HHH(DD) returns
when the above DD is emulated by HHH.
This is proven to be counter-factual by anyone that understands the
above code.

The code is wrong. The call to HHH should return, because we know that
HHH is a decider. You incorrectly turn off the abort check.

When you put code in an infinite loop then this code DOES NOT TERMINATE
NO MATTER WTF IT "SHOULD" DO.

What infinite loop?

It is only an infinite loop if HHH fails to meet the requirements to be
a decider.

Thus, your claims are based on LIES.

Your HHH avoids the infinite loop by aborting it emulation, but then,
since it doesn't have the answer to the behavior, it guesses, and
guesses wrong.

Sorry, you are just being caught in your lies.

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

On 2/24/25 7:06 PM, olcott wrote:

On 2/24/2025 6:16 AM, Richard Damon wrote:

On 2/23/25 10:36 PM, olcott wrote:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source >>>>>>>>>>>>>>> code for a few
years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more >>>>>>>>>>>>> years has
referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting >>>>>>>>>>>> something
new and fresh.

As soon as people fully address rather than endlessly dodge >>>>>>>>>>> my key
points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines* >>>>>>>>>>> *the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man >>>>>>>>> deception aside:

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Only because that statement is based on a false premise.

Since HHH doesn't correctly simulate its input, your statement >>>>>>>> is just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* >>>>>>> It cannot mean imagining a different sequence than the one that
the machine code specifies. That most people here are clueless about >>>>>>> x86 machine code is far less than no rebuttal at all.

_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]

When DD emulated by HHH calls HHH(DD) this call cannot
possibly return to the emulator, conclusively proving
that

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls
F(0) this call cannot possibly return to the emulator,
conclusively proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the
emulation didn't abort (but doing it by the hypothetical of NOT
changing the HHH that DD calls, since that must be the original HHH).

Your problem is you have lied to yourself about what is a "correct
emulation"

In other words you "believe" that the call from DD to HHH(DD)
returns when the above DD is emulated by HHH.

What happens in an incorrect emulation doesn't matter,

One to infinity steps of the above DD emulated by HHH never
terminates normally. That you imagine that this code "should"
do something other than what it specifies is quite stupid.

INVALID, as you are changing your input, or the input isn't a program.

For any instance of the question, there can be one and only one HHH, and
one and only one DD.

If the HHH(DD) returns 0, then there is a finite number of steps of
correct emulation (more than what HHH did) that will show that DD is
halting.

Thus, your claim is invalid, your logic proben to be unsound, and you to
be proven stupid.

Sorry, Strawmen are not allowed, and changing the input with an attempt
at slight-of-hand just proves you are nothing but a fraud.

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

On 2/24/25 8:16 PM, olcott wrote:

On 2/24/2025 6:04 PM, Richard Damon wrote:

On 2/24/25 6:38 PM, olcott wrote:

On 2/24/2025 3:32 AM, joes wrote:

Am Sun, 23 Feb 2025 21:36:14 -0600 schrieb olcott:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code >>>>>>>>>>>>>>>>> for a few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more >>>>>>>>>>>>>>> years has referred to variations of that same code. >>>>>>>>>>>>>> Yes.  It would be a relief if you could move on to posting >>>>>>>>>>>>>> something new and fresh.

As soon as people fully address rather than endlessly dodge my >>>>>>>>>>>>> key points I will be done.

Honestly, you're gonna die first, one way or the other. >>>>>>>>>>>>

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines* >>>>>>>>>>>>> *the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man >>>>>>>>>>> deception aside:
DD correctly simulated by HHH cannot possibly terminate normally >>>>>>>>>>> by reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is >>>>>>>>>> just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* >>>>>>>>> It cannot mean imagining a different sequence than the one that >>>>>>>>> the
machine code specifies. That most people here are clueless
about x86
machine code is far less than no rebuttal at all.
When DD emulated by HHH calls HHH(DD) this call cannot possibly >>>>>>>>> return to the emulator, conclusively proving that
DD correctly simulated by HHH cannot possibly terminate
normally by
reaching its own "return" instruction.
Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls F(0) >>>>>>>> this call cannot possibly return to the emulator, conclusively >>>>>>>> proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the
emulation didn't abort (but doing it by the hypothetical of NOT
changing the HHH that DD calls, since that must be the original HHH). >>>>>> Your problem is you have lied to yourself about what is a "correct >>>>>> emulation"

In other words you "believe" that the call from DD to HHH(DD) returns >>>>> when the above DD is emulated by HHH.
This is proven to be counter-factual by anyone that understands the
above code.

The code is wrong. The call to HHH should return, because we know that >>>> HHH is a decider. You incorrectly turn off the abort check.

When you put code in an infinite loop then this code DOES NOT TERMINATE
NO MATTER WTF IT "SHOULD" DO.

What infinite loop?

If an arbitrary decider is placed in any
infinite loop then IT WILL NOT TERMINATE
NO MATTER WTF ITS SUPPOSED TO DO.

Sure it will, an infinite number of times, once for each call to it.

Now, show me the "loop", since DD doesn't repeatedly call HHH, and has
no loop until after the call, and that never gets back to the call.

I guess you are just showing how STUPID you are to not know what you are talking about.

It is only an infinite loop if HHH fails to meet the requirements to
be a decider.

Thus, your claims are based on LIES.

Your HHH avoids the infinite loop by aborting it emulation, but then,
since it doesn't have the answer to the behavior, it guesses, and
guesses wrong.

Sorry, you are just being caught in your lies.

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

Op 25.feb.2025 om 01:06 schreef olcott:

On 2/24/2025 6:16 AM, Richard Damon wrote:

On 2/23/25 10:36 PM, olcott wrote:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source >>>>>>>>>>>>>>> code for a few
years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>>>>>> particular code.

Every post that I have been talking about for two or more >>>>>>>>>>>>> years has
referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting >>>>>>>>>>>> something
new and fresh.

As soon as people fully address rather than endlessly dodge >>>>>>>>>>> my key
points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines* >>>>>>>>>>> *the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man >>>>>>>>> deception aside:

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Only because that statement is based on a false premise.

Since HHH doesn't correctly simulate its input, your statement >>>>>>>> is just a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* >>>>>>> It cannot mean imagining a different sequence than the one that
the machine code specifies. That most people here are clueless about >>>>>>> x86 machine code is far less than no rebuttal at all.

_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]

When DD emulated by HHH calls HHH(DD) this call cannot
possibly return to the emulator, conclusively proving
that

DD correctly simulated by HHH cannot possibly terminate
normally by reaching its own "return" instruction.

Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls
F(0) this call cannot possibly return to the emulator,
conclusively proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the
emulation didn't abort (but doing it by the hypothetical of NOT
changing the HHH that DD calls, since that must be the original HHH).

Your problem is you have lied to yourself about what is a "correct
emulation"

In other words you "believe" that the call from DD to HHH(DD)
returns when the above DD is emulated by HHH.

What happens in an incorrect emulation doesn't matter,

One to infinity steps of the above DD emulated by HHH never
terminates normally.

Which proves that simulation is not the way to go for a halting decider, because it always fails to reach the normal termination of the halting
program when simulating itself.

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

Op 23.feb.2025 om 18:47 schreef olcott:

On 2/23/2025 5:52 AM, joes wrote:

Am Sat, 22 Feb 2025 18:45:06 -0600 schrieb olcott:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott:

On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source code for a >>>>>>>>>>> few years

True but irrelevant. OP did not specify that HHH means that >>>>>>>>>> particular code.

Every post that I have been talking about for two or more years >>>>>>>>> has referred to variations of that same code.

Yes.  It would be a relief if you could move on to posting
something new and fresh.

As soon as people fully address rather than endlessly dodge my key >>>>>>> points I will be done.

Honestly, you're gonna die first, one way or the other.

Let's start with a root point.
All of the other points validate this root point.
*Simulating termination analyzer HHH correctly determines*
*the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man deception >>>>> aside:
DD correctly simulated by HHH cannot possibly terminate normally by
reaching its own "return" instruction.

Only because that statement is based on a false premise.
Since HHH doesn't correctly simulate its input, your statement is just >>>> a fabrication of your imagination.

*Correct simulation means emulates the machine code as specified* It
cannot mean imagining a different sequence than the one that the machine >>> code specifies. That most people here are clueless about x86 machine
code is far less than no rebuttal at all.

It's not about the machine code. The machine code of HHH specifies a
sequence where simulation is aborted, but you simulate the non-input
of a non-aborting HHH. This is not the HHH that does the simulation.

When DD emulated by HHH calls HHH(DD) this call cannot possibly return
to the emulator, conclusively proving that

That's bad. A decider like HHH is supposed to return.

When a decider itself is called in an infinite loop
then it cannot possibly terminate unless a version
of itself its emulating this instance of itself.

Olcott is dreaming of an infinite loop again. There is no infinite loop.
The direct execution of the program halts, proving that there is no
infinite loop, no infinite recursion and no infinite recursive
simulation. The problem with Olcott's simulator is that as soon as it
sees one recursion, it thinks that it is an infinite recursion.
That is incorrect. This error makes the program a halting program.
Correcting this error will not help, because Olcott is trying to do the logically impossible. Just as every attempt to draw a square circle will
have an error and fixing that error only introduces another error.
Similarly every attempt to make HHH correctly simulate itself will
always have an error, because it is not logically possible for HHH to
correctly simulate itself.

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

On 2/24/25 11:09 PM, olcott wrote:

On 2/24/2025 10:02 PM, Richard Damon wrote:

On 2/24/25 8:16 PM, olcott wrote:

On 2/24/2025 6:04 PM, Richard Damon wrote:

On 2/24/25 6:38 PM, olcott wrote:

On 2/24/2025 3:32 AM, joes wrote:

Am Sun, 23 Feb 2025 21:36:14 -0600 schrieb olcott:

On 2/23/2025 8:50 PM, Richard Damon wrote:

On 2/23/25 12:32 PM, olcott wrote:

On 2/22/2025 8:41 PM, dbush wrote:

On 2/22/2025 7:45 PM, olcott wrote:

On 2/22/2025 6:02 PM, Richard Damon wrote:

On 2/22/25 11:52 AM, olcott wrote:

On 2/22/2025 5:05 AM, joes wrote:

Am Thu, 20 Feb 2025 18:25:27 -0600 schrieb olcott: >>>>>>>>>>>>>>> On 2/20/2025 4:38 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 2/20/2025 2:38 AM, Mikko wrote:

On 2025-02-20 00:31:33 +0000, olcott said:

I have given everyone here all of the complete source >>>>>>>>>>>>>>>>>>> code
for a few years

True but irrelevant. OP did not specify that HHH means >>>>>>>>>>>>>>>>>> that
particular code.

Every post that I have been talking about for two or more >>>>>>>>>>>>>>>>> years has referred to variations of that same code. >>>>>>>>>>>>>>>> Yes.  It would be a relief if you could move on to posting >>>>>>>>>>>>>>>> something new and fresh.

As soon as people fully address rather than endlessly >>>>>>>>>>>>>>> dodge my
key points I will be done.

Honestly, you're gonna die first, one way or the other. >>>>>>>>>>>>>>

Let's start with a root point.
All of the other points validate this root point. >>>>>>>>>>>>>>> *Simulating termination analyzer HHH correctly determines* >>>>>>>>>>>>>>> *the non-halt status of DD*

Since DD halts, that's dead in the water.

Despicably intentionally dishonest attempts at the straw-man >>>>>>>>>>>>> deception aside:
DD correctly simulated by HHH cannot possibly terminate >>>>>>>>>>>>> normally
by reaching its own "return" instruction.

Only because that statement is based on a false premise. >>>>>>>>>>>> Since HHH doesn't correctly simulate its input, your
statement is
just a fabrication of your imagination.

*Correct simulation means emulates the machine code as
specified*
It cannot mean imagining a different sequence than the one >>>>>>>>>>> that the
machine code specifies. That most people here are clueless >>>>>>>>>>> about x86
machine code is far less than no rebuttal at all.
When DD emulated by HHH calls HHH(DD) this call cannot possibly >>>>>>>>>>> return to the emulator, conclusively proving that
DD correctly simulated by HHH cannot possibly terminate
normally by
reaching its own "return" instruction.
Assuming that it does return is simply stupid.

Similarly, when no_numbers_greater_than_10 emulated by F calls >>>>>>>>>> F(0)
this call cannot possibly return to the emulator, conclusively >>>>>>>>>> proving that

Not true. The stack eventually unwinds after ten emulations.

Just like a CORRECT emulation of DD would if the HHH doing the >>>>>>>> emulation didn't abort (but doing it by the hypothetical of NOT >>>>>>>> changing the HHH that DD calls, since that must be the original >>>>>>>> HHH).
Your problem is you have lied to yourself about what is a "correct >>>>>>>> emulation"

In other words you "believe" that the call from DD to HHH(DD)
returns
when the above DD is emulated by HHH.
This is proven to be counter-factual by anyone that understands the >>>>>>> above code.

The code is wrong. The call to HHH should return, because we know
that
HHH is a decider. You incorrectly turn off the abort check.

When you put code in an infinite loop then this code DOES NOT
TERMINATE
NO MATTER WTF IT "SHOULD" DO.

What infinite loop?

If an arbitrary decider is placed in any
infinite loop then IT WILL NOT TERMINATE
NO MATTER WTF ITS SUPPOSED TO DO.

Sure it will, an infinite number of times, once for each call to it.

Joes did not seem to understand that.

So, why do you claim that DD puts HHH into an infinite loop?

Your problem is you can't think about what you yourself say, because you
don't want to see your error.

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