On 7/13/24 2:53 PM, olcott wrote:

On 7/13/2024 1:33 PM, Richard Damon wrote:

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

On 7/13/2024 12:25 PM, Richard Damon wrote:

On 7/13/24 12:48 PM, olcott wrote:

What is the correct halt status for an input to
a simulating termination analyzer that calls its
own termination analyzer?

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

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(DDD);
}

Halting.

Since HHH defined to be a termination analyzer, by that definition
it must return to its caller.

Since DDD has no inputs, its behavior isn't affected by any inputs,
and thus DDD will halt for ALL input conditions, so

You are stupidly saying that Infinite_Loop() will halt because
it has no inputs.

Where did I say no input means halting?

I said that since DDD has no inputs, a Termination analyizer doesn't
need to look over all inputs, as there are no inputs to affect it.

Maybe you forget that a Termination Analyzer is not the same thing as
a Halt Decider.

A Halt Decider determines if the given program will halt for the given
input, and needs to be given both (if the program takes an input).

A Termination Analyzer determines if a given program will halt for
every possible input, and thus is only given the program, and not the
input to test.


Note, for Infinite_Loop below, it IS possible for a simulator to
detect a condition in a finite amount of time that an unbounded
emulation would never halt, so can answer correctly non-halting.

The problem with trying to apply that to DDD is it isn't true, give
the DDD that uses the HHH that tries to think it has determined it to
never halt to a actual pure emulator (and thus DDD still calls that
HHH that thinks it has determined that DDD will not halt and aborts
its emulation and returns) then the pure emulatior will see that HHH
make that decisioin and return to DDD which will return.

Thus HHH can never actually make that same conclusion. You logic is
incorrrect as you presume the input changes with the emulator, but it
actually doesn't, it changes with the emulator you have stated is the
one that gives the correct answer, which you can't change in the
middle of the problem.

void Infinite_Loop()
{
   HERE: goto HERE;
}

for HHH to be a correct termination analysizer it needs to return
the value to indicate Halting.

Yes

And thus, it WILL return that value to the DDD that calls it, and that
DDD will halt.

Your version

I am asking What is the correct halt status for HHH(DDD)
that at least one element of every possible pure function
HHH can provide.

The only correct answer it is able to give is Halt.

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

But the DDD that this HHH is given doesn't need to be aborted.

That is proven by HHH1(DDD).

Remember, the "Input" DDD, includes ALL the code of the program DDD,
which includes the HHH that it is paired with.

EVERY ONE of these versions of DDD that is paired with a HHH that does
aborts its simulation and returns to its caller, when given to an
emulator that does not abort, will see that returning behavior.

You *LIE* by trying to change your DDD when you do that, which is just a
LIE.

The ONLY DDD that doesn't return are the DDD paired with an HHH that
never aborts, and that one never gives an answer for that input, so
fails too.

So, you LIE when you compare the results of the HHH that is given a DDD
that uses the HHH that aborts, to the results of the other HHH that is
given a DDD that uses the HHH that doesn't abort. They are different
inputs, because you LIE about what the input is, because you LIE about
it not including the HHH that it calls, which means you LIE that any of
your HHH CAN emulate per the x86 there input past the call instruction.

In short, your argument is based on nothing by LYING.

Professor Sipser understood this tautology that is
over-your-head.

Nope, you don't understand what he said, so just LIE.

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

On 7/13/24 3:45 PM, olcott wrote:

On 7/13/2024 2:40 PM, Richard Damon wrote:

On 7/13/24 3:23 PM, olcott wrote:

On 7/13/2024 2:10 PM, Richard Damon wrote:

On 7/13/24 2:53 PM, olcott wrote:

On 7/13/2024 1:33 PM, Richard Damon wrote:

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

On 7/13/2024 12:25 PM, Richard Damon wrote:

On 7/13/24 12:48 PM, olcott wrote:

What is the correct halt status for an input to
a simulating termination analyzer that calls its
own termination analyzer?

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

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(DDD);
}

Halting.

Since HHH defined to be a termination analyzer, by that
definition it must return to its caller.

Since DDD has no inputs, its behavior isn't affected by any
inputs, and thus DDD will halt for ALL input conditions, so

You are stupidly saying that Infinite_Loop() will halt because
it has no inputs.

Where did I say no input means halting?

I said that since DDD has no inputs, a Termination analyizer
doesn't need to look over all inputs, as there are no inputs to
affect it.

Maybe you forget that a Termination Analyzer is not the same thing >>>>>> as a Halt Decider.

A Halt Decider determines if the given program will halt for the
given input, and needs to be given both (if the program takes an
input).

A Termination Analyzer determines if a given program will halt for >>>>>> every possible input, and thus is only given the program, and not
the input to test.


Note, for Infinite_Loop below, it IS possible for a simulator to
detect a condition in a finite amount of time that an unbounded
emulation would never halt, so can answer correctly non-halting.

The problem with trying to apply that to DDD is it isn't true,
give the DDD that uses the HHH that tries to think it has
determined it to never halt to a actual pure emulator (and thus
DDD still calls that HHH that thinks it has determined that DDD
will not halt and aborts its emulation and returns) then the pure
emulatior will see that HHH make that decisioin and return to DDD
which will return.

Thus HHH can never actually make that same conclusion. You logic
is incorrrect as you presume the input changes with the emulator,
but it actually doesn't, it changes with the emulator you have
stated is the one that gives the correct answer, which you can't
change in the middle of the problem.

void Infinite_Loop()
{
   HERE: goto HERE;
}

for HHH to be a correct termination analysizer it needs to
return the value to indicate Halting.

Yes

And thus, it WILL return that value to the DDD that calls it, and
that DDD will halt.

Your version

I am asking What is the correct halt status for HHH(DDD)
that at least one element of every possible pure function
HHH can provide.

The only correct answer it is able to give is Halt.

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

But the DDD that this HHH is given doesn't need to be aborted.

That is proven by HHH1(DDD).

That is not the same DDD instance and you know it.
That is the DDD after HHH has aborted its DDD.

My code shows HHH1 creating a process context and
HHH creating two more different contexts.

HHH1 depends on HHH aborting its own different DDD
for the DDD of HHH1 to halt.

And you ignore the fundamental fact that ALL DDDs built on the same
code in HHH will behave the same.

*You are just going to lie about this into perpetuity*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

But *THIS* input doesn't need to be aborted, because the HHH that this
DDD calls DOES abort its simulation (because the one you claimed to be
correct did) and thus THIS HHH could be replaced with a fully correct
emulator (done without changing the input, so is at a different memory
address) and that will simulate it to the end,

Your problem is your setup make you perform incorrect logic because you
don't notice you are changing your input when you aren't allowed to in
order to prove "need" for THIS input.

You just don't understand the fundamental of programming to know that
you can't change the input when you are arguing about the properties of
THAT input.

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

On 7/13/24 3:23 PM, olcott wrote:

On 7/13/2024 2:10 PM, Richard Damon wrote:

On 7/13/24 2:53 PM, olcott wrote:

On 7/13/2024 1:33 PM, Richard Damon wrote:

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

On 7/13/2024 12:25 PM, Richard Damon wrote:

On 7/13/24 12:48 PM, olcott wrote:

What is the correct halt status for an input to
a simulating termination analyzer that calls its
own termination analyzer?

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

void DDD()
{
   HHH(DDD);
}

int main()
{
   HHH(DDD);
}

Halting.

Since HHH defined to be a termination analyzer, by that definition >>>>>> it must return to its caller.

Since DDD has no inputs, its behavior isn't affected by any
inputs, and thus DDD will halt for ALL input conditions, so

You are stupidly saying that Infinite_Loop() will halt because
it has no inputs.

Where did I say no input means halting?

I said that since DDD has no inputs, a Termination analyizer doesn't
need to look over all inputs, as there are no inputs to affect it.

Maybe you forget that a Termination Analyzer is not the same thing
as a Halt Decider.

A Halt Decider determines if the given program will halt for the
given input, and needs to be given both (if the program takes an
input).

A Termination Analyzer determines if a given program will halt for
every possible input, and thus is only given the program, and not
the input to test.


Note, for Infinite_Loop below, it IS possible for a simulator to
detect a condition in a finite amount of time that an unbounded
emulation would never halt, so can answer correctly non-halting.

The problem with trying to apply that to DDD is it isn't true, give
the DDD that uses the HHH that tries to think it has determined it
to never halt to a actual pure emulator (and thus DDD still calls
that HHH that thinks it has determined that DDD will not halt and
aborts its emulation and returns) then the pure emulatior will see
that HHH make that decisioin and return to DDD which will return.

Thus HHH can never actually make that same conclusion. You logic is
incorrrect as you presume the input changes with the emulator, but
it actually doesn't, it changes with the emulator you have stated is
the one that gives the correct answer, which you can't change in the
middle of the problem.

void Infinite_Loop()
{
   HERE: goto HERE;
}

for HHH to be a correct termination analysizer it needs to return
the value to indicate Halting.

Yes

And thus, it WILL return that value to the DDD that calls it, and
that DDD will halt.

Your version

I am asking What is the correct halt status for HHH(DDD)
that at least one element of every possible pure function
HHH can provide.

The only correct answer it is able to give is Halt.

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

But the DDD that this HHH is given doesn't need to be aborted.

That is proven by HHH1(DDD).

That is not the same DDD instance and you know it.
That is the DDD after HHH has aborted its DDD.

My code shows HHH1 creating a process context and
HHH creating two more different contexts.

HHH1 depends on HHH aborting its own different DDD
for the DDD of HHH1 to halt.

And you ignore the fundamental fact that ALL DDDs built on the same code
in HHH will behave the same.

If you disagree, what instruction in one of the behaves differently (or
is "correctly emulated" differently) in one than another.

You just don't understand this fundamental fact, which you just lie and
claim to be untrue, but have never actually show the diffference.

The closes is by INCORRECTLY simulating the CALL H instruction to do
something that isn't actually what a call H instruction does, in other
words, you just LIE.

This just proves that you insufficiently understand the basics of how
cojputers work to make any of your claims.

Go ahead, try to show where the differ at an actually correctly
simulated instruction, and not just were you ASSUME they must differ
based on the assumption that they can differ and they need to give
different results.

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