On 8/19/24 8:14 AM, olcott wrote:

On 8/19/2024 5:17 AM, Fred. Zwarts wrote:

*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

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

void EEE()
{
  HERE: goto HERE;
}

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

Which proves that the simulation failed to reach the end. This makes
the simulation incomplete and therefore incorrect.
The simulating HHH is programmed to abort and halt. The simulated HHH
should behave exactly in the same way, so no cheating with the Root
variable is allowed.
The the simulating HHH aborts when the simulated HHH has only one
cycle to go, after which it would also abort and halt, but the
simulating HHH failed to reach this end.

I made my claim more precise.

Remember, you said: Everything that is not expressly stated below is*
specified as unspecified

Therefore HHHn can NOT correctly emulate DDD past the call HHH
instruction, because it doesn't HAVE the instruciton of the PROGRAM DDD
(which is what you emulate) since it doesn't have the instruction at
000015D2.

The contents of the memory at 000015D2 can not be accessable to HHHn, as
the input is described as DDD and not DDDn, so the input doesn't change
between instances, and thus CAN'T contain that memory that changes, and
thus is not valid to be part of the input.

Thus we also have that HHH∞ can not exist, so both your premises just
fail to be possible.

Sorry, you are just repeating your error because apparently you just
can't learn.

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

On 8/19/24 8:06 PM, olcott wrote:

On 8/19/2024 6:08 PM, Richard Damon wrote:

On 8/19/24 8:14 AM, olcott wrote:

On 8/19/2024 5:17 AM, Fred. Zwarts wrote:

*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

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

void EEE()
{
   HERE: goto HERE;
}

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

Which proves that the simulation failed to reach the end. This makes
the simulation incomplete and therefore incorrect.
The simulating HHH is programmed to abort and halt. The simulated
HHH should behave exactly in the same way, so no cheating with the
Root variable is allowed.
The the simulating HHH aborts when the simulated HHH has only one
cycle to go, after which it would also abort and halt, but the
simulating HHH failed to reach this end.

I made my claim more precise.

Remember, you said: Everything that is not expressly stated below is*
specified as unspecified

Therefore HHHn can NOT correctly emulate DDD past the call HHH
instruction, because it doesn't HAVE the instruciton of the PROGRAM
DDD (which is what you emulate) since it doesn't have the instruction
at 000015D2.

That they are in the same memory space is entailed
in the same way that the x86 code is not being run
on a rubber ducky is entailed.

But not EXPLICITLY stated, so that is a lie.

And what is WRONG with running the code on a rubber ducky, it might be
powered by Pentium.

And, if they ARE in the same memory space, then it is DDDn not DDD, as
there are each different by the memory that came with them.

Sorry, you are just caught out in your lie and stupdity.

You just don't knunderstand what you are talking about.

The contents of the memory at 000015D2 can not be accessable to HHHn,
as the input is described as DDD and not DDDn, so the input doesn't
change between instances, and thus CAN'T contain that memory that
changes, and thus is not valid to be part of the input.

Thus we also have that HHH∞ can not exist, so both your premises just
fail to be possible.

Sorry, you are just repeating your error because apparently you just
can't learn.

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

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

On 8/19/2024 7:46 PM, Richard Damon wrote:

On 8/19/24 8:06 PM, olcott wrote:

On 8/19/2024 6:08 PM, Richard Damon wrote:

On 8/19/24 8:14 AM, olcott wrote:

On 8/19/2024 5:17 AM, Fred. Zwarts wrote:

*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

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

void EEE()
{
   HERE: goto HERE;
}

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

Which proves that the simulation failed to reach the end. This
makes the simulation incomplete and therefore incorrect.
The simulating HHH is programmed to abort and halt. The simulated
HHH should behave exactly in the same way, so no cheating with the >>>>>> Root variable is allowed.
The the simulating HHH aborts when the simulated HHH has only one
cycle to go, after which it would also abort and halt, but the
simulating HHH failed to reach this end.

I made my claim more precise.

Remember, you said: Everything that is not expressly stated below is*
specified as unspecified

Therefore HHHn can NOT correctly emulate DDD past the call HHH
instruction, because it doesn't HAVE the instruciton of the PROGRAM
DDD (which is what you emulate) since it doesn't have the
instruction at 000015D2.

That they are in the same memory space is entailed
in the same way that the x86 code is not being run
on a rubber ducky is entailed.

But not EXPLICITLY stated, so that is a lie.

If you want to pay head games you can play them by yourself.

What "Head Games", Just quoting back the rules you stated as the ground
rules.

Not my fault you can't follow the rules you just made up, because you
don;t know what that means.

Of course, the real problem is you just don't understand what truth is,
so nothing you do makes sense.

And what is WRONG with running the code on a rubber ducky, it might be
powered by Pentium.

And, if they ARE in the same memory space, then it is DDDn not DDD, as
there are each different by the memory that came with them.

Sorry, you are just caught out in your lie and stupdity.

You just don't knunderstand what you are talking about.

The contents of the memory at 000015D2 can not be accessable to
HHHn, as the input is described as DDD and not DDDn, so the input
doesn't change between instances, and thus CAN'T contain that memory
that changes, and thus is not valid to be part of the input.

Thus we also have that HHH∞ can not exist, so both your premises
just fail to be possible.

Sorry, you are just repeating your error because apparently you just
can't learn.

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

On 8/19/24 9:38 PM, olcott wrote:

On 8/19/2024 8:24 PM, Richard Damon wrote:

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

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)

No, it is just a basic fact that NO emulator can properly emulate the
about input past the 4th instruction, as the data just isn't provided.

PERIOD.

Note, above you say HHH, below you say HHHn, thus they are not related problems,

Sorry, you are just proving yourself to be an ignorant liar.

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

void EEE()
{
  HERE: goto HERE;
}

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

Nope, and HHHn creates a DDDn that will call HHHn that will return to it
after emulating n steps, and then DDDn will halt

You are just proving you don't understand the difference between the
behavior of the actuall DDDn to the partial simulation of it by HHHn.

DDDn's behavior doesn't stop just because the emulator looking at it
stopped, but continues to the final state,

The Emulation of DDDn by HHHn DOES stop when HHHn stops emulating, and
thus doesn't tell you what happens afterwards unless you can form an
actual valid inductive argument to carry the emulation forward.

Sorry, you are just proving how stupid you are.

And, that you are nothing but a cheat that trys to twist the words.

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

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

On 8/19/2024 8:55 PM, Richard Damon wrote:

On 8/19/24 9:38 PM, olcott wrote:

On 8/19/2024 8:24 PM, Richard Damon wrote:

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

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)

No, it is just a basic fact that NO emulator can properly emulate the
about input past the 4th instruction, as the data just isn't provided.

The data is provided, but I did not say that the data
is not provided to an ordinary regular bath tub rubber
duck on a big blue sticker, and I won't.

WHERE is it provided?

You said only what was EXPLICITLY stated could be used.

Sorry, you are just proving that you are jus a stupid liar.

PERIOD.

Note, above you say HHH, below you say HHHn, thus they are not related
problems,

Sorry, you are just proving yourself to be an ignorant liar.

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

void EEE()
{
   HERE: goto HERE;
}

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

Nope, and HHHn creates a DDDn that will call HHHn that will return to
it after emulating n steps, and then DDDn will halt

You are just proving you don't understand the difference between the
behavior of the actuall DDDn to the partial simulation of it by HHHn.

DDDn's behavior doesn't stop just because the emulator looking at it
stopped, but continues to the final state,

The Emulation of DDDn by HHHn DOES stop when HHHn stops emulating, and
thus doesn't tell you what happens afterwards unless you can form an
actual valid inductive argument to carry the emulation forward.

Sorry, you are just proving how stupid you are.

And, that you are nothing but a cheat that trys to twist the words.

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

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

On 8/19/2024 9:15 PM, Richard Damon wrote:

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

On 8/19/2024 8:55 PM, Richard Damon wrote:

On 8/19/24 9:38 PM, olcott wrote:

On 8/19/2024 8:24 PM, Richard Damon wrote:

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

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)

No, it is just a basic fact that NO emulator can properly emulate
the about input past the 4th instruction, as the data just isn't
provided.

The data is provided, but I did not say that the data
is not provided to an ordinary regular bath tub rubber
duck on a big blue sticker, and I won't.

WHERE is it provided?

You said only what was EXPLICITLY stated could be used.

Not any more I took that part out.

No you didn't, it is still in the base message of the thread.

To change the foundation of an arguement you need to make a CLEAR and
obvious break from your previous on.

But then, you never understood that ever, because that requires an understanding of how truth works.

You don't understand that you can't just change things in the middle.

Also, it can't be DDD without the n and have different HHHn with the n
as parts of them.

So, your claim is still ligically invalid.

Sorry, you just don't understand what you are talking about and proving
you are nothing but a stupid liar≥

Sorry, you are just proving that you are jus a stupid liar.

PERIOD.

Note, above you say HHH, below you say HHHn, thus they are not
related problems,

Sorry, you are just proving yourself to be an ignorant liar.

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

void EEE()
{
   HERE: goto HERE;
}

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

Nope, and HHHn creates a DDDn that will call HHHn that will return
to it after emulating n steps, and then DDDn will halt

You are just proving you don't understand the difference between the
behavior of the actuall DDDn to the partial simulation of it by HHHn.

DDDn's behavior doesn't stop just because the emulator looking at it
stopped, but continues to the final state,

The Emulation of DDDn by HHHn DOES stop when HHHn stops emulating,
and thus doesn't tell you what happens afterwards unless you can
form an actual valid inductive argument to carry the emulation forward. >>>>
Sorry, you are just proving how stupid you are.

And, that you are nothing but a cheat that trys to twist the words.

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

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

On 8/19/2024 9:49 PM, Richard Damon wrote:

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

On 8/19/2024 9:15 PM, Richard Damon wrote:

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

On 8/19/2024 8:55 PM, Richard Damon wrote:

On 8/19/24 9:38 PM, olcott wrote:

On 8/19/2024 8:24 PM, Richard Damon wrote:

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

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)

No, it is just a basic fact that NO emulator can properly emulate
the about input past the 4th instruction, as the data just isn't
provided.

The data is provided, but I did not say that the data
is not provided to an ordinary regular bath tub rubber
duck on a big blue sticker, and I won't.

WHERE is it provided?

You said only what was EXPLICITLY stated could be used.

Not any more I took that part out.

No you didn't, it is still in the base message of the thread.

To change the foundation of an arguement you need to make a CLEAR and
obvious break from your previous on.

see V5

But that wasn't there when you made the comment, so you are shown to
just have been lying.

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

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

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

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

On 8/19/2024 9:49 PM, Richard Damon wrote:

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

On 8/19/2024 9:15 PM, Richard Damon wrote:

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

On 8/19/2024 8:55 PM, Richard Damon wrote:

On 8/19/24 9:38 PM, olcott wrote:

On 8/19/2024 8:24 PM, Richard Damon wrote:

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

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)

No, it is just a basic fact that NO emulator can properly
emulate the about input past the 4th instruction, as the data
just isn't provided.

The data is provided, but I did not say that the data
is not provided to an ordinary regular bath tub rubber
duck on a big blue sticker, and I won't.

WHERE is it provided?

You said only what was EXPLICITLY stated could be used.

Not any more I took that part out.

No you didn't, it is still in the base message of the thread.

To change the foundation of an arguement you need to make a CLEAR
and obvious break from your previous on.

see V5

But that wasn't there when you made the comment, so you are shown to
just have been lying.

I have three different USENET servers
they sometimes don't update right away.

No, the TIME stamps of the message were out of order.

You commented you took it out 30 minutes before you posted the v5, and
that didn't take OUT the part that was commented about, but added *IN* a
new part of the description that makes the claim just INVALID as DDD is
no longer a single thing, but includes the HHHm that it calls, and thus
NEEDS to be identified with the subscript.

You admitted that it no longer is JUST the code listed, but that it
explicitly contains as an explicitly implied part of the input, all of
the code in Halt7.

You are just digging your hole of lies deeper.

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

Op 19.aug.2024 om 14:14 schreef olcott:

On 8/19/2024 5:17 AM, Fred. Zwarts wrote:

*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

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

void EEE()
{
  HERE: goto HERE;
}

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

DDD is irrelevant, what matters is that DDD calls HHH and, therefore,
HHH needs to predict the behaviour of HHH.
You are stating that HHHn predicts correctly that HHH∞ does not halt.
That may be true.
But the more interesting question is the prediction of HHHn for *itself*
(HHHn) (or the DDD that calls HHHn).
HHHn halts, therefore the correct simulation of HHHn should predict that
it halts, unless you are still cheating with the Root variable to give
the simulated HHH a different behaviour than the simulating HHH, so that
HHH is simulating a non-input.

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