Op 28.jul.2024 om 16:32 schreef olcott:

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

It is also ridiculous to expect that a halting program must be aborted
to prevent non-termination.

HHH(DDD) is the exact same pattern with Infinite_Recursion()
where there are no conditional branch instructions that would
prevent the first three instructions of Infinite_Recursion()
from endlessly repeating.

void Infinite_Recursion()
{
  Infinite_Recursion();
}

HHH has the same pattern as

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

Both HHH and Finite_Recursion halt after a few recursions.
That is because of the conditional branch instructions within HHH, when
HHH simulates itself, as part of the input.

_Infinite_Recursion()
[0000215a] 55         push ebp      ; 1st line
[0000215b] 8bec       mov ebp,esp   ; 2nd line
[0000215d] e8f8ffffff call 0000215a ; 3rd line
[00002162] 5d         pop ebp
[00002163] c3         ret
Size in bytes:(0010) [00002163]

Begin Local Halt Decider Simulation   Execution Trace Stored at:113934 [0000215a][00113924][00113928] 55         push ebp      ; 1st line
[0000215b][00113924][00113928] 8bec       mov ebp,esp   ; 2nd line [0000215d][00113920][00002162] e8f8ffffff call 0000215a ; 3rd line [0000215a][0011391c][00113924] 55         push ebp      ; 1st line
[0000215b][0011391c][00113924] 8bec       mov ebp,esp   ; 2nd line [0000215d][00113918][00002162] e8f8ffffff call 0000215a ; 3rd line
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

If you cannot see that the above x86 machine code proves that
it will never halt then you can't possibly understand what I
have been saying.

The first three lines of _Infinite_Recursion() repeat and there
are no conditional branch in that sequence that can possibly keep
it from repeating forever.

HHH(DDD) is the exact same pattern is shown below. The first
four lines of DDD repeat and there are are no conditional branch
in that sequence that can possibly keep it from repeating forever.

HHH has a very different pattern, because of the conditional branch instructions in the input, namely, those in HHH itself.
HHH halts, as is shown by the direct execution and by a correct simulation.

=====

void DDD()
{
  HHH(DDD);
}

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.

_DDD()
[00002177] 55               push ebp      ; 1st line [00002178] 8bec             mov ebp,esp   ; 2nd line
[0000217a] 6877210000       push 00002177 ; push DDD
[0000217f] e853f4ffff       call 000015d7 ; call HHH
[00002184] 83c404           add esp,+04
[00002187] 5d               pop ebp
[00002188] c3               ret
Size in bytes:(0018) [00002188]

// executed HHH emulates 1st instance of DDD
New slave_stack at:10388d
Begin Local Halt Decider Simulation   Execution Trace Stored at:113895 [00002177][00113885][00113889] 55         push ebp      ; 1st line
[00002178][00113885][00113889] 8bec       mov ebp,esp   ; 2nd line [0000217a][00113881][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011387d][00002184] e853f4ffff call 000015d7 ; call HHH

// emulated HHH emulates 2nd instance of DDD
New slave_stack at:14e2b5
[00002177][0015e2ad][0015e2b1] 55         push ebp      ; 1st line
[00002178][0015e2ad][0015e2b1] 8bec       mov ebp,esp   ; 2nd line [0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

HHH is programmed to print an incorrect message after two recursion.
Apparently the programmer thought that two recursions is enough to prove
an infinite recursion. But two differs from infinite.
One cycle later the simulated HHH would abort and halt, after which DDD
would halt, too.
But olcott is dreaming of a non-aborting non-halting version of HHH and
thinks that dreams are a correct substitute for logic.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.

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

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

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been
aborted.
This is not the same as reaching its ret instruction and terminating >>>>>> normally (AKA halting).

I think you're wrong, here.  All your C programs are a stand in for >>>>> turing machines.  A turing machine is either running or halted.
There is
no third state "aborted".  An aborted C program certainly doesn't
correspond with a running turing machine - so it must be a halted
turing
machine.

So aborted programs are halted programs.  If you disagree, perhaps you >>>>> could point out where in my arguments above I'm wrong.

Aborting is an action performed by a simulator, not the TM being
simulated.

If we want to count "aborted" as some kind of final status, it will
have to be the status of a specific /PARTIAL SIMULATOR's/ simulation
of a given computation.  That's not a property of the computation
itself, as different partial simulators can simulate the same
computation and terminate for different reasons.  Like HHH(DDD)
aborts, while UTM(DDD) simulates to completion and so the final
simulation status is halts. [Neither of those outcomes contradict
the fact that the computation DDD() halts.]

If some partial simulator halts when simulating a computation [as
with UTM(DDD)] that implies the computation DDD() halts.  But if the
simulator aborts, it doesn't say that much (in and of itself) about
whether the /computation/ halts.  The halting problem statement is
not concerned with simulations or how the simulations end.

Every time anyone in these PO threads says "halts" it ought to be
100% clear to everyone whether the computation itself is being
discussed, or whether some simulation final status is intended.
(But that's far from being the case!)  Since the halting problem is
concerned with computations halting and not how partial simulations
are ended, I suggest that PO explicitly make clear that he is
referring to simulations, whenever that is the case.  It seems
reasonable that readers seeing "halts" with no further clarification
can interpret that as actual computation behaviour, as that is how
the term is always used in the literature.  Same with other terms
like "reach"...

So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined
mathematically], or its simulation by HHH?  He means the latter, but
its far from clear, I'd say!  [I think most readers now have come
around to reading it as a statement about simulations rather than
the actual computation, which totally changes things...]


Mike.

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

It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.

*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.

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.

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

Irrelevant nonsense ignored.
We are not discussing a non-halting HHH, but an aborting and halting
HHH. Therefore, aborting a halting program to prevent non-termination,
is simply incorrect.

This is the exact same pattern with Infinite_Recursion()
where there are no conditional branch instructions that
would prevent the first three instructions of
Infinite_Recursion() from endlessly repeating.

void Infinite_Recursion()
{
  Infinite_Recursion();
}

No, there are conditional branch instruction is the simulated HHH, so it
is more like :

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

HHH(DDD)

_DDD()
[00002177] 55               push ebp      ; 1st line [00002178] 8bec             mov ebp,esp   ; 2nd line
[0000217a] 6877210000       push 00002177 ; push DDD
[0000217f] e853f4ffff       call 000015d7 ; call HHH
[00002184] 83c404           add esp,+04
[00002187] 5d               pop ebp
[00002188] c3               ret
Size in bytes:(0018) [00002188]

// executed HHH emulates 1st instance of DDD
New slave_stack at:10388d
Begin Local Halt Decider Simulation   Execution Trace Stored at:113895 [00002177][00113885][00113889] 55         push ebp      ; 1st line
[00002178][00113885][00113889] 8bec       mov ebp,esp   ; 2nd line [0000217a][00113881][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0011387d][00002184] e853f4ffff call 000015d7 ; call HHH

// emulated HHH emulates 2nd instance of DDD
New slave_stack at:14e2b5
[00002177][0015e2ad][0015e2b1] 55         push ebp      ; 1st line
[00002178][0015e2ad][0015e2b1] 8bec       mov ebp,esp   ; 2nd line [0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Here the programmer made a error by programming HHH such that after two recursions it would print this message and abort. Two recursions are not
an infinite recursion.
Apparently, the programmer did not understand that two differs from
infinite.

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

On 7/28/24 4:10 PM, olcott wrote:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been
aborted.
This is not the same as reaching its ret instruction and
terminating
normally (AKA halting).

I think you're wrong, here.  All your C programs are a stand in for >>>>>>> turing machines.  A turing machine is either running or halted. >>>>>>> There is
no third state "aborted".  An aborted C program certainly doesn't >>>>>>> correspond with a running turing machine - so it must be a halted >>>>>>> turing
machine.

So aborted programs are halted programs.  If you disagree,
perhaps you
could point out where in my arguments above I'm wrong.

Aborting is an action performed by a simulator, not the TM being
simulated.

If we want to count "aborted" as some kind of final status, it
will have to be the status of a specific /PARTIAL SIMULATOR's/
simulation of a given computation.  That's not a property of the
computation itself, as different partial simulators can simulate
the same computation and terminate for different reasons.  Like
HHH(DDD) aborts, while UTM(DDD) simulates to completion and so the >>>>>> final simulation status is halts. [Neither of those outcomes
contradict the fact that the computation DDD() halts.]

If some partial simulator halts when simulating a computation [as
with UTM(DDD)] that implies the computation DDD() halts.  But if
the simulator aborts, it doesn't say that much (in and of itself)
about whether the /computation/ halts.  The halting problem
statement is not concerned with simulations or how the simulations >>>>>> end.

Every time anyone in these PO threads says "halts" it ought to be
100% clear to everyone whether the computation itself is being
discussed, or whether some simulation final status is intended.
(But that's far from being the case!)  Since the halting problem
is concerned with computations halting and not how partial
simulations are ended, I suggest that PO explicitly make clear
that he is referring to simulations, whenever that is the case.
It seems reasonable that readers seeing "halts" with no further
clarification can interpret that as actual computation behaviour,
as that is how the term is always used in the literature.  Same
with other terms like "reach"...

So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined >>>>>> mathematically], or its simulation by HHH?  He means the latter,
but its far from clear, I'd say!  [I think most readers now have
come around to reading it as a statement about simulations rather
than the actual computation, which totally changes things...]


Mike.

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

It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.

*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.

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.

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

Irrelevant nonsense ignored.
We are not discussing a non-halting HHH,

No we are not. Please don't act so stupidly.

We are seeing that Infinite_Recursion() does not halt
and seeing that Infinite_Recursion() shows the exact
same non-halting behavior pattern as DDD correctly
emulated by HHH.

So, you are stipulating that HHH will NEVER abort is simulation?

That is the only way that the two traces are even close.

For HHH to ignore the possible conditionality of code activated by the
call to HHH(DDD) inside of DDD, it has to be stipulated that there is none.

Until you do that YOU ARE ACTING STUPIDLY.
Go back an try again.

No, YOU are the one acting deceptively as well as stupidly,

You are just demonstrating how totally ignorant you are of the fields
that you try to talk about, and how little you value truth.

The ONLY way to even partially equate the behavior of
Infinite_Recurstion and DDD / HHH(DDD) is for HHH to be an UNCONDITIONAL emulator of DDD.

I guess you just don't know what unconditional means. It doens't mean it
keeps on going until it shows something, it meens it keeps on going
DISPITE anything that happens.

Of course, understanding conditionals means understanding how logic
works, which has been proven to be beyond your ability,

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

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been
aborted.
This is not the same as reaching its ret instruction and
terminating
normally (AKA halting).

I think you're wrong, here.  All your C programs are a stand in for >>>>>>> turing machines.  A turing machine is either running or halted. >>>>>>> There is
no third state "aborted".  An aborted C program certainly doesn't >>>>>>> correspond with a running turing machine - so it must be a halted >>>>>>> turing
machine.

So aborted programs are halted programs.  If you disagree,
perhaps you
could point out where in my arguments above I'm wrong.

Aborting is an action performed by a simulator, not the TM being
simulated.

If we want to count "aborted" as some kind of final status, it
will have to be the status of a specific /PARTIAL SIMULATOR's/
simulation of a given computation.  That's not a property of the
computation itself, as different partial simulators can simulate
the same computation and terminate for different reasons.  Like
HHH(DDD) aborts, while UTM(DDD) simulates to completion and so the >>>>>> final simulation status is halts. [Neither of those outcomes
contradict the fact that the computation DDD() halts.]

If some partial simulator halts when simulating a computation [as
with UTM(DDD)] that implies the computation DDD() halts.  But if
the simulator aborts, it doesn't say that much (in and of itself)
about whether the /computation/ halts.  The halting problem
statement is not concerned with simulations or how the simulations >>>>>> end.

Every time anyone in these PO threads says "halts" it ought to be
100% clear to everyone whether the computation itself is being
discussed, or whether some simulation final status is intended.
(But that's far from being the case!)  Since the halting problem
is concerned with computations halting and not how partial
simulations are ended, I suggest that PO explicitly make clear
that he is referring to simulations, whenever that is the case.
It seems reasonable that readers seeing "halts" with no further
clarification can interpret that as actual computation behaviour,
as that is how the term is always used in the literature.  Same
with other terms like "reach"...

So when PO says "DDD simulated by HHH cannot reach its final ret
instruction" is he talking about the computation DDD() [as defined >>>>>> mathematically], or its simulation by HHH?  He means the latter,
but its far from clear, I'd say!  [I think most readers now have
come around to reading it as a statement about simulations rather
than the actual computation, which totally changes things...]


Mike.

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

It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.

*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.

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.

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

Irrelevant nonsense ignored.
We are not discussing a non-halting HHH,

No we are not. Please don't act so stupidly.

Why are you contradicting yourself so often? It does not look very clever.
You were talking about an infinite set of HHH, some of which abort, some
of which do not abort.
We all agree that the HHH that do not abort are incorrect, even Olcott
agrees with it. Therefore, no further discussion is needed about the HHH
that do not abort. Starting to mention it again is distracting from the
points of disagreement.

The disagreement that is left is about the HHH that do abort.
Olcott has shown 'traces' of such an HHH when simulating itself.
This proves that after two recursive simulations, HHH aborts its
simulation and halts.
It is comparible with:

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

which also halts after a few recursions.

For some unclear reason, olcott keeps dreaming of the HHH that does not
abort and he thinks that such dreams should play a role in the logic to determine whether the simulation of a halting program is correct.

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

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.

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

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

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

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

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been >>>>>>>>>> aborted.
This is not the same as reaching its ret instruction and
terminating
normally (AKA halting).

I think you're wrong, here.  All your C programs are a stand in >>>>>>>>> for
turing machines.  A turing machine is either running or halted. >>>>>>>>> There is
no third state "aborted".  An aborted C program certainly doesn't >>>>>>>>> correspond with a running turing machine - so it must be a
halted turing
machine.

So aborted programs are halted programs.  If you disagree,
perhaps you
could point out where in my arguments above I'm wrong.

Aborting is an action performed by a simulator, not the TM being >>>>>>>> simulated.

If we want to count "aborted" as some kind of final status, it >>>>>>>> will have to be the status of a specific /PARTIAL SIMULATOR's/ >>>>>>>> simulation of a given computation.  That's not a property of the >>>>>>>> computation itself, as different partial simulators can simulate >>>>>>>> the same computation and terminate for different reasons.  Like >>>>>>>> HHH(DDD) aborts, while UTM(DDD) simulates to completion and so >>>>>>>> the final simulation status is halts. [Neither of those outcomes >>>>>>>> contradict the fact that the computation DDD() halts.]

If some partial simulator halts when simulating a computation
[as with UTM(DDD)] that implies the computation DDD() halts.
But if the simulator aborts, it doesn't say that much (in and of >>>>>>>> itself) about whether the /computation/ halts.  The halting
problem statement is not concerned with simulations or how the >>>>>>>> simulations end.

Every time anyone in these PO threads says "halts" it ought to >>>>>>>> be 100% clear to everyone whether the computation itself is
being discussed, or whether some simulation final status is
intended. (But that's far from being the case!)  Since the
halting problem is concerned with computations halting and not >>>>>>>> how partial simulations are ended, I suggest that PO explicitly >>>>>>>> make clear that he is referring to simulations, whenever that is >>>>>>>> the case. It seems reasonable that readers seeing "halts" with >>>>>>>> no further clarification can interpret that as actual
computation behaviour, as that is how the term is always used in >>>>>>>> the literature.  Same with other terms like "reach"...

So when PO says "DDD simulated by HHH cannot reach its final ret >>>>>>>> instruction" is he talking about the computation DDD() [as
defined mathematically], or its simulation by HHH?  He means the >>>>>>>> latter, but its far from clear, I'd say!  [I think most readers >>>>>>>> now have come around to reading it as a statement about
simulations rather than the actual computation, which totally
changes things...]


Mike.

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

It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.

*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.

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.

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

Irrelevant nonsense ignored.
We are not discussing a non-halting HHH,

No we are not. Please don't act so stupidly.

Why are you contradicting yourself so often? It does not look very
clever.
You were talking about an infinite set of HHH, some of which abort,
some of which do not abort.

*This is all that I am willing to talk about with you*
Every change of subject away from this point will be
construed as the dishonest dodge of the strawman deception.

You didn't even bother to look at how HHH examines the
execution trace of Infinite_Recursion() to determine that Infinite_Recursion() specifies non-halting behavior.

Because of this you cannot see that the execution trace
of DDD correctly emulated by DDD is essentially this same
trace and thus also specifies non-halting behavior.

That is only because you are cheating, by hiding the conditional branch instructions of HHH, which should follow the call instruction into HHH.
HHH simulating itself is more like

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

You never bothered to think about it.

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

On 29/07/2024 20:36, Fred. Zwarts wrote:

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

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

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has been aborted.
This is not the same as reaching its ret instruction and terminating
normally (AKA halting).

I think you're wrong, here.  All your C programs are a stand in for >>>>>>>>>> turing machines.  A turing machine is either running or halted. There is
no third state "aborted".  An aborted C program certainly doesn't >>>>>>>>>> correspond with a running turing machine - so it must be a halted turing
machine.

So aborted programs are halted programs.  If you disagree, perhaps you
could point out where in my arguments above I'm wrong.

Aborting is an action performed by a simulator, not the TM being simulated.

If we want to count "aborted" as some kind of final status, it will have to be the status
of a specific /PARTIAL SIMULATOR's/ simulation of a given computation.  That's not a
property of the computation itself, as different partial simulators can simulate the same
computation and terminate for different reasons.  Like HHH(DDD) aborts, while UTM(DDD)
simulates to completion and so the final simulation status is halts. [Neither of those
outcomes contradict the fact that the computation DDD() halts.] >>>>>>>>>
If some partial simulator halts when simulating a computation [as with UTM(DDD)] that
implies the computation DDD() halts. But if the simulator aborts, it doesn't say that much
(in and of itself) about whether the /computation/ halts.  The halting problem statement is
not concerned with simulations or how the simulations end.

Every time anyone in these PO threads says "halts" it ought to be 100% clear to everyone
whether the computation itself is being discussed, or whether some simulation final status
is intended. (But that's far from being the case!)  Since the halting problem is concerned
with computations halting and not how partial simulations are ended, I suggest that PO
explicitly make clear that he is referring to simulations, whenever that is the case. It
seems reasonable that readers seeing "halts" with no further clarification can interpret
that as actual computation behaviour, as that is how the term is always used in the
literature.  Same with other terms like "reach"...

So when PO says "DDD simulated by HHH cannot reach its final ret instruction" is he talking
about the computation DDD() [as defined mathematically], or its simulation by HHH?  He
means the latter, but its far from clear, I'd say!  [I think most readers now have come
around to reading it as a statement about simulations rather than the actual computation,
which totally changes things...]


Mike.

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

It is a verified fact that DDD emulated by HHH 100% exactly
and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes
HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.

*Anyone as much as hinting otherwise is not being truthful*
If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.

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.

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

Irrelevant nonsense ignored.
We are not discussing a non-halting HHH,

No we are not. Please don't act so stupidly.

Why are you contradicting yourself so often? It does not look very clever. >>> You were talking about an infinite set of HHH, some of which abort, some of which do not abort.

*This is all that I am willing to talk about with you*
Every change of subject away from this point will be
construed as the dishonest dodge of the strawman deception.

You didn't even bother to look at how HHH examines the
execution trace of Infinite_Recursion() to determine that Infinite_Recursion() specifies
non-halting behavior.

Because of this you cannot see that the execution trace
of DDD correctly emulated by DDD is essentially this same
trace and thus also specifies non-halting behavior.

That is only because you are cheating, by hiding the conditional branch instructions of HHH, which
should follow the call instruction into HHH.
HHH simulating itself is more like

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

You never bothered to think about it.

Also there is the crucial difference that Infinite_Recursion() trace is a trace for a single x86
processor. The HHH/DDD trace is not a single processor trace, as it contains entries for multiple
virtual x86 processors, all merged into one. There are all sorts of argument that can be applied to
the simple single x86 processor trace scenario, that simply don't work when transferred to a
multi-processor-simulation merged trace. PO doesn't understand these differences, and has said
there is NO difference! He also deliberately tries to hide these difference, by making his trace
output resemble a single-processor trace as far as he can:

- suppressing trace entries in H which would make it obvious that the matching calls
to HHH are from completely separate logical x86 processors. The output as he presents it
looks pretty much identical to the corresponding (but totally different character) CALL
scenario where HHH calls DDD rather than simulating it.

- omitting a "simulation level" column in his output. He included that info for a brief
period, following my suggestion, but then removed it, saying it "confused" readers.
Of course it did no such thing, but PO thinks anyone who disagrees with him is
confused (or stupid or ignorant). So perhaps the column actually helped people understand
or at least question what the trace was actually saying, and PO didn't like that.)



Mike.

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

Am Mon, 29 Jul 2024 19:16:29 -0500 schrieb olcott:

On 7/29/2024 5:57 PM, Mike Terry wrote:

On 29/07/2024 20:36, Fred. Zwarts wrote:

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

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

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

You didn't even bother to look at how HHH examines the execution
trace of Infinite_Recursion() to determine that Infinite_Recursion()
specifies non-halting behavior.
Because of this you cannot see that the execution trace of DDD
correctly emulated by DDD is essentially this same trace and thus
also specifies non-halting behavior.

That is only because you are cheating, by hiding the conditional
branch instructions of HHH, which should follow the call instruction
into HHH.
HHH simulating itself is more like
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}

Also there is the crucial difference that Infinite_Recursion() trace is
a trace for a single x86 processor.  The HHH/DDD trace is not a single
processor trace, as it contains entries for multiple virtual x86
processors, all merged into one.  There are all sorts of argument that
can be applied to the simple single x86 processor trace scenario, that
simply don't work when transferred to a multi-processor-simulation
merged trace.  PO doesn't understand these differences, and has said
there is NO difference!  He also deliberately tries to hide these
difference, by making his trace output resemble a single-processor
trace as far as he can:

non sequitur:

The simple fact that you continue to ignore is that DDD is correctly
emulated by DDD according to the semantics of the x86 instructions of
DDD and HHH that includes that DDD does call HHH(DDD) in recursive
emulation that will never stop running unless aborted.

Nobody is ignoring that.
The "unless" applies - every HHH in fact aborts simulating.

-  suppressing trace entries in H which would make it obvious that the
matching calls

I am not suppressing any freaking trace entries

You are completely suppressing the trace of the simulator HHH.

Two complete simulations show a pair of identical TMD's are simulating a
pair of identical inputs. We can see this thus proving recursive
simulation.

Except for the Root variable.

   to HHH are from completely separate logical x86 processors.  The
output as he presents it
   looks pretty much identical to the corresponding (but totally
different character) CALL
   scenario where HHH calls DDD rather than simulating it.

Right. I was confused by that for a while. A call could not be aborted.

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

Op 30.jul.2024 om 02:16 schreef olcott:

On 7/29/2024 5:57 PM, Mike Terry wrote:

On 29/07/2024 20:36, Fred. Zwarts wrote:

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

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

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

Stopping running is not the same as halting.
DDD emulated by HHH stops running when its emulation has >>>>>>>>>>>>> been aborted.
This is not the same as reaching its ret instruction and >>>>>>>>>>>>> terminating
normally (AKA halting).

I think you're wrong, here.  All your C programs are a stand >>>>>>>>>>>> in for
turing machines.  A turing machine is either running or >>>>>>>>>>>> halted. There is
no third state "aborted".  An aborted C program certainly >>>>>>>>>>>> doesn't
correspond with a running turing machine - so it must be a >>>>>>>>>>>> halted turing
machine.

So aborted programs are halted programs.  If you disagree, >>>>>>>>>>>> perhaps you
could point out where in my arguments above I'm wrong. >>>>>>>>>>>>

Aborting is an action performed by a simulator, not the TM >>>>>>>>>>> being simulated.

If we want to count "aborted" as some kind of final status, >>>>>>>>>>> it will have to be the status of a specific /PARTIAL
SIMULATOR's/ simulation of a given computation.  That's not a >>>>>>>>>>> property of the computation itself, as different partial >>>>>>>>>>> simulators can simulate the same computation and terminate >>>>>>>>>>> for different reasons.  Like HHH(DDD) aborts, while UTM(DDD) >>>>>>>>>>> simulates to completion and so the final simulation status is >>>>>>>>>>> halts. [Neither of those outcomes contradict the fact that >>>>>>>>>>> the computation DDD() halts.]

If some partial simulator halts when simulating a computation >>>>>>>>>>> [as with UTM(DDD)] that implies the computation DDD() halts. >>>>>>>>>>> But if the simulator aborts, it doesn't say that much (in and >>>>>>>>>>> of itself) about whether the /computation/ halts.  The
halting problem statement is not concerned with simulations >>>>>>>>>>> or how the simulations end.

Every time anyone in these PO threads says "halts" it ought >>>>>>>>>>> to be 100% clear to everyone whether the computation itself >>>>>>>>>>> is being discussed, or whether some simulation final status >>>>>>>>>>> is intended. (But that's far from being the case!)  Since the >>>>>>>>>>> halting problem is concerned with computations halting and >>>>>>>>>>> not how partial simulations are ended, I suggest that PO >>>>>>>>>>> explicitly make clear that he is referring to simulations, >>>>>>>>>>> whenever that is the case. It seems reasonable that readers >>>>>>>>>>> seeing "halts" with no further clarification can interpret >>>>>>>>>>> that as actual computation behaviour, as that is how the term >>>>>>>>>>> is always used in the literature.  Same with other terms like >>>>>>>>>>> "reach"...

So when PO says "DDD simulated by HHH cannot reach its final >>>>>>>>>>> ret instruction" is he talking about the computation DDD() >>>>>>>>>>> [as defined mathematically], or its simulation by HHH?  He >>>>>>>>>>> means the latter, but its far from clear, I'd say!  [I think >>>>>>>>>>> most readers now have come around to reading it as a
statement about simulations rather than the actual
computation, which totally changes things...]


Mike.

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

It is a verified fact that DDD emulated by HHH 100% exactly >>>>>>>>>> and precisely according to the actual x86 semantics of
the emulated code including the recursive call that causes >>>>>>>>>> HHH to emulate itself emulating DDD cannot possibly get
past it own 0000216b machine address.

*Anyone as much as hinting otherwise is not being truthful* >>>>>>>>>> If we remove all of the problematic code then this same
trace still occurs until it crashes from OOM error.

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.

It is ridiculously stupid to expect the correct emulation
of a non-halting input to end.

Irrelevant nonsense ignored.
We are not discussing a non-halting HHH,

No we are not. Please don't act so stupidly.

Why are you contradicting yourself so often? It does not look very
clever.
You were talking about an infinite set of HHH, some of which abort,
some of which do not abort.

*This is all that I am willing to talk about with you*
Every change of subject away from this point will be
construed as the dishonest dodge of the strawman deception.

You didn't even bother to look at how HHH examines the
execution trace of Infinite_Recursion() to determine that
Infinite_Recursion() specifies non-halting behavior.

Because of this you cannot see that the execution trace
of DDD correctly emulated by DDD is essentially this same
trace and thus also specifies non-halting behavior.

That is only because you are cheating, by hiding the conditional
branch instructions of HHH, which should follow the call instruction
into HHH.
HHH simulating itself is more like

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

You never bothered to think about it.

Also there is the crucial difference that Infinite_Recursion() trace
is a trace for a single x86 processor.  The HHH/DDD trace is not a
single processor trace, as it contains entries for multiple virtual
x86 processors, all merged into one.  There are all sorts of argument
that can be applied to the simple single x86 processor trace scenario,
that simply don't work when transferred to a
multi-processor-simulation merged trace.  PO doesn't understand these
differences, and has said there is NO difference!  He also
deliberately tries to hide these difference, by making his trace
output resemble a single-processor trace as far as he can:

The simple fact that you continue to ignore is that DDD
is correctly emulated by DDD according to the semantics
of the x86 instructions of DDD and HHH that includes that
DDD does call HHH(DDD) in recursive emulation that will
never stop running unless aborted.

HHH aborts, so it a halting programs.
Dreaming of a HHH that never stops is not a substitute for logic, but irrelevant
There is no need to abort the simulation of a halting program. It is
against the semantics of the x86 language to skip instructions of a
halting program. Your simulation fails by your own criterion.

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.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incomplete and, therefore, incorrect.

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

On 30/07/2024 08:19, joes wrote:

Am Mon, 29 Jul 2024 19:16:29 -0500 schrieb olcott:

On 7/29/2024 5:57 PM, Mike Terry wrote:

On 29/07/2024 20:36, Fred. Zwarts wrote:

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

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

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

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

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

You didn't even bother to look at how HHH examines the execution
trace of Infinite_Recursion() to determine that Infinite_Recursion() >>>>> specifies non-halting behavior.
Because of this you cannot see that the execution trace of DDD
correctly emulated by DDD is essentially this same trace and thus
also specifies non-halting behavior.

That is only because you are cheating, by hiding the conditional
branch instructions of HHH, which should follow the call instruction
into HHH.
HHH simulating itself is more like
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}

Also there is the crucial difference that Infinite_Recursion() trace is
a trace for a single x86 processor.  The HHH/DDD trace is not a single
processor trace, as it contains entries for multiple virtual x86
processors, all merged into one.  There are all sorts of argument that
can be applied to the simple single x86 processor trace scenario, that
simply don't work when transferred to a multi-processor-simulation
merged trace.  PO doesn't understand these differences, and has said
there is NO difference!  He also deliberately tries to hide these
difference, by making his trace output resemble a single-processor
trace as far as he can:

non sequitur:

The simple fact that you continue to ignore is that DDD is correctly
emulated by DDD according to the semantics of the x86 instructions of
DDD and HHH that includes that DDD does call HHH(DDD) in recursive
emulation that will never stop running unless aborted.

Nobody is ignoring that.
The "unless" applies - every HHH in fact aborts simulating.

-  suppressing trace entries in H which would make it obvious that the
matching calls

I am not suppressing any freaking trace entries

You are completely suppressing the trace of the simulator HHH.

Two complete simulations show a pair of identical TMD's are simulating a
pair of identical inputs. We can see this thus proving recursive
simulation.

Except for the Root variable.

   to HHH are from completely separate logical x86 processors.  The
output as he presents it
   looks pretty much identical to the corresponding (but totally
different character) CALL
   scenario where HHH calls DDD rather than simulating it.

Right. I was confused by that for a while. A call could not be aborted.

Exactly. To avoid infinite recursion:
- Recursive /call/ pattern MUST break from innermost call at some point, which then percolates back
throught the stack of calls until the outer call finally returns. This is (relatively) easy to
reason about in a proof.
- Recursive /simulation/ pattern can break exactly as for recursive call, but additionally might
break from an outer simulation simply aborting its inner simulation. This is more complex to reason
about in a proof.

[But PO is TOTALLY incapable of reasoning about either scenario. Still I doubt that will stop 5000
future posts with PO saying "everyone with the right skills can see my rule is sound", whilst
responders repeat over and over that it patently is not sound since it fails with input DDD.]


Mike.

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