XPost: comp.theory, sci.logic

On 6/29/24 12:09 PM, olcott wrote:

People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.

Nope, we are not disagreeing with the semantics of the x86 language, we
are disagreeing with your misunderstanding of how it works.

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

void Infinite_Loop()
{
  HERE: goto HERE;
}

void Infinite_Recursion()
{
  Infinite_Recursion();
}

void DDD()
{
  H0(DDD);
}

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

Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.

No the x86 language "knows" NOTHING about H0 being a x86 emulator. It is
just a function that maybe happens to be a partial x86 emulator, but
that is NOT a fundamental result of it being H0.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.

It is construed as non-halting BECAUSE it has been shown that your H0
*WILL* terminate its PARTIAL emulation of the code it is emulating and returning.

Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.

Right, so H0 is REQUIRED to return, and thus if the termination analyser
knows that H0 is a termination analyzer it knows that the call to H0
MUST return, and thus DDD must be a terminating program.

An H0 that doesn't know this, and can't figure out that H0 will return,
but just keeps emulating H0 emulating its input will just fail to meet
its own requirement to return.

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

Right, and the only definition Professor Sipser uses for "Correct
Simulation" is a simulation that EXACTLY REPRODUCES the behavior of the directly executed program represented by the input. Your H doesn't do
that, nor correctly predicts the behavior of such a simulation of the
input (since that behavior is to halt) so it can never proper avail
itself of the second paragraph, so does so erroneously getting the wrong answer.

People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that

The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Except that the "N Steps of DDD correctly emulated" is NOT the
definition of the "behavior" of the input DDD.

"inputs" Do not have "behavoir", that is a property of a program, so the
input only "represents" that program, in this case the program DDD.

Programs are also a COMPLETE specification of the steps the program will execute when run, so you below code is NOT a complete representation of
the program DDD, so has include implicitly the definition of the
SPECIFIC HHH that it has been pair with. One aspect of this implicit
pairing is that this input inlcudes that EXACT HHH as part of its
definition (and thus is NOT a "template" so when you argue about giving
it to some other machine HHH, either you are giving that HHH a DIFFERENT
input, or that other HHH is giving this DDD paired with the original HHH.

The Behavior of this input, given your claim that HHH will "correctly" determine it to be non-halting and return that answer, is thus the
behavior of the program DDD, including the code of THAT HHH that will
return to it and return, and thus your HHH is just wrong about the non-terminating behavior of the input.

Looking at your arguement, we need to look at what you are claiming to
do, and fully define it. Are you trying to make DDD just a template
(which doesn't by itself have behavior), or has DDD been bound to the
decider you are claiming.


In the first case, we can't make any logical determination about THIS
input from the behavior of other deciders looking at OTHER inputs.

In the second case, when the other decider simulates THIS input longer,
it will see that it DOES halt (since THIS HHH returns) so your argument
that "No HHH" can emulate thins

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

*A 100% complete and total rewrite of the prior paper* https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P

Since it is clear that you are making the same mistakes in that paper as
you made here, they don't need repeating.

You are just showing you don't understand any of the basics of the field
you are trying to talk about.

You have programs that are not programs and trying to redefine what
"Halting" means, which just proves you are a liar,

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

XPost: comp.theory, sci.logic

On 6/29/24 1:17 PM, olcott wrote:

On 6/29/2024 11:45 AM, Richard Damon wrote:

On 6/29/24 12:09 PM, olcott wrote:

People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.

Nope, we are not disagreeing with the semantics of the x86 language,
we are disagreeing with your misunderstanding of how it works.

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

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   H0(DDD);
}

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

Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.

No the x86 language "knows" NOTHING about H0 being a x86 emulator. It
is just a function that maybe happens to be a partial x86 emulator,
but that is NOT a fundamental result of it being H0.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.

It is construed as non-halting BECAUSE it has been shown that your H0
*WILL* terminate its PARTIAL emulation of the code it is emulating and
returning.

Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.

Right, so H0 is REQUIRED to return, and thus if the termination
analyser knows that H0 is a termination analyzer it knows that the
call to H0 MUST return, and thus DDD must be a terminating program.

An H0 that doesn't know this, and can't figure out that H0 will
return, but just keeps emulating H0 emulating its input will just fail
to meet its own requirement to return.

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

Right, and the only definition Professor Sipser uses for "Correct
Simulation" is a simulation that EXACTLY REPRODUCES the behavior of
the directly executed program represented by the input. Your H doesn't
do that, nor correctly predicts the behavior of such a simulation of
the input (since that behavior is to halt) so it can never proper
avail itself of the second paragraph, so does so erroneously getting
the wrong answer.

People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that

The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Except that the "N Steps of DDD correctly emulated" is NOT the
definition of the "behavior" of the input DDD.

"inputs" Do not have "behavoir", that is a property of a program, so
the input only "represents" that program, in this case the program DDD.

*According to the professor Sipser approved criteria YES IT IS*

Nope. Where dp you see that in what he says? Remember, you need to
interpret the words by what he means them to say.

His ONLY definition of "Correct Simulation" is a simulation that exactly recreates the behavior of the program described by the input, and that
in one that does not stop its simulation. So, NOT your "N Step"

So, you are just stuck in your lies, by trying to change the meaning of
the words that others are argeeing to.

The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Maybe you can say that HHH can not emulate the input to the return, but
that is a different claim.

The behavior for only N steps (N determined by the decider) is NOT a
valid definition of the behavior of the input, as it isn't a property of
the just the input. It is a SUBJECTIVE measure, not an OBJECTIVE measure.

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

Which, as I have pointed out, CAN'T be the sole definition of the input,
as it does not represent a "program, thus showing you argument is built
on deception.

Your "input", must implicitly include the one and only HHH that THIS
input has been paired to.

Either your problem is just invalid as DDD isn't a program at all,

or you are talking about a large (infinite) set of inputs, and you can't actually talk about any of them individually, and thus there is no *THE* behavior of *THE* input, as you don't have just a single program you are talking about,

or, your argument breaks as all your other deciders get this exact input calling this exact HHH which shows that it will return when you look at
it with another version of HHH, looking that that original input calling
that original HHH and it sees that the original HHH will return and thus
DDD will return.

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

XPost: comp.theory, sci.logic

On 6/29/24 2:06 PM, olcott wrote:

On 6/29/2024 12:59 PM, Richard Damon wrote:

On 6/29/24 1:17 PM, olcott wrote:

On 6/29/2024 11:45 AM, Richard Damon wrote:

On 6/29/24 12:09 PM, olcott wrote:

People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.

Nope, we are not disagreeing with the semantics of the x86 language,
we are disagreeing with your misunderstanding of how it works.

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

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   H0(DDD);
}

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

Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.

No the x86 language "knows" NOTHING about H0 being a x86 emulator.
It is just a function that maybe happens to be a partial x86
emulator, but that is NOT a fundamental result of it being H0.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.

It is construed as non-halting BECAUSE it has been shown that your
H0 *WILL* terminate its PARTIAL emulation of the code it is
emulating and returning.

Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.

Right, so H0 is REQUIRED to return, and thus if the termination
analyser knows that H0 is a termination analyzer it knows that the
call to H0 MUST return, and thus DDD must be a terminating program.

An H0 that doesn't know this, and can't figure out that H0 will
return, but just keeps emulating H0 emulating its input will just
fail to meet its own requirement to return.

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

Right, and the only definition Professor Sipser uses for "Correct
Simulation" is a simulation that EXACTLY REPRODUCES the behavior of
the directly executed program represented by the input. Your H
doesn't do that, nor correctly predicts the behavior of such a
simulation of the input (since that behavior is to halt) so it can
never proper avail itself of the second paragraph, so does so
erroneously getting the wrong answer.

People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that

The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Except that the "N Steps of DDD correctly emulated" is NOT the
definition of the "behavior" of the input DDD.

"inputs" Do not have "behavoir", that is a property of a program, so
the input only "represents" that program, in this case the program DDD. >>>>

*According to the professor Sipser approved criteria YES IT IS*

Nope. Where dp you see that in what he says? Remember, you need to
interpret the words by what he means them to say.

His ONLY definition of "Correct Simulation" is a simulation that
exactly recreates the behavior of the program described by the input,
and that in one that does not stop its simulation. So, NOT your "N Step"

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

Professor Sipser certainly would not be stupid enough to
disagree with the semantics of the x86 programming language.

Of course not, and the semantics of the x86 programming language say
that the behavior of a piecee of code (which must be fully defined,
unlike your example) is exactly what it does when run.

"Correct Emulation" of code doesn't arbitrarily stop the emulation,
except to generate only a PARTIAL dec

You are like the thief caught in the act of stealing money
from a cash register and with the stolen money still in your
hand denying that you have any stolen money in your hand.

Really, where is my lie?

YOU are the one that has been caught "red handed" with you numerous lies
that you avoid answering about.

Where is ANY of the authorativive references for ANY of your claims?

MISSING, because you lie about them.

How does your emulator correctly emulate the call instruction when you
don't provide the code it calls?

Where does the x86 language say that ANY instruction begins an
"emulation" of the code provided to the instruction. (Especially when
such emulation has an implicit conditionality to it that you try to ignore).

You are just proving that you whole argument is based on your own lies.

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

XPost: comp.theory, sci.logic

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

On 6/29/2024 12:59 PM, Richard Damon wrote:

On 6/29/24 1:17 PM, olcott wrote:

On 6/29/2024 11:45 AM, Richard Damon wrote:

On 6/29/24 12:09 PM, olcott wrote:

People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.

Nope, we are not disagreeing with the semantics of the x86
language, we are disagreeing with your misunderstanding of how it
works.

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

void Infinite_Loop()
{
   HERE: goto HERE;
}

void Infinite_Recursion()
{
   Infinite_Recursion();
}

void DDD()
{
   H0(DDD);
}

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

Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.

No the x86 language "knows" NOTHING about H0 being a x86 emulator. >>>>>> It is just a function that maybe happens to be a partial x86
emulator, but that is NOT a fundamental result of it being H0.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.

It is construed as non-halting BECAUSE it has been shown that your >>>>>> H0 *WILL* terminate its PARTIAL emulation of the code it is
emulating and returning.

Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.

Right, so H0 is REQUIRED to return, and thus if the termination
analyser knows that H0 is a termination analyzer it knows that the >>>>>> call to H0 MUST return, and thus DDD must be a terminating program. >>>>>>
An H0 that doesn't know this, and can't figure out that H0 will
return, but just keeps emulating H0 emulating its input will just
fail to meet its own requirement to return.

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

Right, and the only definition Professor Sipser uses for "Correct
Simulation" is a simulation that EXACTLY REPRODUCES the behavior
of the directly executed program represented by the input. Your H
doesn't do that, nor correctly predicts the behavior of such a
simulation of the input (since that behavior is to halt) so it can >>>>>> never proper avail itself of the second paragraph, so does so
erroneously getting the wrong answer.

People are trying to get away with disagreeing with the semantics >>>>>>> of the x86 language by disagreeing that

The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Except that the "N Steps of DDD correctly emulated" is NOT the
definition of the "behavior" of the input DDD.

"inputs" Do not have "behavoir", that is a property of a program,
so the input only "represents" that program, in this case the
program DDD.

*According to the professor Sipser approved criteria YES IT IS*

Nope. Where dp you see that in what he says? Remember, you need to
interpret the words by what he means them to say.

His ONLY definition of "Correct Simulation" is a simulation that
exactly recreates the behavior of the program described by the
input, and that in one that does not stop its simulation. So, NOT
your "N Step"

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly
emulated by HHH would never stop running unless aborted
or out-of-memory error

*proves that you are trying to get away with a bald-faced lie*
I really hope that you repent before it is too late.

Nope, just shows your stupidity, as the above code has NO defined
behavior as it accesses code that is not defined by it.

When you include that code, your claim is non-sense, as the definition
of HHH becomes FIXED AND DEFINED and your terminology meaningless.

"unless" implies choices, which no longer exist, as HHH has been
specifed so it does or it doesn't.

If HHH DOES abort its simulation and returns, then DDD DOES return.

"DDD correctly emulated by HHH", when that emulation is allowed to be
partial, is NOT a valid property for the input, as it is not a property
of JUST the input. So, the ONLY possible meanings are that you are
defining HHH to NEVER abort, at which poiht the "unless" is meaningless
as something defined to never abort can't abort, or that you are just
using wrong definitons of terms.

Sorry, but you "logic" is just filled with illogic and is just based on deception and lies.

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

XPost: comp.theory, sci.logic

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION per HIS
definition does not halt
.
That means the DIRECT EXECUTION of the program represented by the input
does not halt, since that is the DEFINITION of the results of a correct simuation.

That also requires that the simulation does not stop until it reaches a
final state. You H neither does that nor correctly determines that
(since it does halt) thus you can never use the second paragraph to be
allowed to abort, even though you do anyway, which is why you get the
wrong answer.

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly
emulated by HHH would never stop running unless aborted
or out-of-memory error

*proves that you are trying to get away with a bald-faced lie*
I really hope that you repent before it is too late.

Nope, just shows your stupidity, as the above code has NO defined
behavior as it accesses code that is not defined by it.

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
    the recursive emulation call from DDD to HHH(DDD).

But by the semantics of the x86 langugage, the call to HHH does NOT do a "recursive simulation" since that is not a term in that language.

The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates
    N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL correct
emulation (since correct emulation implies EVERY instruction but a
terminal one is followed by the next instruction).

The key fact is that PARTIAL emulation doesn't reveal the future of the behavior past the point of the emulation. But the "Behavior" of the
program represtented by the input, does.

Remember, "Behavior" is an attribute of programs, not "inputs", inputs
only point to the behavior of the program they represent. Programs do
not "stop" just because some emulation of them ceased.

*I am not infallible so I may have left out a detail*

Like FACTS.

*These facts are deduced from the above facts*
(1) The call from DDD to HHH(DDD) when N steps of DDD are
   correctly emulated by any pure function x86 emulator
   HHH cannot possibly return.

No, the CALL DOES return (if HHH is a decider), that return is just not emulated by HHH, which being just a PARTIAL emulation doesn't reveal the behavior after it aborts its emulation.

(2) (1) means that DDD correctly simulated by HHH would
    never stop running unless aborted.

Nope, It means that either you have an HHH that never stops its
emulation, and thus fail to be the decider you claim, or that it does
and doesn't do

I don't understand why you risk your salvation
by trying to get away with such a bald-faced lie.

But it isn't a lie. It is the truth.

You just don't seem to understand that knowing just part of what is
correct isn't knowing ALL of what is correct.

Those the believe salvation cannot be lost may
correct in the God sees their future behavior thus
never granting them salvation in the first place.

That is one theory.

Doesn't seem it really matters to you, since it is clear you were never
came close to salvation, as you don't accept God's word as his word, but
have decided you get to pick and choose from it.

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

XPost: comp.theory, sci.logic

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION per HIS
definition does not halt
.
That means the DIRECT EXECUTION of the program represented by the
input does not halt, since that is the DEFINITION of the results of a
correct simuation.

That also requires that the simulation does not stop until it reaches
a final state. You H neither does that nor correctly determines that
(since it does halt) thus you can never use the second paragraph to be
allowed to abort, even though you do anyway, which is why you get the
wrong answer.

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly
emulated by HHH would never stop running unless aborted
or out-of-memory error

*proves that you are trying to get away with a bald-faced lie*
I really hope that you repent before it is too late.

Nope, just shows your stupidity, as the above code has NO defined
behavior as it accesses code that is not defined by it.

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
     the recursive emulation call from DDD to HHH(DDD).

But by the semantics of the x86 langugage, the call to HHH does NOT do
a "recursive simulation" since that is not a term in that language.

The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates
     N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL correct
emulation (since correct emulation implies EVERY instruction but a
terminal one is followed by the next instruction).

The key fact is that PARTIAL emulation doesn't reveal the future of
the behavior past the point of the emulation.

In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:

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

Nope, he just laid a trap that you fell into.

The ONLY simulation that Professor Sipser accepts as correct, is one
that shows EXACTLY the behavior of the machine being simulated.

Thus, for H to determine that its simulated D would never stop running
unless aborted, that means that the UTM simulation of this input would
never stop running. That is the only "simulated D" that has meaning in
the subject. The "its" refers to the simulation of this machines input.

Since that doesn't happen, your H can not correct determine that it would.

So, you H can not use the clause to have permission to abort.

Now, if you had saind until H correctly determines that its simulaiton
of D would never stop running unless aborted you might have had a leg to
stand on, except that just has a meaningless "unless" as this H either
does or does not abort, and can not do the other thing.

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

XPost: comp.theory, sci.logic

On 6/29/24 4:33 PM, olcott wrote:

On 6/29/2024 3:25 PM, Richard Damon wrote:

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION per HIS
definition does not halt
.
That means the DIRECT EXECUTION of the program represented by the
input does not halt, since that is the DEFINITION of the results of
a correct simuation.

That also requires that the simulation does not stop until it
reaches a final state. You H neither does that nor correctly
determines that (since it does halt) thus you can never use the
second paragraph to be allowed to abort, even though you do anyway,
which is why you get the wrong answer.

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly
emulated by HHH would never stop running unless aborted
or out-of-memory error

*proves that you are trying to get away with a bald-faced lie*
I really hope that you repent before it is too late.

Nope, just shows your stupidity, as the above code has NO defined
behavior as it accesses code that is not defined by it.

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
     the recursive emulation call from DDD to HHH(DDD).

But by the semantics of the x86 langugage, the call to HHH does NOT
do a "recursive simulation" since that is not a term in that language. >>>>
The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates
     N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL correct
emulation (since correct emulation implies EVERY instruction but a
terminal one is followed by the next instruction).

The key fact is that PARTIAL emulation doesn't reveal the future of
the behavior past the point of the emulation.

In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:

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

Nope, he just laid a trap that you fell into.

He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.

Right, and he could have seen the errors in your apparent
misunderstanding of the words and accepted them, knowing that they were actually meaningless.

The ONLY simulation that Professor Sipser accepts as correct, is one
that shows EXACTLY the behavior of the machine being simulated.

So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?

The question said NOTHING of the x86 language, so it doesn't matter.

Since you said "Halt Decider" he would be correct to asume you were
talking about Turing Machines.

And, in Turing Machines, the only thing talked about as far as
"Simulation" would be the UTM, and that ONLY does fully correct and
complete simulations, so barring very clear mention otherwise, that is
what is assumed.

I guess you are just admitting you fell for the trap.

*I don't buy it. You are not that stupid you are a liar*

But YOU seem to be that stupid, or self-enforced ignorant.

You just don't know what is actually true.

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

XPost: comp.theory, sci.logic

On 6/29/24 6:54 PM, olcott wrote:

On 6/29/2024 4:19 PM, Richard Damon wrote:

On 6/29/24 4:33 PM, olcott wrote:

On 6/29/2024 3:25 PM, Richard Damon wrote:

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION per HIS >>>>>> definition does not halt
.
That means the DIRECT EXECUTION of the program represented by the
input does not halt, since that is the DEFINITION of the results
of a correct simuation.

That also requires that the simulation does not stop until it
reaches a final state. You H neither does that nor correctly
determines that (since it does halt) thus you can never use the
second paragraph to be allowed to abort, even though you do
anyway, which is why you get the wrong answer.

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly
emulated by HHH would never stop running unless aborted
or out-of-memory error

*proves that you are trying to get away with a bald-faced lie* >>>>>>>>> I really hope that you repent before it is too late.

Nope, just shows your stupidity, as the above code has NO
defined behavior as it accesses code that is not defined by it. >>>>>>>>

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
     the recursive emulation call from DDD to HHH(DDD).

But by the semantics of the x86 langugage, the call to HHH does
NOT do a "recursive simulation" since that is not a term in that
language.

The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates
     N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL
correct emulation (since correct emulation implies EVERY
instruction but a terminal one is followed by the next instruction). >>>>>>
The key fact is that PARTIAL emulation doesn't reveal the future
of the behavior past the point of the emulation.

In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:

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

Nope, he just laid a trap that you fell into.

He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.

Right, and he could have seen the errors in your apparent
misunderstanding of the words and accepted them, knowing that they
were actually meaningless.

The ONLY simulation that Professor Sipser accepts as correct, is one
that shows EXACTLY the behavior of the machine being simulated.

So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?

The question said NOTHING of the x86 language, so it doesn't matter.

Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!

But the question to Professor Sipser was, as you quoted:

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


Which said NOTHING about the x86 language,

So, who is the liar now?

_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 call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Which wasn't what we were talking about with Professor Sipser, who never
saw any of that.

I guess you just have a major brain malfunction and can't keep your lies straight.

This just proves your unreliability when it comes to statements

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

XPost: comp.theory, sci.logic

On 6/29/24 10:46 PM, olcott wrote:

On 6/29/2024 6:46 PM, Richard Damon wrote:

On 6/29/24 6:54 PM, olcott wrote:

On 6/29/2024 4:19 PM, Richard Damon wrote:

On 6/29/24 4:33 PM, olcott wrote:

On 6/29/2024 3:25 PM, Richard Damon wrote:

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>> until H correctly determines that its simulated D would never >>>>>>>>> stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION per >>>>>>>> HIS definition does not halt
.
That means the DIRECT EXECUTION of the program represented by
the input does not halt, since that is the DEFINITION of the
results of a correct simuation.

That also requires that the simulation does not stop until it
reaches a final state. You H neither does that nor correctly
determines that (since it does halt) thus you can never use the >>>>>>>> second paragraph to be allowed to abort, even though you do
anyway, which is why you get the wrong answer.

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly >>>>>>>>>>> emulated by HHH would never stop running unless aborted
or out-of-memory error

*proves that you are trying to get away with a bald-faced lie* >>>>>>>>>>> I really hope that you repent before it is too late.

Nope, just shows your stupidity, as the above code has NO
defined behavior as it accesses code that is not defined by it. >>>>>>>>>>

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
     the recursive emulation call from DDD to HHH(DDD).

But by the semantics of the x86 langugage, the call to HHH does >>>>>>>> NOT do a "recursive simulation" since that is not a term in that >>>>>>>> language.

The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates
     N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL
correct emulation (since correct emulation implies EVERY
instruction but a terminal one is followed by the next
instruction).

The key fact is that PARTIAL emulation doesn't reveal the future >>>>>>>> of the behavior past the point of the emulation.

In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:

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

Nope, he just laid a trap that you fell into.

He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.

Right, and he could have seen the errors in your apparent
misunderstanding of the words and accepted them, knowing that they
were actually meaningless.

The ONLY simulation that Professor Sipser accepts as correct, is
one that shows EXACTLY the behavior of the machine being simulated. >>>>>>

So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?

The question said NOTHING of the x86 language, so it doesn't matter.

Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!

But the question to Professor Sipser was, as you quoted:

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


Which said NOTHING about the x86 language,

So, who is the liar now?

_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 call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Which wasn't what we were talking about with Professor Sipser, who
never saw any of that.

I guess you just have a major brain malfunction and can't keep your
lies straight.

This just proves your unreliability when it comes to statements

Partial halt deciders constructed for the x86 language
are isomorphic to this termination analyzer build for
the C programming language.

Which still has nothing to do with you LYING about your question to
Professor Sipser.

And x86 is not fully isomorphic to the C programming language.

The x86 language is probably easier to simulate but harder to decide on, because it can create more complicated interactions.

Note, there isn't a trivial translation between x86 and C (or LLVM). C
to LLVM to x86 is algorithmically doable, but with a lot of options at
each step. And when doing the reverse, you normally don't get anything
like the original code you started with.

And then we get to the fact that "Halt Deciding" and "Termination
Analying" are DIFFERENT problems, Halt Deciding being if a particular Program/Input will halt when it is run, while Termination Analysers
answer if there is ANY input that might make a given machine not Halt. A
much different problem (which you clearly don't understand).

*AProVE: Non-Termination Witnesses for C Programs*
To prove (non-)termination of a C program, AProVE uses the
Clang compiler [7] to translate it to the intermediate
representation of the LLVM framework [15]. Then AProVE
symbolically executes the LLVM program and uses abstraction
to obtain a finite symbolic execution graph (SEG) containing
all possible program runs. https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf

Which isn't based on "Pure Emulation" like your deciders are. There is a
lot of pre-work done to determine what parts might need to be emulated.
Note, since "Termination Analyzers" don't have an input to the program,
the "emulation" they do needs to be different, but looking at the
mapping of possible states to possible states.

Even a Turing machine based partial halt decider is
locked in to the Turing Machine description language.
Is this really over your head?

But there isn't a single Turing Machine Description Language that all
UTMs use.

Also, the Theory isn't about "Partial" Halt Deciders, as those are
numerous, but about Correct Halt Decider (implied Complete, i.e. handles
ALL inputs), so switching to partial decider is just a deceitful dodge.

It is still true that the xemantics of the x86 language define the
behavior of a set of bytes, as the behavior when you ACTUALLY RUN THEM,
and nothing else.

And that means, you need the code for the COMPLETE program (or
sub-program) to talk about behavior, which includes the code for
everything that one piece of code calls, so for your D family of inputs,
the H family of deciders that it has been paired with.

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

XPost: comp.theory, sci.logic

On 6/30/24 10:07 AM, olcott wrote:

On 6/30/2024 7:34 AM, Richard Damon wrote:

On 6/29/24 10:46 PM, olcott wrote:

On 6/29/2024 6:46 PM, Richard Damon wrote:

On 6/29/24 6:54 PM, olcott wrote:

On 6/29/2024 4:19 PM, Richard Damon wrote:

On 6/29/24 4:33 PM, olcott wrote:

On 6/29/2024 3:25 PM, Richard Damon wrote:

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>> 10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>>>> until H correctly determines that its simulated D would never >>>>>>>>>>> stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION per >>>>>>>>>> HIS definition does not halt
.
That means the DIRECT EXECUTION of the program represented by >>>>>>>>>> the input does not halt, since that is the DEFINITION of the >>>>>>>>>> results of a correct simuation.

That also requires that the simulation does not stop until it >>>>>>>>>> reaches a final state. You H neither does that nor correctly >>>>>>>>>> determines that (since it does halt) thus you can never use >>>>>>>>>> the second paragraph to be allowed to abort, even though you >>>>>>>>>> do anyway, which is why you get the wrong answer.

*N steps of correct simulation are specified*
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly >>>>>>>>>>>>> emulated by HHH would never stop running unless aborted >>>>>>>>>>>>> or out-of-memory error

*proves that you are trying to get away with a bald-faced lie* >>>>>>>>>>>>> I really hope that you repent before it is too late. >>>>>>>>>>>>>

Nope, just shows your stupidity, as the above code has NO >>>>>>>>>>>> defined behavior as it accesses code that is not defined by it. >>>>>>>>>>>>

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes
     the recursive emulation call from DDD to HHH(DDD). >>>>>>>>>>

But by the semantics of the x86 langugage, the call to HHH >>>>>>>>>> does NOT do a "recursive simulation" since that is not a term >>>>>>>>>> in that language.

The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates
     N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL >>>>>>>>>> correct emulation (since correct emulation implies EVERY
instruction but a terminal one is followed by the next
instruction).

The key fact is that PARTIAL emulation doesn't reveal the
future of the behavior past the point of the emulation.

In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:

H correctly simulates its input D until H correctly determines >>>>>>>>> that its simulated D would never stop running unless aborted

Nope, he just laid a trap that you fell into.

He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.

Right, and he could have seen the errors in your apparent
misunderstanding of the words and accepted them, knowing that they >>>>>> were actually meaningless.

The ONLY simulation that Professor Sipser accepts as correct, is >>>>>>>> one that shows EXACTLY the behavior of the machine being simulated. >>>>>>>>

So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?

The question said NOTHING of the x86 language, so it doesn't matter. >>>>>>

Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!

But the question to Professor Sipser was, as you quoted:

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

Which said NOTHING about the x86 language,

So, who is the liar now?

_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 call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Which wasn't what we were talking about with Professor Sipser, who
never saw any of that.

I guess you just have a major brain malfunction and can't keep your
lies straight.

This just proves your unreliability when it comes to statements

Partial halt deciders constructed for the x86 language
are isomorphic to this termination analyzer build for
the C programming language.

Which still has nothing to do with you LYING about your question to
Professor Sipser.

And x86 is not fully isomorphic to the C programming language.

The x86 language is probably easier to simulate but harder to decide
on, because it can create more complicated interactions.

Note, there isn't a trivial translation between x86 and C (or LLVM). C
to LLVM to x86 is algorithmically doable, but with a lot of options at
each step. And when doing the reverse, you normally don't get anything
like the original code you started with.

And then we get to the fact that "Halt Deciding" and "Termination
Analying" are DIFFERENT problems, Halt Deciding being if a particular
Program/Input will halt when it is run, while Termination Analysers
answer if there is ANY input that might make a given machine not Halt.
A much different problem (which you clearly don't understand).

*AProVE: Non-Termination Witnesses for C Programs*
To prove (non-)termination of a C program, AProVE uses the
Clang compiler [7] to translate it to the intermediate
representation of the LLVM framework [15]. Then AProVE
symbolically executes the LLVM program and uses abstraction
to obtain a finite symbolic execution graph (SEG) containing
all possible program runs.
https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf

Which isn't based on "Pure Emulation" like your deciders are. There is
a lot of pre-work done to determine what parts might need to be
emulated. Note, since "Termination Analyzers" don't have an input to
the program, the "emulation" they do needs to be different, but
looking at the mapping of possible states to possible states.

Even a Turing machine based partial halt decider is
locked in to the Turing Machine description language.
Is this really over your head?

But there isn't a single Turing Machine Description Language that all
UTMs use.

Also, the Theory isn't about "Partial" Halt Deciders, as those are
numerous, but about Correct Halt Decider (implied Complete, i.e.
handles ALL inputs), so switching to partial decider is just a
deceitful dodge.

It is still true that the xemantics of the x86 language define the
behavior of a set of bytes, as the behavior when you ACTUALLY RUN
THEM, and nothing else.

That stupid idea forces "interpreting" the call to HHH(DDD)
from DDD simulated by HHH to disagree with the x86 language
and return when the x86 language says this is impossible.

Why do you say that?

By the x86 language, HHH is just a series of instructions to do something.

And without the bytes specified, we don't know what they do.

There is no way to try to specify AT THE x86 instruction level, that HHH
is an "emulator" as that isn't a concept at the x86 instruction level.

Also, it is a LIE to say HHH is a "x86 Emulator", as that term,
unadorned, means it is an UNCONDITIONAL emulator (like a UTM) which is
isn't since you define that it has the power to decide that its input is non-halting (and might do it incorrectly) and thus its emulation at each
step is conditional on that logic.

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

And that means, you need the code for the COMPLETE program (or
sub-program) to talk about behavior, which includes the code for
everything that one piece of code calls, so for your D family of
inputs, the H family of deciders that it has been paired with.

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

XPost: comp.theory, sci.logic

On 6/30/24 5:37 PM, olcott wrote:

On 6/30/2024 2:31 PM, Richard Damon wrote:

On 6/30/24 10:07 AM, olcott wrote:

On 6/30/2024 7:34 AM, Richard Damon wrote:

On 6/29/24 10:46 PM, olcott wrote:

On 6/29/2024 6:46 PM, Richard Damon wrote:

On 6/29/24 6:54 PM, olcott wrote:

On 6/29/2024 4:19 PM, Richard Damon wrote:

On 6/29/24 4:33 PM, olcott wrote:

On 6/29/2024 3:25 PM, Richard Damon wrote:

On 6/29/24 4:17 PM, olcott wrote:

On 6/29/2024 3:10 PM, Richard Damon wrote:

On 6/29/24 3:25 PM, olcott wrote:

On 6/29/2024 2:08 PM, Richard Damon wrote:

On 6/29/24 2:47 PM, olcott wrote:

On 6/29/2024 1:38 PM, Richard Damon wrote:

On 6/29/24 2:06 PM, olcott wrote:

<MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>>>> 10/13/2022>
If simulating halt decider H correctly simulates its input D >>>>>>>>>>>>> until H correctly determines that its simulated D would never >>>>>>>>>>>>> stop running unless aborted then

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

But that only applies if H determines a CORRECT SIMULATION >>>>>>>>>>>> per HIS definition does not halt
.
That means the DIRECT EXECUTION of the program represented >>>>>>>>>>>> by the input does not halt, since that is the DEFINITION of >>>>>>>>>>>> the results of a correct simuation.

That also requires that the simulation does not stop until >>>>>>>>>>>> it reaches a final state. You H neither does that nor
correctly determines that (since it does halt) thus you can >>>>>>>>>>>> never use the second paragraph to be allowed to abort, even >>>>>>>>>>>> though you do anyway, which is why you get the wrong answer. >>>>>>>>>>>>

*N steps of correct simulation are specified* >>>>>>>>>>>>>>>>> H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H
H correctly simulates its input D until H

Which does not determine the ACTUAL behavor

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

That you already know that it does prove that DDD correctly >>>>>>>>>>>>>>> emulated by HHH would never stop running unless aborted >>>>>>>>>>>>>>> or out-of-memory error

*proves that you are trying to get away with a bald-faced >>>>>>>>>>>>>>> lie*
I really hope that you repent before it is too late. >>>>>>>>>>>>>>>

Nope, just shows your stupidity, as the above code has NO >>>>>>>>>>>>>> defined behavior as it accesses code that is not defined >>>>>>>>>>>>>> by it.

*Its behavior is completely defined by*
(a) The finite string x86 machine code that includes >>>>>>>>>>>>>      the recursive emulation call from DDD to HHH(DDD). >>>>>>>>>>>>

But by the semantics of the x86 langugage, the call to HHH >>>>>>>>>>>> does NOT do a "recursive simulation" since that is not a >>>>>>>>>>>> term in that language.

The Call to HHH just cause the

(b) The semantics of the x86 language.

(c) That HHH is an x86 emulator that correctly emulates >>>>>>>>>>>>>      N steps of DDD.

Which isn't an ACTUALY correct emulation, but only a PARTIAL >>>>>>>>>>>> correct emulation (since correct emulation implies EVERY >>>>>>>>>>>> instruction but a terminal one is followed by the next >>>>>>>>>>>> instruction).

The key fact is that PARTIAL emulation doesn't reveal the >>>>>>>>>>>> future of the behavior past the point of the emulation. >>>>>>>>>>>

In other words you are trying to get away with claiming
that professor Sipser made a stupid mistake:

H correctly simulates its input D until H correctly determines >>>>>>>>>>> that its simulated D would never stop running unless aborted >>>>>>>>>>

Nope, he just laid a trap that you fell into.

He could not have possibly laid any trap you dumb bunny.
All of the words were my own verbatim words. It took me
two years to compose those exact words.

Right, and he could have seen the errors in your apparent
misunderstanding of the words and accepted them, knowing that
they were actually meaningless.

The ONLY simulation that Professor Sipser accepts as correct, >>>>>>>>>> is one that shows EXACTLY the behavior of the machine being >>>>>>>>>> simulated.

So you are stupid enough to believe that professor Sipser
is stupid enough to to try and get away with disagreeing
with the semantics of the x86 language?

The question said NOTHING of the x86 language, so it doesn't
matter.

Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!
Liar Liar pants on fire !!!

But the question to Professor Sipser was, as you quoted:

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


Which said NOTHING about the x86 language,

So, who is the liar now?

_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 call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

Which wasn't what we were talking about with Professor Sipser, who >>>>>> never saw any of that.

I guess you just have a major brain malfunction and can't keep
your lies straight.

This just proves your unreliability when it comes to statements

Partial halt deciders constructed for the x86 language
are isomorphic to this termination analyzer build for
the C programming language.

Which still has nothing to do with you LYING about your question to
Professor Sipser.

And x86 is not fully isomorphic to the C programming language.

The x86 language is probably easier to simulate but harder to decide
on, because it can create more complicated interactions.

Note, there isn't a trivial translation between x86 and C (or LLVM).
C to LLVM to x86 is algorithmically doable, but with a lot of
options at each step. And when doing the reverse, you normally don't
get anything like the original code you started with.

And then we get to the fact that "Halt Deciding" and "Termination
Analying" are DIFFERENT problems, Halt Deciding being if a
particular Program/Input will halt when it is run, while Termination
Analysers answer if there is ANY input that might make a given
machine not Halt. A much different problem (which you clearly don't
understand).

*AProVE: Non-Termination Witnesses for C Programs*
To prove (non-)termination of a C program, AProVE uses the
Clang compiler [7] to translate it to the intermediate
representation of the LLVM framework [15]. Then AProVE
symbolically executes the LLVM program and uses abstraction
to obtain a finite symbolic execution graph (SEG) containing
all possible program runs.
https://link.springer.com/content/pdf/10.1007/978-3-030-99527-0_21.pdf >>>>

Which isn't based on "Pure Emulation" like your deciders are. There
is a lot of pre-work done to determine what parts might need to be
emulated. Note, since "Termination Analyzers" don't have an input to
the program, the "emulation" they do needs to be different, but
looking at the mapping of possible states to possible states.

Even a Turing machine based partial halt decider is
locked in to the Turing Machine description language.
Is this really over your head?

But there isn't a single Turing Machine Description Language that
all UTMs use.

Also, the Theory isn't about "Partial" Halt Deciders, as those are
numerous, but about Correct Halt Decider (implied Complete, i.e.
handles ALL inputs), so switching to partial decider is just a
deceitful dodge.

It is still true that the xemantics of the x86 language define the
behavior of a set of bytes, as the behavior when you ACTUALLY RUN
THEM, and nothing else.

That stupid idea forces "interpreting" the call to HHH(DDD)
from DDD simulated by HHH to disagree with the x86 language
and return when the x86 language says this is impossible.

Why do you say that?

By the x86 language, HHH is just a series of instructions to do
something.

Then what you are saying here are just words that are
about something or other and no more specific than that.

No, since you have defined that meaning is based on the x86 instructions
set, and its correct emulation, then the ONLY thing a "call HHH"
instruction can mean, is that the next steps of the behavior will be the emulation of the instructions of HHH.

There is no "option" to define that HHH is an emulator and that the call
to HHH just starts an emulation, because that isn't behavior defined in
the x86 instruction set.

Also, HHH is no "a x86 emulator" but a CONDITIONAL x86 emulator, and
that fact is important. For one thing, it means that you can not, even
under an "equivalency" of emulation replace the emulation of the
emulator with the machie it is emulating as you are doing, as that is
only valid for an UNCONDITIONAL emulation, which isn't what HHH does.

And without the bytes specified, we don't know what they do.

There is no way to try to specify AT THE x86 instruction level, that
HHH is an "emulator" as that isn't a concept at the x86 instruction
level.

Also, it is a LIE to say HHH is a "x86 Emulator", as that term,
unadorned, means it is an UNCONDITIONAL emulator (like a UTM) which is
isn't since you define that it has the power to decide that its input
is non-halting (and might do it incorrectly) and thus its emulation at
each step is conditional on that logic.

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

And that means, you need the code for the COMPLETE program (or
sub-program) to talk about behavior, which includes the code for
everything that one piece of code calls, so for your D family of
inputs, the H family of deciders that it has been paired with.

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

XPost: comp.theory, sci.logic

Op 29.jun.2024 om 18:09 schreef olcott:

People are still trying to get away with disagreeing with
the semantics of the x86 language. That is isomorphic to
trying to get away with disagreeing with arithmetic.

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

void Infinite_Loop()
{
  HERE: goto HERE;
}

void Infinite_Recursion()
{
  Infinite_Recursion();
}

void DDD()
{
  H0(DDD);
}

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

Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop, Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.

When this is construed as non-halting criteria then simulating
termination analyzer H0 is correct to reject these inputs as
non-halting by returning 0 to its caller.

Simulating termination analyzers must report on the behavior
that their finite string input specifies thus H0 must report
that DDD correctly emulated by H0 remains stuck in recursive
simulation.

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

People are trying to get away with disagreeing with the semantics
of the x86 language by disagreeing that

The call from DDD to HHH(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator HHH cannot possibly
return.

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

*A 100% complete and total rewrite of the prior paper* https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P

Apparently the x86 language and simulation are to complex for you. Make
it simple. What about the following halt decider:

int Halt (ptr p) {
return 1;
}

It is clear that the question "Will de program described in the input
halt" is incorrect, because Halt is unable to process that question, so
we cannot ask that question. Therefore, we need to redefine the question
to "Does the program described in the input halt or not?".
And since the expression (X || !X) always result in true for any value
of X, the Halt function is always correct and we have solved the halting problem.

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