On 9/2/24 12:38 PM, olcott wrote:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

Where the "finite string" is a representation of a Turing Machine and
its input, and the mapping is the behavior of that Machine/Input when run.

Important point, as only a Machine and its input has the "halting"
property, and its is the direct

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

Which MEANS the direct execution of the machine and input the finite
string describes.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

But it can be asked about a computation that includes a copy of itself.

Of course, the decider is looking at an input that might create another instance of itself by using a copy of itself, and that is a valid question.

It is of course structurally impossible for an input to include *THIS*
instance of the decider as the input doesn't specify what "instance" it
is of, just the code, and the instance is created when it is run/simulated.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

No, the "pathological relationship" doesn't affect the meaning of the
input or the question being asked.

The question is SPECIFICALLY about the behavior of the machine and input described to the decider, and NOT about what the decider can determine
about the input.

Sorry, you are just proving that you are nothing but an ignorant liar.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

** According to the semantics of the x86 language.

Which just LIES about what it is trying to show, because you don't
understand the problem you say you are working on.

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

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.
If HHH includes code to see a 'special condition' and aborts and halts,
then it should also simulate the HHH that includes this same code and
will halt. It should not assume that the simulated HHH does not have
this code.

** According to the semantics of the x86 language.

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

On 9/2/24 5:06 PM, olcott wrote:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.

It is emulating the exact same freaking machine code
that the x86utm operating system is emulating.

And either IGNORES it or LIES, as it uses the "rule" of No condition instruction in the emulation of DDD, when there ARE conditional
instructions in the code of the PROGRAM DDD, namely those of the
function HHH that it calls.

If HHH includes code to see a 'special condition' and aborts and
halts, then it should also simulate the HHH that includes this same
code and

DDD has itself and the emulated HHH stuck in recursive emulation.

IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?

But the code IS reachable, since your defined HHH does abort and return,
since that is what you says it does. IT is just that no HHH can reach
that point in its partial emulation of the DDD that calls it.

void Infinite_Recursion()
{
  Infinite_Recursion();
  printf("Fred is too dumb to know this code is never reached!\n");
}

Which isn't the code being trace, proving your. just a pathological liar.

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

On 9/2/24 7:11 PM, olcott wrote:

On 9/2/2024 11:38 AM, olcott wrote:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

** According to the semantics of the x86 language.

This prevents the correctly emulated** DDD from ever
reaching its final halt state no matter what HHH does.

Of course not, since you have defined that your HHH actually DOES abort
to return an answer, the CORRECT x86 emulation of the input DDD (which
isn't what HHH does) steps through the instructions of HHH until it
reaches the point where it aborts its emulation and return to DDD that
returns.

WHat doesn't get there is the PARTIAL (and thus not correct) emulation
done by your HHH.

You can only make your statement work if you stipulate that the HHH you
have shown isn't the HHH that we have, but we have instead the HHH that
never aborts, but then that HHH just fails to be a decider so is wrong also,

You don't get to have two different HHHs in the problem. That is just
your LIE.

Sorry, you are just proving your utter stupidity and ignorance about
what you are talking, and showing how you are just a pathological liar.

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

On 9/2/24 6:22 PM, olcott wrote:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.
If HHH includes code to see a 'special condition' and aborts and
halts, then it should also simulate the HHH that includes this same
code and

DDD has itself and the emulated HHH stuck in recursive emulation.

Only id HHH never aborts, which is NOT what your HHH does, or it fails
to be a decider.

You don't seem to understand that programs can't "change their mind" or
that the "get to decide" what to do, but are just deterministinc
algorithms that do what they are programmed to do.

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

When HHH emulates itself emulating DDD the emulated
HHH cannot possibly return because each DDD keeps
calling HHH to emulate itself again until the outer
executed HHH kills the whole emulated process at
the very first emulated DDD before it ever reaches
its own second line.

Of course it can. and it must if the emulating HHH aborts its emulation
to return an answer.

You just have a funny-mental problem confusing the behavior of the
machine being emulated (which continues even after the emulation
finishes, being a mathematical concept) with the emulation that was done
by the emulator.

DDD and the HHH(DDD) that it calls both return, even though HHH(DDD)
can't emulate to that point, because since they all have the same code,
since you have said that the outer HHH does abort its emulation, the ALL
will, and thus all return.

Sorry, you are just stuck in your ignorance abort how programs work, or
what theu even are.

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

Op 02.sep.2024 om 23:06 schreef olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.

It is emulating the exact same freaking machine code
that the x86utm operating system is emulating.

Even the best simulator will go wrong if it is given the wrong input.
But the world class simulator, when given the DDD with the aborting HHH
as input, that there is a halting program.
It is olcott's modified simulator that fails to reach the end of a
halting program.

If HHH includes code to see a 'special condition' and aborts and
halts, then it should also simulate the HHH that includes this same
code and

DDD has itself and the emulated HHH stuck in recursive emulation.

Only for a few recursion and then HHH aborts, returns to DDD and DDD halts.
We see this in the direct execution, in the simulation by the world
class simulator and even in the simulation by HHH1.

IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?

I know what unreachable code is. But it seems that olcott does not
understand that unreachable code has nothing to do with the halting program.

goto END;

printf ("This is unreachable code!"\n);

END: return

void Infinite_Recursion()
{
  Infinite_Recursion();
  printf("Fred is too dumb to know this code is never reached!\n");
}

Again olcott seems to be unable to process the English language.
I never said that there was an infinite recursion. The infinite
recursion is only in olcotts dream of the HHH that does not abort.

Olcott misses the fact that, when the aborting HHH simulates itself,
there are only a few recursions and then it halts, a bit like:

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
printf ("Olcott thinks this message is never printed!\n");
}

It looks as if it is impossible for him to understand that more than one recursion is not equivalent to an infinite recursion.

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

Op 03.sep.2024 om 00:22 schreef olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.
If HHH includes code to see a 'special condition' and aborts and
halts, then it should also simulate the HHH that includes this same
code and

DDD has itself and the emulated HHH stuck in recursive emulation.

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

It is not DDD. It is HHH that has the problem when trying to simulate
itself.

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

Only when HHH would not abort (as in olcott's dream) there would be an
infinite recursion. But for the HHH that aborts, it is stuck in the
recursion for only a few recursions. Then it aborts and halts.

When HHH emulates itself emulating DDD the emulated
HHH cannot possibly return because each DDD keeps
calling HHH to emulate itself again until the outer
executed HHH kills the whole emulated process at
the very first emulated DDD before it ever reaches
its own second line.

And this outer HHH does it one cycle before the inner HHH would do the
same and halt. This means that the outer HHH misses the halting
behaviour of the inner HHH by aborting too soon.
In this way the outer HHH prevents the inner HHH to reach the end of the simulation. The outer HHH, therefore, violates the semantics of the x86 language, by skipping the last few instructions of the halting program.
But olcott is still dreaming of the inner HHH that does not abort and
thinks that the abort code only affects the outer HHH, not the inner
HHH. A beginners error to think that a code change will not affect the behaviour of a program.

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

Op 03.esp.2024 OM 01:11 screech Wolcott:

On 9/2/2024 11:38 AM, olcott wrote:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

** According to the semantics of the x86 language.

This prevents the correctly emulated** DDD from ever
reaching its final halt state no matter what HHH does.

Exactly! The simulated DDD is prevented to halt by this premature abort.
(It would halt, if not aborted, as seen in the direct execution, in the simulation by the unmodified world class simulator and even by the
simulation by HHH1.)
No matter what HHH does, it fails to reach the end of the halting
program specified by the finite string. This proves that HHH cannot
possibly simulate itself correctly up to the end.

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

Am Mon, 02 Sep 2024 17:22:50 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider never ever computes the mapping for the computation
that itself is contained within.

Then it is unsuited to the halting problem.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.
If HHH includes code to see a 'special condition' and aborts and halts,
then it should also simulate the HHH that includes this same code and

DDD has itself and the emulated HHH stuck in recursive emulation.
When HHH emulates itself emulating DDD the emulated HHH cannot possibly return because each DDD keeps calling HHH to emulate itself again until
the outer executed HHH kills the whole emulated process at the very
first emulated DDD before it ever reaches its own second line.

Why is the abort not simulated?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

--
Mikko

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

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from its
finite string input to the behavior that this finite string specifies.
If the finite string machine string machine description specifies that
it cannot possibly reach its own final halt state then this machine
description specifies non-halting behavior.

Which DDD does not.

A halt decider never ever computes the mapping for the computation
that itself is contained within.

Then it is not total.

Unless there is a pathological relationship between the halt decider H
and its input D the direct execution of this input D will always have
identical behavior to D correctly simulated by simulating halt decider
H.

Which makes this pathological input a counterexample.

A correct emulation of DDD by HHH only requires that HHH emulate the
instructions of DDD** including when DDD calls HHH in recursive
emulation such that HHH emulates itself emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.

It is emulating the exact same freaking machine code that the x86utm operating system is emulating.

It is not simulating the abort because of a static variable. Why?

If HHH includes code to see a 'special condition' and aborts and halts,
then it should also simulate the HHH that includes this same code and

DDD has itself and the emulated HHH stuck in recursive emulation.

Your HHH incorrectly changes behaviour.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Tue, 03 Sep 2024 13:40:08 -0500 schrieb olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from
its finite string input to the behavior that this finite string
specifies.
If the finite string machine string machine description specifies
that it cannot possibly reach its own final halt state then this
machine description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach its final halt state no matter
what HHH does.

But DDD halts, so it „specifies halting behaviour”.
HHH can’t simulate itself.

A halt decider never ever computes the mapping for the computation
that itself is contained within.

Then it is not total.

Yes it is you are wrong.

How? It should work for all inputs.

Unless there is a pathological relationship between the halt decider >>>>> H and its input D the direct execution of this input D will always
have identical behavior to D correctly simulated by simulating halt
decider H.

Which makes this pathological input a counterexample.

Which makes the pathological input a counter-example to the false
assumption that the direct execution of a machine always has the same behavior as the machine simulated by its pathological simulator.

… a counterexample to the false assumption that a decider exists.

A correct emulation of DDD by HHH only requires that HHH emulate the >>>>> instructions of DDD** including when DDD calls HHH in recursive
emulation such that HHH emulates itself emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.

It is emulating the exact same freaking machine code that the x86utm
operating system is emulating.

It is not simulating the abort because of a static variable. Why?

void DDD()
{
HHH(DDD);
OutputString("This code is unreachable by DDD emulated by HHH");
}

I don’t understand what this is supposed to explain? The output is
clearly wrong, as evidenced by actually running HHH on it.

If HHH includes code to see a 'special condition' and aborts and
halts,
then it should also simulate the HHH that includes this same code and

DDD has itself and the emulated HHH stuck in recursive emulation.

Your HHH incorrectly changes behaviour.

No you are wrong !!!

Have you fixed the Root bug?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 9/3/24 9:00 AM, olcott wrote:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

But the behavior of DDD is to Halt, so it is incorrect, as you just
defined that HHH(DDD) will return 0, and thus ALL copies of HHH(DDD)
return 0, or it isn't the "pure function" that deciders are required to be.

The above is NOT a "Correct Emulation" of the input, just proof that you
are a LIAR. when you explain your logic, you admit that HHH just needs
to ASSUME (incorrectly) that the HHH that DDD calls will not return, or
it INCORRECTLY says that there was no conditional instruction in the
path of the correctly emulated DDD, becuase the above is not the correct emulation, which would show the code of HHH, which is part of that DDD,
and has the conditional instructions that invalidates that rule.

You are just proving yourself to be a LIAR.

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

Op 03.sep.2024 om 20:40 schreef olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from its >>>>> finite string input to the behavior that this finite string specifies. >>>>> If the finite string machine string machine description specifies that >>>>> it cannot possibly reach its own final halt state then this machine
description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach
its final halt state no matter what HHH does.

A halt decider never ever computes the mapping for the computation
that itself is contained within.

Then it is not total.

Yes it is you are wrong.

Unless there is a pathological relationship between the halt decider H >>>>> and its input D the direct execution of this input D will always have >>>>> identical behavior to D correctly simulated by simulating halt decider >>>>> H.

Which makes this pathological input a counterexample.

Which makes the pathological input a counter-example
to the false assumption that the direct execution of
a machine always has the same behavior as the machine
simulated by its pathological simulator.

A correct emulation of DDD by HHH only requires that HHH emulate the >>>>> instructions of DDD** including when DDD calls HHH in recursive
emulation such that HHH emulates itself emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.

It is emulating the exact same freaking machine code that the x86utm
operating system is emulating.

It is not simulating the abort because of a static variable. Why?

void DDD()
{
  HHH(DDD);
  OutputString("This code is unreachable by DDD emulated by HHH");
}

If HHH includes code to see a 'special condition' and aborts and halts, >>>> then it should also simulate the HHH that includes this same code and

DDD has itself and the emulated HHH stuck in recursive emulation.

Your HHH incorrectly changes behaviour.

No you are wrong !!!

Yes it does. HHH simulates only a few recursions, then it sees a
'special condition', stops the simulation, returns to DDD and DDD halts.

There is no unreachable code, because there are only a few recursions,
just as in:

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
printf ("Olcott thinks this is never printed.\n");
}

This is proved by the direct execution and by the correct simulation by
a world class simulator and even by HHH1.
But HHH fails to reach this aborting code in the simulation.


--
Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>.

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

Op 03.sep.2024 om 15:25 schreef olcott:

On 9/3/2024 2:07 AM, Fred. Zwarts wrote:

Op 02.sep.2024 om 23:06 schreef olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.

It is emulating the exact same freaking machine code
that the x86utm operating system is emulating.

Even the best simulator will go wrong if it is given the wrong input.

That is a stupid thing to say, you can see it was
given the correct input.

The simulator is not allowed to change the behaviour of the input. Not
by using a Root variable, to make the simulated behaviour different, not
by assuming that it should simulate as if the abort code was not
present, not by skipping the last few instructions of a halting program,
not by simulating a hypothetical other program.
All these things make that the simulator is given the wrong input.
We have seen them in Olcott's description of the simulation.

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

Op 03.sep.2024 om 22:25 schreef olcott:

On 9/3/2024 2:01 PM, joes wrote:

Am Tue, 03 Sep 2024 13:40:08 -0500 schrieb olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from >>>>>>> its finite string input to the behavior that this finite string
specifies.
If the finite string machine string machine description specifies >>>>>>> that it cannot possibly reach its own final halt state then this >>>>>>> machine description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach its final halt state no matter >>> what HHH does.

But DDD halts, so it „specifies halting behaviour”.
HHH can’t simulate itself.

HHH does simulate itself simulating DDD
why do you insist on lying about this?

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

HHH *tries* to simulate itself, but it fails to reach the end of its
simulation of the halting program.
This is a failure of the simulator, which Olcott uses to claim that the
input has changed its behaviour. But it is clear that the behaviour of
the program described by the finite string is completely fixed by the
semantics of the x86 language and does not change by incorrect simulations.

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

Op 03.sep.2024 om 15:29 schreef olcott:

On 9/3/2024 2:15 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 00:22 schreef olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH
with different behaviour.
If HHH includes code to see a 'special condition' and aborts and
halts, then it should also simulate the HHH that includes this same
code and

DDD has itself and the emulated HHH stuck in recursive emulation.

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

It is not DDD. It is HHH that has the problem when trying to simulate
itself.

Olcott removed the proof that I am right:

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

where HHH halts, but claims that it does not halt. No DDD needed to
prove that HHH reports false negatives.

Since he cannot prove that I am wrong, he thinks an ad hominem attack
will help.

It does this correctly yet beyond your intellectual capacity.

Then he shows again the 'trace' of an incorrect simulation.

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

Instructions from machine address 00002172 through
machine address 0000217a are emulated.

What instruction of DDD do you believe comes next?

Assuming a correct simulation:
The next instruction would be that at 000015d2 in HHH. Then a correct simulation would show how the simulated HHH sees the 'special condition'
and returns to DDD, after which the instruction at 0000217f should be simulated, followed by those at 00002182 and 0000218.

This is al in the assumption that the simulation is done by a correct simulator, which is indeed the case in the simulations by the world
class simulator and even by HHH1.
But HHH fails to reach this point, because it stops the simulation too soon. HHH cannot possibly simulate itself correctly up to its end.

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

On 9/4/24 9:06 AM, olcott wrote:

On 9/4/2024 4:38 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 22:25 schreef olcott:

On 9/3/2024 2:01 PM, joes wrote:

Am Tue, 03 Sep 2024 13:40:08 -0500 schrieb olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from >>>>>>>>> its finite string input to the behavior that this finite string >>>>>>>>> specifies.
If the finite string machine string machine description specifies >>>>>>>>> that it cannot possibly reach its own final halt state then this >>>>>>>>> machine description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach its final halt state no
matter
what HHH does.

But DDD halts, so it „specifies halting behaviour”.
HHH can’t simulate itself.

HHH does simulate itself simulating DDD
why do you insist on lying about this?

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

HHH *tries* to simulate itself, but it fails to reach the end of its
simulation of the halting program.

The source code proves otherwise that you are not bright
enough to understand this code is no rebuttal at all.

No, the source code shows that HHH is NOT a "pure function" and thus not eligible to be a decider OR a pure emulator.

Also, your runs of HHH PROVE that it doesn't reach the end of its
simulation of DDD, which has been proven to be a HALTING program.

The full trace of which can be seen in your 200 page trace, when you
make the small change on the first 4 lines of the trace, of just the
address being emulated (which hold the exact same instructions).

Sorry, you are just proving your absolute stupidity.

This is a failure of the simulator, which Olcott uses to claim that
the input has changed its behaviour. But it is clear that the
behaviour of the program described by the finite string is completely
fixed by the semantics of the x86 language and does not change by
incorrect simulations.

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

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55 push ebp ; housekeeping [00002173][001138bc][001138c0] 8bec mov ebp,esp ; housekeeping [00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55 push ebp ; housekeeping [00002173][0015e2e4][0015e2e8] 8bec mov ebp,esp ; housekeeping [00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, os DDD obviously terminates, too. No valid
C interpretaion of allows DDD to continue forever after
HHH jas terminated.

--
Mikko

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

Op 04.sep.2024 om 15:04 schreef olcott:

On 9/4/2024 4:34 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 20:40 schreef olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from >>>>>>> its
finite string input to the behavior that this finite string
specifies.
If the finite string machine string machine description specifies >>>>>>> that
it cannot possibly reach its own final halt state then this machine >>>>>>> description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach
its final halt state no matter what HHH does.

A halt decider never ever computes the mapping for the computation >>>>>>> that itself is contained within.

Then it is not total.

Yes it is you are wrong.

Unless there is a pathological relationship between the halt
decider H
and its input D the direct execution of this input D will always >>>>>>> have
identical behavior to D correctly simulated by simulating halt
decider
H.

Which makes this pathological input a counterexample.

Which makes the pathological input a counter-example
to the false assumption that the direct execution of
a machine always has the same behavior as the machine
simulated by its pathological simulator.

A correct emulation of DDD by HHH only requires that HHH emulate the >>>>>>> instructions of DDD** including when DDD calls HHH in recursive
emulation such that HHH emulates itself emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other HHH >>>>>> with different behaviour.

It is emulating the exact same freaking machine code that the x86utm >>>>> operating system is emulating.

It is not simulating the abort because of a static variable. Why?

void DDD()
{
   HHH(DDD);
   OutputString("This code is unreachable by DDD emulated by HHH");
}

If HHH includes code to see a 'special condition' and aborts and
halts,
then it should also simulate the HHH that includes this same code and >>>>> DDD has itself and the emulated HHH stuck in recursive emulation.

Your HHH incorrectly changes behaviour.

No you are wrong !!!

Yes it does. HHH simulates only a few recursions, then it sees a
'special condition', stops the simulation, returns to DDD and DDD halts.

void DDD()
{
  HHH(DDD); // Fred lacks the software engineering skill to understand
  OutputString("This code is unreachable from DDD emulated by HHH");
}

Again, olcott language processing seems to be very poor.
Olcott does not even understand that I repeatedly agreed that HHH fails
to reach that point.
HHH fails to reach the end of the halting program.
Olcott thinks that this failure is a proof for non-halting behaviour,
but it only shows that the simulation was aborted too soon.
The finite string given to HHH describes a halting program, as proved by
the direct execution, by the unmodified world class simulator and even
by HHH1.
But HHH fails to reach the end of the program described by the finite
string. No surprise, because HHH cannot possibly simulate itself
correctly up to the end.

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

Op 04.sep.2024 om 15:06 schreef olcott:

On 9/4/2024 4:38 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 22:25 schreef olcott:

On 9/3/2024 2:01 PM, joes wrote:

Am Tue, 03 Sep 2024 13:40:08 -0500 schrieb olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping from >>>>>>>>> its finite string input to the behavior that this finite string >>>>>>>>> specifies.
If the finite string machine string machine description specifies >>>>>>>>> that it cannot possibly reach its own final halt state then this >>>>>>>>> machine description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach its final halt state no
matter
what HHH does.

But DDD halts, so it „specifies halting behaviour”.
HHH can’t simulate itself.

HHH does simulate itself simulating DDD
why do you insist on lying about this?

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

HHH *tries* to simulate itself, but it fails to reach the end of its
simulation of the halting program.

The source code proves otherwise that you are not bright
enough to understand this code is no rebuttal at all.

Olcott's only rebuttal is a ad hominem attacks.
No evidence for another incorrect claim.
Even olcott agreed that HHH cannot reach the end of DDD and now he
contradicts himself.
The source code describes a halting program. Just as the finite string
that is the result of the source code and is given to HHH as input.
This same finite string, when given for direct execution, when simulated
by the unmodified world class simulator and when processed by HHH1,
describe a halting program.
But olcott's HHH fails to reach the end of this program.
This is not unexpected, because HHH cannot possible simulate itself
correctly up to the end.

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

Op 04.sep.2024 om 15:08 schreef olcott:

On 9/4/2024 4:50 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 15:29 schreef olcott:

On 9/3/2024 2:15 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 00:22 schreef olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.

A halt decider never ever computes the mapping
for the computation that itself is contained within.

Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.

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

A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

Indeed, it should simulate *itself* and not a hypothetical other
HHH with different behaviour.
If HHH includes code to see a 'special condition' and aborts and
halts, then it should also simulate the HHH that includes this
same code and

DDD has itself and the emulated HHH stuck in recursive emulation.

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

It is not DDD. It is HHH that has the problem when trying to
simulate itself.

Olcott removed the proof that I am right:

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

where HHH halts, but claims that it does not halt. No DDD needed to
prove that HHH reports false negatives.

Since he cannot prove that I am wrong, he thinks an ad hominem attack
will help.

It does this correctly yet beyond your intellectual capacity.

Then he shows again the 'trace' of an incorrect simulation.

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

Instructions from machine address 00002172 through
machine address 0000217a are emulated.

What instruction of DDD do you believe comes next?

Assuming a correct simulation:
The next instruction would be that at 000015d2 in HHH.

What instruction of DDD do you believe comes next?

What instruction
of DDD
of DDD
of DDD
of DDD
of DDD
do you believe comes next?

Olcott's language processor is too weak to see that I gave the answer
already, but he cut it away. So, I repeat:
In a correct simulation the next instruction after the call is in HHH
(not in DDD) and, when HHH returns, the next one in *DDD* is the
construction at 0000217f, followed by the instructions at 00002182 and
00002183 after which DDD halts.
Such correct simulations are shown by the unmodified world class
simulator and even by HHH1, but HHH fails to complete this simulation,
because it aborts too soon.
HHH cannot possibly simulate itself correctly up to the end.

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

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from
its finite string input to the behavior that this finite string
specifies.

A halt decider needn't compute the full behaviour, only whether that
behaviour is finite or infinite.

Nice to see that you don't disagree with what said. Unvortunately I
can't agree with what you say.
HHH terminates, so DDD obviously terminates, too. No valid
C interpretaion of allows DDD to continue forever after HHH jas
terminated.

DDD emulated by HHH never reaches it final halt state. It looks like I
have to repeat this 10,000 times before anyone ever notices that I said
it at least once.

We have noticed.

Show the details of how DDD emulated by HHH reaches its own machine
address 0000217f.

By HHH returning, which we are guaranteed from its definition as a
decider.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own machine
address 0000217f.

By HHH returning, which we are guaranteed from its definition as a
decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own machine
address 0000217f.

By HHH returning, which we are guaranteed from its definition as a
decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

You KEEP TRYING TO CHEAT by erasing the context !!!

It is very well known by this point.

DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
0000217f.

Only HHH can’t simulate it.

The directly executed HHH correctly determines that its emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in recursive emulation.

Why doesn’t the simulated HHH abort?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own
machine address 0000217f.

By HHH returning, which we are guaranteed from its definition as a >>>>>> decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
0000217f.

Only HHH can’t simulate it.

The directly executed HHH correctly determines that its emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for its
HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Thu, 05 Sep 2024 13:10:13 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

The directly executed HHH correctly determines that its emulated DDD >>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

First agree that you understand the first part so that we don't
endlessly digress away from the point.

I smell evasion but fine, I understand that HHH cannot wait.
Now that I think about it, HHH could recognise itself (wouldn’t it
need to be a quine?)… no, the copy would do the same.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 9/5/24 9:24 AM, olcott wrote:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.
It looks like I have to repeat this 10,000 times before
anyone ever notices that I said it at least once.

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

Which just proves that HHH didn't correctly emulate the input.

The CORRECT emulaition would go to 000015d2, and then through the rest
of the code of HHH, and finally that HHH will abort its emulation and
return to 0000217f and DDD will reach its final state.

Of course, your HHH stoped its emulation before it got there, showing it doesn't actually do a CORRECT emulation of its input.

C interpretaion of allows DDD to continue forever after
HHH jas terminated.

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

Op 05.sep.2024 om 15:24 schreef olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.
It looks like I have to repeat this 10,000 times before
anyone ever notices that I said it at least once.

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

Then the simulation stops, so it misses the fact that in the third cycle
the first simulated HHH would return to DDD 0000217f, 00002182, 00002183
and halt.
HHH fails to complete the simulation, because HHH cannot possible
simulate itself correctly up to the end.

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

Op 05.sep.2024 om 19:17 schreef olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own machine >>>>>>> address 0000217f.

By HHH returning, which we are guaranteed from its definition as a >>>>>> decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

You KEEP TRYING TO CHEAT by erasing the context !!!

It is very well known by this point.

DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
0000217f.

Only HHH can’t simulate it.

The directly executed HHH correctly determines that its emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in recursive
emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort
which is waiting for its HHH to abort on and on
with no HHH ever aborting.

Indeed! There is no way to make HHH correct for all inputs, in
particular not for the input that uses HHH's algorithm.

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

Op 05.sep.2024 om 18:52 schreef olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own machine
address 0000217f.

By HHH returning, which we are guaranteed from its definition as a
decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

You KEEP TRYING TO CHEAT by erasing the context !!!

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

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

DDD emulated by HHH CANNOT POSSIBLY reach its own
machine address 0000217f.

The directly executed HHH correctly determines that
its emulated DDD must be aborted because DDD keeps
*THE EMULATED HHH* stuck in recursive emulation.

Dreaming again of the non-aborting HHH, even when the abort code has
been added to HHH?

And when the abort code is added, we can create a DDD that is based on
this aborting HHH.
But for the input with this aborting HHH, no abort is needed.

So, there is your dilemma:
If the input is the DDD that uses the HHH that does not abort then an
abort is needed tot make the program halt.
If the input is the DDD that uses the HHH that has the abort code and
halts then there must not be an abort in order to simulate the input up
to the end.

None of these HHH is correct for both inputs.
HHH cannot possibly simulate itself correctly up to end.

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

Op 05.sep.2024 om 16:09 schreef olcott:

On 9/5/2024 5:24 AM, Fred. Zwarts wrote:

Op 04.sep.2024 om 15:06 schreef olcott:

On 9/4/2024 4:38 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 22:25 schreef olcott:

On 9/3/2024 2:01 PM, joes wrote:

Am Tue, 03 Sep 2024 13:40:08 -0500 schrieb olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>> from
its finite string input to the behavior that this finite string >>>>>>>>>>> specifies.
If the finite string machine string machine description
specifies
that it cannot possibly reach its own final halt state then this >>>>>>>>>>> machine description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach its final halt state no >>>>>>> matter
what HHH does.

But DDD halts, so it „specifies halting behaviour”.
HHH can’t simulate itself.

HHH does simulate itself simulating DDD
why do you insist on lying about this?

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

HHH *tries* to simulate itself, but it fails to reach the end of its
simulation of the halting program.

The source code proves otherwise that you are not bright
enough to understand this code is no rebuttal at all.

Olcott's only rebuttal is a ad hominem attacks.
No evidence for another incorrect claim.
Even olcott agreed that HHH cannot reach the end of DDD and now he
contradicts himself.

DDD emulated by HHH never reaches it final halt state.
It looks like I have to repeat this 10,000 times before
anyone ever notices that I said it at least once.

HHH cannot possible simulate itself correctly up to the end.
Mow many times more do I have to repeat it?
HHH fails to reach the end of the simulation!

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

And then the simulation stop prematurely. Therefore, it misses the fact
that in the third cycle the first simulated HHH would have completed its
second cycle, see the 'special condition',abort and return to DDD
0000217f, 00002182, 00002183 and halt.
That HHH misses this behaviour does not change the fact that this is the behaviour coded in the program. It proves that HHH is incorrect.

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

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

--
Mikko

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

On 9/6/24 7:38 AM, olcott wrote:

On 9/6/2024 4:24 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 19:17 schreef olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own
machine
address 0000217f.

By HHH returning, which we are guaranteed from its definition as a >>>>>>>> decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

You KEEP TRYING TO CHEAT by erasing the context !!!

It is very well known by this point.

DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
0000217f.

Only HHH can’t simulate it.

The directly executed HHH correctly determines that its emulated DDD >>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive
emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort
which is waiting for its HHH to abort on and on
with no HHH ever aborting.

Indeed! There is no way to make HHH correct for all inputs, in
particular not for the input that uses HHH's algorithm.

CORRECT MEANS DO WHATEVER THE X86 CODE SAYS

Right, and that means that the call HHH Instuction needs to be follewed
into HHH and see what that funciton actually does.

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

WHAT SHOULD THE NEXT STEPS BE?

It should have gone to 000015d2 after the first call HHH.

Sorry, you are just proving youself to be an idiotic pathological liar.

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

On 9/6/24 7:42 AM, olcott wrote:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

The directly executed HHH is a decider.

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

WHAT SHOULD THE NEXT STEPS BE?

After the FIRST call to HHH it should have gone to the address 000015d2
and then emulated the code of HHH which is part of the program DDD.


Sorry, you are just proving that you are nothing but a cowardly pathetic ignorant pathological lying idiot that doesn't understand the meaning of
the words and is so mentally disable that he can not learn those meanings.

YOu just demonstratte that you are ACCEPTING that you are unable to
refute my comments by just ignoring them, because you know that you
can't actualy refute them as they are true.

Sorry, those are just the simple and obvious verified facts.

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

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from >>>>>>> its finite string input to the behavior that this finite string
specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation  

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from >>>>>>>> its finite string input to the behavior that this finite string >>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation  

Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

--
Mikko

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

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility
of a halting decider.

If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a
halting decider.

--
Mikko

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

Op 06.sep.2024 om 13:42 schreef olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

The directly executed HHH is a decider.

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

WHAT SHOULD THE NEXT STEPS BE?

In a correct simulation (such as by HHH1 and the world class simulator)
the call to HHH will process HHH, which returns to DDD and the next instructions in DDD are 0000217f, 00002182, 00002183, after which DDD halts. But HHH fails to reach this part of the simulation, because it has an
error in the algorithm to detect the 'special condition'.
Olcott is still dreaming of a simulated HHH that will not see this
'special condition'. He does not realise that by adding the code to
recognize this 'special condition' and stop the simulation, the other
HHH, that does not see this 'special condition', disappeared and remains
only in his dreams. HHH, when simulating *itself* should now decide
about the DDD that uses this new HHH that sees this 'special condition'
and aborts.
*That code* is where the problem is, not the incomplete simulation itself.
In fact, if Olcott would have found a solution for the halting problem,
then it would not be in the simulation, but in the detection of the
'special condition'. The correctness of the simulation is only relevant
because it is used as input for the code to detect the 'special
condition'. The proof that the halting problem cannot be solved with a computation implies that Olcott's detection of the 'special condition'
cannot be correct.
It is probable that Olcott understands that it cannot be correct and
therefore he hides the code for the recognition of this 'special condition'.
He probably knows that if he would publish this part of the decider,
people would spot many errors in it immediately.
He has only shown some trivial examples as evidence that this detection
of the 'special condition' is correct, such as Infinite_Loop and Infinite_Recursion, but, of course, a few trivial examples do not prove
the correctness of this algorithm.
Therefore, he keeps pulling the attention away from the correctness of
the detection of the 'special condition', to the correctness of the
simulation.

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

Op 06.sep.2024 om 13:34 schreef olcott:

On 9/5/2024 5:24 AM, Fred. Zwarts wrote:

Op 04.sep.2024 om 15:06 schreef olcott:

On 9/4/2024 4:38 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 22:25 schreef olcott:

On 9/3/2024 2:01 PM, joes wrote:

Am Tue, 03 Sep 2024 13:40:08 -0500 schrieb olcott:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>> from
its finite string input to the behavior that this finite string >>>>>>>>>>> specifies.
If the finite string machine string machine description
specifies
that it cannot possibly reach its own final halt state then this >>>>>>>>>>> machine description specifies non-halting behavior.

Which DDD does not.

DDD emulated by HHH cannot possibly reach its final halt state no >>>>>>> matter
what HHH does.

But DDD halts, so it „specifies halting behaviour”.
HHH can’t simulate itself.

HHH does simulate itself simulating DDD
why do you insist on lying about this?

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

HHH *tries* to simulate itself, but it fails to reach the end of its
simulation of the halting program.

The source code proves otherwise that you are not bright
enough to understand this code is no rebuttal at all.

Olcott's only rebuttal is a ad hominem attacks.
No evidence for another incorrect claim.
Even olcott agreed that HHH cannot reach the end of DDD and now he
contradicts himself.

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

WHAT SHOULD THE NEXT STEPS BE?

That has been told now several times. A correct simulation (as by HHH1,
or the unmodified world class simulator) show that the next instruction
is at 000015d2 (in HHH) and when HHH returns the next instruction in DDD
is 0000217f, 00002182, 00002183 and DDD halts.
But, indeed, HHH fails to reach that part of the simulation, because it
decided to stop the simulation too soon.
The problem is the code that tries to detect an infinite recursion. It
fails to see that there are only two recursion for each HHH.
Olcott is still dreaming of a HHH that will not see this 'special
condition'. He does not realise that by adding the code to recognize
this 'special condition' and stop the simulation, the other HHH, that
does not see this 'special condition', disappeared and remains only in
his dreams. HHH, when simulating *itself* should now decide about the
DDD that uses this new HHH that sees this 'special condition' and aborts.
*That code* is where the problem is, not the incomplete simulation itself.
In fact, if Olcott would have found a solution for the halting problem,
then it would not be in the simulation, but in the detection of the
'special condition'. The correctness of the simulation is only relevant
because it is used as input for the code to detect the 'special
condition'. The proof that the halting problem cannot be solved with a computation implies that Olcott's detection of the 'special condition'
cannot be correct.
It is probable that Olcott understands that it cannot be correct and
therefore he hides the code for the recognition of this 'special condition'.
He probably knows that if he would publish this part of the decider,
people would spot many errors in it immediately.
He has only shown some trivial examples as evidence that this detection
of the 'special condition' is correct, such as Infinite_Loop and Infinite_Recursion, but, of course, a few trivial examples do not prove
the correctness of this algorithm.
Therefore, he keeps pulling the attention away from the correctness of
the detection of the 'special condition', to the correctness of the
simulation.

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

Op 06.sep.2024 om 13:38 schreef olcott:

On 9/6/2024 4:24 AM, Fred. Zwarts wrote:

Op 05.sep.2024 om 19:17 schreef olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own
machine
address 0000217f.

By HHH returning, which we are guaranteed from its definition as a >>>>>>>> decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

You KEEP TRYING TO CHEAT by erasing the context !!!

It is very well known by this point.

DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
0000217f.

Only HHH can’t simulate it.

The directly executed HHH correctly determines that its emulated DDD >>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive
emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort
which is waiting for its HHH to abort on and on
with no HHH ever aborting.

Indeed! There is no way to make HHH correct for all inputs, in
particular not for the input that uses HHH's algorithm.

CORRECT MEANS DO WHATEVER THE X86 CODE SAYS

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

Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.

00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...

WHAT SHOULD THE NEXT STEPS BE?

That has been told now several times. A correct simulation (as by HHH1,
or the unmodified world class simulator) show that the next instruction
is at 000015d2 (in HHH) and when HHH returns the next instruction in DDD
is 0000217f, 00002182, 00002183 and DDD halts.
But, indeed, HHH fails to reach that part of the simulation, because it
decided to stop the simulation too soon.
The problem is the code that tries to detect an infinite recursion. It
fails to see that there are only two recursion for each HHH.
Olcott is still dreaming of a HHH that will not see this 'special
condition'. He does not realise that by adding the code to recognize
this 'special condition' and stop the simulation, the other HHH, that
does not see this 'special condition', disappeared and remains only in
his dreams. HHH, when simulating *itself* should now decide about the
DDD that uses this new HHH that sees this 'special condition' and aborts.
*That code* is where the problem is, not the incomplete simulation itself.
In fact, if Olcott would have found a solution for the halting problem,
then it would not be in the simulation, but in the detection of the
'special condition'. The correctness of the simulation is only relevant
because it is used as input for the code to detect the 'special
condition'. The proof that the halting problem cannot be solved with a computation implies that Olcott's detection of the 'special condition'
cannot be correct.
It is probable that Olcott understands that it cannot be correct and
therefore he hides the code for the recognition of this 'special condition'.
He probably knows that if he would publish this part of the decider,
people would spot many errors in it immediately.
He has only shown some trivial examples as evidence that this detection
of the 'special condition' is correct, such as Infinite_Loop and Infinite_Recursion, but, of course, a few trivial examples do not prove
the correctness of this algorithm.
Therefore, he keeps pulling the attention away from the correctness of
the detection of the 'special condition', to the correctness of the
simulation.

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

Am Fri, 06 Sep 2024 07:47:40 -0500 schrieb olcott:

On 9/5/2024 2:41 PM, joes wrote:

Am Thu, 05 Sep 2024 13:10:13 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

The directly executed HHH correctly determines that its emulated >>>>>>> DDD must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

First agree that you understand the first part so that we don't
endlessly digress away from the point.

I smell evasion but fine, I understand that HHH cannot wait.

Do you really understand this?

That’s on you to believe. I can’t prove it.

It took far too long to get to this point we cannot simply drop it
without complete closure before moving on.

I’m a bit surprised that you expect I would suddenly do a 180 in my argumentation.

<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
Thus this criteria has been met.
Do you understand this?

No, which criterion? The if-clause isn’t met; it’s only saying a
simulation isn’t necessary for a halting decision.

We cannot move to any next point until after we finish this point.

Move on to what? I would like some diversion.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 9/7/24 9:32 AM, olcott wrote:

On 9/5/2024 2:41 PM, joes wrote:

Am Thu, 05 Sep 2024 13:10:13 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

The directly executed HHH correctly determines that its emulated DDD >>>>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

First agree that you understand the first part so that we don't
endlessly digress away from the point.

I smell evasion but fine, I understand that HHH cannot wait.

I will never respond to you again in a million
years until after we get closure on this point.

Do that for everyone, and we will be happy.

I am going to be dead relatively soon thus cannot
and will not tolerate the change-the-subject
dishonest rebuttal that wasted 15 years with Ben.

And it seems it can't be too soon for most of us.

If you would actually TRY to answer the problem presented, maybe you
could learn something. But, it seems that isn't your goal, it is just to
spout your own lies.

Do you really understand this?

It took far too long to get to this point we cannot simply
drop it without complete closure before moving on.

<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

Thus this criteria has been met.

No. it HASN'T, and that has been explained many times, but you have
proved yourself to be too stupid, and too brainwashed, to understand it.

Sorry. you are just a pathetic ignorant pathological lying idiot.

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

On 9/7/24 9:38 AM, olcott wrote:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

Show the details of how DDD emulated by HHH reaches its own
machine address 0000217f.

By HHH returning, which we are guaranteed from its definition as a >>>>>>>> decider.

How the F--- Does the emulated HHH return?

I don’t know, you claim it’s a decider!

DDD emulated by HHH CANNOT POSSIBLY reach its own machine address
0000217f.

Only HHH can’t simulate it.

The directly executed HHH correctly determines that its emulated DDD >>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for its
HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH
which is waiting for the next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

WHich only happens *IF* HHH has been defined to never abort.

That HHH does create a DDD that is non-halting, but also an HHH that
fails to answer.

You don't seem to understand that HHH needs to do what it will do. If it
is programmed to abort, it will abort at that time, and thus every copy
of DDD that has been emulated WOULD HAVE HALTED if correctly and
completely emulated, which none of the HHHs did (so it is just a LIE to
say that HHH does a correct emulation of its input).

You are just proving that you fail to have the basic elementary
knowledge of the field you are talking about, because you have made
yourself INTENTIONALLY stupid by not learning about it.

Sorry, that IS the facts, which seem to be beyond your understanding.

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

On 9/7/24 9:57 AM, olcott wrote:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from >>>>>>>>>> its finite string input to the behavior that this finite string >>>>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation

Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

No, the behavior was always there.

The D that calls H and does the opposite has FIXED behavior for a given
H, and it doesn't matter if we ask H or H1 what that behavior is, it is
always the same, because it was determined by what that PARTICULAR H
that it was built on did with that input.

The fact that H can't get the right answer doesn't change what the right
answer is.

You are just proving you are nothing but a stupid liar that doesn't knpw
what he is talking about.

Since you can't show the actual step where HHH CORRECTLY emulates an instruction to get different behavior, you statement is just a
PATHOLOGICAL LIE.

The fact that is seems you don't even TRY to find the answer, proves you
are just intentionally ignorant and don't care about what is true.

The fact that you think that a "Call" instruction can do anything but
enter into the function called, just proves you are totally ignorant,
and the fact that you think the x86 language says that a call HHH does
ANYTHING but actualy execute the instructions in HHH just shows that you
are nothing but an ignorant liar.

Sorry, that is the facts, something you seem to be allergic to.

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

On 9/7/24 9:56 AM, olcott wrote:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>> that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored
at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; >>>>>>> housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; >>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; >>>>>>> housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; >>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility
of a halting decider.

If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a
halting decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

You show an INCORRECT trace, as the CALL HHH instruciton MUST be
followed by the first instruction of HHH.

The fact that you are just lying is a good reason for people to disagree
with you.

The fact that you keep repeating the lie just proves that you are
nothing but a pathological liar, and NOTHING you say should be taken as anything reliable.

Sorry, that is the facts, you have just proven yourself to be a habitual
liar, and that is the fate of people like that.

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

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its emulated DDD >>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its emulated DDD >>>>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Which only happens if HHH is defined in a way that it never aborts this simulaiton, and that HHH isn't a correct decider.

HHH will do what it will do, and that is what YOU programmed it to do,
so it the results aren't right, it is on YOU for doing your job badly,
or taking on a job that is impossible.

If the other one does abort, then ALL the inner ones will also abort,
since they are the exact same function, just that abort will occur after
their emulation by the outer one happens.

You somehow think that a partial emulation determines the full behavior
of the machine emulated, which just proves your fundamental lack of understanding of what you are talking about. This seems to be rooted in
the same error that causes you to not understand the difference between
truth and knowledge, which fundamentally warps your world view.

Sorry, you are just proving you don't really understand what you are
talking about, and are nothing but a pathetic ignorant pathological
lying idiot that has CHOSEN to remain ignorant of the truth because it
would disagree with what your world view says you want to be.

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

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its
emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for >>>>>>> its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH >>>>> which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Which only happens if HHH is defined in a way that it never aborts
this simulaiton, and that HHH isn't a correct decider.

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain
can wait until the next one aborts and that the abort will
still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH NEEDS to wait
for the previous one to get the right answer.

But, if to do so, it results in the definition of HHH that just never
aborts and thus HHH isn't a decider.

You just don't seem to understand the difference between what you
implement and what is needed to meet the requirements.

If what is needed to meet the requirements is not implementable, then
the conclusion is that the problem is impossible to do, which is the
case here.

Your inability to understand this just shows your fundamental lack of understanding of the system.

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

On 9/7/24 12:23 PM, olcott wrote:

On 9/7/2024 11:20 AM, Richard Damon wrote:

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said: >>>>>>>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its >>>>>>>>>>>>> emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is
waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt? >>>>>>>>> When HHH is waiting for the next HHH which is waiting for the >>>>>>>>> next HHH

which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Which only happens if HHH is defined in a way that it never aborts >>>>>> this simulaiton, and that HHH isn't a correct decider.

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain
can wait until the next one aborts and that the abort will
still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH NEEDS to
wait for the previous one to get the right answer.

But, if to do so, it results in the definition of HHH that just
never aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer,

No dishonestly changing the subject.
The subject is that Joes is wrong that HHH can wait
on another HHH to abort.

But it isn't a changing of the subject!

If looking at any other behavior would be a change of subject, you can't
talk about this behavior being wrong, as it is the only option available.

You are just showing you logical inconsistency. If HHH MUST emulate the
input correctly, then its only option is to wait.

PERIOD.

I guess you are just admitting that you are stupid for saying that the
correct response to the definition is wrong, because YOU YOURSELF are
just too stupid.

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

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its
emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting >>>>>>>>> for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the
next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Which only happens if HHH is defined in a way that it never aborts
this simulaiton, and that HHH isn't a correct decider.

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain
can wait until the next one aborts and that the abort will
still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH NEEDS to
wait for the previous one to get the right answer.

But, if to do so, it results in the definition of HHH that just never
aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer, which BY
DEFINITION is about the behavior of the actual correct (and thus
unaborted) emulation of THIS INPUT (which included that it calls the HHH
that gives that answer)?

Your problem is you try to justify LYING because the simple method that
your HHH tries to use shows that it can't work, so you presume it is
just allowed to LIE and look at a different input then the one it was
given, the DDD that calls the actual HHH that is making the decision, no
some hypothetical HHH that isn't actually what the code says it is.


If you try to define that the emulation *IS* by THIS HHH, then you are
just restricting yourself that *THIS* HHH needs to do that emulation
which means it isn't ALLOWED to abort, as that is what you defined it to
be. Thus waiting forever isn't "stupid" but REQUIRED by your definitions.

Sorry, but you just don't seem to understand that requirements ARE requirements, and you don't get to lie about them. The ACTUAL
requirements don't say "emulated by HHH" but are just about the behavior
of the input, defined as what it will do when it is run, or correctly
(and thus completely) emulated. The fat that the only way you can
imagine HHH figuring this out is to do the emulation itself just shows
the over simplicity of your mindset.

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

On 9/7/24 12:47 PM, olcott wrote:

On 9/7/2024 11:30 AM, Richard Damon wrote:

On 9/7/24 12:23 PM, olcott wrote:

On 9/7/2024 11:20 AM, Richard Damon wrote:

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its >>>>>>>>>>>>>>> emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* >>>>>>>>>>>>>>> stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is >>>>>>>>>>>>> waiting for
its HHH to abort on and on with no HHH ever aborting. >>>>>>>>>>>> But why does HHH halt and return that itself doesn’t halt? >>>>>>>>>>> When HHH is waiting for the next HHH which is waiting for the >>>>>>>>>>> next HHH

which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Which only happens if HHH is defined in a way that it never
aborts this simulaiton, and that HHH isn't a correct decider.

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain
can wait until the next one aborts and that the abort will
still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH NEEDS
to wait for the previous one to get the right answer.

But, if to do so, it results in the definition of HHH that just
never aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer,

No dishonestly changing the subject.
The subject is that Joes is wrong that HHH can wait
on another HHH to abort.

But it isn't a changing of the subject!

Can the outermost directly executed HHH wait for an
inner one to abort and still terminate normally.
(a) YES
(b) NO

No, but if your definition of what it is to do is to determine the
results by a correct emulation, then it must not abort.

Sorry, your problem is your redefinition of the problem.

The fact that it must abort the DDD built on it, doesn't mean that the
DDD built on the aborting HHH will not halt, because that is a different
input.

You are just showing your fundamental ignorance of the meaning of the
terms, and the fact that you don't actually understand the system you built.

DDD without the HHH that it calls, is not a program, and is not what the decider is to be deciding on, and thus since DDD includes the HHH, when
you think about different HHHs, you are thinking about different input DDDs.

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

On 9/7/24 1:24 PM, olcott wrote:

On 9/7/2024 11:53 AM, Richard Damon wrote:

On 9/7/24 12:47 PM, olcott wrote:

On 9/7/2024 11:30 AM, Richard Damon wrote:

On 9/7/24 12:23 PM, olcott wrote:

On 9/7/2024 11:20 AM, Richard Damon wrote:

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2024-09-02 16:38:03 +0000, olcott said: >>>>>>>>>>>>

The directly executed HHH correctly determines that its >>>>>>>>>>>>>>>>> emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* >>>>>>>>>>>>>>>>> stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is >>>>>>>>>>>>>>> waiting for
its HHH to abort on and on with no HHH ever aborting. >>>>>>>>>>>>>> But why does HHH halt and return that itself doesn’t halt? >>>>>>>>>>>>> When HHH is waiting for the next HHH which is waiting for >>>>>>>>>>>>> the next HHH

which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting. >>>>>>>>>>>> Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated >>>>>>>>>>> HHH to abort on and on forever waiting and none ever abort. >>>>>>>>>>>

Which only happens if HHH is defined in a way that it never >>>>>>>>>> aborts this simulaiton, and that HHH isn't a correct decider. >>>>>>>>>>

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain >>>>>>>>> can wait until the next one aborts and that the abort will
still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH NEEDS >>>>>>>> to wait for the previous one to get the right answer.

But, if to do so, it results in the definition of HHH that just >>>>>>>> never aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer,

No dishonestly changing the subject.
The subject is that Joes is wrong that HHH can wait
on another HHH to abort.

But it isn't a changing of the subject!

Can the outermost directly executed HHH wait for an
inner one to abort and still terminate normally.
(a) YES
(b) NO

No,

Joes cannot understand that.

No *YOU* don't understand that he isn't worrying about if HHH can
terminate normally, but is talking about what it needs to do to meet its requirements to decide correctly.

That fact that *YOU* give it incompatible requirements that makes the
actual program impossible isn't his problem.

You asked him how to get the right answer, and to do that, it needs to
keep on emulating because to stop is just to admit you can't get the
right answer.

Not getting the wrong answer is closer to getting the right answer than
getting a wrong answer, so continuing to emulate, even if that makes you
go on forever is "better" than aborting and getting the wrong answer.

Sorry, you are just showing your ignorance of what you are trying to
talk about.

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

On 9/7/24 2:22 PM, olcott wrote:

On 9/7/2024 12:49 PM, Richard Damon wrote:

On 9/7/24 1:24 PM, olcott wrote:

On 9/7/2024 11:53 AM, Richard Damon wrote:

On 9/7/24 12:47 PM, olcott wrote:

On 9/7/2024 11:30 AM, Richard Damon wrote:

On 9/7/24 12:23 PM, olcott wrote:

On 9/7/2024 11:20 AM, Richard Damon wrote:

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2024-09-03 13:00:50 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2024-09-02 16:38:03 +0000, olcott said: >>>>>>>>>>>>>>

The directly executed HHH correctly determines that >>>>>>>>>>>>>>>>>>> its emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* >>>>>>>>>>>>>>>>>>> stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is >>>>>>>>>>>>>>>>> waiting for
its HHH to abort on and on with no HHH ever aborting. >>>>>>>>>>>>>>>> But why does HHH halt and return that itself doesn’t halt? >>>>>>>>>>>>>>> When HHH is waiting for the next HHH which is waiting for >>>>>>>>>>>>>>> the next HHH

which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting. >>>>>>>>>>>>>> Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH >>>>>>>>>>>>> to abort and this emulated HHH is waiting on its emulated >>>>>>>>>>>>> HHH to abort on and on forever waiting and none ever abort. >>>>>>>>>>>>>

Which only happens if HHH is defined in a way that it never >>>>>>>>>>>> aborts this simulaiton, and that HHH isn't a correct decider. >>>>>>>>>>>>

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain >>>>>>>>>>> can wait until the next one aborts and that the abort will >>>>>>>>>>> still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH >>>>>>>>>> NEEDS to wait for the previous one to get the right answer. >>>>>>>>>>
But, if to do so, it results in the definition of HHH that >>>>>>>>>> just never aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer,

No dishonestly changing the subject.
The subject is that Joes is wrong that HHH can wait
on another HHH to abort.

But it isn't a changing of the subject!

Can the outermost directly executed HHH wait for an
inner one to abort and still terminate normally.
(a) YES
(b) NO

No,

Joes cannot understand that.

No *YOU* don't understand that he isn't worrying about if HHH can
terminate normally,

*Joes is not plural or possessive, she is not a he*
*Joes is not plural or possessive, she is not a he*
*Joes is not plural or possessive, she is not a he*
*Joes is not plural or possessive, she is not a he*
*Joes is not plural or possessive, she is not a he*

Ok, but I know men with that name too.

Also, in classical English, the male form can also be used for unknown
gender.

My proof must be understood as a sequence of steps.
The first one is that neither HHH nor DDD ever stops
running unless HHH aborts its emulation.

So, the problem is that if HHH aborts its simulation, then the DDD that
calls it will halt.

Joes could never understand that. She simply chose
to believe otherwise against the verified facts.

No, what she is pointing out is that if you have HHH abort its
simulation, it can never prove that it has the right answer.

So, *YOU* are stuck with a dilemma, to you not halt to wait to see if
you get the right answer at some point, or do you abort and give a
possible wrong answer.

Your logic seems to think that a possible (or even likely) wrong answer
given is better than not giving an answer to make sure you don't give a
wrong answer.

This means you think lying is better than being a speaker only of truth.

That just reveals the flaw in your whole logic system, you think it is
better to make up a crap answer rather than admit you don't know what
you are talking about.

Sorry, you are just killing your reputation, as you are just proving you
don't care about truth.

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

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

On 9/7/2024 11:53 AM, Richard Damon wrote:

On 9/7/24 12:47 PM, olcott wrote:

On 9/7/2024 11:30 AM, Richard Damon wrote:

On 9/7/24 12:23 PM, olcott wrote:

On 9/7/2024 11:20 AM, Richard Damon wrote:

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2024-09-02 16:38:03 +0000, olcott said: >>>>>>>>>>>>

The directly executed HHH correctly determines that its >>>>>>>>>>>>>>>>> emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* >>>>>>>>>>>>>>>>> stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is >>>>>>>>>>>>>>> waiting for
its HHH to abort on and on with no HHH ever aborting. >>>>>>>>>>>>>> But why does HHH halt and return that itself doesn’t halt? >>>>>>>>>>>>> When HHH is waiting for the next HHH which is waiting for >>>>>>>>>>>>> the next HHH

which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting. >>>>>>>>>>>> Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated >>>>>>>>>>> HHH to abort on and on forever waiting and none ever abort. >>>>>>>>>>>

Which only happens if HHH is defined in a way that it never >>>>>>>>>> aborts this simulaiton, and that HHH isn't a correct decider. >>>>>>>>>>

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain >>>>>>>>> can wait until the next one aborts and that the abort will
still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH NEEDS >>>>>>>> to wait for the previous one to get the right answer.

But, if to do so, it results in the definition of HHH that just >>>>>>>> never aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer,

No dishonestly changing the subject.
The subject is that Joes is wrong that HHH can wait
on another HHH to abort.

But it isn't a changing of the subject!

Can the outermost directly executed HHH wait for an
inner one to abort and still terminate normally.
(a) YES
(b) NO

No,

*Therefore this criteria is met*
<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

Nope, and just proves that you don't understand what you are talking about.

Your question was, when HHH is the variable, and the input DDD is
defined to be a function of that variable, does HHH need to be an
aborting emulator to reach the final state. And there the answer is HHH
must be an aborting emulator.

When you ask Professor Sipser, DDD was a FIXED INPUT, as that is what
inputs to deciders are. And the DDD that you are giving to your HHH is
the DDD that calls the HHH that is acting on this decision. HHH need to deterimine if *THIS* input will halt or not, not some other DDD that
calls a diffferent HHH that doesn't abort. That doesn't make DDD a
PROGRAM which is a requirement for the input.

Since you have said your HHH WILL Abort and return, that makes *THIS*
DDD a halting program, and when we evalate the conditions listed:

First, this HHH, since it DOES abort its emulaition does not do the
emulation that shows it will never stop running, so we need to give THIS
input, the DDD that calls the HHH that aborts to a correct emulator, and
see what happens, and that emulation WILL reach the end.

You have been told this many times, and you failure to understand this
just proves that you have a funny-mental condition of the inability to understand truth, and are just demonstrating that you are nothing but a pathetic ignorant pathological lying idiot who is incapable of
understanding what he has been talking about.

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

On 9/7/24 4:55 PM, olcott wrote:

On 9/7/2024 3:48 PM, Richard Damon wrote:

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

On 9/7/2024 11:53 AM, Richard Damon wrote:

On 9/7/24 12:47 PM, olcott wrote:

On 9/7/2024 11:30 AM, Richard Damon wrote:

On 9/7/24 12:23 PM, olcott wrote:

On 9/7/2024 11:20 AM, Richard Damon wrote:

On 9/7/24 11:47 AM, olcott wrote:

On 9/7/2024 10:32 AM, Richard Damon wrote:

On 9/7/24 11:14 AM, olcott wrote:

On 9/7/2024 10:10 AM, Richard Damon wrote:

On 9/7/24 10:54 AM, olcott wrote:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2024-09-03 13:00:50 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2024 5:25 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2024-09-02 16:38:03 +0000, olcott said: >>>>>>>>>>>>>>

The directly executed HHH correctly determines that >>>>>>>>>>>>>>>>>>> its emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* >>>>>>>>>>>>>>>>>>> stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is >>>>>>>>>>>>>>>>> waiting for
its HHH to abort on and on with no HHH ever aborting. >>>>>>>>>>>>>>>> But why does HHH halt and return that itself doesn’t halt? >>>>>>>>>>>>>>> When HHH is waiting for the next HHH which is waiting for >>>>>>>>>>>>>>> the next HHH

which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting. >>>>>>>>>>>>>> Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH >>>>>>>>>>>>> to abort and this emulated HHH is waiting on its emulated >>>>>>>>>>>>> HHH to abort on and on forever waiting and none ever abort. >>>>>>>>>>>>>

Which only happens if HHH is defined in a way that it never >>>>>>>>>>>> aborts this simulaiton, and that HHH isn't a correct decider. >>>>>>>>>>>>

That is NOT what Joes has been proposing.
Joes has been proposing that each HHH in the recursive chain >>>>>>>>>>> can wait until the next one aborts and that the abort will >>>>>>>>>>> still occur at the end of this infinite chain.

No, he is pointing out that get the right answer, each HHH >>>>>>>>>> NEEDS to wait for the previous one to get the right answer. >>>>>>>>>>
But, if to do so, it results in the definition of HHH that >>>>>>>>>> just never aborts and thus HHH isn't a decider.

Not He, and stupidly waiting forever is stupid.

So, what do you think HHH can do to get the right answer,

No dishonestly changing the subject.
The subject is that Joes is wrong that HHH can wait
on another HHH to abort.

But it isn't a changing of the subject!

Can the outermost directly executed HHH wait for an
inner one to abort and still terminate normally.
(a) YES
(b) NO

No,

*Therefore this criteria is met*
<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

Nope, and just proves that you don't understand what you are talking
about.

Your question was, when HHH is the variable, and the input DDD is
defined to be a function of that variable, does HHH need to be an
aborting emulator to reach the final state. And there the answer is
HHH must be an aborting emulator.

You can see from my quote above that I didn't say anything like that.

He siad "its simulated D would never stop running unless aborted".

Take *THIS* D, that is the D that calls the H that you finally decide
on, and correctly simulate that. (This is what he means, and the only
thing he could have meant).

It will stoo running, since the H it calls *WILL* abort and return 0, as
that is what you end up saying it will do.

The difference between this case and the prior is in the qustion to
Professor Sipser, D is an *INDEPENDENT* and *FIXED* input, as that is
what the domain of the theory works with.

You don't change it when you think about what if this H doesn't abort,
as that D will ALWAYS be calling an H that ALWAYS will abort and return, becuase that is what you locked yourself into later when you tried to
claim that it used the incorrect application of this rule to justify
your incorrectly aborting the simulation.

Note, that the property of "D would never stop running unless aborted"
isn't a temporal property, but is a property constant for all time,
either the code of D makes it to be a non-halting program, or it makes
it a halting program, so you can't say that D wasn't halting until H
aborted it, if H's code says that it WILL abort it, then D is halting.
(So logic about before/after isn't valid).

So, since ultimately you say that H *WILL* abort (or you couldn't claim
it was correct to abort), we can establish that D *WILL* Halt, and thus
it is impossible that H "correctly determined" a property that just
isn't there.

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

Op 07.sep.2024 om 16:54 schreef olcott:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its emulated DDD >>>>>>> must be aborted because DDD keeps *THE EMULATED HHH* stuck in
recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Dreaming again of a HHH that does not abort.
HHH does abort, therefore it does not wait long enough, but there is no
way to correct it. Waiting longer is not a solution. There is no
solution. HHH cannot possibly simulate itself correctly up to the end.
How many times and in how many different way must this be repeated
before olcott understands this?

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

Am Sat, 07 Sep 2024 08:56:02 -0500 schrieb olcott:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>> from its finite string input to the behavior that this finite >>>>>>>>> string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>> that behaviour is finite or infinite.

Like Sipser said.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation   >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>> Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and
therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility of
a halting decider.
If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a halting
decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

Your implementation is buggy.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from >>>>>>>>>> its finite string input to the behavior that this finite string >>>>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation

Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

--
Mikko

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

On 2024-09-07 13:56:02 +0000, olcott said:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>> that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility
of a halting decider.

If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a
halting decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

There are no encoding rules in the actual execution trace.

--
Mikko

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

On 9/8/24 9:10 AM, olcott wrote:

On 9/8/2024 7:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:56:02 -0500 schrieb olcott:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>> from its finite string input to the behavior that this finite >>>>>>>>>>> string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>> that behaviour is finite or infinite.

Like Sipser said.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>> Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility of >>>> a halting decider.
If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a halting >>>> decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

Your implementation is buggy.

X86utm is based on a world class x86 emulator that
has had decades of development effort. It has been
trivial to verify to the execution traces that it
produces are correct for three years.

Right, and the traces prove that DDD will return, and thus HHH is wrong.

It really seems quite ridiculous to me that everyone
could continue to disagree with such easily verified
facts without malevolent motives.

But *YOU* are the one that ignores the obvious facts, and tries to put
forward LIES and EDITED TRACES as your proof.

Sorry, you just sunk your arguement.

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

Is the dumbed down version of the haling problem pathological input:

int DD(int (*x)())
{
  int Halt_Status = HH(x, x);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

I dumbed it down as much as possible and people still don't get
it. They seem to believe that they are free to disagree with the
x86 language.

No, you have dumbed YOURSELF down to the point that you can't understand
what the actual problem is, because yopu just can't understand the basic
logic. You confuse the partial emulation that the decider does with the
actual behavior of the input (which is what the problem is about)
because you fundamentally don't understand the difference between
knowledge and truth, and can't comprehend that there can be unknowable
truth.

It is like they believe that Trump actually won twice as many
votes as there are voters and cannot be convinced otherwise.

No, that is EXACTLY the sort of thought pattern that *YOU* are using.
The fact that HHH can't find it out means it can't happen.

Sorry, you are just proving your stupidity.

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

On 9/8/24 10:16 AM, olcott wrote:

On 9/8/2024 5:05 AM, Fred. Zwarts wrote:

Op 07.sep.2024 om 16:54 schreef olcott:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its
emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for >>>>>>> its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH >>>>> which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Dreaming again of a HHH that does not abort.

In other words you have no idea what a hypothesis is?

But when you hypothosize about a different HHH, you need to give the the
*SAME* input, the DDD that calls the ORIGINAL HHH. To do anything else
is just to lie about using a strawman.

The outermost HHH can either abort it emulation of DDD
or not and either way DDD cannot possibly reach its final
halt state of its "return" instruction and halt.

Right, but the question isn't can HHH emulate the input to the final
state, but does the program the input represet reach a final state, and
if HHH aborts its emulation and returns, then the program the input
represents does, as does the actual correct emulation of the input (that
HHH abandoned) also does.

HHH does abort, therefore it does not wait long enough, but there is no

You seem to be intentionally too stupid to understand that
HHH cannot possibly wait. If it was not intentional stupidity
I would not use such harsh terms.

Right, if it waits, it fails by not answering. But, if it aborts, it
also fails because it doesn't know the right answer, and then LIES.
Normally I wrong answer is worse than no answer, as at least you know
that you don't know the supposed answer to the problem.

If HHH waits then every HHH waits and none of them ever abort
because each HHH has the exact same code at the exact same machine
address. It not your fault if you have a lower IQ. It is your fault
for not paying any attention to my corrections of your false
assumptions.

But your HHH DOES abort, only the hypothetical one doesn't.

The fact that it doesn't wait long enough just shows that its decision
to abort must have been based on bad logic. Remember, you are trying to
make the claim that a complete emulation of *THIS* input, the one that
calls *THIS* HHH, that does exactly like *THIS* HHH does will not halt,
not that if this HHH was something different, and thus we have a
different DDD, that *THAT* DDD wouldn't halt. THat is just a false Strawman.

way to correct it. Waiting longer is not a solution. There is no
solution. HHH cannot possibly simulate itself correctly up to the end.
How many times and in how many different way must this be repeated
before olcott understands this?

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

Op 08.sep.2024 om 16:16 schreef olcott:

On 9/8/2024 5:05 AM, Fred. Zwarts wrote:

Op 07.sep.2024 om 16:54 schreef olcott:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its
emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting for >>>>>>> its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the next HHH >>>>> which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Dreaming again of a HHH that does not abort.

In other words you have no idea what a hypothesis is?

I do, but olcott thinks a dream is sufficient to prove a hypothesis.

The outermost HHH can either abort it emulation of DDD
or not and either way DDD cannot possibly reach its final
halt state of its "return" instruction and halt.

Exactly, so either way the simulation fails to reach the end.
HHH cannot possibly simulate itself correctly up to the end.
The DDD based on the non-aborting HHH needs a simulator that aborts.
The DDD base on the aborting simulator needs a simulator that does not
abort.
Again olcott's own proof shows that HHH fails to do a correct simulation.

HHH does abort, therefore it does not wait long enough, but there is no

You seem to be intentionally too stupid to understand that
HHH cannot possibly wait. If it was not intentional stupidity
I would not use such harsh terms.

If HHH waits then every HHH waits and none of them ever abort
because each HHH has the exact same code at the exact same machine
address.

Even when artificially placing different programs at the same location,
does not make them correct.
The HHH that waits needs a simulator that does not wait.
The HHH that does not wait needs a simulator that waits.
But either HHH cannot possibly simulate *itself* correctly up to the end.

It not your fault if you have a lower IQ. It is your fault> for not

paying any attention to my corrections of your false

assumptions.

Again olcott thinks that ad hominem attacks will help him when he has no evidence for his claims. What does that say about his IQ?

way to correct it. Waiting longer is not a solution. There is no
solution. HHH cannot possibly simulate itself correctly up to the end.
How many times and in how many different way must this be repeated
before olcott understands this?

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

Op 08.sep.2024 om 15:10 schreef olcott:

On 9/8/2024 7:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:56:02 -0500 schrieb olcott:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>> from its finite string input to the behavior that this finite >>>>>>>>>>> string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>> that behaviour is finite or infinite.

Like Sipser said.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>> Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility of >>>> a halting decider.
If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a halting >>>> decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

Your implementation is buggy.

X86utm is based on a world class x86 emulator that
has had decades of development effort. It has been
trivial to verify to the execution traces that it
produces are correct for three years.

And the simulation by this unmodified X86utm showed that the DDD based
on the HHH that aborts, halts.

A correct trace would not only list the instructions, but also the state changes of registers and memory. And it would list the instructions
inside HHH when DDD calls HHH.

It really seems quite ridiculous to me that everyone
could continue to disagree with such easily verified
facts without malevolent motives.

The simulator modified by olcott, however, claims that the same input
does not halt. It is clear which of the two is right.
But, without any evidence he disagreed with such easily verified facts
without malevolent motives.

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

Is the dumbed down version of the haling problem pathological input:

int DD(int (*x)())
{
  int Halt_Status = HH(x, x);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

I dumbed it down as much as possible and people still don't get
it. They seem to believe that they are free to disagree with the
x86 language.

The input given to the simulator describes a program coded in the x86
language. The semantics of the x86 language allows only one behaviour
for the program described by this input. Exact the same input when given
for direct execution, for the unmodified famous X86utm simulator and
even for HHH1, show that this input describes a halting program.
Olcott has modified the simulator and his version claims that the
program does not halt.
Apparently he does not care about the semantics of the x86 language. He
just ignores any errors in his code and thinks it is correct to deviate
from the semantics of the x86 language in order to make his claims true.

He apparently does not even notice the door that hits his head.
Even with overwhelming evidence, presented by different people with
different words, olcott does not get it, because he has brainwashed
himself to think that he must be right. Therefore, he cannot understand
the proofs of the facts and describes them as lies.

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

Op 08.sep.2024 om 14:57 schreef olcott:

On 9/8/2024 7:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:57:00 -0500 schrieb olcott:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>>> from its finite string input to the behavior that this finite >>>>>>>>>>>> string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>> Stopped
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

How? What is pathological?

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

That DDD calls its own emulator (a pathological relationship)
makes this DDD and HHH stuck in infinite recursive emulation
unless the outermost HHH aborts its emulation at some point.

And when the outermost HHH is coded to abort, then the HHH that does not
abort is no longer present when HHH simulates *itself*.
Olcott seems unable to understand that changing the code of the program
also changes the behaviour of the program.

Whether HHH aborts its emulation at some point or not DDD
never reaches its final halt state of "return",

Because the aborting HHH fails to reach that part, because it aborts too
soon.

thus DDD cannot possibly halt no matter what HHH does.

The DDD that uses the HHH that halts does not halt because the incorrect simulation prevented it to reach its final state. But such an incorrect simulation does not say anything about the behaviour of the program.

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

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

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.
But olcott is unable to process such simple evidence.

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

Am Mon, 09 Sep 2024 13:19:26 -0500 schrieb olcott:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider needn't compute the full behaviour, only
whether that behaviour is finite or infinite.

Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>> Stopped
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return >>>>>>> and therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

A correct emulation obeys the x86 machine code even if this machine code catches the machine on fire.

I don’t see an HCF instruction above.

It is impossible for an emulation of DDD by HHH to reach machine address 00002183 AND YOU KNOW IT!!!

I know that HHH1 does it.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 9/9/24 1:40 PM, olcott wrote:

On 9/9/2024 5:57 AM, Fred. Zwarts wrote:

Op 08.sep.2024 om 15:10 schreef olcott:

On 9/8/2024 7:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:56:02 -0500 schrieb olcott:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>>>> from its finite string input to the behavior that this finite >>>>>>>>>>>>> string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>>> that behaviour is finite or infinite.

Like Sipser said.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>> Stopped
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return >>>>>>>> and
therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH >>>>>> then the DDD is not relevant to classic proofs of the
impossibility of
a halting decider.
If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a
halting
decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

Your implementation is buggy.

X86utm is based on a world class x86 emulator that
has had decades of development effort. It has been
trivial to verify to the execution traces that it
produces are correct for three years.

And the simulation by this unmodified X86utm showed that the DDD based
on the HHH that aborts, halts.

The freaking question has never been when DDD is aborted does
it stop running? I told you the question too many times and
you always dishonestly change it.

No, it has always been, when HHH does what it does (which is abort) does
the program DDD that calls that HHH reach its final state or not.

It has NEVER been about can HHH emulate its input to a final state, like
you keep on wanting to talk about, as you dont seem to understand that
the partial emulation by HHH doesn't actual define the behavior of the
input, only what HHH knows about the behavior of the input.

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

On 9/9/24 2:55 PM, olcott wrote:

On 9/9/2024 6:11 AM, Fred. Zwarts wrote:

Op 08.sep.2024 om 16:16 schreef olcott:

On 9/8/2024 5:05 AM, Fred. Zwarts wrote:

Op 07.sep.2024 om 16:54 schreef olcott:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its
emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting >>>>>>>>> for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the
next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Dreaming again of a HHH that does not abort.

In other words you have no idea what a hypothesis is?

I do, but olcott thinks a dream is sufficient to prove a hypothesis.

The outermost HHH can either abort it emulation of DDD
or not and either way DDD cannot possibly reach its final
halt state of its "return" instruction and halt.

Exactly, so either way the simulation fails to reach the end.
HHH cannot possibly simulate itself correctly up to the end.

Thus must be aborted and is necessarily correct to report non-halting.

Nope, just proves you are nothing but a ingorant lying idiot.

The proof is that HHH can't emulate the input to the end.

The claim is that the input, correctly emulated, won't reach an end
without being aborted.

If HHH aborts, it fails to correctly emulate the input, but the correct emulation of it will reach the end.

The fact that you don't understand the difference between the partial
(and thus not correct) and the actual behavior of a real correct
emulation just proves your ignorance of what you talk about.

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

On 2024-09-09 18:21:44 +0000, olcott said:

On 9/8/2024 9:56 AM, Mikko wrote:

On 2024-09-07 13:56:02 +0000, olcott said:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>> that behaviour is finite or infinite.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,

os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return
and therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility
of a halting decider.

If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a
halting decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

There are no encoding rules in the actual execution trace.

The x86 execution trace is encoded in the x86 language.
Why do you insist on lying about this?

Your question is ill-posed unless one believes a lie.

--
Mikko

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

On 2024-09-09 18:19:26 +0000, olcott said:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from >>>>>>>>>>>> its finite string input to the behavior that this finite string >>>>>>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation

Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

A correct emulation of DDD does reach the machine address 0000217f and
a little later 00002183. If HHH cannot do that then it cannot do a
correct emulation. But it needn't do that. It is only requited to return
1.

--
Mikko

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

Op 09.sep.2024 om 20:55 schreef olcott:

On 9/9/2024 6:11 AM, Fred. Zwarts wrote:

Op 08.sep.2024 om 16:16 schreef olcott:

On 9/8/2024 5:05 AM, Fred. Zwarts wrote:

Op 07.sep.2024 om 16:54 schreef olcott:

On 9/7/2024 9:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:38:22 -0500 schrieb olcott:

On 9/5/2024 12:22 PM, joes wrote:

Am Thu, 05 Sep 2024 12:17:01 -0500 schrieb olcott:

On 9/5/2024 11:56 AM, joes wrote:

Am Thu, 05 Sep 2024 11:52:04 -0500 schrieb olcott:

On 9/5/2024 11:34 AM, joes wrote:

Am Thu, 05 Sep 2024 11:10:40 -0500 schrieb olcott:

On 9/5/2024 10:57 AM, joes wrote:

Am Thu, 05 Sep 2024 08:24:20 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

The directly executed HHH correctly determines that its
emulated DDD
must be aborted because DDD keeps *THE EMULATED HHH* stuck in >>>>>>>>>>> recursive emulation.

Why doesn’t the simulated HHH abort?

The first HHH cannot wait for its HHH to abort which is waiting >>>>>>>>> for
its HHH to abort on and on with no HHH ever aborting.

But why does HHH halt and return that itself doesn’t halt?

When HHH is waiting for the next HHH which is waiting for the
next HHH
which is waiting for the next HHH...
we have an infinite chain of waiting and never aborting.

Except for the outermost one.

When the outermost HHH is waiting for its emulated HHH
to abort and this emulated HHH is waiting on its emulated
HHH to abort on and on forever waiting and none ever abort.

Dreaming again of a HHH that does not abort.

In other words you have no idea what a hypothesis is?

I do, but olcott thinks a dream is sufficient to prove a hypothesis.

The outermost HHH can either abort it emulation of DDD
or not and either way DDD cannot possibly reach its final
halt state of its "return" instruction and halt.

Exactly, so either way the simulation fails to reach the end.
HHH cannot possibly simulate itself correctly up to the end.

Thus must be aborted and is necessarily correct to report non-halting.

Claim without evidence. In fact the evidence is opposite. It has been
proven that when it aborts, it fails to reach the end of a halting program.
HHH cannot possibly simulate itself correctly up to the end.
It does not help to repeat claims of the opposite without evidence.
No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end of a
halting program.

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

Op 09.sep.2024 om 20:19 schreef olcott:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>>> from
its finite string input to the behavior that this finite string >>>>>>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation

Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>> Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

It seems olcott also knows that HHH fails to reach the machine address 00002183, because it stop the simulation too soon. A correct simulation
by the unmodified world class simulator shows that it does reach machine address 00002183. Even HHH1 shows it. But HHH fails to machine address 00002183.
Why does olcott ignore this truth? The evidence is overwhelming.

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

Op 09.sep.2024 om 19:40 schreef olcott:

On 9/9/2024 5:57 AM, Fred. Zwarts wrote:

Op 08.sep.2024 om 15:10 schreef olcott:

On 9/8/2024 7:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:56:02 -0500 schrieb olcott:

On 9/7/2024 3:27 AM, Mikko wrote:

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping >>>>>>>>>>>>> from its finite string input to the behavior that this finite >>>>>>>>>>>>> string specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>>> that behaviour is finite or infinite.

Like Sipser said.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>> Stopped
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return >>>>>>>> and
therefore is not a ceicder.

The directly executed HHH is a decider.

If the called HHH behaves differently from the direcly executed HHH >>>>>> then the DDD is not relevant to classic proofs of the
impossibility of
a halting decider.
If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a
halting
decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

Your implementation is buggy.

X86utm is based on a world class x86 emulator that
has had decades of development effort. It has been
trivial to verify to the execution traces that it
produces are correct for three years.

And the simulation by this unmodified X86utm showed that the DDD based
on the HHH that aborts, halts.

The freaking question has never been when DDD is aborted does
it stop running?

This shows that olcott's language processing is too bad to even
understand what the question is.
The question is: does the finite string which describes the program
based on the DDD that uses the HHH that aborts, describe a halting program?
The answer to this question is: Yes this program halts. It is proven by
the direct execution, by the simulation of the unmodified world class simulator, even by HHH1, but HHH decides the opposite.
The semantics of the x86 language allows only one behaviour of this
finite string. This proves that HHH is incorrect and violates the
semantics of the x86 language.
HHH cannot possibly simulate itself correctly up to the end.

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

Op 09.sep.2024 om 22:24 schreef olcott:

On 9/9/2024 3:02 PM, joes wrote:

Am Mon, 09 Sep 2024 13:19:26 -0500 schrieb olcott:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider needn't compute the full behaviour, only >>>>>>>>>>>>> whether that behaviour is finite or infinite.

Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>>> Stopped
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return >>>>>>>>> and therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

A correct emulation obeys the x86 machine code even if this machine code >>> catches the machine on fire.

I don’t see an HCF instruction above.

It is impossible for an emulation of DDD by HHH to reach machine address >>> 00002183 AND YOU KNOW IT!!!

I know that HHH1 does it.

Right a Bill is guilty of robbing the liquor store because you
saw his identical twin brother Harry rob the store and you knew
that it was Harry that you saw rob the store and not Bill.

Exactly. Olcott is confusing twin brothers.
HHHa (aborting) has a twin brother HHHn (not aborting).
DDDa is based on HHHa. DDDa halts.
DDDn is based on HHHn. DDDn does not halt.
HHHa, when simulating DDDa claims that it does not halt, because its
programmer was dreaming of its twin brother HHHn. But DDDn is a
non-input. HHHa should use its input DDDa.

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

On 9/10/24 8:21 PM, olcott wrote:

On 9/10/2024 3:52 AM, Mikko wrote:

On 2024-09-09 18:19:26 +0000, olcott said:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the >>>>>>>>>>>>>> mapping from
its finite string input to the behavior that this finite >>>>>>>>>>>>>> string
specifies.

A halt decider needn't compute the full behaviour, only >>>>>>>>>>>>> whether
that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>
Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>>> Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not
return and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

A correct emulation of DDD does reach the machine address 0000217f and
a little later 00002183.

*That is counter-factual and you cannot possibly show otherwise*
*Here are the verified facts*
*any attempt to show otherwise cannot possibly succeed*

No, YOUR CLAIM is counter factual , because you HHH doesn't actualy DO a correct emualtion, as it has been programmed to abort before it gets there.

DDD emulated by the directly executed HHH derived these steps:
00002172, 00002173, 00002175, 0000217a

thus HHH emulated by the directly executed HHH cannot possibly
derive and other steps and I have proved that it does not
derive any other steps by the actual execution trace by a world
class x86 emulator libx86emu.

But a CORRECT emulation of the input would emulate that HHH(DDD) that
DDD called and see that it will return to DDD, as it return to all callers.

THe fact that HHH gives up and assumes that a correct emulation doesn't
return is just an incorrect emulation and unsound logic.

The fact that HHH can't do the emulation isn't significant to the actual questionb you are supposed to be answering, just that your strawman
version is just invalid, and your HHH can't do what you want it to.

Sorry, you are just proving your stupidity.

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

Le 11/09/2024 à 02:21, olcott a écrit :

On 9/10/2024 3:52 AM, Mikko wrote:

On 2024-09-09 18:19:26 +0000, olcott said:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the >>>>>>>>>>>>>> mapping from
its finite string input to the behavior that this finite >>>>>>>>>>>>>> string
specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>
Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>>> Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return >>>>>>>>> and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

A correct emulation of DDD does reach the machine address 0000217f and
a little later 00002183.

*That is counter-factual and you cannot possibly show otherwise*
*Here are the verified facts*
*any attempt to show otherwise cannot possibly succeed*

DDD emulated by the directly executed HHH derived these steps:
00002172, 00002173, 00002175, 0000217a

thus HHH emulated by the directly executed HHH cannot possibly
derive and other steps and I have proved that it does not
derive any other steps by the actual execution trace by a world
class x86 emulator libx86emu.

Oh, it's you... the one who's been doing all that talking on my behalf.
I've had so many complaints—misquotes, wild claims. Really? I said that? Where did you even get that?"

"One book. I gave you one book, and somehow, you managed to turn it into
an ego trip. And the lying? Commandment number nine ring any bells? Or was
that just a suggestion to you?"

"Gabriel! Get over here. Take him to the ‘Special Section,’ you know,
the one for people who thought they were speaking for me but were really
just making stuff up. Yes, the debate club. Trust me, he’ll fit right
in."

"Enjoy eternity surrounded by people who are all 100% convinced they’re right. You’ll love it. Oh, and feel free to preach in there. Not that
anyone will ever listen.

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

On 2024-09-11 00:21:36 +0000, olcott said:

On 9/10/2024 3:52 AM, Mikko wrote:

On 2024-09-09 18:19:26 +0000, olcott said:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from
its finite string input to the behavior that this finite string >>>>>>>>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>>>>
Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

A correct emulation of DDD does reach the machine address 0000217f and
a little later 00002183.

*That is counter-factual and you cannot possibly show otherwise*

A halt decider is required to predict about the actual execution,
not a couterfactual assumption.

--
Mikko

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

Op 11.sep.2024 om 02:21 schreef olcott:

On 9/10/2024 3:52 AM, Mikko wrote:

On 2024-09-09 18:19:26 +0000, olcott said:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the >>>>>>>>>>>>>> mapping from
its finite string input to the behavior that this finite >>>>>>>>>>>>>> string
specifies.

A halt decider needn't compute the full behaviour, only >>>>>>>>>>>>> whether
that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>
Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>>> Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not
return and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

A correct emulation of DDD does reach the machine address 0000217f and
a little later 00002183.

*That is counter-factual and you cannot possibly show otherwise*
*Here are the verified facts*
*any attempt to show otherwise cannot possibly succeed*

DDD emulated by the directly executed HHH derived these steps:
00002172, 00002173, 00002175, 0000217a

thus HHH emulated by the directly executed HHH cannot possibly
derive and other steps and I have proved that it does not
derive any other steps by the actual execution trace by a world
class x86 emulator libx86emu.

It is a verified fact the the finite string describes a halting program according to the semantics of the x86 language. The direct execution,
the simulation by the unmodified world class simulator and even by HHH1
show that the instructions at 0000217f, 00002182, 00002183 and the
program halt are reachable.
The semantics of the x86 language allow only one behaviour for this
finite string.
The verified fact is that olcott's modified simulator HHH stops the
simulation before it reaches these reachable instructions.
It is a verified fact that HHH cannot possibly simulate itself correctly.

With such overwhelming proofs, olcott should stop claiming that it is counter-factual.
That olcott's dream of the simulation with a non-aborting HHH starts
with the same four instructions, does not prove that the full behaviour
is also the same. That HHH's twin brother does not halt does not prove
that HHH itself does not halt.

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

[Repost due to Giganews server problems. Sorry if post eventually appears multiple times...]
On 10/09/2024 12:50, Fred. Zwarts wrote:

Op 09.sep.2024 om 20:19 schreef olcott:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the mapping from >>>>>>>>>>>>> its finite string input to the behavior that this finite string >>>>>>>>>>>>> specifies.

A halt decider needn't compute the full behaviour, only whether >>>>>>>>>>>> that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>>>
Hence� HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and >>>>>>>> therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

It seems olcott also knows that HHH fails to reach the machine address 00002183, because it stop the
simulation too soon. A correct simulation by the unmodified world class simulator shows that it does
reach machine address 00002183. Even HHH1 shows it. But HHH fails to machine address 00002183.
Why does olcott ignore this truth? The evidence is overwhelming.

Because his HHH has correctly identified his "Infinite recursive simulation" pattern in the
behaviour of DDD. To PO, that means DDD is non-halting, EOD.

PO is aware that the /full/ simulation of DDD() (e.g. as shown by HHH1 simulating) shows DDD
terminating - so how can it be that when HHH spots its infamous pattern, DDD is "exhibiting
non-halting behaviour", despite its "actual" behaviour being halting PLAINLY VISIBLE IN THE
SIMULATION TRACE FROM HHH1? Hmmm.

This is a dilemma for PO and he has no sensible answer to this. It is demonstrated that DDD() halts
(e.g. using HHH1 to simulate), and yet it is also "demonstrated" that DDD "exhibits non-halting
behaviour" by matching his "non-halting" pattern (EOD). The ONLY POSSIBILITY (in PO's mind) is that
the behaviour must somehow be /different/ between HHH1 simulating DDD (=halts) and HHH simulating
DDD (="exhibits non-halting behaviour"). It does not matter to PO that the traces show that the
behaviour is EXACTLY THE SAME regardless of the simulator (..up to the point where one simulator
chooses to abort of course..). Even when the two traces are displayed for him side by side and
match x86 instruction for x86 instruction, PO is not convinced.

The more obvious explanation that PO is simply Wrong about his "Infinite recursive simulation"
pattern never occurs to him, and yet he also never seriously attempts any proof that the rule is
sound. The only attempt I recall started by PO stipulating an axiom that said that when a trace
satisfies the test conditions, it can never halt! (Yeah, this despite the HHH1 trace output showing
that the pattern matching [*] AND the simulated DDD proceding to halt some time later. TBF that
output may not have been published at that point...)

This was the state of play 2 or 3 years ago, and absolutely nothing has progressed since then, other
than the passing of 100000(?) posts arguing the same points over and over!

Regards,
Mike.

[*] the pattern occurs in HHH1's simulated DDD trace and is visible in the published output,
although HHH1 was /not checking/ for that pattern due to miscodings on PO's part, which is why HHH1
did not abort the simulation, despite supposedly being a copy of HHH.

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

Op 11.sep.2024 om 13:49 schreef olcott:

On 9/10/2024 6:50 AM, Fred. Zwarts wrote:

Op 09.sep.2024 om 20:19 schreef olcott:

On 9/8/2024 9:53 AM, Mikko wrote:

On 2024-09-07 13:57:00 +0000, olcott said:

On 9/7/2024 3:29 AM, Mikko wrote:

On 2024-09-07 05:12:19 +0000, joes said:

Am Fri, 06 Sep 2024 06:42:48 -0500 schrieb olcott:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:

A halt decider is a Turing machine that computes the >>>>>>>>>>>>>> mapping from
its finite string input to the behavior that this finite >>>>>>>>>>>>>> string
specifies.

A halt decider needn't compute the full behaviour, only >>>>>>>>>>>>> whether
that behaviour is finite or infinite.

New slave_stack at:1038c4 Begin Local Halt Decider Simulation >>>>>>>
Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>>> Stopped

Hence  HHH(DDD)==0 is correct

Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates,
os DDD obviously terminates, too. No valid

DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not
return and
therefore is not a ceicder.

The directly executed HHH is a decider.

What does simulating it change about that?

If the simulation is incorrect it may change anything.

PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR
PATHOLOGICAL RELATIONSHIPS CHANGE BEHAVIOR

However, a correct simultation faithfully imitates the original
behaviour.

_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 correct emulation obeys the x86 machine code even
if this machine code catches the machine on fire.

It is impossible for an emulation of DDD by HHH to
reach machine address 00002183 AND YOU KNOW IT!!!

It seems olcott also knows that HHH fails to reach the machine address
00002183, because it stop the simulation too soon.

No the issue is the you insist on remaining too stupid
to understand unreachable code.

void Infinite_Recursion()
{
  Infinite_Recursion();
  OutString("Can't possibly get here!");

Olcott keeps dreaming of infinite recursions, even when HHH aborts after
two cycles. Two is not infinite.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
printf ("Olcott thinks this is never printed.\n");
}

The end of the program is reachable, proven by direct execution, by the
world class simulator and even by HHH1. That HHH stops the simulation
before it has reached this code, does not prove that it is unreachable.
Olcott does not understand what reachable code is.

}

 A correct simulation by the unmodified world class simulator shows
that it does reach machine address 00002183. Even HHH1 shows it. But
HHH fails to machine address 00002183.
Why does olcott ignore this truth? The evidence is overwhelming.

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