XPost: sci.logic

On 7/13/24 4:15 PM, olcott wrote:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
  HERE: goto HERE;
}

void Infinite_Recursion()
{
  Infinite_Recursion();
}

void DDD()
{
  HHH(DDD);
}

int main()
{
  HHH(Infinite_Loop);
  HHH(Infinite_Recursion);
  HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

And, if this HHH does abort is simulation, then it doesn't NEED to be
aborted as the DDD that it is simulating has been paired with that
aborting HHH, so, if THIS input (still paired to that HHH that aborts)
is given to a FULL simulator that doesn't abort, it will simulate DDD
calling HHH(DDD), then that HHH simulating its input for a while, and
then deciding to abort (since that is what you claimd that HHH did) and
return to the DDD that is being simulated and that DDD will return,

Thus, the HHH that aborts doesn't need to abort because it was paired
with an input that calls a copy of it that will do the same thing and
when fully simulated will return.

Your problem is your program structure doesn't allow the operation you
try to do of arguing about changing the base HHH, as that ILLEGALLY
changes the input program.

For the first two inputs, we don't have that problem, as changing HHH
doesn't change the code in the program of the input (or at least not in
a way that affects its behavior, only unreferenced code in memory).

You just don't understand the rules of the system you are trying to work
in so you make the rookie errors that a littile bit of study could have
saved your DECADES of errors.

Sorry, you logic just is broken because you have brainwashed yourself to believe your lies, which is why your "defense" just keeps repeating the
smme lies as you have nothing under them to go more basic on, as that
will just reveal how badly you are just lyimg.

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

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
HERE: goto HERE;
}

void Infinite_Recursion()
{
Infinite_Recursion();
}

void DDD()
{
HHH(DDD);
}

int main()
{
HHH(Infinite_Loop);
HHH(Infinite_Recursion);
HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does, as can be verified by running

#include <stdio.h>
int main(void) {
printf("calling HHH(DDD)\n");
HHH(DDD);
printf("HHH(DDD) halted\n");
printf("calling DDD()\n");
DDD();
printf("DDD halted\n");
return 0;
}

--
Mikko

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

On 7/14/24 10:38 AM, olcott wrote:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if
HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

But if HHH does abort and return 0, then the full correct simulaton of
the input DDD (which need to include that HHH that aborted at the
address) will halt, HHH did not "need" to abort.

The fact that the HHH the doesn't abort when given the DDD paired with
it doesn't count, as that DDD is a DIFFERENT DDD, as it includes the HHH
that it called, which is different.

Trying to exclude the HHH from the definiton of DDD just means that DDD
is now NOT a program, and thus isn't a valid input for a Halt Decider.
(The act of the input accessing something outside what it has been
defined to have makes it invalid, and if you include that code, it is
part of the input, even if not shown explicitily, as part of the
conversion of the subjective question to an objective question which
deciders are defined to handle).

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

On 7/14/24 7:22 PM, olcott wrote:

On 7/14/2024 4:41 PM, Richard Damon wrote:

On 7/14/24 10:38 AM, olcott wrote:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if
HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

But if HHH does abort

int x = 5;
int y = 3;
if (x > y) // *before abort*
{
  printf("x > y is necessarily true\n");
  y = 2 * x;  // *after abort*
}

Red Hering, showin your utter stupidity.

The behavior of a given DDD (as determined by its full code) is fixed an immutable and HHH can;t "change" it.

Note, a given HHH has fixed behavior, and that establishes the behavior
of the DDD that calls it.

THus, if this HHH aborts its simulation, it was always going to abort
its simulation and always will abort its simulation, and thus every DDD
that calls that HHH will be returned to and it will halt.

You just don't seem to understand the basic definition of a program, and
seem to want to give them volition and mutability, things programs don't
have.

Of course, you have also admitted that your whole system is based on the
LIE that your setup actually is equivalent to the proofs you are trying
to rebute, when you admit they are not as you want DDD to not actually
be considered to include the code of HHH as part of itself, so you never
were actually talking about actual programs, but some undefined abomination.

THAT shows your total depravity about truth and logic.

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

On 7/14/24 7:57 PM, olcott wrote:

On 7/14/2024 6:46 PM, Richard Damon wrote:

On 7/14/24 7:22 PM, olcott wrote:

On 7/14/2024 4:41 PM, Richard Damon wrote:

On 7/14/24 10:38 AM, olcott wrote:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if
HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

But if HHH does abort

int x = 5;
int y = 3;
if (x > y) // *before abort*
{
   printf("x > y is necessarily true\n");
   y = 2 * x;  // *after abort*
}

Red Hering, showin your utter stupidity.

In other words giving up on you was the correct thing
to do. You have proven to be incorrigible when you
consistently deny tautologies.

No, you dont have tautologies, but LIE based on changing the meaning of
words.

You seem to think that programs cam actually CHOOSE what they will do
and can change that based on "something". That just shows your utter
ignorance of what you are talking about.

You have admitted that you are considering the input to HHH to be
something that doesn't actually meet the definition of a program, again, showing you utter stupidity.

You have claimed "verified facts" that you can not show that they are
actually true, and that just seems to mean something you think must be true.

You have admitted that you logic is just nonsense by claiming to have a "Diagonalization Proof" that shows that Godel is incorrect, and then
when asked for that proof you said that Diagonaization proof were nonsense.

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

On 7/14/24 9:27 PM, olcott wrote:

On 7/14/2024 7:30 PM, Richard Damon wrote:

On 7/14/24 7:57 PM, olcott wrote:

On 7/14/2024 6:46 PM, Richard Damon wrote:

On 7/14/24 7:22 PM, olcott wrote:

On 7/14/2024 4:41 PM, Richard Damon wrote:

On 7/14/24 10:38 AM, olcott wrote:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if >>>>>>>> HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

But if HHH does abort

int x = 5;
int y = 3;
if (x > y) // *before abort*
{
   printf("x > y is necessarily true\n");
   y = 2 * x;  // *after abort*
}

Red Hering, showin your utter stupidity.

In other words giving up on you was the correct thing
to do. You have proven to be incorrigible when you
consistently deny tautologies.

No, you dont have tautologies,

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and thus,
if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function
DDD proper then you are just admitting that you are nothing more than a
lying idiot that doesn't understand the problem, and who refuses to
understand the problem, and that EVERYTHING you have said over the years
has been based on a LIE that your problem has been setup as an
equivelent to the proofs you want to try to refute.


YOU ARE NOTHING BUT A STUPID LIAR.

but LIE based on changing the meaning of words.

That is what you have been doing.

Nope YOU are the one that has been changing the meaning of the words, as
you don't use them with the meaning they have in the field.

That makes YOU the liar.

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

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted.
And if the input specifies that its input is aborted then the behaviour
is not non-terminating.

--
Mikko

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

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function
DDD proper then you are just admitting that you are nothing more than a
lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing machine. That way a Turing machine can say someting about another Turing machine, even simulate its complete execution. Or it can count something simple like the number of states or the set of symbols that the described Turing machine may write but not erase. But there are questions that no Turing machine can
answer from a description of another Turing machine.

--
Mikko

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

Am Sun, 14 Jul 2024 22:41:24 -0500 schrieb olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of
simulating termination analyzer HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

Specifically, the input HHH aborts.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function
DDD proper then you are just admitting that you are nothing more than a
lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on
other Turing machines *dumbo*

Don't deflect. HHH as part of DDD (because it is called) needs to be
included in the input to the simulator.
Bedsides, TMs can be encoded as strings. Notwithstanding that HHH is not
and does not simulate a TM.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/14/24 11:41 PM, olcott wrote:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the
function DDD proper then you are just admitting that you are nothing
more than a lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

But they can operate on REPRESENTATIONS of Turing Machines, just like
ALL processing machines work on representations for almost everything
they do.

But, the representation needs to include ALL the relevant information
about the thing that is being represented, so, when representing a
program to a program, you need to include representations of ALL the
code of that program that is needed to run it.

YOU seem to be the flying elephant.

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

Am Mon, 15 Jul 2024 07:34:39 -0500 schrieb olcott:

On 7/15/2024 4:03 AM, joes wrote:

Am Sun, 14 Jul 2024 22:41:24 -0500 schrieb olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of
simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

Specifically, the input HHH aborts.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the
function DDD proper then you are just admitting that you are nothing
more than a lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on
other Turing machines *dumbo*

Don't deflect. HHH as part of DDD (because it is called) needs to be
included in the input to the simulator.
Bedsides, TMs can be encoded as strings. Notwithstanding that HHH is
not and does not simulate a TM.

Richard insists that HHH report on the behavior of the TM that is *not* encoded as finite string. TM's are not allowed to report on the behavior
of the computation that they are contained within.

What TM do you mean? They can all be encoded.
TMs CAN report on their input, if we arrange for it to be the same as
their environment.

The question is not whether or not HHH halts.
The question is does the finite string input to HHH mathematically map
to behavior that halts

And the answer is yes, as you have agreed.

when DDD is correctly emulated by HHH according
to the semantics of the x86 language?

If HHH can't map it, it is not simulating correctly.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Am Mon, 15 Jul 2024 08:26:22 -0500 schrieb olcott:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

int main()
{
   HHH(Infinite_Loop); HHH(Infinite_Recursion);
   HHH(DDD);
}
Any input that must be aborted to prevent the non termination of HHH >>>>> necessarily specifies non-halting behavior or it would never need to >>>>> be aborted.

Everyone understands that DDD specifies a halting behaviour if
HHH(DDD) does,

*You can comprehend this is a truism or fail to* *comprehend it
disagreement is necessarily incorrect* Any input that must be aborted
to prevent the non termination of HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

That the input is aborted does not mean that the input must be aborted.

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH.

Only if it does not terminate by itself.

And if the input specifies that its input is aborted then the behaviour
is not non-terminating.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Op 15.jul.2024 om 14:48 schreef olcott:

On 7/15/2024 6:09 AM, Richard Damon wrote:

On 7/14/24 10:33 PM, olcott wrote:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

Nope, the "input" needs to define everything that varies from one
question to another,

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

But the simulation of HHH does not need to be aborted. Because it aborts
and halts by itself.

DDD has nothing to do with it. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

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

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a
string of bytes, but an address (00002163). This points to the starting
of the code of DDD. But a simulation needs a program, not a function
calling undefined other functions. Therefore, all functions called by
DDD (such as HHH) are included in the code to simulate.

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

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of
simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.
The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the
function DDD proper then you are just admitting that you are nothing
more than a lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on
other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing
machine.

No that is wrong. The finite string must encode a Turing machine.

Same difference.

That way a Turing machine can say someting about another Turing
machine,

Not exactly. It can only report on the behavior that the input finite
string specifies.

Which is that other TM.

even simulate its complete execution. Or it can count something simple
like the number of states or the set of symbols that the described
Turing machine may write but not erase. But there are questions that no
Turing machine can answer from a description of another Turing machine.

All of the questions that a TM cannot answer are logical impossibilities

Not true. Some interesting questions are undecidable.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/15/24 8:34 AM, olcott wrote:

On 7/15/2024 4:03 AM, joes wrote:

Am Sun, 14 Jul 2024 22:41:24 -0500 schrieb olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of
simulating termination analyzer HHH necessarily specifies non-halting >>>>> behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

Specifically, the input HHH aborts.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function >>>> DDD proper then you are just admitting that you are nothing more than a >>>> lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on
other Turing machines *dumbo*

Don't deflect. HHH as part of DDD (because it is called) needs to be
included in the input to the simulator.
Bedsides, TMs can be encoded as strings. Notwithstanding that HHH is not
and does not simulate a TM.

Richard insists that HHH report on the behavior of the TM that
is *not* encoded as finite string. TM's are not allowed to report
on the behavior of the computation that they are contained within.

Why ISN'T it encoded in the finite string?

Isn't that what HHH(DDD) MEANS? that the input is supposed to encode the program DDD?

So, since to be the TM equivalent, the input to HHH WOULD be the
encoding of DDD, then HHH can surely be asked to report on its behavior.

You are just showing you are nothing but a lying blowhard.

The question is not whether or not HHH halts.

No, but DDD Halts if and only if HHH(DDD) halts

The question is does the finite string input to HHH mathematically
map to behavior that halts when DDD is correctly emulated by HHH
according to the semantics of the x86 language?

No, as DDD needs to be a PROGRAM, which means it maps to behavior
reguardless of what HHH's simulation says.

Now, DDD is dependent on the code of HHH, so we don't have a DDD until
you choose have HHH is, and it also means that the input that shows DDD
must include all of the code that DDD uses, including that of HHH , or
you are just showing that you are a LIAR.

Your problem is you chose a game where you must go first, and second
player wins, and you are trying to change things so you go second, but
that breaks the rules.

You are just stuck with your LIES.

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

On 7/15/24 4:56 PM, olcott wrote:

On 7/15/2024 3:51 PM, joes wrote:

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of >>>>>>> simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.
The input to HHH is ALL of the memory that it would be accessed in a >>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>> thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the
function DDD proper then you are just admitting that you are nothing >>>>>> more than a lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on >>>>> other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing
machine.

No that is wrong. The finite string must encode a Turing machine.

Same difference.

Not at all. The huge mistake of all these years is that
people stupidly expected that HHH to report on the behavior
of its own executing Turing machine. The theory of computation
forbids that.

WHERE?

Another of you obvious lies, just like your diagonalization proof that
you admitted was just nonsense.

You have shown you don't know Jack about computation theory, just as you
don't know anything about how logic works, or what Truth is.

You have made up your own fantasy of what you think all of it means and
just ignore the reality.

This is basically the proof of your insanity.

That way a Turing machine can say someting about another Turing
machine,

Not exactly. It can only report on the behavior that the input finite
string specifies.

Which is that other TM.

even simulate its complete execution. Or it can count something simple >>>> like the number of states or the set of symbols that the described
Turing machine may write but not erase. But there are questions that no >>>> Turing machine can answer from a description of another Turing machine. >>> All of the questions that a TM cannot answer are logical impossibilities

Not true. Some interesting questions are undecidable.

It is a despicable lie that it even be called "undecidable".
It is like no one can "make up their mind" about the square
root of a dead rat.

Just shows you don't know the meaning of the words.

Your are just STUPID LIAR

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

Op 15.jul.2024 om 21:40 schreef olcott:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a
string of bytes, but an address (00002163). This points to the
starting of the code of DDD. But a simulation needs a program, not a
function calling undefined other functions. Therefore, all functions
called by DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

It seems that olcott does not understand the x86 language.
The input for HHH is an address, not a finite string. Nowhere does this
address specify that it is meant to be interpreted as a finite string.
There is no length specification, it is only the address of DDD in the
middle of an address space. So, HHH has access to the whole address space.
The parameter, therefore, must be interpreted only as a starting point
of the program and does nowhere exclude other addresses in this address
space. In particular, the functions called by DDD are included in the
address space given to HHH. Including address 000015c3.
Unbelievable that someone who blames other people for not knowing x86
makes such an error when reading x86.

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

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

You have already said that a decider is not allowed to answer anything
other than its input. Now you say that the the program at 15c3 is not
a part of the input. Therefore a decider is not allowed consider it
even to the extent to decide whether it ever returns. But without that knowledge it is not possible to determine whether DDD halts.

--
Mikko

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

On 2024-07-15 13:51:14 +0000, olcott said:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a
correct simulation of DDD, which includes all the codd of HHH, and
thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function >>>> DDD proper then you are just admitting that you are nothing more than a >>>> lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing machine.

No that is wrong. The finite string must encode a Turing machine.

That you agree does not mean that it is wrong.

--
Mikko

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

On 2024-07-15 20:56:21 +0000, olcott said:

On 7/15/2024 3:51 PM, joes wrote:

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of >>>>>>> simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.
The input to HHH is ALL of the memory that it would be accessed in a >>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>> thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the
function DDD proper then you are just admitting that you are nothing >>>>>> more than a lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on >>>>> other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing
machine.

No that is wrong. The finite string must encode a Turing machine.

Same difference.

Not at all. The huge mistake of all these years is that
people stupidly expected that HHH to report on the behavior
of its own executing Turing machine.

No, the error is that HHH report on its own behavour instead of the
behaviour specified by its inputs. Nobody expects that your programs
do anything interesting or useful.

--
Mikko

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

Am Mon, 15 Jul 2024 15:56:21 -0500 schrieb olcott:

On 7/15/2024 3:51 PM, joes wrote:

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of >>>>>>> simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.
The input to HHH is ALL of the memory that it would be accessed in >>>>>> a correct simulation of DDD, which includes all the codd of HHH,
and thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the
function DDD proper then you are just admitting that you are
nothing more than a lying idiot that doesn't understand the
problem,

Turing machines only operate on finite strings they do not operate
on other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing
machine.

No that is wrong. The finite string must encode a Turing machine.

Same difference.

Not at all. The huge mistake of all these years is that people stupidly expected that HHH to report on the behavior of its own executing Turing machine. The theory of computation forbids that.

Encoding = description.
HHH isn't executed by anything. It simply reports on a string that
represents itself.

That way a Turing machine can say someting about another Turing
machine,

Not exactly. It can only report on the behavior that the input finite
string specifies.

Which is that other TM.

Do you agree?

even simulate its complete execution. Or it can count something
simple like the number of states or the set of symbols that the
described Turing machine may write but not erase. But there are
questions that no Turing machine can answer from a description of
another Turing machine.

All of the questions that a TM cannot answer are logical
impossibilities

Not true. Some interesting questions are undecidable.

It is a despicable lie that it even be called "undecidable". It is like
no one can "make up their mind" about the square root of a dead rat.

You may dislike the term; it means there is no program that gives
the answer for every input.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted.

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH.

That is not an acceptable axiom. That you are unable to prove that
either XXX is aborted or HHH does not terminate is insufficient
reason to call it an axiom.

From the fact that XXX must be aborted we can conclude that XXX must be aborted.

Nothing that contains the word "must" is a fact.

I can't see how you were simply not flat out dishonest.

That you cannot do something without being dishoest does not prevent us.

--
Mikko

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

On 7/16/24 3:28 AM, Fred. Zwarts wrote:

Op 15.jul.2024 om 21:40 schreef olcott:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a
string of bytes, but an address (00002163). This points to the
starting of the code of DDD. But a simulation needs a program, not a
function calling undefined other functions. Therefore, all functions
called by DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

It seems that olcott does not understand the x86 language.
The input for HHH is an address, not a finite string. Nowhere does this address specify that it is meant to be interpreted as a finite string.
There is no length specification, it is only the address of DDD in the
middle of an address space. So, HHH has access to the whole address space. The parameter, therefore, must be interpreted only as a starting point
of the program and does nowhere exclude other addresses in this address space. In particular, the functions called by DDD are included in the
address space given to HHH. Including address 000015c3.
Unbelievable that someone who blames other people for not knowing x86
makes such an error when reading x86.

He says that it is just that string because he thinks he gets to make
the rules. All that does is make him a LIAR.

Either the input is the whole program DDD, and the claim that string is
the whole input is a lie, or the input is just that string, and the
claim that it represents the whole program is a lie.

Either way, he is just demonstrating that his idea of logic is to see
who can tell the biggest lie and convince someone, only he has lost
because everyone sees through his lies, and he has said them so many
times everyone knows that everything he says just needs to be treated as
a lie, even if they might happen to be true, that is just a mistake,

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

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a
string of bytes, but an address (00002163). This points to the
starting of the code of DDD. But a simulation needs a program, not a
function calling undefined other functions. Therefore, all functions
called by DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite
string. When you say that a finite string *is not* a finite
string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of another.
It is the fact that DDD calls HHH(DDD) in recursive emulation
that makes it impossible for DDD correctly emulated by HHH to halt.

Everyone disagrees with this entirely on the basis of the strawman
deception (damned lie) that some other DDD somewhere else has
different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts
because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD
are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has
already been aborted is the same as the state of being hungry
changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not change.

HHH's idea of needing to abort evolves, but since HHH WILL halt its
emulation becuase of its code (assuming we are talking about one of the
HHH that does abort) it NEVER "needed" to abort, but will.

You are just showing your total ignorance of how programs work.

DDD *IS* a halting program as soon as you make your HHH that will abort
it, and then make that DDD. We don't KNOW that HHH will abort it until
we run it (or simulate it in some way), and then we see that HHH makes
what turns out to be an INCORRECT decision, because it use FAULTY logic
(the only kind you know it seems) to make its decision. We KNOW the
decision is incorrect when we run or simulate (fully) that DDD, or just
use proper logic, knowing that DDD will halt if and only if HHH halts,
so HHH saying non-halting for the DDD input can never be correct.

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

Am Tue, 16 Jul 2024 08:50:12 -0500 schrieb olcott:

On 7/16/2024 3:17 AM, joes wrote:

Am Mon, 15 Jul 2024 15:56:21 -0500 schrieb olcott:

On 7/15/2024 3:51 PM, joes wrote:

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Turing machines only operate on finite strings they do not operate >>>>>>> on other Turing machines *dumbo*

That's right. But the finite string can be a description of a
Turing machine.

No that is wrong. The finite string must encode a Turing machine.

Same difference.

Not at all. The huge mistake of all these years is that people
stupidly expected that HHH to report on the behavior of its own
executing Turing machine. The theory of computation forbids that.

Encoding = description.
HHH isn't executed by anything.

// HHH is not allowed to report on this DDD int main() { DDD(); }
invokes HHH(DDD);

The outer DDD? HHH doesn't report on that. That DDD isn't even a TM
that executes (simulates) HHH.

It simply reports on a string that represents itself.

That way a Turing machine can say someting about another Turing
machine,

Not exactly. It can only report on the behavior that the input
finite string specifies.

Which is that other TM.

Do you agree?

even simulate its complete execution. Or it can count something
simple like the number of states or the set of symbols that the
described Turing machine may write but not erase. But there are
questions that no Turing machine can answer from a description of
another Turing machine.

All of the questions that a TM cannot answer are logical
impossibilities

Not true. Some interesting questions are undecidable.

It is a despicable lie that it even be called "undecidable". It is
like no one can "make up their mind" about the square root of a dead
rat.

You may dislike the term; it means there is no program that gives the
answer for every input.

The term "undecidable input" incorrectly cites the decider as the source
of the issue instead of rejecting incorrect input.
The problem is that no program gives the answer whether a
self-contradictory input is true or false because the correct answer is neither. It isn't that the decider "couldn't make up ts mind" it is that
the input was invalid.

The counterexample input has a well-defined halting status determined
by the decider that it calls.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Op 16.jul.2024 om 15:41 schreef olcott:

On 7/16/2024 2:28 AM, Fred. Zwarts wrote:

Op 15.jul.2024 om 21:40 schreef olcott:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a
string of bytes, but an address (00002163). This points to the
starting of the code of DDD. But a simulation needs a program, not a
function calling undefined other functions. Therefore, all functions
called by DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

It seems that olcott does not understand the x86 language.
The input for HHH is an address, not a finite string.

This is such a terribly incorrect reply that I am ignoring it. Try again

In your poor English it means: "I do not know an answer for it.".
It is a simple, easily verifiable fact. Anyone who disagrees should
start a beginner's course in the x86 language.

The input for HHH is an address, not a finite string. Nowhere does this
address specify that it is meant to be interpreted as a finite string.
There is no length specification, it is only the address of DDD in the
middle of an address space. So, HHH has access to the whole address space.
The parameter, therefore, must be interpreted only as a starting point
of the program and does nowhere exclude other addresses in this address
space. In particular, the functions called by DDD are included in the
address space given to HHH. Including address 000015c3.
Unbelievable that someone who blames other people for not knowing x86
makes such an error when reading x86.

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

Am Tue, 16 Jul 2024 09:04:18 -0500 schrieb olcott:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of >>>>>>>> simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

It seems that you do not understand x86 language. The input is not a >>>>> string of bytes, but an address (00002163). This points to the
starting of the code of DDD. But a simulation needs a program, not a >>>>> function calling undefined other functions. Therefore, all functions >>>>> called by DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*
You are talking about the behavior specified by that finite string.
When you say that a finite string *is not* a finite string you are
disagreeing with the law of identity.
Every rebuttal to my work disagrees with one tautology of another. It
is the fact that DDD calls HHH(DDD) in recursive emulation that makes
it impossible for DDD correctly emulated by HHH to halt.
Everyone disagrees with this entirely on the basis of the strawman
deception (damned lie) that some other DDD somewhere else has
different behavior.

*They disagree with the following*
In other words the fact that the directly executed DDD halts because
the HHH(DDD) that it calls has already aborted its simulation proves
these these two different instances of DDD are in different process
states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has already
been aborted is the same as the state of being hungry changes after
you have had something to eat.

Can't. Since programs are unchanging, their properties can not change.

*WRONG* https://en.wikipedia.org/wiki/Self-modifying_code

There is no self-modification here.

DDD needing to be aborted changes to DDD not needing to be aborted as
all after being aborted.

You are talking about the runtime status. The static code of DDD will
not change to need to be aborted (or not) no matter how many times it
is run.

HHH1(DDD) does not need to abort its input because the HHH(DDD) that DDD calls has already done this.

HHH1 is a different decider, right?

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/16/24 10:20 AM, olcott wrote:

On 7/16/2024 3:32 AM, Mikko wrote:

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if
HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted. >>>

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH.

That is not an acceptable axiom. That you are unable to prove that
either XXX is aborted or HHH does not terminate is insufficient
reason to call it an axiom.

*Premise* (assumed to be true)
Any input that must be aborted to prevent
the non termination of HHH

That needs to be PROPERLY defined, or it just a false statement.

*Logically entailed by the above premise*
necessarily specifies non-halting behavior or
it would never need to be aborted.

Which, with your wrong definition, leads to your wrong answer.

"Must be aborted" should mean giving that exact same represented program
to a correct emulator will not abort ever.

Since you claimed input isn't even a program, you just fail to be able
to even talk about using that definition.

From the fact that XXX must be aborted we can conclude that XXX must
be aborted.

Nothing that contains the word "must" is a fact.

When simulated input X stops running {if and only if}
the simulation of this input X has been aborted this
necessitates that input X specifies non-halting behavior.

But since the simulition of the DDD that calls the HHH that aborts it
will reach a final state, we see that this claim is incorrect.

Either your input doesn't include the code of HHH, at which point the simulation MUST STOP at the call HHH instruction, meaning it can't be a non-halting simulition.

or, your inp[ut includes the code of HHH, at which point you can't
change the code of HHH at the address specified to do you analysis, but
give it to the unconditional emulating versio of HHH loaded at a
different address, while DDD still cause the original HHH, and that one
WILL HALT too, so HHH is wrong.

I can't see how you were simply not flat out dishonest.

That you cannot do something without being dishoest does not prevent us.

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

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a >>>>> string of bytes, but an address (00002163). This points to the starting >>>>> of the code of DDD. But a simulation needs a program, not a function >>>>> calling undefined other functions. Therefore, all functions called by >>>>> DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite
string. When you say that a finite string *is not* a finite
string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of another.
It is the fact that DDD calls HHH(DDD) in recursive emulation
that makes it impossible for DDD correctly emulated by HHH to halt.

Everyone disagrees with this entirely on the basis of the strawman
deception (damned lie) that some other DDD somewhere else has
different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts
because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD
are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has
already been aborted is the same as the state of being hungry
changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not change.

*WRONG*
https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

--
Mikko

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

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

You have already said that a decider is not allowed to answer anything
other than its input. Now you say that the the program at 15c3 is not
a part of the input. Therefore a decider is not allowed consider it
even to the extent to decide whether it ever returns. But without that
knowledge it is not possible to determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That mapping is not a part of the finite string and not a part of the
problem specification. The finite string does not reveal what is the
effect of calling whatever that address happens to contain. The
behaviour of HHH is specified outside of the input. Therefore your
"decider" decides about a non-input, which you said is not allowed.

--
Mikko

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

On 2024-07-16 14:20:09 +0000, olcott said:

On 7/16/2024 3:32 AM, Mikko wrote:

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted. >>>

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH.

That is not an acceptable axiom. That you are unable to prove that
either XXX is aborted or HHH does not terminate is insufficient
reason to call it an axiom.

*Premise* (assumed to be true)
Any input that must be aborted to prevent
the non termination of HHH

*Logically entailed by the above premise*
necessarily specifies non-halting behavior or
it would never need to be aborted.

No, it is not. Both "need to be" and "must be" are different from "is".
The correct asxiom is "If the program can be executed to its halting in
a finite time then the program specifies a halting behaviour."

From the fact that XXX must be aborted we can conclude that XXX must be
aborted.

Nothing that contains the word "must" is a fact.

When simulated input X stops running {if and only if}
the simulation of this input X has been aborted this
necessitates that input X specifies non-halting behavior.

Nothing that contains the word "necessitates" is a fact, either.
Perhaps you should learn some philosophy.

--
Mikko

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

Op 17.jul.2024 om 15:27 schreef olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

You have already said that a decider is not allowed to answer anything >>>> other than its input. Now you say that the the program at 15c3 is not
a part of the input. Therefore a decider is not allowed consider it
even to the extent to decide whether it ever returns. But without that >>>> knowledge it is not possible to determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the
effect of calling whatever that address happens to contain.

A simulating termination analyzer proves this.

The
behaviour of HHH is specified outside of the input. Therefore your
"decider" decides about a non-input, which you said is not allowed.

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on
the effect of the behavior of the simulation of itself simulating DDD.

But only on the effect of a correct simulation. But HHH cannot possible simulate itself correctly. It aborts after N cycles when the simulated
HHH has executed only N-1 cycles. So, it aborts prematurely, which makes
the simulation invalid.
HHH, although it halts, cannot possibly reach the simulation of its own
end. It aborts one cycle too soon.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms
it. The trace you have shown also proves that HHH cannot reach the end
of its own simulation. So, your own claims prove that it is true that
HHH cannot possibly simulate itself up to the end, which makes the
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

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

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on
the effect of the behavior of the simulation of itself simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also self-evident:
it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms
it. The trace you have shown also proves that HHH cannot reach the end
of its own simulation. So, your own claims prove that it is true that
HHH cannot possibly simulate itself up to the end, which makes the
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

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

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer
anything other than its input. Now you say that the the program at
15c3 is not a part of the input. Therefore a decider is not allowed
consider it even to the extent to decide whether it ever returns. But
without that knowledge it is not possible to determine whether DDD
halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 to
non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That string is meaningless outside of the execution environment of HHH, specifically the simulation of DDD it is doing. It does not encode
anything, DDD does not have access to that address. That string
doesn't call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the effect of calling
whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore your
"decider" decides about a non-input, which you said is not allowed.

HHH is not allowed to report on the behavior of it actual self in its
own directly executed process. HHH is allowed to report on the effect of
the behavior of the simulation of itself simulating DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Am Wed, 17 Jul 2024 09:56:58 -0500 schrieb olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self in
its own directly executed process. HHH is allowed to report on the
effect of the behavior of the simulation of itself simulating DDD.

But only on the effect of a correct simulation.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

Yes, that is exactly why DDD halts.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer
anything other than its input. Now you say that the the program at >>>>>> 15c3 is not a part of the input. Therefore a decider is not allowed >>>>>> consider it even to the extent to decide whether it ever returns.
But without that knowledge it is not possible to determine whether >>>>>> DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 to
non-halting behavior because this finite string calls HHH(DDD) in
recursive simulation.

That string is meaningless outside of the execution environment of HHH,
specifically the simulation of DDD it is doing. It does not encode
anything, DDD does not have access to that address. That string doesn't
call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the effect of calling
whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore
your "decider" decides about a non-input, which you said is not
allowed.

HHH is not allowed to report on the behavior of it actual self in its
own directly executed process. HHH is allowed to report on the effect
of the behavior of the simulation of itself simulating DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely
different process.

Of course it doesn't make sense to return to a higher stack frame.
And of course a function can recursively call itself.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/17/24 1:20 PM, olcott wrote:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer
anything other than its input. Now you say that the the program at >>>>>> 15c3 is not a part of the input. Therefore a decider is not allowed >>>>>> consider it even to the extent to decide whether it ever returns. But >>>>>> without that knowledge it is not possible to determine whether DDD >>>>>> halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 to
non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That string is meaningless outside of the execution environment of HHH,
specifically the simulation of DDD it is doing. It does not encode
anything, DDD does not have access to that address. That string
doesn't call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the effect of calling
whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore your >>>> "decider" decides about a non-input, which you said is not allowed.

HHH is not allowed to report on the behavior of it actual self in its
own directly executed process. HHH is allowed to report on the effect of >>> the behavior of the simulation of itself simulating DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists
in an entirely different process.

So, DDD isn't a program, and you just admitted you are a LIAR.

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

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer
anything other than its input. Now you say that the the program >>>>>>>> at 15c3 is not a part of the input. Therefore a decider is not >>>>>>>> allowed consider it even to the extent to decide whether it ever >>>>>>>> returns. But without that knowledge it is not possible to
determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 to >>>>>>> non-halting behavior because this finite string calls HHH(DDD) in >>>>>>> recursive simulation.

That string is meaningless outside of the execution environment of
HHH,
specifically the simulation of DDD it is doing. It does not encode
anything, DDD does not have access to that address. That string
doesn't call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of
the problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the effect of calling
whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore
your "decider" decides about a non-input, which you said is not
allowed.

HHH is not allowed to report on the behavior of it actual self in
its own directly executed process. HHH is allowed to report on the
effect of the behavior of the simulation of itself simulating DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely
different process.

Of course it doesn't make sense to return to a higher stack frame.
And of course a function can recursively call itself.

A separate process is like a different program on a different computer.

It makes no sense to call a running program. DDD creates a new
instance of the same code with its own memory and code pointer.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on
the effect of the behavior of the simulation of itself simulating DDD. >>>>>

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a HHH
that aborts and halts is irrelevant. Therefore, the 'unless aborted' is irrelevant. The semantics of the x86 instructions are self-evident: HHH
halts.
HHH is programmed to abort after N recursions. Therefore, it is
incorrect to abort the simulation of HHH after N-1 recursions.
The semantics of the x86 code of a halting program is also self-evident:
it halts.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms
it. The trace you have shown also proves that HHH cannot reach the end
of its own simulation. So, your own claims prove that it is true that
HHH cannot possibly simulate itself up to the end, which makes the
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

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

Am Thu, 18 Jul 2024 09:14:32 -0500 schrieb olcott:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer >>>>>>>>>> anything other than its input. Now you say that the the program >>>>>>>>>> at 15c3 is not a part of the input. Therefore a decider is not >>>>>>>>>> allowed consider it even to the extent to decide whether it >>>>>>>>>> ever returns. But without that knowledge it is not possible to >>>>>>>>>> determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 >>>>>>>>> to non-halting behavior because this finite string calls
HHH(DDD) in recursive simulation.

That string is meaningless outside of the execution environment of >>>>>> HHH,
specifically the simulation of DDD it is doing. It does not encode >>>>>> anything, DDD does not have access to that address. That string
doesn't call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of >>>>>>>> the problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the effect of calling >>>>>>>> whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore >>>>>>>> your "decider" decides about a non-input, which you said is not >>>>>>>> allowed.

HHH is not allowed to report on the behavior of it actual self in >>>>>>> its own directly executed process. HHH is allowed to report on the >>>>>>> effect of the behavior of the simulation of itself simulating DDD. >>>>>> HHH must report on itself if its input calls it.

HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely
different process.

Of course it doesn't make sense to return to a higher stack frame.
And of course a function can recursively call itself.

A separate process is like a different program on a different
computer.

It makes no sense to call a running program. DDD creates a new instance
of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.

I mean, why are you talking about that?

The new instance does have different behavior that is beyond what you
can comprehend. It is actually as simple as this:
Before HHH(DDD) aborts its emulation the directly executed DDD()
cannot possibly halt.

What direct execution? Doesn't main() call HHH?
HHH will halt, because it will abort simulating DDD.

After HHH(DDD) aborts its emulation the directly executed DDD()
halts.

I have no idea where in the call stack you are.
Aborting a simulation does not make the simulated program halt, only
the simulator.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/18/24 10:14 AM, olcott wrote:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer >>>>>>>>>> anything other than its input. Now you say that the the program >>>>>>>>>> at 15c3 is not a part of the input. Therefore a decider is not >>>>>>>>>> allowed consider it even to the extent to decide whether it ever >>>>>>>>>> returns. But without that knowledge it is not possible to
determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 to >>>>>>>>> non-halting behavior because this finite string calls HHH(DDD) in >>>>>>>>> recursive simulation.

That string is meaningless outside of the execution environment of >>>>>> HHH,
specifically the simulation of DDD it is doing. It does not encode >>>>>> anything, DDD does not have access to that address. That string
doesn't call anything, the program in HHH's memory space does.
Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of >>>>>>>> the problem specification.

decider/input pairs <are> a key element of the specification.

The finite string does not reveal what is the effect of calling >>>>>>>> whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore >>>>>>>> your "decider" decides about a non-input, which you said is not >>>>>>>> allowed.

HHH is not allowed to report on the behavior of it actual self in >>>>>>> its own directly executed process. HHH is allowed to report on the >>>>>>> effect of the behavior of the simulation of itself simulating DDD. >>>>>> HHH must report on itself if its input calls it.

HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely
different process.

Of course it doesn't make sense to return to a higher stack frame.
And of course a function can recursively call itself.

A separate process is like a different program on a different computer.

It makes no sense to call a running program. DDD creates a new
instance of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.
The new instance does have different behavior that is beyond
what you can comprehend. It is actually as simple as this:

In other words you are admitting that your concept of Computation theory
is so fundamentally different from the standard that the concept of the consistancy of program behavior no longer hold.

That just shows you have been just blantently lying about everything you
have been talking about for years if not decades.

I guess you consider that it is reasonable for your computers Window
Operating system to decide that it has been mistreated and lock you out
of your house.

When you are hungry you remain hungry until you eat.
  Before HHH(DDD) aborts its emulation the directly
  executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
  After HHH(DDD) aborts its emulation the directly
  executed DDD() halts.

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

Op 18.jul.2024 om 16:18 schreef olcott:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on >>>>>>> the effect of the behavior of the simulation of itself simulating >>>>>>> DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a HHH
that aborts and halts is irrelevant. Therefore, the 'unless aborted'
is irrelevant. The semantics of the x86 instructions are self-evident:
HHH halts.

When you are hungry you remain hungry until you eat.
  Before HHH(DDD) aborts its emulation the directly
  executed DDD() cannot possibly halt.

No, but HHH would have halted when not aborted, because that is how it
is programmed. That is the semantics of its x86 code.

After you eat you are no longer hungry.
  After HHH(DDD) aborts its emulation the directly
  executed DDD() halts.

Dreaming that you are still hungry will make that you eat to much.
The simulated HHH already aborts, so the abort of the simulating HHH is incorrect. Dreaming of a HHH that does not abort is irrelevant.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms
it. The trace you have shown also proves that HHH cannot reach the end
of its own simulation. So, your own claims prove that it is true that
HHH cannot possibly simulate itself up to the end, which makes the
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

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

Op 18.jul.2024 om 17:37 schreef olcott:

On 7/18/2024 10:27 AM, joes wrote:

Am Thu, 18 Jul 2024 09:14:32 -0500 schrieb olcott:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer >>>>>>>>>>>> anything other than its input. Now you say that the the program >>>>>>>>>>>> at 15c3 is not a part of the input. Therefore a decider is not >>>>>>>>>>>> allowed consider it even to the extent to decide whether it >>>>>>>>>>>> ever returns. But without that knowledge it is not possible to >>>>>>>>>>>> determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 >>>>>>>>>>> to non-halting behavior because this finite string calls >>>>>>>>>>> HHH(DDD) in recursive simulation.

That string is meaningless outside of the execution environment of >>>>>>>> HHH,
specifically the simulation of DDD it is doing. It does not encode >>>>>>>> anything, DDD does not have access to that address. That string >>>>>>>> doesn't call anything, the program in HHH's memory space does. >>>>>>>> Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of >>>>>>>>>> the problem specification.

decider/input pairs <are> a key element of the specification. >>>>>>>>

The finite string does not reveal what is the effect of calling >>>>>>>>>> whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore >>>>>>>>>> your "decider" decides about a non-input, which you said is not >>>>>>>>>> allowed.

HHH is not allowed to report on the behavior of it actual self in >>>>>>>>> its own directly executed process. HHH is allowed to report on the >>>>>>>>> effect of the behavior of the simulation of itself simulating DDD. >>>>>>>> HHH must report on itself if its input calls it.

HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely >>>>>>> different process.

Of course it doesn't make sense to return to a higher stack frame. >>>>>> And of course a function can recursively call itself.

A separate process is like a different program on a different
computer.

It makes no sense to call a running program. DDD creates a new instance >>>> of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.

I mean, why are you talking about that?

All of the halting problem proofs are incorrectly anchored
in the behavior of the direct execution of the input thus
not the behavior that this input specifies to a decider that
this input invokes.

Exactly the same input is presented to the direct execution and the
simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases, so
a correct simulator should interpret the x86 in the same way as the
direct execution. When exactly the same input is given to another
simulator, it turns out that a correct simulation is possible.
But HHH cannot possibly simulate itself correctly up to the end, because
the simulated HHH always runs one cycle behind the simulating HHH,
therefore, when it aborts, it aborts one cycle too soon.
The error of the simulation is that it does not process al the input,
but it aborts halfway the simulation of a program.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms
it. The trace you have shown also proves that HHH cannot reach the end
of its own simulation. So, your own claims prove that it is true that
HHH cannot possibly simulate itself up to the end, which makes the
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

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

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>> non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>>> argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a >>>>>>> string of bytes, but an address (00002163). This points to the starting >>>>>>> of the code of DDD. But a simulation needs a program, not a function >>>>>>> calling undefined other functions. Therefore, all functions called by >>>>>>> DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite
string. When you say that a finite string *is not* a finite
string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of another. >>>>>> It is the fact that DDD calls HHH(DDD) in recursive emulation
that makes it impossible for DDD correctly emulated by HHH to halt. >>>>>
Everyone disagrees with this entirely on the basis of the strawman >>>>>> deception (damned lie) that some other DDD somewhere else has
different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts
because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD
are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has
already been aborted is the same as the state of being hungry
changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not change. >>>>

*WRONG*
https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

My compiler can accept assembly language
that can derive self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as
if the program were in a read-only memory, and typical compilers
compile so that the program can be run under such operating systems.

My first paper is based on a decider that changes itself
so that it can always get the correct answer.

Self Modifying Turing Machine (SMTM) Solution to the Halting Problem (concrete example) August 2016

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

--
Mikko

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

On 2024-07-17 13:27:08 +0000, olcott said:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

You have already said that a decider is not allowed to answer anything >>>> other than its input. Now you say that the the program at 15c3 is not
a part of the input. Therefore a decider is not allowed consider it
even to the extent to decide whether it ever returns. But without that >>>> knowledge it is not possible to determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

Not of any specification of any interesting problem.

The finite string does not reveal what is the
effect of calling whatever that address happens to contain.

A simulating termination analyzer proves this.

Irrelevant, as you just said it is not a part of the input.

The
behaviour of HHH is specified outside of the input. Therefore your
"decider" decides about a non-input, which you said is not allowed.

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on
the effect of the behavior of the simulation of itself simulating DDD.

Now you said that it is allowed to report on a non-input.
Earlier you have said that it is not allowed to report on a non-input.

--
Mikko

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

On 2024-07-16 18:26:12 +0000, olcott said:

On 7/16/2024 3:16 AM, Mikko wrote:

On 2024-07-15 13:51:14 +0000, olcott said:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination
of simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your
argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a >>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>> thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function >>>>>> DDD proper then you are just admitting that you are nothing more than a >>>>>> lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing machine.

No that is wrong. The finite string must encode a Turing machine.

That you agree does not mean that it is wrong.

Your ignorance that a Turing machine cannot take its own
executing self as an input is no rebuttal what-so-ever.

You should not assume that everyone is as stupid as you.

--
Mikko

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

On 2024-07-16 18:27:35 +0000, olcott said:

On 7/16/2024 3:20 AM, Mikko wrote:

On 2024-07-15 20:56:21 +0000, olcott said:

On 7/15/2024 3:51 PM, joes wrote:

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of >>>>>>>>> simulating termination analyzer HHH necessarily specifies
non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your >>>>>>>> argument because you have misdefined what the input is.
The input to HHH is ALL of the memory that it would be accessed in a >>>>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>>>> thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the >>>>>>>> function DDD proper then you are just admitting that you are nothing >>>>>>>> more than a lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do not operate on >>>>>>> other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing >>>>>> machine.

No that is wrong. The finite string must encode a Turing machine.

Same difference.

Not at all. The huge mistake of all these years is that
people stupidly expected that HHH to report on the behavior
of its own executing Turing machine.

No, the error is that HHH report on its own behavour instead of the
behaviour specified by its inputs. Nobody expects that your programs
do anything interesting or useful.

HHH computes the mapping from this finite string: 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string
calls HHH(DDD) in recursive simulation.

But it does not compute any interesting mapping. You cannot even specify
the mapping wiohout a reference to HHH.

--
Mikko

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

On 2024-07-17 13:30:07 +0000, olcott said:

On 7/17/2024 2:49 AM, Mikko wrote:

On 2024-07-16 14:20:09 +0000, olcott said:

On 7/16/2024 3:32 AM, Mikko wrote:

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted. >>>>>

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH.

That is not an acceptable axiom. That you are unable to prove that
either XXX is aborted or HHH does not terminate is insufficient
reason to call it an axiom.

*Premise* (assumed to be true)
Any input that must be aborted to prevent
the non termination of HHH

*Logically entailed by the above premise*
necessarily specifies non-halting behavior or
it would never need to be aborted.

No, it is not. Both "need to be" and "must be" are different from "is".
The correct asxiom is "If the program can be executed to its halting in
a finite time then the program specifies a halting behaviour."

From the fact that XXX must be aborted we can conclude that XXX must be >>>>> aborted.

Nothing that contains the word "must" is a fact.

When simulated input X stops running {if and only if}
the simulation of this input X has been aborted this
necessitates that input X specifies non-halting behavior.

Nothing that contains the word "necessitates" is a fact, either.
Perhaps you should learn some philosophy.

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

_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]

DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stops running unless aborted.

That Professor Sipser does not express any agreement with anything
about the syntax of facts is not relevant to our (or any) discussion
about syntax of facts.

--
Mikko

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

On 2024-07-18 14:18:51 +0000, olcott said:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on >>>>>>> the effect of the behavior of the simulation of itself simulating DDD. >>>>>>>

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a HHH
that aborts and halts is irrelevant. Therefore, the 'unless aborted' is
irrelevant. The semantics of the x86 instructions are self-evident: HHH
halts.

When you are hungry you remain hungry until you eat.
Before HHH(DDD) aborts its emulation the directly
executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
After HHH(DDD) aborts its emulation the directly
executed DDD() halts.

If DDD does not halt it indicates that HHH is faulty. Therefore the
interesting question is whether DDD halts, not when DDD halts.

--
Mikko

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

On 7/19/24 10:23 AM, olcott wrote:

On 7/19/2024 2:57 AM, Mikko wrote:

On 2024-07-17 13:27:08 +0000, olcott said:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>> non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>> argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

You have already said that a decider is not allowed to answer
anything
other than its input. Now you say that the the program at 15c3 is not >>>>>> a part of the input. Therefore a decider is not allowed consider it >>>>>> even to the extent to decide whether it ever returns. But without
that
knowledge it is not possible to determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

Computable functions are the formalized analogue of the intuitive notion
of algorithms, in the sense that a function is computable if there
exists an algorithm that can do the job of the function, i.e. given an
input of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function

Right, but not all functions are computable, so you can't assume the
existance of a program to get the answer.

Not of any specification of any interesting problem.

Everyone here seems to think that they can stupidly ignore
the fact that an input calls its own decider and make pretend
that this pathological relationship does not exist.

No, you need to take it FULLY into account, since the program the input represents WILL HALT since the copy of the decider it calls WILL RETUN
0, since that IS the behavior of you claimed to be correct decider.

The finite string does not reveal what is the
effect of calling whatever that address happens to contain.

A simulating termination analyzer proves this.

Irrelevant, as you just said it is not a part of the input.

It is not part of the input in that we already know that
HHH halts and we only need to find out whether or not DDD halts.

But since HHH halts, it is a NECCESARY fact that the DDD that just clll
that HHH and retuns will halt halt.

It is IMPOSSIBLE for this DDD to not halt when it calls a HHH that halts.

HHH doesn't know this, and makes a INVALID assumption in its logic
because its programmer is just an idiot, but that doesn't affect ther VERIFIABLE FACT that the actual behavior, as defined by the x86
interpreation of ALL the code of DDD will halt.


Now, that fact that you try to exclude some of the necessary code from
being part of DDD, just means you are just a damned lying idiot that
doesn't understand the requirements for an input to be a representation
of a PROGRAM, because you made yourself INTENTIONALLY into an IGNORANT
IDIOT in the field.

Either the problem is invalid, of DDD will halt if HHH halts.

The
behaviour of HHH is specified outside of the input. Therefore your
"decider" decides about a non-input, which you said is not allowed.

HHH is not allowed to report on the behavior of it actual self
in its own directly executed process. HHH is allowed to report on
the effect of the behavior of the simulation of itself simulating DDD.

Now you said that it is allowed to report on a non-input.
Earlier you have said that it is not allowed to report on a non-input.

Not the same. It cannot report on its actual self as a directly
executed process. I can report on a copy of itself that it being
emulating in a different process.

But it can report on the representation of itself it has been given.


If you claim it isn't in the input representation, then yolu LIED that
the input is the representatio of the PROGRAM DDD, which just shows you
are just an lying ignorant idiot about computer science.

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

On 7/19/24 10:56 AM, olcott wrote:

On 7/19/2024 1:40 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 16:18 schreef olcott:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>> in its own directly executed process. HHH is allowed to report on >>>>>>>>> the effect of the behavior of the simulation of itself
simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a
HHH that aborts and halts is irrelevant. Therefore, the 'unless
aborted' is irrelevant. The semantics of the x86 instructions are
self-evident: HHH halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

No, but HHH would have halted when not aborted, because that is how it
is programmed. That is the semantics of its x86 code.

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or
HHH, emulated DDD and executed DDD never stop running.

And since it DOES abort that simulation (or HHH fails to be the decider
you claim it is) that means that DDD DOES stop rubnning.

This means you logic is nothing but a LIE, and that you are proven to be totally ignorant of how programming works.

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

On 7/19/24 10:49 AM, olcott wrote:

On 7/19/2024 4:14 AM, Mikko wrote:

On 2024-07-18 14:18:51 +0000, olcott said:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>> in its own directly executed process. HHH is allowed to report on >>>>>>>>> the effect of the behavior of the simulation of itself
simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a
HHH that aborts and halts is irrelevant. Therefore, the 'unless
aborted' is irrelevant. The semantics of the x86 instructions are
self-evident: HHH halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
   After HHH(DDD) aborts its emulation the directly
   executed DDD() halts.

If DDD does not halt it indicates that HHH is faulty. Therefore the
interesting question is whether DDD halts, not when DDD halts.

*By your same reasoning*
If Infinite_Loop() does not halt HHH is faulty.

In other words if Infinite_Loop()  is an actual infinite
loop then this is all the fault of HHH.

No, because Infinite_Loop just never halts when run, and doesn't depend
on the behavior of HHH.

DDD does depend on the behavior of HHH, so HHH to CORRECT analyze its
behavior must correct decide on its own behavior. If HHH will halt, then
HHH needs to include that knowledge in its analysis of DDD, but it
doesn't, so its analysis is just wrong.

HHH could have used the Flibble method, and gotten the answer, but it
failed to do that, so it failed at a solvable problem.

void Infinite_Loop()
{
  HERE: goto HERE;
}

int main()
{
  HHH(Infinite_Loop);
}

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

Am Fri, 19 Jul 2024 09:54:07 -0500 schrieb olcott:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 17:37 schreef olcott:

On 7/18/2024 10:27 AM, joes wrote:

Am Thu, 18 Jul 2024 09:14:32 -0500 schrieb olcott:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

The behaviour of HHH is specified outside of the input. >>>>>>>>>>>> Therefore your "decider" decides about a non-input, which you >>>>>>>>>>>> said is not allowed.

HHH is not allowed to report on the behavior of it actual self >>>>>>>>>>> in its own directly executed process. HHH is allowed to report >>>>>>>>>>> on the effect of the behavior of the simulation of itself >>>>>>>>>>> simulating DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely >>>>>>>>> different process.

Of course it doesn't make sense to return to a higher stack
frame. And of course a function can recursively call itself.

A separate process is like a different program on a different
computer.

It makes no sense to call a running program. DDD creates a new
instance of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.

I mean, why are you talking about that?

All of the halting problem proofs are incorrectly anchored in the
behavior of the direct execution of the input thus not the behavior
that this input specifies to a decider that this input invokes.

Exactly the same input is presented to the direct execution and the
simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases,
so a correct simulator should interpret the x86 in the same way as the
direct execution.

Before HHH(DDD) aborts its emulation the directly executed DDD()
cannot possibly halt.
After HHH(DDD) aborts its emulation the directly executed DDD()
halts.

What do you mean "after"? The outer DDD called by main? It will halt
even before HHH has aborted, because it is deterministic and actually
does halt. It makes no sense to say that something that will, couldn't.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

Am Fri, 19 Jul 2024 09:23:01 -0500 schrieb olcott:

On 7/19/2024 2:57 AM, Mikko wrote:

On 2024-07-17 13:27:08 +0000, olcott said:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer
anything other than its input. Now you say that the the program at >>>>>> 15c3 is not a part of the input. Therefore a decider is not allowed >>>>>> consider it even to the extent to decide whether it ever returns.
But without that knowledge it is not possible to determine whether >>>>>> DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 to
non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

Not of any specification of any interesting problem.

Everyone here seems to think that they can stupidly ignore the fact that
an input calls its own decider and make pretend that this pathological relationship does not exist.

The finite string does not reveal what is the effect of calling
whatever that address happens to contain.

A simulating termination analyzer proves this.

Irrelevant, as you just said it is not a part of the input.

It is not part of the input in that we already know that HHH halts and
we only need to find out whether or not DDD halts.

That is trivial since DDD only calls HHH.

The behaviour of HHH is specified outside of the input. Therefore
your "decider" decides about a non-input, which you said is not
allowed.

HHH is not allowed to report on the behavior of it actual self in its
own directly executed process. HHH is allowed to report on the effect
of the behavior of the simulation of itself simulating DDD.

Now you said that it is allowed to report on a non-input.
Earlier you have said that it is not allowed to report on a non-input.

Not the same. It cannot report on its actual self as a directly executed process. I can report on a copy of itself that it being emulating in a different process.

It has no need to report on itself, it can just do whatever it does.
All running or (completely) simulated copies of it behave the same.
It is not immediately simulating itself; its input is DDD.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

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

On 7/19/24 4:21 PM, olcott wrote:

On 7/19/2024 11:03 AM, joes wrote:

Am Fri, 19 Jul 2024 09:54:07 -0500 schrieb olcott:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Exactly the same input is presented to the direct execution and the
simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases,
so a correct simulator should interpret the x86 in the same way as the >>>> direct execution.

No it is not.
Although you are the same person when you are hungry before
you eat after you eat you are no longer in the hungry state.
*Same person transitioning from hungry to not-hungry*

I may be the same person, but people, and there hunger state, and
mutable and change with time.

Because or actions that HHH does DDD changes its state
from needing to be aborted to not needing to be aborted.

But Programs are fixed, and their "need to be aborted" is an UNCHANGING attribute.

In fact, you CAN'T ask a decider about a changeable attribute, because
the map being computed does have time as an input.

So, you are just admitting that you are nothing but an ignorant liar.

Same program transitioning from needing to be aborted
to not needing to be aborted.

How? Programs are unchangable code.

     Before HHH(DDD) aborts its emulation the directly executed DDD() >>>      cannot possibly halt.
     After HHH(DDD) aborts its emulation the directly executed DDD() >>>      halts.

What do you mean "after"? The outer DDD called by main? It will halt
even before HHH has aborted, because it is deterministic and actually
does halt. It makes no sense to say that something that will, couldn't.

void DDD()
{
  HHH(DDD);
}

int main()
{
  DDD();
}

DDD() is invoked and calls HHH(DDD) that emulates its own
separate DDD instance as a separate process.

Unless HHH(DDD) aborts its emulated DDD:
HHH, emulated DDD and executed DDD never stop running.

You keep on saying that, but you admit that HHH DOES abort its
simulation (so it can be a decider) and returns, so it returns to DDD>


Yes, I think we all admit that you you make THE ONLY HHH to not abort,
then NEITHER HHH or DDD return, and HHH failts to be a decider.


The problem is since HHH is given a DDD that class the HHH doing the
deciding, HHH can't think that it can abort but the one used by DDD does.

You are just using incorrect logic based on your LYING about what the
setup is.

You are just proving your total ignorance of the basics of programming.

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

Op 19.jul.2024 om 16:54 schreef olcott:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 17:37 schreef olcott:

On 7/18/2024 10:27 AM, joes wrote:

Am Thu, 18 Jul 2024 09:14:32 -0500 schrieb olcott:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer >>>>>>>>>>>>>> anything other than its input. Now you say that the the >>>>>>>>>>>>>> program
at 15c3 is not a part of the input. Therefore a decider is >>>>>>>>>>>>>> not
allowed consider it even to the extent to decide whether it >>>>>>>>>>>>>> ever returns. But without that knowledge it is not >>>>>>>>>>>>>> possible to
determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 >>>>>>>>>>>>> to non-halting behavior because this finite string calls >>>>>>>>>>>>> HHH(DDD) in recursive simulation.

That string is meaningless outside of the execution
environment of
HHH,
specifically the simulation of DDD it is doing. It does not >>>>>>>>>> encode
anything, DDD does not have access to that address. That string >>>>>>>>>> doesn't call anything, the program in HHH's memory space does. >>>>>>>>>> Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a >>>>>>>>>>>> part of
the problem specification.

decider/input pairs <are> a key element of the specification. >>>>>>>>>>

The finite string does not reveal what is the effect of calling >>>>>>>>>>>> whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. >>>>>>>>>>>> Therefore
your "decider" decides about a non-input, which you said is not >>>>>>>>>>>> allowed.

HHH is not allowed to report on the behavior of it actual >>>>>>>>>>> self in
its own directly executed process. HHH is allowed to report >>>>>>>>>>> on the
effect of the behavior of the simulation of itself simulating >>>>>>>>>>> DDD.

HHH must report on itself if its input calls it.
HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely >>>>>>>>> different process.

Of course it doesn't make sense to return to a higher stack frame. >>>>>>>> And of course a function can recursively call itself.

A separate process is like a different program on a different
computer.

It makes no sense to call a running program. DDD creates a new
instance
of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.

I mean, why are you talking about that?

All of the halting problem proofs are incorrectly anchored
in the behavior of the direct execution of the input thus
not the behavior that this input specifies to a decider that
this input invokes.

Exactly the same input is presented to the direct execution and the
simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases,
so a correct simulator should interpret the x86 in the same way as the
direct execution.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
   After HHH(DDD) aborts its emulation the directly
   executed DDD() halts.

In other words you should remain hungry after you eat
because you are the same person in both cases.

So you think that you should keep eating, because you could dream of a situation where you were hungry.

You keep dreaming of an HHH that does not halt and therefore you keep
thinking that an abort is necessary, even for a HHH that aborts and halts.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

Op 19.jul.2024 om 16:56 schreef olcott:

On 7/19/2024 1:40 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 16:18 schreef olcott:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>> in its own directly executed process. HHH is allowed to report on >>>>>>>>> the effect of the behavior of the simulation of itself
simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a
HHH that aborts and halts is irrelevant. Therefore, the 'unless
aborted' is irrelevant. The semantics of the x86 instructions are
self-evident: HHH halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

No, but HHH would have halted when not aborted, because that is how it
is programmed. That is the semantics of its x86 code.

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or
HHH, emulated DDD and executed DDD never stop running.

Whether HHH *must* abort, or *not abort* is irrelevant. It aborts.
When HHH is coded to abort, the reason why is no longer relevant when
the behaviour is analysed.
HHH aborts and halts, therefore it is incorrect to abort the simulated
HHH, which would also abort and halt.
The semantics of the x86 language is the same for the direct execution
and for the simulator. The semantics of x86 does not depend on who will interpret it.
HHH, which is coded to abort, cannot refuse to abort, which makes the simulation incorrect.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Your HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much you want it to be correct, or how many times you
repeat that it is correct, it does not change the fact that such a
simulation is incorrect, because it is unable to reach the end.
Your own claim that the simulated HHH does not reach its end confirms
it. The trace you have shown also proves that HHH cannot reach the end
of its own simulation. So, your own claims prove that it is true that
HHH cannot possibly simulate itself up to the end, which makes the
simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that the
simulation is incorrect.

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

Op 19.jul.2024 om 16:49 schreef olcott:

On 7/19/2024 4:14 AM, Mikko wrote:

On 2024-07-18 14:18:51 +0000, olcott said:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>> in its own directly executed process. HHH is allowed to report on >>>>>>>>> the effect of the behavior of the simulation of itself
simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a
HHH that aborts and halts is irrelevant. Therefore, the 'unless
aborted' is irrelevant. The semantics of the x86 instructions are
self-evident: HHH halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
   After HHH(DDD) aborts its emulation the directly
   executed DDD() halts.

If DDD does not halt it indicates that HHH is faulty. Therefore the
interesting question is whether DDD halts, not when DDD halts.

*By your same reasoning*
If Infinite_Loop() does not halt HHH is faulty.

In other words if Infinite_Loop()  is an actual infinite
loop then this is all the fault of HHH.

void Infinite_Loop()
{
  HERE: goto HERE;
}

int main()
{
  HHH(Infinite_Loop);
}

Irrelevant, because you do not understand the difference between
Infinite_Loop and Finite_Recursion.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

HHH is unable to recognise a finite recursion, such as in an aborting HHH.


DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria you stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

Op 19.jul.2024 om 22:21 schreef olcott:

On 7/19/2024 11:03 AM, joes wrote:

Am Fri, 19 Jul 2024 09:54:07 -0500 schrieb olcott:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Exactly the same input is presented to the direct execution and the
simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases,
so a correct simulator should interpret the x86 in the same way as the >>>> direct execution.

No it is not.
Although you are the same person when you are hungry before
you eat after you eat you are no longer in the hungry state.
*Same person transitioning from hungry to not-hungry*

But a halting program does not change into a non-halting program when
only the fort few instructions are execute/simulated.

Because or actions that HHH does DDD changes its state
from needing to be aborted to not needing to be aborted.

No, there is no need to abort. Correct simulations of HHH have been
presented, that show that the simulated HHH does not need to be aborted,
but halts of its own.
The problem is that HHH cannot possibly simulate itself correctly.

Same program transitioning from needing to be aborted
to not needing to be aborted.

     Before HHH(DDD) aborts its emulation the directly executed DDD() >>>      cannot possibly halt.
     After HHH(DDD) aborts its emulation the directly executed DDD() >>>      halts.

What do you mean "after"? The outer DDD called by main? It will halt
even before HHH has aborted, because it is deterministic and actually
does halt. It makes no sense to say that something that will, couldn't.

void DDD()
{
  HHH(DDD);
}

int main()
{
  DDD();
}

DDD() is invoked and calls HHH(DDD) that emulates its own
separate DDD instance as a separate process.

Unless HHH(DDD) aborts its emulated DDD:
HHH, emulated DDD and executed DDD never stop running.

And when HHH aborts, the simulation is incomplete and, therefore, incorrect.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

On 2024-07-19 14:49:46 +0000, olcott said:

On 7/19/2024 4:14 AM, Mikko wrote:

On 2024-07-18 14:18:51 +0000, olcott said:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>> in its own directly executed process. HHH is allowed to report on >>>>>>>>> the effect of the behavior of the simulation of itself simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a HHH
that aborts and halts is irrelevant. Therefore, the 'unless aborted' is >>>> irrelevant. The semantics of the x86 instructions are self-evident: HHH >>>> halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
   After HHH(DDD) aborts its emulation the directly
   executed DDD() halts.

If DDD does not halt it indicates that HHH is faulty. Therefore the
interesting question is whether DDD halts, not when DDD halts.

This time I made a typo that is much worse than my usual typos.
Pro "when DDD halts" lege "when HHH halts".

*By your same reasoning*
If Infinite_Loop() does not halt HHH is faulty.

No, the reasoning must be differ. Infinite_Loop can be proven to halt
by a simple inspection of a short code. Similar simple inspection of
DDD reveals that DDD does halt if HHH halts but not whether HHH halts. Therefore the interesting question, needed to complete the proof, is
whether HHH halts. If that can be determined the question about DDD
is easy.

In other words if Infinite_Loop() is an actual infinite
loop then this is all the fault of HHH.

Nothing is the fault of HHH. If a program is faulty it is the fault
of the author of the program. Usually an infinite loop is a fault
but that depends on the purpose and specification of the program.
Sometimes a program is faulty if it does terminate.

--
Mikko

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

Op 19.jul.2024 om 16:23 schreef olcott:

On 7/19/2024 2:57 AM, Mikko wrote:

On 2024-07-17 13:27:08 +0000, olcott said:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>> non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>> argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

You have already said that a decider is not allowed to answer
anything
other than its input. Now you say that the the program at 15c3 is not >>>>>> a part of the input. Therefore a decider is not allowed consider it >>>>>> even to the extent to decide whether it ever returns. But without
that
knowledge it is not possible to determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string calls HHH(DDD)
in recursive simulation.

That mapping is not a part of the finite string and not a part of the
problem specification.

decider/input pairs <are> a key element of the specification.

Computable functions are the formalized analogue of the intuitive notion
of algorithms, in the sense that a function is computable if there
exists an algorithm that can do the job of the function, i.e. given an
input of the function domain it can return the corresponding output. https://en.wikipedia.org/wiki/Computable_function

Not of any specification of any interesting problem.

Everyone here seems to think that they can stupidly ignore
the fact that an input calls its own decider and make pretend
that this pathological relationship does not exist.

The finite string does not reveal what is the
effect of calling whatever that address happens to contain.

A simulating termination analyzer proves this.

Irrelevant, as you just said it is not a part of the input.

It is not part of the input in that we already know that
HHH halts and we only need to find out whether or not DDD halts.

How do you know that HHH halts? The direct execution? But then we
already know that DDD halts as well, because its direct execution halts
as well.
But since you seem to think that a correct simulation can change the
behaviour of a program, you should also show that the behaviour of HHH
does not change when simulated.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

On 2024-07-19 14:54:07 +0000, olcott said:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 17:37 schreef olcott:

On 7/18/2024 10:27 AM, joes wrote:

Am Thu, 18 Jul 2024 09:14:32 -0500 schrieb olcott:

On 7/18/2024 3:25 AM, joes wrote:

Am Wed, 17 Jul 2024 15:36:24 -0500 schrieb olcott:

On 7/17/2024 3:30 PM, joes wrote:

Am Wed, 17 Jul 2024 12:20:43 -0500 schrieb olcott:

On 7/17/2024 12:16 PM, joes wrote:

Am Wed, 17 Jul 2024 08:27:08 -0500 schrieb olcott:

On 7/17/2024 2:43 AM, Mikko wrote:

On 2024-07-16 18:24:49 +0000, olcott said:

On 7/16/2024 3:12 AM, Mikko wrote:

On 2024-07-15 02:33:28 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

You have already said that a decider is not allowed to answer >>>>>>>>>>>>>> anything other than its input. Now you say that the the program >>>>>>>>>>>>>> at 15c3 is not a part of the input. Therefore a decider is not >>>>>>>>>>>>>> allowed consider it even to the extent to decide whether it >>>>>>>>>>>>>> ever returns. But without that knowledge it is not possible to >>>>>>>>>>>>>> determine whether DDD halts.

It maps the finite string 558bec6863210000e853f4ffff83c4045dc3 >>>>>>>>>>>>> to non-halting behavior because this finite string calls >>>>>>>>>>>>> HHH(DDD) in recursive simulation.

That string is meaningless outside of the execution environment of >>>>>>>>>> HHH,
specifically the simulation of DDD it is doing. It does not encode >>>>>>>>>> anything, DDD does not have access to that address. That string >>>>>>>>>> doesn't call anything, the program in HHH's memory space does. >>>>>>>>>> Ceterum censeo that HHH halts.

That mapping is not a part of the finite string and not a part of >>>>>>>>>>>> the problem specification.

decider/input pairs <are> a key element of the specification. >>>>>>>>>>

The finite string does not reveal what is the effect of calling >>>>>>>>>>>> whatever that address happens to contain.

A simulating termination analyzer proves this.

The behaviour of HHH is specified outside of the input. Therefore >>>>>>>>>>>> your "decider" decides about a non-input, which you said is not >>>>>>>>>>>> allowed.

HHH is not allowed to report on the behavior of it actual self in >>>>>>>>>>> its own directly executed process. HHH is allowed to report on the >>>>>>>>>>> effect of the behavior of the simulation of itself simulating DDD. >>>>>>>>>> HHH must report on itself if its input calls it.

HHH does not directly simulate itself, it just executes.
It reports on DDD by simulating it.

Its input cannot call its actual self that exists in an entirely >>>>>>>>> different process.

Of course it doesn't make sense to return to a higher stack frame. >>>>>>>> And of course a function can recursively call itself.

A separate process is like a different program on a different
computer.

It makes no sense to call a running program. DDD creates a new instance >>>>>> of the same code with its own memory and code pointer.

It is not that it makes no sense it is that it is impossible.

I mean, why are you talking about that?

All of the halting problem proofs are incorrectly anchored
in the behavior of the direct execution of the input thus
not the behavior that this input specifies to a decider that
this input invokes.

Exactly the same input is presented to the direct execution and the
simulation, namely the x86 code of the program.
The semantics of the x86 language does not change in these two cases,
so a correct simulator should interpret the x86 in the same way as the
direct execution.

When you are hungry you remain hungry until you eat.
Before HHH(DDD) aborts its emulation the directly
executed DDD() cannot possibly halt.

As lame as your other analogies. Being hungry is a state: one can be
sometimes hungry and other times not whithout becaming another person.
Programs are constant texts. They don't have states. They only have
permanent properties.

--
Mikko

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

On 2024-07-19 14:41:47 +0000, olcott said:

On 7/19/2024 4:00 AM, Mikko wrote:

On 2024-07-16 18:27:35 +0000, olcott said:

On 7/16/2024 3:20 AM, Mikko wrote:

On 2024-07-15 20:56:21 +0000, olcott said:

On 7/15/2024 3:51 PM, joes wrote:

Am Mon, 15 Jul 2024 08:51:14 -0500 schrieb olcott:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination of >>>>>>>>>>> simulating termination analyzer HHH necessarily specifies >>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>

Excpet, as I have shown, it doesn't.
Your problem is you keep on ILEGALLY changing the input in your >>>>>>>>>> argument because you have misdefined what the input is.
The input to HHH is ALL of the memory that it would be accessed in a >>>>>>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>>>>>> thus, if you change HHH you get a different input.
If you want to try to claim the input is just the bytes of the >>>>>>>>>> function DDD proper then you are just admitting that you are nothing >>>>>>>>>> more than a lying idiot that doesn't understand the problem, >>>>>>>>> Turing machines only operate on finite strings they do not operate on >>>>>>>>> other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing >>>>>>>> machine.

No that is wrong. The finite string must encode a Turing machine. >>>>>> Same difference.

Not at all. The huge mistake of all these years is that
people stupidly expected that HHH to report on the behavior
of its own executing Turing machine.

No, the error is that HHH report on its own behavour instead of the
behaviour specified by its inputs. Nobody expects that your programs
do anything interesting or useful.

HHH computes the mapping from this finite string:
558bec6863210000e853f4ffff83c4045dc3
to non-halting behavior because this finite string
calls HHH(DDD) in recursive simulation.

But it does not compute any interesting mapping. You cannot even specify
the mapping wiohout a reference to HHH.

You cannot even specify the mapping wiohout a reference to HHH.

Of course I can't. I am not so ridiculously stupid to believe
that we can just ignore the fact that DDD does call HHH(DDD) in
recursive simulation.

Fortunate the mapping is so uninteresting that you needn't.

--
Mikko

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

On 2024-07-19 14:46:19 +0000, olcott said:

On 7/19/2024 4:07 AM, Mikko wrote:

On 2024-07-17 13:30:07 +0000, olcott said:

On 7/17/2024 2:49 AM, Mikko wrote:

On 2024-07-16 14:20:09 +0000, olcott said:

On 7/16/2024 3:32 AM, Mikko wrote:

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted.

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH.

That is not an acceptable axiom. That you are unable to prove that >>>>>> either XXX is aborted or HHH does not terminate is insufficient
reason to call it an axiom.

*Premise* (assumed to be true)
Any input that must be aborted to prevent
the non termination of HHH

*Logically entailed by the above premise*
necessarily specifies non-halting behavior or
it would never need to be aborted.

No, it is not. Both "need to be" and "must be" are different from "is". >>>> The correct asxiom is "If the program can be executed to its halting in >>>> a finite time then the program specifies a halting behaviour."

From the fact that XXX must be aborted we can conclude that XXX must be >>>>>>> aborted.

Nothing that contains the word "must" is a fact.

When simulated input X stops running {if and only if}
the simulation of this input X has been aborted this
necessitates that input X specifies non-halting behavior.

Nothing that contains the word "necessitates" is a fact, either.
Perhaps you should learn some philosophy.

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

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stops running unless aborted.

That Professor Sipser does not express any agreement with anything
about the syntax of facts is not relevant to our (or any) discussion
about syntax of facts.

void DDD()
{
HHH(DDD);
}

int main()
{
DDD();
}

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

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or HHH, emulated DDD and executed DDD
never stop running.

If HHH can detect that a part of the code to be emulated ie HHH itself it
may skip the emulation of itself and continue from the return. The knowledge that HHH always terminates can be coded in HHH. Therefore the abortion is
not necessary.

--
Mikko

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

On 2024-07-19 14:43:53 +0000, olcott said:

On 7/19/2024 4:02 AM, Mikko wrote:

On 2024-07-16 18:26:12 +0000, olcott said:

On 7/16/2024 3:16 AM, Mikko wrote:

On 2024-07-15 13:51:14 +0000, olcott said:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>> non-halting behavior or it would never need to be aborted.

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>> argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a >>>>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>>>> thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function
DDD proper then you are just admitting that you are nothing more than a
lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing machine.

No that is wrong. The finite string must encode a Turing machine.

That you agree does not mean that it is wrong.

Your ignorance that a Turing machine cannot take its own
executing self as an input is no rebuttal what-so-ever.

You should not assume that everyone is as stupid as you.

That all rebuttals to my work have one fatal flaw or
another is beyond the comprehension of my reviewers
provides zero evidence that these rebuttals are not flawed.

You can claim that the indications of flaws of your "work" are flawed
but that does not remove the indicated flaws from your work.

--
Mikko

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

On 7/20/24 9:32 AM, olcott wrote:

On 7/20/2024 3:48 AM, Fred. Zwarts wrote:

Op 19.jul.2024 om 16:56 schreef olcott:

On 7/19/2024 1:40 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 16:18 schreef olcott:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>>>> in its own directly executed process. HHH is allowed to
report on
the effect of the behavior of the simulation of itself
simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a
HHH that aborts and halts is irrelevant. Therefore, the 'unless
aborted' is irrelevant. The semantics of the x86 instructions are
self-evident: HHH halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

No, but HHH would have halted when not aborted, because that is how
it is programmed. That is the semantics of its x86 code.

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or
HHH, emulated DDD and executed DDD never stop running.

Whether HHH *must* abort, or *not abort* is irrelevant.

In other words you can't begin to understand hypothetical
possibilities, thus this material may simply be over your head.

The problem is you don't understand the differnce between hypothtical possibilities and hypothetical IMpossibilities.

Of every possible HHH that can possibly exist HHH must abort
its emulation of DDD or not. Not is the wrong answer thus
making abort the correct answer.

But the question isn't doesn't it need to be aborted by H, the question
is does DDD Halt when run.

Also, To HAVE a DDD, we must have a specific HHH for it to call, or we
don't have a PROGRAM DDD to talk about, and that fixes the behavior of
that HHH.

Answering the wrong question doesn't make wrong answers correct.

You are just stuck being caught in your lies and trying to squirm out.

And this just shows how little you understand about the field, that you
try to misinterprete a question to be something that isn't even in the
field.

Computation Theory is about PROGRAMS and their ability. Halting is about
the behavior of a PROGRAM.

Your attempt to define DDD without fixing the HHH it calls makes it not
a program, so questions about it are outside of Computation Theory until
you pair the DDD with a specific HHH.

Your claiming that you ideas are "equivalent" to the statements in
Computation Theory is just a LIE.

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

On 7/20/24 10:54 AM, olcott wrote:

On 7/20/2024 4:39 AM, Mikko wrote:

On 2024-07-19 14:43:53 +0000, olcott said:

On 7/19/2024 4:02 AM, Mikko wrote:

On 2024-07-16 18:26:12 +0000, olcott said:

On 7/16/2024 3:16 AM, Mikko wrote:

On 2024-07-15 13:51:14 +0000, olcott said:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in >>>>>>>>>> your argument because you have misdefined what the input is. >>>>>>>>>>
The input to HHH is ALL of the memory that it would be
accessed in a correct simulation of DDD, which includes all >>>>>>>>>> the codd of HHH, and thus, if you change HHH you get a
different input.

If you want to try to claim the input is just the bytes of the >>>>>>>>>> function DDD proper then you are just admitting that you are >>>>>>>>>> nothing more than a lying idiot that doesn't understand the >>>>>>>>>> problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a
Turing machine.

No that is wrong. The finite string must encode a Turing machine. >>>>>>

That you agree does not mean that it is wrong.

Your ignorance that a Turing machine cannot take its own
executing self as an input is no rebuttal what-so-ever.

You should not assume that everyone is as stupid as you.

That all rebuttals to my work have one fatal flaw or
another is beyond the comprehension of my reviewers
provides zero evidence that these rebuttals are not flawed.

You can claim that the indications of flaws of your "work" are flawed
but that does not remove the indicated flaws from your work.

Every rebuttal of my work denies a tautology
proving that the rebuttal is incorrect because
all tautologies are necessarily true.

But you claimed "tautology" is not correct because it is based on lying
words.

int main()
{
  DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

*The above is a Tautology*

But that is isn't a correct statement, cause by a broken computation system.

Your system, the way you argue it, doesn't all you to change the
deciding HHH to be non-aborting with out changing the input.

That means you have stripped your words of valid meaning.

When we fix that, and give the same input that this HHH (one that aborts
its emulation) to an emulator that doesn't abort, and that input still
calls that original HHH, we see that the emulation DOES reach an end,
and thus you are just LYING that this HHH "must abort" is emulation.

All you are doing is proving that you are nothing but an ignorant
pathological lying idiot that doesn't know the real meaning of the words
he uses but twists them to form his lies.

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

On 7/20/24 10:47 AM, olcott wrote:

On 7/20/2024 4:20 AM, Mikko wrote:

On 2024-07-19 14:54:07 +0000, olcott said:

On 7/19/2024 1:35 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 17:37 schreef olcott:

On 7/18/2024 10:27 AM, joes wrote:

When you are hungry you remain hungry until you eat.
    Before HHH(DDD) aborts its emulation the directly
    executed DDD() cannot possibly halt.

As lame as your other analogies. Being hungry is a state: one can be
sometimes hungry and other times not whithout becaming another person.
Programs are constant texts. They don't have states. They only have
permanent properties.

Right and like Richard says every program always executes
all of itself steps simultaneously so there is never a
point in the execution trace before HHH has aborted its
emulation of DDD when it needs to abort this emulation.
DDD is already aborted before HHH begins to execute.

It is easy to spot liars when they deny tautologies.

Yes, like you do.

The BEHAVIOR of a program is established instanatinously by the code and creates the FULL listing of the step that WILL HAPPEN (as they are fully determined by the code and data).

Thus "Needs to be aborted" is a property of a given input that is a
constant over time.

At the begining, HHH doesn't have an idea of that value, so it observes
it for a while, HHH doesn't have the knowledge of the value, but the
value exists.

If the input is infinite_loop, then HHH will discover that value at some
point, and then aborts. Neither learning of the value, nor aborting
changed the value of the operation "needs to abort".

When you try to look at the infinite set of HHHs looking at the infinite
set of DDDs then each individual DDD has a fixed value of "Needs to be aborted", which will be false for all the DDDs built on HHHs that will
decide to abort and return and will be true for all DDDs built on HHHs
that will never abort.

The fact that your aborting HHHs do so on the erroneous decision that
they think the HHH that DDD calls will not halt, even when they do, is
what makes them get the wrong answer.

Part of your problem is that you try to define that all thes DDDs are
the "same" because you want to exclude HHH from its description, but
that makes DDD NOT A PROGRAM, and thus outside the domain of what
Computain theory talks about with halting.

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

On 7/20/24 10:49 AM, olcott wrote:

On 7/20/2024 4:30 AM, Mikko wrote:

On 2024-07-19 14:46:19 +0000, olcott said:

On 7/19/2024 4:07 AM, Mikko wrote:

On 2024-07-17 13:30:07 +0000, olcott said:

On 7/17/2024 2:49 AM, Mikko wrote:

On 2024-07-16 14:20:09 +0000, olcott said:

On 7/16/2024 3:32 AM, Mikko wrote:

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting >>>>>>>>>>>>> behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour >>>>>>>>>>>> if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be >>>>>>>>>> aborted.

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH. >>>>>>>>

That is not an acceptable axiom. That you are unable to prove that >>>>>>>> either XXX is aborted or HHH does not terminate is insufficient >>>>>>>> reason to call it an axiom.

*Premise* (assumed to be true)
Any input that must be aborted to prevent
the non termination of HHH

*Logically entailed by the above premise*
necessarily specifies non-halting behavior or
it would never need to be aborted.

No, it is not. Both "need to be" and "must be" are different from
"is".
The correct asxiom is "If the program can be executed to its
halting in
a finite time then the program specifies a halting behaviour."

From the fact that XXX must be aborted we can conclude that XXX >>>>>>>>> must be aborted.

Nothing that contains the word "must" is a fact.

When simulated input X stops running {if and only if}
the simulation of this input X has been aborted this
necessitates that input X specifies non-halting behavior.

Nothing that contains the word "necessitates" is a fact, either.
Perhaps you should learn some philosophy.

<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> >>>>>
_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stops running unless aborted.

That Professor Sipser does not express any agreement with anything
about the syntax of facts is not relevant to our (or any) discussion
about syntax of facts.

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

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

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or HHH, emulated DDD and executed DDD
never stop running.

If HHH can detect that a part of the code to be emulated ie HHH itself it
may skip the emulation of itself and continue from the return. The
knowledge
that HHH always terminates can be coded in HHH. Therefore the abortion is
not necessary.

In other words you are suggesting that HHH lies and
makes pretend that recursive emulation does not exist.

Since if HHH aborts its emulation and returns, that INFINITE recursive emulation does not exist.

It LIES if it aborts and says that INFINITE RECURSION exists that causes
DDD to be non-halting.

Remember, the question is about the behavior of the program represented
by the input, which is the DDD that calls this HHH. It doesn't matter
HOW that program reaches its final state, just that it does. So the fact
that each HHH makes an error in aborting its emulation, because it could
have gone on and the next one would abort and return, doesn't change the
right answer.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

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

Op 20.jul.2024 om 16:54 schreef olcott:

On 7/20/2024 4:39 AM, Mikko wrote:

On 2024-07-19 14:43:53 +0000, olcott said:

On 7/19/2024 4:02 AM, Mikko wrote:

On 2024-07-16 18:26:12 +0000, olcott said:

On 7/16/2024 3:16 AM, Mikko wrote:

On 2024-07-15 13:51:14 +0000, olcott said:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in >>>>>>>>>> your argument because you have misdefined what the input is. >>>>>>>>>>
The input to HHH is ALL of the memory that it would be
accessed in a correct simulation of DDD, which includes all >>>>>>>>>> the codd of HHH, and thus, if you change HHH you get a
different input.

If you want to try to claim the input is just the bytes of the >>>>>>>>>> function DDD proper then you are just admitting that you are >>>>>>>>>> nothing more than a lying idiot that doesn't understand the >>>>>>>>>> problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a
Turing machine.

No that is wrong. The finite string must encode a Turing machine. >>>>>>

That you agree does not mean that it is wrong.

Your ignorance that a Turing machine cannot take its own
executing self as an input is no rebuttal what-so-ever.

You should not assume that everyone is as stupid as you.

That all rebuttals to my work have one fatal flaw or
another is beyond the comprehension of my reviewers
provides zero evidence that these rebuttals are not flawed.

You can claim that the indications of flaws of your "work" are flawed
but that does not remove the indicated flaws from your work.

Every rebuttal of my work denies a tautology
proving that the rebuttal is incorrect because
all tautologies are necessarily true.

int main()
{
  DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

*The above is a Tautology*

It is not, because the input is the same HHH that aborts and halts, so
its simulation halts when it is not aborted.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that skips the real behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

Op 20.jul.2024 om 15:32 schreef olcott:

On 7/20/2024 3:48 AM, Fred. Zwarts wrote:

Op 19.jul.2024 om 16:56 schreef olcott:

On 7/19/2024 1:40 AM, Fred. Zwarts wrote:

Op 18.jul.2024 om 16:18 schreef olcott:

On 7/18/2024 3:41 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:56 schreef olcott:

On 7/17/2024 9:32 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 16:20 schreef olcott:

On 7/17/2024 8:54 AM, Fred. Zwarts wrote:

Op 17.jul.2024 om 15:27 schreef olcott:

HHH is not allowed to report on the behavior of it actual self >>>>>>>>>>> in its own directly executed process. HHH is allowed to
report on
the effect of the behavior of the simulation of itself
simulating DDD.

But only on the effect of a correct simulation.

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

It is self evident that a program that aborts will halt.
The semantics of the x86 code of a halting program is also
self-evident: it halts.
So, the aborting HHH, when simulated correctly, stops.
Dreaming of a HHH that does not abort is irrelevant.

That is all the dishonest dodge of the strawman deception.
HHH is required to halt by its design spec.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*THIS IS SELF EVIDENT THUS DISAGREEMENT IS INCORRECT*
DDD emulated by any pure function HHH according to the
semantic meaning of its x86 instructions never stops
running unless aborted.

Dreaming of a HHH that does not halt, when we are talking about a
HHH that aborts and halts is irrelevant. Therefore, the 'unless
aborted' is irrelevant. The semantics of the x86 instructions are
self-evident: HHH halts.

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

No, but HHH would have halted when not aborted, because that is how
it is programmed. That is the semantics of its x86 code.

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or
HHH, emulated DDD and executed DDD never stop running.

Whether HHH *must* abort, or *not abort* is irrelevant.

In other words you can't begin to understand hypothetical
possibilities, thus this material may simply be over your head.

In other word, you do not understand that hypothetical possibilities are irrelevant when we have a concrete program.

HHH aborts and halts, therefore, there is no need to abort its
simulation. Dreaming of a hypothetical other HHH that does not abort, is irrelevant.

When you think you can prove something by dreaming about hypothetical
other possibilities, logic is over your head.

When HHH is coded to abort, the reason why is no longer relevant when
the behaviour is analysed.
HHH aborts and halts, therefore it is incorrect to abort the simulated
HHH, which would also abort and halt.
The semantics of the x86 language is the same for the direct execution
and for the simulator. The semantics of x86 does not depend on who will interpret it.
HHH, which is coded to abort, cannot refuse to abort, which makes the simulation incorrect.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

On 2024-07-20 14:54:54 +0000, olcott said:

On 7/20/2024 4:39 AM, Mikko wrote:

On 2024-07-19 14:43:53 +0000, olcott said:

On 7/19/2024 4:02 AM, Mikko wrote:

On 2024-07-16 18:26:12 +0000, olcott said:

On 7/16/2024 3:16 AM, Mikko wrote:

On 2024-07-15 13:51:14 +0000, olcott said:

On 7/15/2024 3:37 AM, Mikko wrote:

On 2024-07-15 03:41:24 +0000, olcott said:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>>>> argument because you have misdefined what the input is.

The input to HHH is ALL of the memory that it would be accessed in a >>>>>>>>>> correct simulation of DDD, which includes all the codd of HHH, and >>>>>>>>>> thus, if you change HHH you get a different input.

If you want to try to claim the input is just the bytes of the function
DDD proper then you are just admitting that you are nothing more than a
lying idiot that doesn't understand the problem,

Turing machines only operate on finite strings they do
not operate on other Turing machines *dumbo*

That's right. But the finite string can be a description of a Turing machine.

No that is wrong. The finite string must encode a Turing machine. >>>>>>

That you agree does not mean that it is wrong.

Your ignorance that a Turing machine cannot take its own
executing self as an input is no rebuttal what-so-ever.

You should not assume that everyone is as stupid as you.

That all rebuttals to my work have one fatal flaw or
another is beyond the comprehension of my reviewers
provides zero evidence that these rebuttals are not flawed.

You can claim that the indications of flaws of your "work" are flawed
but that does not remove the indicated flaws from your work.

Every rebuttal of my work denies a tautology
proving that the rebuttal is incorrect because
all tautologies are necessarily true.

int main()
{
DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

*The above is a Tautology*

No, it is not. The code of DDD is not included so it it is not even determinable, let alone a tautology, what HHH(DDD) can or should do.

--
Mikko

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

On 7/21/24 10:09 AM, olcott wrote:

On 7/21/2024 4:57 AM, Mikko wrote:

On 2024-07-20 14:54:54 +0000, olcott said:

Every rebuttal of my work denies a tautology
proving that the rebuttal is incorrect because
all tautologies are necessarily true.

int main()
{
   DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

*The above is a Tautology*

No, it is not. The code of DDD is not included so it it is not even
determinable, let alone a tautology, what HHH(DDD) can or should do.

I prove that DDD is included with fully operational code
so you are contradicting reality. Not the kind of thing
people interested in an honest dialogue would do.

And then you show an incorrect simulation, as the ONLY correct x86
language simulation of a CALL instruction is to show the instructions in
the routine called.

Thus, you prove yourself to be a LIAR.

The problem seems to be that you made yourself totally ignorant of the
field you decided to talk about, and thus made yourself into an ignorant pathological lying idiot who recklessly disregards the truth.

typedef void (*ptr)();
int HHH(ptr P);

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

int main()
{
  DDD();
}

_DDD()
[00002177] 55             push ebp
[00002178] 8bec           mov ebp,esp
[0000217a] 6877210000     push 00002177
[0000217f] e853f4ffff     call 000015d7
[00002184] 83c404         add esp,+04
[00002187] 5d             pop ebp
[00002188] c3             ret
Size in bytes:(0018) [00002188]

_main()
[00002197] 55             push ebp
[00002198] 8bec           mov ebp,esp
[0000219a] e8d8ffffff     call 00002177
[0000219f] 33c0           xor eax,eax
[000021a1] 5d             pop ebp
[000021a2] c3             ret
Size in bytes:(0012) [000021a2]

 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  =========  ============= [00002197][001037e9][00000000] 55         push ebp [00002198][001037e9][00000000] 8bec       mov ebp,esp [0000219a][001037e5][0000219f] e8d8ffffff call 00002177 [00002177][001037e1][001037e9] 55         push ebp [00002178][001037e1][001037e9] 8bec       mov ebp,esp [0000217a][001037dd][00002177] 6877210000 push 00002177 [0000217f][001037d9][00002184] e853f4ffff call 000015d7
New slave_stack at:10388d

Begin Local Halt Decider Simulation   Execution Trace Stored at:113895 [00002177][00113885][00113889] 55         push ebp [00002178][00113885][00113889] 8bec       mov ebp,esp [0000217a][00113881][00002177] 6877210000 push 00002177 [0000217f][0011387d][00002184] e853f4ffff call 000015d7
New slave_stack at:14e2b5
[00002177][0015e2ad][0015e2b1] 55         push ebp [00002178][0015e2ad][0015e2b1] 8bec       mov ebp,esp [0000217a][0015e2a9][00002177] 6877210000 push 00002177 [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00002184][001037e1][001037e9] 83c404     add esp,+04 [00002187][001037e5][0000219f] 5d         pop ebp [00002188][001037e9][00000000] c3         ret [0000219f][001037e9][00000000] 33c0       xor eax,eax [000021a1][001037ed][00000018] 5d         pop ebp [000021a2][001037f1][00000000] c3         ret
Number of Instructions Executed(10071) == 150 Pages

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

On 2024-07-20 14:49:28 +0000, olcott said:

On 7/20/2024 4:30 AM, Mikko wrote:

On 2024-07-19 14:46:19 +0000, olcott said:

On 7/19/2024 4:07 AM, Mikko wrote:

On 2024-07-17 13:30:07 +0000, olcott said:

On 7/17/2024 2:49 AM, Mikko wrote:

On 2024-07-16 14:20:09 +0000, olcott said:

On 7/16/2024 3:32 AM, Mikko wrote:

On 2024-07-15 13:26:22 +0000, olcott said:

On 7/15/2024 3:23 AM, Mikko wrote:

On 2024-07-14 14:38:31 +0000, olcott said:

On 7/14/2024 3:09 AM, Mikko wrote:

On 2024-07-13 20:15:56 +0000, olcott said:

typedef void (*ptr)();
int HHH(ptr P);

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(Infinite_Loop);
   HHH(Infinite_Recursion);
   HHH(DDD);
}

Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting >>>>>>>>>>>>> behavior or it would never need to be aborted.

Everyone understands that DDD specifies a halting behaviour if HHH(DDD) does,

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

Disagreeing with the above is analogous to disagreeing
with arithmetic.

That the input is aborted does not mean that the input must be aborted.

Weasel words. This is an axiom:
Input XXX must be aborted to prevent the non-termination of HHH. >>>>>>>>

That is not an acceptable axiom. That you are unable to prove that >>>>>>>> either XXX is aborted or HHH does not terminate is insufficient >>>>>>>> reason to call it an axiom.

*Premise* (assumed to be true)
Any input that must be aborted to prevent
the non termination of HHH

*Logically entailed by the above premise*
necessarily specifies non-halting behavior or
it would never need to be aborted.

No, it is not. Both "need to be" and "must be" are different from "is". >>>>>> The correct asxiom is "If the program can be executed to its halting in >>>>>> a finite time then the program specifies a halting behaviour."

From the fact that XXX must be aborted we can conclude that XXX must be
aborted.

Nothing that contains the word "must" is a fact.

When simulated input X stops running {if and only if}
the simulation of this input X has been aborted this
necessitates that input X specifies non-halting behavior.

Nothing that contains the word "necessitates" is a fact, either.
Perhaps you should learn some philosophy.

<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> >>>>>
_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stops running unless aborted.

That Professor Sipser does not express any agreement with anything
about the syntax of facts is not relevant to our (or any) discussion
about syntax of facts.

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

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

int main { DDD(); } calls HHH(DDD) that must abort the
emulation of its input or HHH, emulated DDD and executed DDD
never stop running.

If HHH can detect that a part of the code to be emulated ie HHH itself it
may skip the emulation of itself and continue from the return. The knowledge >> that HHH always terminates can be coded in HHH. Therefore the abortion is
not necessary.

In other words you are suggesting that HHH lies and
makes pretend that recursive emulation does not exist.

You are the one that lies. The varant of HHH mentioned above does not
say anything about any recusive emulation. It says "yes".

_DDD()
[00002163] 55 push ebp ; housekeeping
[00002164] 8bec mov ebp,esp ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404 add esp,+04
[00002173] 5d pop ebp
[00002174] c3 ret
Size in bytes:(0018) [00002174]

--
Mikko

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