On 8/12/24 9:43 PM, olcott wrote:

We prove that the simulation is correct.

Which means it runs unitl it reaches a final state, and exactly details
the behavior of the machine the input represents.

Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted.

Which means that a NON-ABORTED simulation of this input will never reach
the final state.

And that input is exactly the input that you will use belew.

The semantics of the x86 language conclusive proves this is true.

Only if you FOLLOW the x86 language semantics, which again says you
can't stop the simulation that defines the behavior until it reaches a
final state.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

And, if that string doesn't contrain the code for the decider it was
built on, it isn't the right string, as it isn't a program.

https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Except that the only way for HHH to DO a correct emulation is to never
abort, and thus is can't return if its input is non-halting.

If it does abort, then the fact that its simulation didn't reach a final
state doesn't say anything, we need to give that exact same input (which
will be INCLUDE the copy of the decider that it was built on that
doesn't change for this verification step) to a real complete simulator.

That simulator will see the start of the input program call the copy of
the decider that the input usses, and since it aborts and returns, it
will see the copy do that same thing which will thus return to the based decider which will halt.

Your problems are you think the input doesn't contain the copy of the
decider, and thus all the inputs to every decider in your infinite set
of input/decider pairs are the same, but then the input isn't a program,
and you argument makes a category error.

Then, you try to let a partial simulation that doesn't reach the final
state to be considered a "correct simulation" such that its not reaching
the final state indicates non-halting, which is just an error.

Sorry, these errors have been expalined many times, and the fact you
keep repeating them either means you are totally stupid, and can't even
see that you are stupid (the worse kind of stupid) or are such a liar
that you don't care that your lies are so blatant, which is worse.


Note, you also need to fix your decider so it IS a computation, and thus
not vary its behavior based on things other than it explicit input,
which basically removes the option of using static memory like your
currect bunch uses.

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

Le 13/08/2024 à 03:43, olcott a écrit :

We prove that the simulation is correct.

No. You didn't.

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

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted.
The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is
not interesting.

The behviour specified by DDD on the first page of the linked article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies non-halting behaviour" is either uninteresting or unsound.

--
Mikko

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

Op 13.aug.2024 om 15:04 schreef olcott:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted.
The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is
not interesting.

The behviour specified by DDD on the first page of the linked article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies
non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

Contradiction in terminus.
A correct simulation is not possible. The simulation failes to reach the
final halt state.

It is true that anyone that cannot understand this is true
has insufficient technical competence.

In particular when he thinks that a simulation that fails to reach the
final halt status of a halting program is correct.

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

Op 13.aug.2024 om 17:25 schreef olcott:

On 8/13/2024 9:40 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 15:04 schreef olcott:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted. >>>>> The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is >>>> not interesting.

The behviour specified by DDD on the first page of the linked article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies >>>> non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

Contradiction in terminus.
A correct simulation is not possible.

*YOU JUST DON'T GET THIS*
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is stipulated to be correct.

You don't get that you cannot stipulate that something is correct. It
must be proven. The semantics of the x86 language does not allow to use
only the first N instructions of a halting program.

*YOU JUST DON'T GET THIS EITHER*
A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

A false claim, without any evidence. HHH is stipulated to halt. So, when
the simulation of HHH does not reach its final halt state, then the
simulation failed. The unlimited simulation, e.g. by HHH1, shows that it
halts.
But the aborting HHH cannot do an unlimited simulation of *itself*.
Therefore it fails to reach the halting state. A failed simulation.
HHH cannot possible simulate itself correctly.

*YOU JUST DON'T GET THIS EITHER*
Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs.

You don't get that a prediction is incorrect when the input has halting behaviour and the prediction claims non-halting.

*MOST JUST DON'T GET THIS*
Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs, thus
the behavior of non-inputs is outside of their domain.

You don't get that DDD includes HHH. HHH is required to halt, so DDD
halts as well. A correct prediction of this input would be that it
halts. That can be done, e.g., by HHH1, but not by HHH itself.

You don't get that HHH cannot possibly simulate itself correctly.

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

Op 13.aug.2024 om 18:36 schreef olcott:

On 8/13/2024 11:11 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 17:25 schreef olcott:

On 8/13/2024 9:40 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 15:04 schreef olcott:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being
aborted.
The semantics of the x86 language conclusive proves this is true. >>>>>>>
Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the
proof is
not interesting.

The behviour specified by DDD on the first page of the linked article >>>>>> is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD)
specifies
non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

Contradiction in terminus.
A correct simulation is not possible.

*YOU JUST DON'T GET THIS*
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is stipulated to be correct.

You don't get that you cannot stipulate that something is correct.

It is objectively incorrect to disagree with the semantics
of the x86 language when one is assessing whether or not
an emulation of N instructions of an input is correct or
incorrect.

If you can't agree to that anything else that you say is moot.

It is objectively incorrect to say that a simulation is correct when it
only simulated the first N instructions correctly.
It is twisting the meaning of words to say that the simulation is
correct, if only the first N instructions are correctly simulated and
the next M instructions, up to the end are skipped.
So, I do not disagree that the simulation made a correct start, but
after that it failed to reach the end of the simulation.

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

Op 13.aug.2024 om 20:07 schreef olcott:

On 8/13/2024 12:58 PM, Fred. Zwarts wrote:

Op 13.aug.2024 om 18:36 schreef olcott:

On 8/13/2024 11:11 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 17:25 schreef olcott:

On 8/13/2024 9:40 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 15:04 schreef olcott:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being >>>>>>>>> aborted.
The semantics of the x86 language conclusive proves this is true. >>>>>>>>>
Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies >>>>>>>>> non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the >>>>>>>> proof is
not interesting.

The behviour specified by DDD on the first page of the linked
article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting. >>>>>>>>
Any proof of the false statement that "the input to HHH(DDD)
specifies
non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

Contradiction in terminus.
A correct simulation is not possible.

*YOU JUST DON'T GET THIS*
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is stipulated to be correct.

You don't get that you cannot stipulate that something is correct.

It is objectively incorrect to disagree with the semantics
of the x86 language when one is assessing whether or not
an emulation of N instructions of an input is correct or
incorrect.

If you can't agree to that anything else that you say is moot.

It is objectively incorrect to say that a simulation is correct when
it only simulated the first N instructions correctly.

It is objectively correct to say that the first N instructions
were emulated correctly when the first N instructions were
emulated correctly.

Changing my words then providing a rebuttal for these changed
words is a form of intentional deceit known as strawman.

*You* are changing words.
A few lines above *you* said:

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

Here you are not talking about a few correctly simulated instructions,
but about the simulation of a program.
Now you say that you are not talking about 'DDD correctly simulated by
HHH', but that HHH only made a good start when correctly simulating only
the first N instructions.

We can agree that HHH made a good start in the simulation by simulating
N instructions, but it failed to complete the simulation.

I am not changing your words, but I wonder whether you remember and
understand your own words.

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

On 8/13/24 4:43 PM, olcott wrote:

On 8/13/2024 3:38 PM, joes wrote:

Am Tue, 13 Aug 2024 08:30:08 -0500 schrieb olcott:

HHH correctly predicts that a correct and unlimited emulation of DDD by
HHH cannot possibly reach its own "return" instruction final halt state.

If let run, the HHH called by DDD will abort and return.

H has never ever been required to do an unlimited emulation of a
non-halting input. H has only ever been required to correctly predict
what the behavior of a unlimited emulation would be.

Which it doesn't fulfill.

*I break this down into smaller steps here*

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

Nope, it may be the correct PARTIAL emulation of just the first N
instructions of DDD, but if DDD runs for more than N instructions, it
isn't a correct emulation of DDD.

Do you correctly walk all they way on a five mile trail, if you leave
after walking the first mile.

NO.

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope. Proven wrong and you have never even tried to refute that proof.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs, thus
the behavior of non-inputs is outside of their domain.

And that behavior, BY DEFINITION, is the behavior of the directly
exectuted machine that the input represents.

THAT IS BY DEFINITION, and any claim otherwise just prove you are a
stupid liar that doesn't know what he is talking about.

Try to prove otherwise.

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

On 8/13/24 11:36 AM, olcott wrote:

On 8/12/2024 8:43 PM, olcott wrote:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted.
The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

*ESSENCE OF PROOF OF KEY POINTS*
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is stipulated to be correct.

Not a valid stipulation, you can not stipulate something to be "correct".

If you mean to stipulate a MEANING for corect, then you just locked your
self out of using "correct" in the normal meaning, and thus locked you
self out of proving anything.

Using your "stipulation" of correct, to mean that you are stipulating
what will be considered to be a "Correct Simulation" for your previous statement, that make that statement FALSE, because ANY DDD that calls an
HHH that will simulate for just N instructions and then return will be
HALTING by simple inspection.

Yes, the simulation doesn't reach the final state, but partial
simulation don't show what happens as a final state of the machine (or
if it reaches on).

You keep repeating this error, proving that you seem to have a learning disability that prevents you from understanding the true meaning of words.

If you want to change your statement to be an actruism, then you need to
say something like: "It is true that no partial or complete correct
simulaiton of DDD by HHH will ever reach the return instruction of DDD".

The key is you need simulation, not DDD to be the subject of the verb
reach, so that is what you are actually talking about, and what reaches
(or not) the final state.

A correct simulation of N instructions of DDD by HHH is
sufficient to correctly predict the behavior of an unlimited
simulation.

Nope, proven incorrect, as the unlimited simulation of the DDD that
calls the HHH that does the partial simulation, and then returns, will
see that DDD call the HHH and then the HHH will simulate those N
instructions and then returns to the DDD and DDD then reaches it final
state.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs.

Which *IS* the behavior of the program the input represents, BY
DEFINITION OF A HALT DECIDER.

Also, that means HHH must consider the HHH that DDD calls to be the
actual HHH which is there, which is itself, and it can not argue that if
it didn't abort, the simulation would go on, as if HHH aobrts, so does
the one that DDD calls, and thus that DDD is halting.

Termination analyzers / halt deciders are only required
to correctly predict the behavior of their inputs, thus
the behavior of non-inputs is outside of their domain.

Which *IS* the behavior of the program the input represents, BY
DEFINITION OF A HALT DECIDER.

Also, that means HHH must consider the HHH that DDD calls to be the
actual HHH which is there, which is itself, and it can not argue that if
it didn't abort, the simulation would go on, as if HHH aobrts, so does
the one that DDD calls, and thus that DDD is halting.

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

On 8/13/24 2:07 PM, olcott wrote:

On 8/13/2024 12:58 PM, Fred. Zwarts wrote:

Op 13.aug.2024 om 18:36 schreef olcott:

On 8/13/2024 11:11 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 17:25 schreef olcott:

On 8/13/2024 9:40 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 15:04 schreef olcott:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being >>>>>>>>> aborted.
The semantics of the x86 language conclusive proves this is true. >>>>>>>>>
Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies >>>>>>>>> non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the >>>>>>>> proof is
not interesting.

The behviour specified by DDD on the first page of the linked
article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting. >>>>>>>>
Any proof of the false statement that "the input to HHH(DDD)
specifies
non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

Contradiction in terminus.
A correct simulation is not possible.

*YOU JUST DON'T GET THIS*
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is stipulated to be correct.

You don't get that you cannot stipulate that something is correct.

It is objectively incorrect to disagree with the semantics
of the x86 language when one is assessing whether or not
an emulation of N instructions of an input is correct or
incorrect.

If you can't agree to that anything else that you say is moot.

It is objectively incorrect to say that a simulation is correct when
it only simulated the first N instructions correctly.

It is objectively correct to say that the first N instructions
were emulated correctly when the first N instructions were
emulated correctly.

Changing my words then providing a rebuttal for these changed
words is a form of intentional deceit known as strawman.

But the first N instructions are not ALL the instructions and thus do
not provide a completely correct view of what the program does, and not
being completely correct is just INCORRECT.

One lie spoils a proof, many lies prove one to be a LIAR.

We have lost count of the number of lies you have stated, since it has
gotten so big.

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

On 2024-08-13 13:04:17 +0000, olcott said:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted.
The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is
not interesting.

The behviour specified by DDD on the first page of the linked article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies
non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

If DDD does not halt then HHH does not halt.

--
Mikko

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

Op 13.aug.2024 om 21:20 schreef olcott:

On 8/13/2024 2:08 PM, Fred. Zwarts wrote:

Op 13.aug.2024 om 20:07 schreef olcott:

On 8/13/2024 12:58 PM, Fred. Zwarts wrote:

Op 13.aug.2024 om 18:36 schreef olcott:

On 8/13/2024 11:11 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 17:25 schreef olcott:

On 8/13/2024 9:40 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 15:04 schreef olcott:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being >>>>>>>>>>> aborted.
The semantics of the x86 language conclusive proves this is >>>>>>>>>>> true.

Thus when we measure the behavior specified by this finite >>>>>>>>>>> string by DDD correctly simulated/emulated by HHH it specifies >>>>>>>>>>> non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the >>>>>>>>>> proof is
not interesting.

The behviour specified by DDD on the first page of the linked >>>>>>>>>> article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting. >>>>>>>>>>
Any proof of the false statement that "the input to HHH(DDD) >>>>>>>>>> specifies
non-halting behaviour" is either uninteresting or unsound. >>>>>>>>>>

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state. >>>>>>>>

Contradiction in terminus.
A correct simulation is not possible.

*YOU JUST DON'T GET THIS*
A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is stipulated to be correct.

You don't get that you cannot stipulate that something is correct.

It is objectively incorrect to disagree with the semantics
of the x86 language when one is assessing whether or not
an emulation of N instructions of an input is correct or
incorrect.

If you can't agree to that anything else that you say is moot.

It is objectively incorrect to say that a simulation is correct when
it only simulated the first N instructions correctly.

It is objectively correct to say that the first N instructions
were emulated correctly when the first N instructions were
emulated correctly.

Changing my words then providing a rebuttal for these changed
words is a form of intentional deceit known as strawman.

*You* are changing words.
A few lines above *you* said:

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

It is cheating to provide a rebuttal to the words that I
actually said right now based on any other words that I
said anywhere else.

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

We can agree that HHH made a good start for the simulation with a
correct simulation of the first N steps, but failed to complete the
simulation by not reaching the end of the simulation.

Note that the semantics of the x86 language does not depend on who or
what is using it. The direct execution uses the same semantics and it
correctly shows that the end of the program can be reached according to
this semantics. So, when the simulator does not reach the end, it
deviates from the semantics of the input, when it processes the same input.

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

Op 14.aug.2024 om 15:49 schreef olcott:

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

On 2024-08-13 13:04:17 +0000, olcott said:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted. >>>>> The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is >>>> not interesting.

The behviour specified by DDD on the first page of the linked article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies >>>> non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

If DDD does not halt then HHH does not halt.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

The impossibility of DDD emulated by HHH
(according to the semantics of the x86 language)
to reach its own machine address [00002183] is
complete proof that DDD never halts.

This has nothing to do with whether or not HHH
halts.

Even a beginner sees that DDD halts if and only if HHH halts.
In fact 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.
It shows that HHH cannot possibly simulate itself correctly.

HHH is simply unable to decide about comparable finite recursions.

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

Op 14.aug.2024 om 15:56 schreef olcott:

On 8/14/2024 4:01 AM, Fred. Zwarts wrote:

Op 13.aug.2024 om 21:20 schreef olcott:

A simulation of N instructions of DDD by HHH according to
the semantics of the x86 language is necessarily correct.

We can agree that HHH made a good start for the simulation with a
correct simulation of the first N steps, but failed to complete the
simulation by not reaching the end of the simulation.

No wrong. That N instructions were emulating correctly
is the whole point. Anything else is a distraction from
this point.

No, you are trying to twist the meaning of the words. Simulating a few instructions is not a correct simulation of a program.

Note that the semantics of the x86 language does not depend on who or
what is using it. The direct execution uses the same semantics and it
correctly shows that the end of the program can be reached according
to this semantics. So, when the simulator does not reach the end, it
deviates from the semantics of the input, when it processes the same
input.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

The is a hypothetical mental exercise and can be
accomplished even if the only DDD in the world
was simply typed into a word processor and never run.

HHH can be purely imaginary yet must emulate the
above code and itself according to the semantics
of the x86 language. In this case HHH is a pure
emulator.

(a) On this basis we know that such an HHH would
emulate the first four instructions of DDD.

(b) This includes a calls from the emulated DDD
to an emulated HHH(DDD).

(c) This emulated HHH would emulate the first
four instructions of DDD.

(b) and (c) keep repeating.

We can do that all in our head never needing
any actually existing HHH.

Indeed, the HHH that is a pure simulator that does not abort, does not
halt. But it is incorrect to say that it simulates only the first four instructions of DDD. If it is a correct simulator, then it will also
simulate the instructions in the called HHH.

But this is all a change of subject and distraction from the subject
because we were talking about the HHH that halts, which can only be the
case if it aborts.
The HHH that does not abort should now disappear from your head and we
now look only at the HHH that aborts and halts.
For this HHH it is not true that '(b) and (c) keep repeating', because
it aborts after N cycles.
That is something we can do in our head, too.
We see that when HHH aborts after N cycles, the simulated HHH has only performed N-1 cycles. The simulated HHH has the same code as the
simulating HHH and, therefore, has the same behaviour. Both the
simulating and the simulated HHH are coded to abort after N cycles. So,
we can see in our head that the simulated HHH would also abort after N
cycles, but it was aborted prematurely, when it was only 1 cycle from
the end.
This makes that the simulation is incomplete and, therefore, incorrect.

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

On 2024-08-14 13:49:28 +0000, olcott said:

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

On 2024-08-13 13:04:17 +0000, olcott said:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted. >>>>> The semantics of the x86 language conclusive proves this is true.

Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is >>>> not interesting.

The behviour specified by DDD on the first page of the linked article
is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies >>>> non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

If DDD does not halt then HHH does not halt.

_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]

The impossibility of DDD emulated by HHH
(according to the semantics of the x86 language)
to reach its own machine address [00002183] is
complete proof that DDD never halts.

This has nothing to do with whether or not HHH
halts.

Everone who understands either C or x86 machine code can see that
the next thing DDD does after the return from HHH (if HHH ever
returns) is that DDD returns. There is no conditional code that
could cause anything else. Therefore, if DDD does not return
the inference that HHH does not return is correct.

--
Mikko

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

On 2024-08-15 15:07:11 +0000, olcott said:

On 8/15/2024 3:13 AM, Mikko wrote:

On 2024-08-14 13:49:28 +0000, olcott said:

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

On 2024-08-13 13:04:17 +0000, olcott said:

On 8/13/2024 5:57 AM, Mikko wrote:

On 2024-08-13 01:43:49 +0000, olcott said:

We prove that the simulation is correct.
Then we prove that this simulation cannot possibly
reach its final halt state / ever stop running without being aborted. >>>>>>> The semantics of the x86 language conclusive proves this is true. >>>>>>>
Thus when we measure the behavior specified by this finite
string by DDD correctly simulated/emulated by HHH it specifies
non-halting behavior.

https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

Input to HHH(DDD) is DDD. If there is any other input then the proof is >>>>>> not interesting.

The behviour specified by DDD on the first page of the linked article >>>>>> is halting if HHH(DDD) halts. Otherwise HHH is not interesting.

Any proof of the false statement that "the input to HHH(DDD) specifies >>>>>> non-halting behaviour" is either uninteresting or unsound.

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

It is true that DDD correctly emulated by any HHH cannot
possibly reach its own "return" instruction final halt state.

If DDD does not halt then HHH does not halt.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

The impossibility of DDD emulated by HHH
(according to the semantics of the x86 language)
to reach its own machine address [00002183] is
complete proof that DDD never halts.

This has nothing to do with whether or not HHH
halts.

Everone who understands either C or x86 machine code can see that
the next thing DDD does after the return from HHH (if HHH ever
returns) is that DDD returns.

It is 100% impossible for the first emulated instance
of DDD to return because it is never called.

Whether the first emulated instance is called or not does not
affect the behaviour that DDD specifies.

--
Mikko

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