On 7/26/24 1:09 PM, olcott wrote:

On 7/26/2024 11:28 AM, olcott wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

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

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

HHH(DDD) is only accountable for the actual behavior that
its input specifies and is not accountable for the behavior
of the computation that itself is contained within:
the directly executed DDD();

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.

When we understand that embedded_H is accountable for the
behavior of its input and not accountable for the behavior
of the computation that itself is contained within then
we understand that embedded_H is necessarily correct to
transition to its own Ĥ.qn state.

https://www.liarparadox.org/Linz_Proof.pdf

_DDD()
[00002177] 55               push ebp
[00002178] 8bec             mov ebp,esp
[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]

_main()
[00002197] 55               push ebp
[00002198] 8bec             mov ebp,esp
[0000219a] e8d8ffffff       call 00002177 ; call DDD
[0000219f] 33c0             xor eax,eax
[000021a1] 5d               pop ebp
[000021a2] c3               ret
Size in bytes:(0012) [000021a2]

 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  =========  ============= [00002197][001037e9][00000000] 55         push ebp [00002198][001037e9][00000000] 8bec       mov ebp,esp [0000219a][001037e5][0000219f] e8d8ffffff call 00002177 ; call DDD [00002177][001037e1][001037e9] 55         push ebp [00002178][001037e1][001037e9] 8bec       mov ebp,esp [0000217a][001037dd][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001037d9][00002184] e853f4ffff call 000015d7 ; call HHH

// 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 [00002178][00113885][00113889] 8bec       mov ebp,esp [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 [00002178][0015e2ad][0015e2b1] 8bec       mov ebp,esp [0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[00002184][001037e1][001037e9] 83c404     add esp,+04 [00002187][001037e5][0000219f] 5d         pop ebp [00002188][001037e9][00000000] c3         ret [0000219f][001037e9][00000000] 33c0       xor eax,eax [000021a1][001037ed][00000018] 5d         pop ebp [000021a2][001037f1][00000000] c3         ret
Number of Instructions Executed(10071) == 150 Pages

So, where is the correct emulaiton of the input?

All you deiders just INCORRECTLY assume that HHH(DDD) will never return,
which you prove to be incorrect.

So, you just prove your program is wrong.

3 is not "infinite", I guess you can't count very high because you are
that stupid.

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

On 7/26/24 12:28 PM, olcott wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

Of course it is, if that is the machine that its input describes.

Got a reference for you claim, or is th9is just anothoer of your "Diagonalization proof" lies. It will be presumed to be such a lie until
you can provide proof.

You do this enough, you have earned that presumption.

It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

Right, it is accountable for the behavior defined by the problem it is
supposed to be answering. For Halting, one expression of that is what an
ACTUAL UTM will do when given this input, which means

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

void DDD()
{
  HHH(DDD);
}

int main()
{
  DDD();
}

And, without the actual code of H, this isn't a valid halting problem
input, as it isn't a full program.

When we include that code for HHH, we of course get a DIFFERENT input
for each different HHH that DDD has been paired to (which doesn't change
if we look at the behavor of THIS input to other deciders, or the UTM
that determines the actual behavior).

HHH(DDD) is only accountable for the actual behavior that
its input specifies and is not accountable for the behavior
of the computation that itself is contained within:
the directly executed DDD();

WRONG. The actual behavior that its input specifies *IS* the behavior of
the computation that is the directly executed DDD().

YOu are just proving yourself a ignorant stupid liar.

Sourcd for you claim, or you are a liar, and you are presumed (and
proven to be) one until you actually provide that proof.

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

Which only happens like that if H (and thus embedded_H) *NEVER* abort
its simulation of its input and thus fails to be a decider.

IF it ever does, then after that number of steps, the outer embedded_H
will abort its simulation and return to H^.qn and thus H^ will halt.

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.

Nope, not if they are conditional simulation, and if they are not, then
they can't abort the simulation.

When we understand that embedded_H is accountable for the
behavior of its input and not accountable for the behavior
of the computation that itself is contained within then
we understand that embedded_H is necessarily correct to
transition to its own Ĥ.qn state.

https://www.liarparadox.org/Linz_Proof.pdf

But it is responsible for ALL the bebavior of its input, even the
behavior that it doesn't get to because it has decided to stop its
simulation.

Of course, if it never decides to stop its simulation, it never does and
never answers, so the programmer has a problem on their hands.

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

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

--
Mikko

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

Op 26.jul.2024 om 18:28 schreef olcott:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

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

void DDD()
{
  HHH(DDD);
}

int main()
{
  DDD();
}

You keep repeating this, without learning from your errors.
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.

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

HHH(DDD) is only accountable for the actual behavior that
its input specifies and is not accountable for the behavior
of the computation that itself is contained within:
the directly executed DDD();

And the input is DDD, which calls HHH, so HHH is accountable for a
correct simulation of *itself*.
If it recognises that a copy of itself is within the input, it should
take its own behaviour into account.
DDD has no other behaviour than HHH. When HHH returns, DDD does, too.
But HHH cannot possibly simulate *itself* correctly.

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

Op 26.jul.2024 om 19:09 schreef olcott:

On 7/26/2024 11:28 AM, olcott wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

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

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

HHH(DDD) is only accountable for the actual behavior that
its input specifies and is not accountable for the behavior
of the computation that itself is contained within:
the directly executed DDD();

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.

When we understand that embedded_H is accountable for the
behavior of its input and not accountable for the behavior
of the computation that itself is contained within then
we understand that embedded_H is necessarily correct to
transition to its own Ĥ.qn state.

https://www.liarparadox.org/Linz_Proof.pdf

_DDD()
[00002177] 55               push ebp
[00002178] 8bec             mov ebp,esp
[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]

_main()
[00002197] 55               push ebp
[00002198] 8bec             mov ebp,esp
[0000219a] e8d8ffffff       call 00002177 ; call DDD
[0000219f] 33c0             xor eax,eax
[000021a1] 5d               pop ebp
[000021a2] c3               ret
Size in bytes:(0012) [000021a2]

 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  =========  ============= [00002197][001037e9][00000000] 55         push ebp [00002198][001037e9][00000000] 8bec       mov ebp,esp [0000219a][001037e5][0000219f] e8d8ffffff call 00002177 ; call DDD [00002177][001037e1][001037e9] 55         push ebp [00002178][001037e1][001037e9] 8bec       mov ebp,esp [0000217a][001037dd][00002177] 6877210000 push 00002177 ; push DDD [0000217f][001037d9][00002184] e853f4ffff call 000015d7 ; call HHH

// 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 [00002178][00113885][00113889] 8bec       mov ebp,esp [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 [00002178][0015e2ad][0015e2b1] 8bec       mov ebp,esp [0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD [0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

A stupid programmer has made HHH to print this incorrect message. There
is no infinite recursion.
HHH is simply unable to decide about finite recursions.

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

Similarly HHH aborts after N recursions.
HHH decides after N recursions that there is an infinite recursion,
which is incorrect.

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.

[00002184][001037e1][001037e9] 83c404     add esp,+04 [00002187][001037e5][0000219f] 5d         pop ebp [00002188][001037e9][00000000] c3         ret [0000219f][001037e9][00000000] 33c0       xor eax,eax [000021a1][001037ed][00000018] 5d         pop ebp [000021a2][001037f1][00000000] c3         ret
Number of Instructions Executed(10071) == 150 Pages

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

Op 26.jul.2024 om 19:29 schreef olcott:

On 7/26/2024 12:09 PM, olcott wrote:

On 7/26/2024 11:28 AM, olcott wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

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

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

HHH(DDD) is only accountable for the actual behavior that
its input specifies and is not accountable for the behavior
of the computation that itself is contained within:
the directly executed DDD();

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.

When we understand that embedded_H is accountable for the
behavior of its input and not accountable for the behavior
of the computation that itself is contained within then
we understand that embedded_H is necessarily correct to
transition to its own Ĥ.qn state.

https://www.liarparadox.org/Linz_Proof.pdf

_DDD()
[00002177] 55               push ebp
[00002178] 8bec             mov ebp,esp
[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]

_main()
[00002197] 55               push ebp
[00002198] 8bec             mov ebp,esp
[0000219a] e8d8ffffff       call 00002177 ; call DDD
[0000219f] 33c0             xor eax,eax
[000021a1] 5d               pop ebp
[000021a2] c3               ret
Size in bytes:(0012) [000021a2]

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00002197][001037e9][00000000] 55         push ebp
[00002198][001037e9][00000000] 8bec       mov ebp,esp
[0000219a][001037e5][0000219f] e8d8ffffff call 00002177 ; call DDD
[00002177][001037e1][001037e9] 55         push ebp
[00002178][001037e1][001037e9] 8bec       mov ebp,esp
[0000217a][001037dd][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][001037d9][00002184] e853f4ffff call 000015d7 ; call HHH

// 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
[00002178][00113885][00113889] 8bec       mov ebp,esp
[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
[00002178][0015e2ad][0015e2b1] 8bec       mov ebp,esp
[0000217a][0015e2a9][00002177] 6877210000 push 00002177 ; push DDD
[0000217f][0015e2a5][00002184] e853f4ffff call 000015d7 ; call HHH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above has the same behavior pattern as infinite recursion
shown below.

void Infinite_Recursion()
{
  Infinite_Recursion();
}

No, it has the same behaviour pattern as Finite_Recursion:

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

But HHH (and probably olcott as well) thinks that two recursions are
enough to prove an infinite recursion.

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.

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

On Fri, 26 Jul 2024 11:28:43 -0500, olcott <[email protected]>
wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.>
It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

You might want to actually work on definitions rather than shouting
out word salad

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

Op 27.jul.2024 om 16:21 schreef olcott:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).
It computes the mapping from its input to the value of their sum.

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

And the semantics of the x86 code shows that DDD has halting behaviour,
which is proved by the direct execution and by the simulation by another simulator.

The input to HHH(DDD) specifies the equivalent of infinite
recursion as fully elaborated in another reply.

The input to HHH is DDD, which includes HHH, which aborts and halts
after two recursions, so DDD halts as well. Therefore, the input
specifies a two cycle recursion, but HHH is unable to simulate it
correctly, because
HHH cannot possibly simulate *itself* correctly, which has been proved
in many replies.
Two is different from infinite. Is that already over your head?

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

On 7/27/24 9:41 AM, olcott wrote:

On 7/27/2024 3:59 AM, Mad Hamish wrote:

On Fri, 26 Jul 2024 11:28:43 -0500, olcott <[email protected]>
wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.>
It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

You might want to actually work on definitions rather than shouting
out word salad

Which definitions do you need?
Computing the mapping from a finite string of x86 machine
language to its actual behavior is the most difficult one.

Because HHH is an x86 emulator it merely emulates its input
including emulating itself emulating its input. That is how
the mapping is computed.

Maybe you should understand the actual meaning of your definitiion and
DO it correctly.

HHH does show its emulationg itself emulating the input, it show the
emulation it would do, but ignores that said emulation is CPONDITIONAL.

Knowing the semantics of the x86 language is also required, the
best that I can do here is annotate the code. I provide the C
source code to make that easier.

Which meean that HHH needs to actually emulate the code that the call
HHH points to, and can't (as you try to do) replace that with a generic
idea of what that code does as an emulator.

Note: The x86 language has no concept of an instruction causing a
emulation of a piece of code, only the direct execution of the code that
is in the actual stream of execution.

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

void DDD()
{
  HHH(DDD);
}

int main()
{
  DDD();
}

*H is a termination analyzer based on an x86 emulator*

The only two things that need to be known about HHH is that:
(a) It emulates its input in DebugStep() mode
(b) It stops emulating its input when it seen a
non-terminating behavior pattern.

Nope, You are just admitting that you are LYING that it does a "Correct
x86 emulaiton" of the code, as the code can only be correctly emulated
as x86 code if you have the code.

And, if you loosen your requirements to allow for just some form of
equivalency emulation, the existance of condition (b) means that when
you look at the emulation you need to allow for the fact that HHH might
abort its emulation of the code at EVERY STEP, and thus you can not
possible conclude the necessity of infinite recursion, as you have a conditional in the loop that can abort it at every steps.

Thus the only way that the code actually HAS infinite recursion is if
HHH NEVER aborts, but since HHH will decide to abort, that case is not true.

So, all you are proving is you don't understand the rules of logic, you
are not allowed to use the assumption of a predicate to be true, when it
is actually (or even just potentially) false.

*Here is the C source code of DDD, HHH and supporting functions* https://github.com/plolcott/x86utm/blob/master/Halt7.c

*This function switches process context from HHH to DDD*
*to emulate one x86 machine language instruction of DDD*
*then switches back to HHH*

u32  DebugStep(Registers* master_state,
               Registers* slave_state,
               Decoded_Line_Of_Code* decoded) { return 0; }

typedef struct Decoded
{
  u32 Address;
  u32 ESP;          // Current value of ESP
  u32 TOS;          // Current value of Top of Stack
  u32 NumBytes;
  u32 Simplified_Opcode;
  u32 Decode_Target;
} Decoded_Line_Of_Code;

Immediately before an instruction is emulated HHH
searches a scratch build std::vector<Decoded> execution_trace;
Looking for a non-halting behavior pattern.

An x86utm operating system function provides PushBack()
void PushBack(u32 stdvector, u32 data_ptr, u32 size_in_bytes) {}

An x86utm operating system function allocated memory
u32* Allocate(u32 size) { return 0; }

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

On 7/27/24 10:21 AM, olcott wrote:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).
It computes the mapping from its input to the value of their sum.

Right, and the input to HHH(DDD) is the PROGRAM DDD

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

And if that finite string doesn't contain ALL the code of DDD, it just
isn't the right input, or the right inerpreation of the inpt,

The input to HHH(DDD) specifies the equivalent of infinite
recursion as fully elaborated in another reply.

Nope, that comment just shows that you are just an ignorant
pathoological liar.

Which case is it:

The input doesn't contain the full code of DDD, and thus isn't a proper
input to ask about the behavior of DDD, and thus your whole arguement is
based on a false premise that you are asking the question you say you
are, since HHH can not do a correct x86 emulation of code that it does
not have.

That you think of the input as containing a version of HHH that differs
in actual behavior from the ACTUAL HHH that is there, and thus you are
lying that you are asking about the DDD that is actually there (as that
DOES call the HHH that behaves as the HHH that main calls).

That you admit that the input contains the same version of HHH as is
there, but HHH is allowed to think of it as something different, and
ignore that it WILL abort its emulation and return, and thus you are
lying about HHH actually doing something at least generically called a
correct emulation, since a correct emulation must replicate the behavior
of the thing being emulated.

Or, you just admit that you are lying about what HHH is doing.

You get your choice, which way are you lying

YOU ARE LYIBG,

Try to sbow how what you are doing is ACTUALLY correct, since you admit
that the diffect execution of DDD will halt, and the actual question to
HHH is what the direct execution does, which you admit is different then
th e answer you are giving.

Where is an actually reliable source, and not just one of your LYING
CLAIMS that justifies your LYING CLAIM.

Sorry, you have just built your life on lies, and are paying the price
for that in a destroyed reputation.

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

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

It computes the mapping from its input to the value of their sum.

That's obvious but is it relevant?

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

Now is that relevant?

Besides, what does the word "must" mean?
And what justifies that "must"?

The input to HHH(DDD) specifies the equivalent of infinite
recursion as fully elaborated in another reply.

That claim is not proven but is it relevant here?

--
Mikko

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

On 2024-07-27 08:59:47 +0000, Mad Hamish said:

On Fri, 26 Jul 2024 11:28:43 -0500, olcott <[email protected]>
wrote:

No decider is ever accountable for the behavior of the
computation that itself is contained within.>
It is only accountable for computing the mapping from the
input finite string to the actual behavior that this finite
string specifies.

You might want to actually work on definitions rather than shouting
out word salad

From what he has posted recently and earlier it seems the opposite.

--
Mikko

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

On 7/29/24 12:32 PM, olcott wrote:

On 7/28/2024 3:40 AM, Mikko wrote:

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

It computes the mapping from its input to the value of their sum.

That's obvious but is it relevant?

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

Now is that relevant?

Halt deciders report the halt status on the basis
of the behavior that a finite string input specifies.

And that is the behavior of the program that the input specifies, which
must be a FULL program.

I.E. HHH(DDD) gets as the input ALL the code that DDD uses, inlcuding
that of HHH.

Did you think that halt deciders report the halt
status on some other basis?

Nope.

Halt deciders are not allowed to report on the behavior
of the actual computation that they themselves are contained
within. They are only allowed to compute the mapping from
input finite strings.

Of course they are if that is what the input specifies by fully
describing the algorithm of that program.

Where do you get you stupid ideas?

I think you just make them up out of your ignorance.


Yes, You can't ask about "The program that you are constained in" as
that form of indirect reference, but there is nothing against giving it
the representation of an algorithm that includes a copy of the decider,
whether or not that algorithm is the one that is using it (which can't
matter).

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

On 2024-07-29 16:32:00 +0000, olcott said:

On 7/28/2024 3:40 AM, Mikko wrote:

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

It computes the mapping from its input to the value of their sum.

That's obvious but is it relevant?

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

Now is that relevant?

Halt deciders report the halt status on the basis
of the behavior that a finite string input specifies.

How is that relevant?

--
Mikko

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

On 2024-07-30 23:20:43 +0000, olcott said:

On 7/30/2024 1:56 AM, Mikko wrote:

On 2024-07-29 16:32:00 +0000, olcott said:

On 7/28/2024 3:40 AM, Mikko wrote:

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable" >>>>>> in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).

That claim is fully unjustified. How do you even define "accountable"
in the context of computations, automata, and deciders?

It computes the mapping from its input to the value of their sum.

That's obvious but is it relevant?

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

Now is that relevant?

Halt deciders report the halt status on the basis
of the behavior that a finite string input specifies.

How is that relevant?

Computable functions are the formalized analogue of the intuitive
notion of algorithms, in the sense that a function is computable if
there exists an algorithm that can do the job of the function, i.e.
*given an* *input of the function domain it can return the
corresponding output* https://en.wikipedia.org/wiki/Computable_function

How is that relevant?

The question is still unanswered. Apparently the answer is "no way" or
an answer would already be given.

--
Mikko

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

Am Thu, 01 Aug 2024 06:38:36 -0500 schrieb olcott:

On 8/1/2024 2:40 AM, Mikko wrote:

On 2024-07-30 23:20:43 +0000, olcott said:

On 7/30/2024 1:56 AM, Mikko wrote:

On 2024-07-29 16:32:00 +0000, olcott said:

On 7/28/2024 3:40 AM, Mikko wrote:

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define

"accountable"
in the context of computations, automata, and deciders?

It computes the mapping from its input to the value of their sum. >>>>>> That's obvious but is it relevant?

The question is still unanswered. Apparently the answer is "no way" or
an answer would already be given.

int main() { DDD(); } halts yet is HHH is no allowed to consider that.

Wut. HHH gets DDD as input.

HHH is not allowed to report on the behavior of the computation that
itself is contained within. HHH is only allowed to report on the
behavior that its input finite string specifies.

Those are identical. Its input is a description of its container.

It is a matter of verified fact that when DDD is correctly emulated by
HHH that the sequence of steps is different than when DDD is correctly emulated by HHH1.

Where is the verification, especially in the light of the Root variable?

--
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-08-01 11:38:36 +0000, olcott said:

On 8/1/2024 2:40 AM, Mikko wrote:

On 2024-07-30 23:20:43 +0000, olcott said:

On 7/30/2024 1:56 AM, Mikko wrote:

On 2024-07-29 16:32:00 +0000, olcott said:

On 7/28/2024 3:40 AM, Mikko wrote:

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

No decider is ever accountable for the behavior of the
computation that itself is contained within.

That claim is fully unjustified. How do you even define "accountable" >>>>>>>> in the context of computations, automata, and deciders?

int sum(int x, int y){ return x + y; }
sum(5,6) is not accountable for reporting sum(3,2).

That claim is fully unjustified. How do you even define "accountable" >>>>>> in the context of computations, automata, and deciders?

It computes the mapping from its input to the value of their sum. >>>>>>

That's obvious but is it relevant?

HHH must compute the mapping from its input finite string
of the x86 machine code of DDD to the behavior that this
finite string specifies and then report on the halt status
of this behavior.

Now is that relevant?

Halt deciders report the halt status on the basis
of the behavior that a finite string input specifies.

How is that relevant?

Computable functions are the formalized analogue of the intuitive
notion of algorithms, in the sense that a function is computable if
there exists an algorithm that can do the job of the function, i.e.
*given an* *input of the function domain it can return the
corresponding output* https://en.wikipedia.org/wiki/Computable_function

How is that relevant?

The question is still unanswered. Apparently the answer is "no way" or
an answer would already be given.

int main() { DDD(); } halts yet is HHH is no allowed
to consider that. HHH is not allowed to report on the
behavior of the computation that itself is contained
within. HHH is only allowed to report on the behavior
that its input finite string specifies.

It is a matter of verified fact that when DDD is correctly
emulated by HHH that the sequence of steps is different
than when DDD is correctly emulated by HHH1.

correctly emulated* According to the x86 semantics of
DDD, HHH, and HHH1.

It has always been correct for the last three years
and people try to get away with "it doesn't do what
I expect therefore its wrong".

That does not define what "accountable" means in the context of behaviours
of computations.

--
Mikko

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