On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the 5th instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention HHHn
below, so that changes, but DDD, so the input doesn't and thus is CAN'T
be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that
input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is available
to HHHn when it emulates its input, that DDD must actually be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Your problem is that for any other DDDn / HHHn, you don't have Y so you
don't have Z.

void EEE()
{
  HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.

It can't for DDDn, since when we move to HHHn+1 we no longer have DDDn
but DDDn+1, which is a different input.

And in fact, if we give this DDDn that calls HHHn to an independent
actual correct x86 emulator, then we see that DDDn calls HHHn which will simulate n steps of the DDDn it was given, then abort its emulation and
return to the DDDn that called it which returns.

Thus, ALL DDDn, with a finite n are Halting, and only DDD∞ is non-halting.

You have been shown thins many times, and your inability to understand
it just shows that you seem to have a funny-mental problem with your understanding of the basics of the things you are trying to talk about,
and have shown yourself to be nothing but a stupid liar.

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

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the 5th
instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention HHHn
below, so that changes, but DDD, so the input doesn't and thus is
CAN'T be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86 language >>> Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that
input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually
be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86 language >> Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting.


Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so
you don't have Z.

void EEE()
{
   HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.

It can't for DDDn, since when we move to HHHn+1 we no longer have DDDn
but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

HHHn is given DDDn as its input,

Remeber, since you said that the input to HHH includes all the memory,
if that differs, it is a DIFFERENT input, and needs to be so marked.

You are just admittig that you are just stupid and think two things that
are different are the same.

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

Am Mon, 19 Aug 2024 23:33:52 -0500 schrieb olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.
I thought you said you removed it.

_DDD()
[00002172] 55         push ebp      ; housekeeping [00002173]
8bec       mov ebp,esp   ; housekeeping [00002175] 6872210000 push
00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call
HHH(DDD)
[0000217f] 83c404     add esp,+04 [00002182] 5d         pop ebp
[00002183] c3         ret Size in bytes:(0018) [00002183]

But it can't emulate DDD correctly past 4 instructions, since the 5th
instruciton to emulate doesn't exist.
And, you can't include the memory that holds HHH, as you mention HHHn
below, so that changes, but DDD, so the input doesn't and thus is
CAN'T be part of the input.

Changing the code, but not the address, constitutes a change.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c Thus making
all of the code of HHH directly available to DDD and itself. HHH
emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that
input needs to be DDDn
And, in fact,
Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually
be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:
X = DDD∞ emulated by HHH∞ according to the semantics of the x86
language Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running
The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting.
Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so
you don't have Z.

HHHn correctly predicts the behavior of DDD the same way that HHHn
correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.
It can't for DDDn, since when we move to HHHn+1 we no longer have
DDDn but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can do this same sort of
thing. Computations are not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).
It does this same same way that HHHn(EEE)
predicts the behavior of HHH∞(EEE).

The bytes of HHH are part of DDD.

--
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-20 02:47:49 +0000, olcott said:

*Everything that is not expressly stated below is*
*specified as unspecified*

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

_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

X = DDD emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

No, it does not. Above X is not a truth bearer (no verb).
Y and Z are distinct propositions abot different things,
Y about HHH∞ and Z about DDD with no obvious connection.
In addition your "basic fact" menstions HHH but not HHH∞.
It is unspecifend whether HHH or HHH∞ ever emulate or
ever abort their emulation or have aborted their emulation
and therefore whether "DDD emulated by HHH" and "DDD
emulated by HHH∞" denote anything. As DDD only calls HHH
but not HHH∞ there is no connection between X and Z.

x86utm takes the compiled Halt7.obj file of this c program https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

void EEE()
{
HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

It cannot correctly predicted the same if the behavours
of DDD and EEE are different.

--
Mikko

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

Op 20.aug.2024 om 06:33 schreef olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the
5th instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention
HHHn below, so that changes, but DDD, so the input doesn't and thus
is CAN'T be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86
language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that
input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually
be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86
language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting.


Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so
you don't have Z.

void EEE()
{
   HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.


It can't for DDDn, since when we move to HHHn+1 we no longer have
DDDn but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

Not all HHH can be at the same memory at the same time. When HHHn is in
the memory, then DDD calls HHHn, not HHH∞.
When HHHn is doing the simulation, HHHn is in that memory, therefore, it
should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless you
are cheating with the Root variable to switch between HHHn and HHH∞,
which causes HHHn to process the non-input HHH∞ instead of the input HHHn.

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

Am Tue, 20 Aug 2024 08:18:57 -0500 schrieb olcott:

On 8/20/2024 5:29 AM, Fred. Zwarts wrote:

Op 20.aug.2024 om 06:33 schreef olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

Not all HHH can be at the same memory at the same time.

Counter factual. HHH∞ is hypothetical thus takes no memory.
HHH and DDD remains at the same physical machine address locations.

HHH_oo can be implemented.

When HHHn is in the memory, then DDD calls HHHn, not HHH∞.
When HHHn is doing the simulation, HHHn is in that memory, therefore,
it should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless you
are cheating with the Root variable to switch between HHHn and HHH∞,
which causes HHHn to process the non-input HHH∞ instead of the input
HHHn.

HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts the
behavior of a hypothetical HHH∞(DDD) as described below

HHHn should simulate itself, and HHH_oo should also be simulated by
itself.

--
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 8/20/24 4:07 PM, olcott wrote:

On 8/20/2024 1:55 PM, joes wrote:

Am Tue, 20 Aug 2024 08:18:57 -0500 schrieb olcott:

On 8/20/2024 5:29 AM, Fred. Zwarts wrote:

Op 20.aug.2024 om 06:33 schreef olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

Not all HHH can be at the same memory at the same time.

Counter factual. HHH∞ is hypothetical thus takes no memory.
HHH and DDD remains at the same physical machine address locations.

HHH_oo can be implemented.

A change of one line of code would do this.

When HHHn is in the memory, then DDD calls HHHn, not HHH∞.
When HHHn is doing the simulation, HHHn is in that memory, therefore,
it should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless you >>>> are cheating with the Root variable to switch between HHHn and HHH∞, >>>> which causes HHHn to process the non-input HHH∞ instead of the input >>>> HHHn.

HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts the
behavior of a hypothetical HHH∞(DDD) as described below

HHHn should simulate itself, and HHH_oo should also be simulated by
itself.

*This is HHHn and it does emulate itself emulating DDD*

No, it emulates DDDn, not just DDD, as DDD varies on the decider it
calls, which is the decider that needs to get it right.

It is just a LIE to try to say that all the HHHns get the "same" input,
becuase the input contains HHHn, and they are different.

x86utm takes the compiled Halt7.obj file of this c program https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

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

On 8/20/24 9:18 AM, olcott wrote:

On 8/20/2024 5:29 AM, Fred. Zwarts wrote:

Op 20.aug.2024 om 06:33 schreef olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the
5th instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention
HHHn below, so that changes, but DDD, so the input doesn't and
thus is CAN'T be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86 >>>>>>> language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input,
that input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must
actually be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86 >>>>>> language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting. >>>>

Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y
so you don't have Z.

void EEE()
{
   HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.


It can't for DDDn, since when we move to HHHn+1 we no longer have
DDDn but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

Not all HHH can be at the same memory at the same time.

Counter factual. HHH∞ is hypothetical thus takes no memory.
HHH and DDD remains at the same physical machine address locations.

Then DDD calls THIS HHH, the one claimed to get the answer, and HHH∞
which it correctly emulates this DDD, will see it call the actual HHH
which will emulate for a while and then abort its emulation and return,
and thus HHH∞ will see it reach the final state.

Sorry, you just put yourself into the hole

When HHHn is in the memory, then DDD calls HHHn, not HHH∞.
When HHHn is doing the simulation, HHHn is in that memory, therefore,
it should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless
you are cheating with the Root variable to switch between HHHn and
HHH∞, which causes HHHn to process the non-input HHH∞ instead of the
input HHHn.

HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts
the behavior of a hypothetical HHH∞(DDD) as described below

But that isn't what happens, since HHH∞ isn't actually in memory, DDD
doesn't call it but the actual HHH, and thus HHH∞ will see that DDD Halts.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then

And since we just showed that HHH∞ emulation of the ACTUAL DDD that is
there and calls the HHH that you claim will be correct, sees the input
reach its final state, that doesn't happen.

Sorry, you just proved yourself wrong.

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

On 2024-08-20 13:13:57 +0000, olcott said:

On 8/20/2024 3:45 AM, joes wrote:

Am Mon, 19 Aug 2024 23:33:52 -0500 schrieb olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.
I thought you said you removed it.

_DDD()
[00002172] 55         push ebp      ; housekeeping [00002173]
8bec       mov ebp,esp   ; housekeeping [00002175] 6872210000 push
00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call
HHH(DDD)
[0000217f] 83c404     add esp,+04 [00002182] 5d         pop ebp
[00002183] c3         ret Size in bytes:(0018) [00002183] >>>>>> But it can't emulate DDD correctly past 4 instructions, since the 5th >>>>>> instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention HHHn >>>>>> below, so that changes, but DDD, so the input doesn't and thus is
CAN'T be part of the input.

Changing the code, but not the address, constitutes a change.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c Thus making >>>>>>> all of the code of HHH directly available to DDD and itself. HHH >>>>>>> emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that >>>>>> input needs to be DDDn
And, in fact,
Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually >>>>>> be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:
X = DDD∞ emulated by HHH∞ according to the semantics of the x86 >>>>>> language Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running
The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting. >>>> Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so >>>>>> you don't have Z.

HHHn correctly predicts the behavior of DDD the same way that HHHn >>>>>>> correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.
It can't for DDDn, since when we move to HHHn+1 we no longer have
DDDn but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can do this same sort of
thing. Computations are not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).
It does this same same way that HHHn(EEE)
predicts the behavior of HHH∞(EEE).

The bytes of HHH are part of DDD.

*The following criteria only means*
HHHn(DDD) correctly predicts the behavior of HHH∞(EEE) and HHH∞(DDD)

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

No, that is not what they mean. The criteria don't say anything about predicting the behaviour of HHH∞.

--
Mikko

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

Op 20.aug.2024 om 15:18 schreef olcott:

On 8/20/2024 5:29 AM, Fred. Zwarts wrote:

Op 20.aug.2024 om 06:33 schreef olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the
5th instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention
HHHn below, so that changes, but DDD, so the input doesn't and
thus is CAN'T be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86 >>>>>>> language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input,
that input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must
actually be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86 >>>>>> language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting. >>>>

Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y
so you don't have Z.

void EEE()
{
   HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.


It can't for DDDn, since when we move to HHHn+1 we no longer have
DDDn but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

Not all HHH can be at the same memory at the same time.

Counter factual. HHH∞ is hypothetical thus takes no memory.
HHH and DDD remains at the same physical machine address locations.

When HHHn is in the memory, then DDD calls HHHn, not HHH∞.
When HHHn is doing the simulation, HHHn is in that memory, therefore,
it should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless
you are cheating with the Root variable to switch between HHHn and
HHH∞, which causes HHHn to process the non-input HHH∞ instead of the
input HHHn.

HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts
the behavior of a hypothetical HHH∞(DDD) as described below

Which makes HHHn incorrect, because it should simulate its input, not a hypothetical non-input HHH∞.

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

On 2024-08-20 13:13:57 +0000, olcott said:

On 8/20/2024 3:45 AM, joes wrote:

Am Mon, 19 Aug 2024 23:33:52 -0500 schrieb olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.
I thought you said you removed it.

_DDD()
[00002172] 55         push ebp      ; housekeeping [00002173]
8bec       mov ebp,esp   ; housekeeping [00002175] 6872210000 push
00002172 ; push DDD [0000217a] e853f4ffff call 000015d2 ; call
HHH(DDD)
[0000217f] 83c404     add esp,+04 [00002182] 5d         pop ebp
[00002183] c3         ret Size in bytes:(0018) [00002183] >>>>>> But it can't emulate DDD correctly past 4 instructions, since the 5th >>>>>> instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention HHHn >>>>>> below, so that changes, but DDD, so the input doesn't and thus is
CAN'T be part of the input.

Changing the code, but not the address, constitutes a change.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c Thus making >>>>>>> all of the code of HHH directly available to DDD and itself. HHH >>>>>>> emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that >>>>>> input needs to be DDDn
And, in fact,
Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually >>>>>> be DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:
X = DDD∞ emulated by HHH∞ according to the semantics of the x86 >>>>>> language Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running
The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting. >>>> Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so >>>>>> you don't have Z.

HHHn correctly predicts the behavior of DDD the same way that HHHn >>>>>>> correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.
It can't for DDDn, since when we move to HHHn+1 we no longer have
DDDn but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can do this same sort of
thing. Computations are not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).
It does this same same way that HHHn(EEE)
predicts the behavior of HHH∞(EEE).

The bytes of HHH are part of DDD.

*The following criteria only means*
HHHn(DDD) correctly predicts the behavior of HHH∞(EEE) and HHH∞(DDD)

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then

No, it does not. You have not proven that H determines with a sound
method that its simulated D would never stop running unless aborted.
Nothe that above D is called H's input so it is important to apply
the correct meaning of the word "input".

--
Mikko

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

On 2024-08-20 04:33:52 +0000, olcott said:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the 5th
instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention HHHn
below, so that changes, but DDD, so the input doesn't and thus is CAN'T >>>> be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86 language >>>>> Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that
input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually be >>>> DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting.


Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so you >>>> don't have Z.

void EEE()
{
   HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.


It can't for DDDn, since when we move to HHHn+1 we no longer have DDDn >>>> but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

It does this same same way that HHHn(EEE)
predicts the behavior of HHH∞(EEE).

If HHH is not a part of the input then the input does not specify
a behaviour. Consequently no statement about the behaviour of the
input is a truth-bearer and it has no computable truth value.
Consequently no program can correctly compute the non-existent
truth value.

--
Mikko

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

On 2024-08-21 07:59:46 +0000, Fred. Zwarts said:

Op 20.aug.2024 om 15:18 schreef olcott:

On 8/20/2024 5:29 AM, Fred. Zwarts wrote:

Op 20.aug.2024 om 06:33 schreef olcott:

On 8/19/2024 11:02 PM, Richard Damon wrote:

On 8/19/24 11:50 PM, olcott wrote:

On 8/19/2024 10:32 PM, Richard Damon wrote:

On 8/19/24 10:47 PM, olcott wrote:

*Everything that is not expressly stated below is*
*specified as unspecified*

Looks like you still have this same condition.

I thought you said you removed it.

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

_DDD()
[00002172] 55         push ebp      ; housekeeping >>>>>>>> [00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

*It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)

But it can't emulate DDD correctly past 4 instructions, since the 5th >>>>>>> instruciton to emulate doesn't exist.

And, you can't include the memory that holds HHH, as you mention HHHn >>>>>>> below, so that changes, but DDD, so the input doesn't and thus is CAN'T >>>>>>> be part of the input.

X = DDD emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD
Z = DDD never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

And neither X or Y are possible.

x86utm takes the compiled Halt7.obj file of this c program
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Thus making all of the code of HHH directly available to
DDD and itself. HHH emulates itself emulating DDD.

Which is irrelevent and a LIE as if HHHn is part of the input, that >>>>>>> input needs to be DDDn

And, in fact,

Since, you have just explicitly introduced that all of HHHn is
available to HHHn when it emulates its input, that DDD must actually be >>>>>>> DDDn as it changes.

Thus, your ACTUAL claim needs to be more like:

X = DDD∞ emulated by HHH∞ according to the semantics of the x86 language
Y = HHH∞ never aborts its emulation of DDD∞
Z = DDD∞ never stops running

The above claim boils down to this: (X ∧ Y) ↔ Z

Yes that is correct.

So, you only prove that the DDD∞ that calls the HHH∞ is non-halting. >>>>>

Not any of the other DDDn

Your problem is that for any other DDDn / HHHn, you don't have Y so you >>>>>>> don't have Z.

void EEE()
{
   HERE: goto HERE;
}

HHHn correctly predicts the behavior of DDD the same
way that HHHn correctly predicts the behavior of EEE.

Nope, HHHn can form a valid inductive proof of the input.


It can't for DDDn, since when we move to HHHn+1 we no longer have DDDn >>>>>>> but DDDn+1, which is a different input.

You already agreed that (X ∧ Y) ↔ Z is correct.
Did you do an infinite trace in your mind?

But only for DDD∞, not any of the other ones.

If you can do it and I can do it then HHH can
do this same sort of thing. Computations are
not inherently dumber than human minds.

But HHHn isn't given DDD∞ as its input, so that doesn't matter.

All of the DDD have identical bytes it is only the HHH that varies.
HHHn(DDD) predicts the behavior of HHH∞(DDD).

Not all HHH can be at the same memory at the same time.

Counter factual. HHH∞ is hypothetical thus takes no memory.
HHH and DDD remains at the same physical machine address locations.

When HHHn is in the memory, then DDD calls HHHn, not HHH∞.
When HHHn is doing the simulation, HHHn is in that memory, therefore,
it should simulate HHHn, not HHH∞.
They cannot be at the same memory location at the same time, unless you
are cheating with the Root variable to switch between HHHn and HHH∞,
which causes HHHn to process the non-input HHH∞ instead of the input
HHHn.

HHH∞ is hypothetical thus takes no memory. HHHn(DDD) predicts
the behavior of a hypothetical HHH∞(DDD) as described below

Which makes HHHn incorrect, because it should simulate its input, not a hypothetical non-input HHH∞.

HHHn is free to simulate whichever way its author wants. It is correct
if it gives the correct answer for every input and incorrect otherwise.
Whether an answer is correct depends on the problem. If the problem
is not specified there is no correctness.

--
Mikko

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