On 7/28/24 10:32 AM, olcott wrote:

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

Right. SO why does your supposed "correct emulation" of a input you
claim to b on-halting end. Only because you are showing that HHH's
emulation is *NOT* a "correct emulation", but only a PARTIAL emulaiton,
which doesn't show the behavior of the input after it aborts.

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.

Nope, becasue a call to Infinite_Recursion is not the same thing as a
call to HHH(DDD).

The call to Infinite_Recursion will never end no matter how long you
look at the behavior of the program.

THe call to HHH(DDD) will, by your admission, emulate DDD for a while
and then abort its emulation and then Return. This is because there ARE conditional branch instructions in the execution path, which goes into HHH.

So, unless you want to try to claim that running forever is exactly the
same as talting behaovir of HHH(DDD)< you are stuck with being shown to
be a liar.

Now, if HHH was an UNCONDITIONAL emulator, and not a decider, there are arguements that the pattern, while not EXACTLY the same, is close enough
that a similar proof could be built. But that requires HHH to be a UNCONDITIONAL emulator, the fact that its emulation is conditioned on
its halting deciding adds that conditional branch that breaks the
infinite loop.

You are just so stupid you don't see that clear and obvous fact, because
you don't even seem to know what a PROGRAM is that can be decided on.

Your problem is that you just made yourself into a self-made ignorant
idiot which doesn't actually care about what it true, which has made you
into the pathetic pathological liar you have proved yourself to be.

void Infinite_Recursion()
{
  Infinite_Recursion();
}

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

=====

void DDD()
{
  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]

Which CAN NOT be the input for the progream "DDD" as it calls outside of
the input, and thus you are proving that you are just a pathetic
ignorant pathological liar.

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

But that isn't a correct emulation of the call HHH by ANY criteria.

By the x86 criteria, it must be the instrcuctions of HHH, which need to
be part of the input, thus proving your stupdiity.

If by functional equivalence, since HHH is a CONDITIONAL emulation,
every step along the way needs to be marked by the fact that the HHH
that was called had the option of stopping the emulation before
continuing, which shows that the trace is FUNDANMENTALLY DIFFERENT

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

Not, if the trace IS correct, and there was no conditionality of the
emulation, then that final abort statement is just a LIE, or the proof
that you lied before.

Sorry, you are just proving you don't care about what is actually true,
but are running your halting-problem scam by the playbook of the
election deniers and the climate-change deniers, thus telling them that
you agree with their methods, as you use them too.

Sorrty, that just makes you a damned hypocritical liar that is likely
destined for an eternity in Gehenna.

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

On 7/29/24 8:16 PM, olcott wrote:

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.

How do you say that? The call HHH instruction is *NOT* correctly emulated.

You ignore this error to just prove you are a pathological liar.

Please show where in the Intel documentation there is support for your
claim.

Your failure to do this has PROVED that you are just a pathetic liar

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

I am not suppressing any freaking trace entries https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Which, as has been pointed out before, isn't a listing of the trace that
any HHH made, so irrelvent, except to prove that you are just a liar.

It is exactly as I have been saying all along
if you can freaking understand a 1.5 page trace
then adding a 200 more pages cannot possibly help.

But both the 1.5 page trace, and the 200 page trace are wrong as the
trace of the x86 emulation that HHH does.

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation

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.

But not INFINITE, unless embedded_H NEVER aborts, and thus not a decider.

If embedded_H ever aborts, then the simulatation started at the first
instance of (c) will abort (removing all the following layers) and then
the machine will halt.

*For context here is the full Linz proof* https://www.liarparadox.org/Linz_Proof.pdf

There aren't any freaking virtual x86 processors there.
There are still simulation levels.
It doesn't freaking make any damn difference.

Nope, no "simulation levels" as those don't actually exist, but are just
a meta-logic. There is the operation of the machine H (H^) (H^) and the
machine H^ (H^).

If H (H^) (H^) goes to qn to say its input is not halting, then the copy
of it in H^ (H^) does the same, and H^ (H^) Halts, showing H was just wrong.

    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)