On 2024-08-27 02:33:14 +0000, olcott said:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

That means that HHH is stuck in a recursive simulation and does
not return. As x86 does not support an infinite memory space the
excution soon crashes in memory overflow.
Because HHH does not return the execution of DDD and consequently
the emulation of such execution is not continued after the call.
Therefore,

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

--
Mikko

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

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.
In the following program

int main() {
return HHH(main);
}

HHH cannot possibly simulate itself up to the end of itself. Still HHH
halts, which proves that there is an end. The only conclusion is, that
the simulation is incomplete and therefore incorrect.
Further it is incorrect to think that the fact that the simulation halts
too soon is an indication for non-halting behaviour. The analysis of
that 'special condition' is the real problem, not the partial incorrect simulation.

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

On 8/26/24 10:33 PM, olcott wrote:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

But only under a couple of conditions and implications.

1) It only hold *IF* and *ONLY IF* HHH is IN FACT an actual x86 emulator
that totally emulates the input given to it, and NEVER "stops" before
reaching an end.

If HHH decides to stop emulating and returning, then the DDD that it was emulating will reach its end, just after the point that HHH emulated it,
as DDD refers to the FULL PROGRAM DDD, and not just the fragment shown,
and its behavior is its full behavior. (If you want the behavior of the emulation, then that needs to be the subject of the sentence, not DDD).

2) Such an HHH is BY DEFINITION not a pure function, as to do what it is described to do, it needed to use information that was not part of its
input, namely the code for the HHH that DDD is calling, that you have
excluded from the input.

3) Since HHH in emulating this input needs to access information outside
that input to perform that action, the results also only apply to the
case where that extra data still matches, in other words, it only
applies to a correct emulation of a DDD that calls a non-aborting
correctly emulating HHH.

Thus, while we KNOW you are just lying about this actually intending on
being a stand-alone post, your conditions actually force it to be, as
your conditions EXCLUDE HHH from being changed to a Halt Decider and
still have the results applicable.

Sorry, you are painting yourself into a box.

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

On 8/27/24 8:39 AM, olcott wrote:

On 8/27/2024 2:15 AM, Mikko wrote:

On 2024-08-27 02:33:14 +0000, olcott said:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

That means that HHH is stuck in a recursive simulation and does
not return. As x86 does not support an infinite memory space the
excution soon crashes in memory overflow.
Because HHH does not return the execution of DDD and consequently
the emulation of such execution is not continued after the call.
Therefore,

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

_DDD()
[00002162] 55         push ebp
[00002163] 8bec       mov ebp,esp
[00002165] 6862210000 push 00002162
[0000216a] e853f4ffff call 000015c2
[0000216f] 83c404     add esp,+04
[00002172] 5d         pop ebp
[00002173] c3         ret
Size in bytes:(0018) [00002173]

*Limited to 20,000,000 total instructions*
*Limited to 20,000,000 total instructions*
*Limited to 20,000,000 total instructions*

 machine   stack     stack     machine     assembly
 address   address   data      code        language
 ========  ========  ========  ========== ============= [00002182][00103806][00000000] 55         push ebp      ; begin main
[00002183][00103806][00000000] 8bec       mov ebp,esp [00002185][00103802][00002162] 6862210000 push 00002162 ; push DDD [0000218a][001037fe][0000218f] e833f4ffff call 000015c2 ; call HHH
New slave_stack at:1038aa

The following is an INCORRECT emulaiton, showing you are just a LIAR.

Sorry, those are the facts.

The correct emulation of the call 000015c2 instruction must be followed
by the emulation of the instruction at 000015c2

You inability to provide ANY reputale source to back you claim just
proves that you are nothing but a stupid liar that doesn't know what he
is talking about.

Sorry, that is just the basic facts. Ignorance is NOT a excuse for
breaking the truth.

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138b2 [00002162][001138a2][001138a6] 55         push ebp [00002163][001138a2][001138a6] 8bec       mov ebp,esp [00002165][0011389e][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0011389a][0000216f] e853f4ffff call 000015c2 ; call HHH
New slave_stack at:14e2d2
[00002162][0015e2ca][0015e2ce] 55         push ebp [00002163][0015e2ca][0015e2ce] 8bec       mov ebp,esp [00002165][0015e2c6][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0015e2c2][0000216f] e853f4ffff call 000015c2 ; call HHH
New slave_stack at:15e372
[00002162][0016e36a][0016e36e] 55         push ebp [00002163][0016e36a][0016e36e] 8bec       mov ebp,esp [00002165][0016e366][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0016e362][0000216f] e853f4ffff call 000015c2 ; call HHH
New slave_stack at:16e412
[00002162][0017e40a][0017e40e] 55         push ebp [00002163][0017e40a][0017e40e] 8bec       mov ebp,esp [00002165][0017e406][00002162] 6862210000 push 00002162 ; push DDD [0000216a][0017e402][0000216f] e853f4ffff call 000015c2 ; call HHH
Number of Instructions Executed(20000000) == 298507 Pages

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

On 2024-08-27 12:39:06 +0000, olcott said:

On 8/27/2024 2:15 AM, Mikko wrote:

On 2024-08-27 02:33:14 +0000, olcott said:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

That means that HHH is stuck in a recursive simulation and does
not return. As x86 does not support an infinite memory space the
excution soon crashes in memory overflow.
Because HHH does not return the execution of DDD and consequently
the emulation of such execution is not continued after the call.
Therefore,

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

_DDD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 6862210000 push 00002162
[0000216a] e853f4ffff call 000015c2
[0000216f] 83c404 add esp,+04
[00002172] 5d pop ebp
[00002173] c3 ret
Size in bytes:(0018) [00002173]

*Limited to 20,000,000 total instructions*

You cannot limit unless you limit something.
Is that a limitation of the execution environment or HHH?
Does the count include untraced instructions?
You should also specify what happens when the limit is reached.

--
Mikko

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

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

--
Mikko

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

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language.

then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used to
describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD is not
needed is a simple truism, a tautology in your terms?

In the following program

        int main() {
          return HHH(main);
        }

HHH cannot possibly simulate itself up to the end of itself. Still HHH
halts, which proves that there is an end. The only conclusion is, that
the simulation is incomplete and therefore incorrect.
Further it is incorrect to think that the fact that the simulation
halts too soon is an indication for non-halting behaviour. The
analysis of that 'special condition' is the real problem, not the
partial incorrect simulation.

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

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language. >>>>>
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under
discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used to
describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD is not
needed is a simple truism, a tautology in your terms?

When 100% of the whole point is for HHH to correctly determine
whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Acting ridiculously stupid when on is not stupid at all
cannot be reasonably construed as anything besides a sadistic
head game.

When without DDD it is clear as crystal that HHH cannot possibly
simulate itself correctly:

int main() {
return HHH(main);
}

(where HHH stops running but claims that it does not stop running)

then it is ridiculously stupid to create an even more complicated
example in which HHH simulates itself (by introducing DDD that does
nothing else than calling HHH) and then claim that the problem is in DDD.

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

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD. >>>>>>> (b) HHH emulates DDD according to the semantics of the x86 language. >>>>>>>
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually
under discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used to
describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD is
not needed is a simple truism, a tautology in your terms?

When 100% of the whole point is for HHH to correctly determine
whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Acting ridiculously stupid when on is not stupid at all
cannot be reasonably construed as anything besides a sadistic
head game.

When without DDD it is clear as crystal that HHH cannot possibly
simulate itself correctly:

Damned Liar !!!

I will ignore this, because I know how difficult it is for you to accept
the truth.

I have told you too many times that correct simulation
is simply obeying the semantics of the 86 language for
whatever the x86 input finite string specifies.

You may repeat it many more times, but HHH violated the semantics of the
x86 language by skipping the last few instructions of a halting program.
This finite string, when given for direct execution, shows a halting
behaviour. This is the proof what the semantics of the x86 language
means for this finite string: a halting program.

If the x86 string tells the computer to catch on fire and
the computer catches on fire then this proves that the
emulation was correct.

And when the x86 string tells the computer that there is a halting
program and the simulator decides that there is a non-halting program,
this proves that the simulation is incorrect.
Clear as crystal: the semantics of the x86 string is proved by its
direct execution.
This is shown in the example below, where the direct execution of HHH
halts, but HHH decides that it does not halt.

       int main() {
           return HHH(main);
       }

  (where HHH stops running but claims that it does not stop running)

then it is ridiculously stupid to create an even more complicated
example in which HHH simulates itself (by introducing DDD that does
nothing else than calling HHH) and then claim that the problem is in DDD.

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

Op 28.aug.2024 om 17:13 schreef olcott:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>> DDD.
(b) HHH emulates DDD according to the semantics of the x86
language.

then we can see that DDD emulated by HHH cannot possibly get past >>>>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one
actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used to
describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD is
not needed is a simple truism, a tautology in your terms?

When 100% of the whole point is for HHH to correctly determine
whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Acting ridiculously stupid when on is not stupid at all
cannot be reasonably construed as anything besides a sadistic
head game.

When without DDD it is clear as crystal that HHH cannot possibly
simulate itself correctly:

Damned Liar !!!

I will ignore this, because I know how difficult it is for you to
accept the truth.

I have told you too many times that correct simulation
is simply obeying the semantics of the 86 language for
whatever the x86 input finite string specifies.

You may repeat it many more times, but HHH violated the semantics of
the x86 language by skipping the last few instructions of a halting
program. This finite string, when given for direct execution, shows a
halting behaviour. This is the proof what the semantics of the x86
language means for this finite string: a halting program.

If the x86 string tells the computer to catch on fire and
the computer catches on fire then this proves that the
emulation was correct.

And when the x86 string tells the computer that there is a halting
program and the simulator decides that there is a non-halting program,
this proves that the simulation is incorrect.
Clear as crystal: the semantics of the x86 string is proved by its
direct execution.
This is shown in the example below, where the direct execution of HHH
halts, but HHH decides that it does not halt.

By this same reasoning that fact that you are no longer hungry
AFTER you have eaten proves that you never needed to eat.

No, again, you do not understand what It said.

The behavior of DDD before HHH aborts its simulation
(before it has eaten) it not the same behavior after
DDD has been aborted (after it has eaten).

If hungry stands for fear for infinite recursion and eating stands for aborting, then both the simulating HHH and the simulated HHH are hungry
and both are coded to eat. But the simulating HHH kills the simulated
HHH before the simulated HHH could eat, which does not prove that it
would not have eaten if not killed.
There was no need to kill the simulated HHH, because it also knows how
to eat.

You seem to think that if the simulated HHH was not killed, it would
have eaten. But it knows how to eat, because that is how it is coded.

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

Op 28.aug.2024 om 18:21 schreef olcott:

On 8/28/2024 11:11 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 17:13 schreef olcott:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space >>>>>>>>>>> as DDD.
(b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>> language.

then we can see that DDD emulated by HHH cannot possibly get >>>>>>>>>>> past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one >>>>>>>>> actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used >>>>>>>> to describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD >>>>>>>> is not needed is a simple truism, a tautology in your terms?

When 100% of the whole point is for HHH to correctly determine
whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Acting ridiculously stupid when on is not stupid at all
cannot be reasonably construed as anything besides a sadistic
head game.

When without DDD it is clear as crystal that HHH cannot possibly
simulate itself correctly:

Damned Liar !!!

I will ignore this, because I know how difficult it is for you to
accept the truth.

I have told you too many times that correct simulation
is simply obeying the semantics of the 86 language for
whatever the x86 input finite string specifies.

You may repeat it many more times, but HHH violated the semantics of
the x86 language by skipping the last few instructions of a halting
program. This finite string, when given for direct execution, shows
a halting behaviour. This is the proof what the semantics of the x86
language means for this finite string: a halting program.

If the x86 string tells the computer to catch on fire and
the computer catches on fire then this proves that the
emulation was correct.

And when the x86 string tells the computer that there is a halting
program and the simulator decides that there is a non-halting
program, this proves that the simulation is incorrect.
Clear as crystal: the semantics of the x86 string is proved by its
direct execution.
This is shown in the example below, where the direct execution of
HHH halts, but HHH decides that it does not halt.

By this same reasoning that fact that you are no longer hungry
AFTER you have eaten proves that you never needed to eat.

No, again, you do not understand what It said.

The behavior of DDD before HHH aborts its simulation
(before it has eaten) it not the same behavior after
DDD has been aborted (after it has eaten).

If hungry stands for fear for infinite recursion

hungry stands for will not stop running unless aborted
just like
will remain hungry until eating is always true whenever hungry

Your HHH will see a 'special condition' after a few recursions, abort
and halt. It then returns to DDD, which will halt, too. No need to abort
them. So, neither HHH, nor DDD is hungry and they don't need to eat.
This is seen in the direct execution and in the correct simulation by HHH1. Only the incorrect simulation by HHH does not reach the final halting
state, because HHH cannot possibly simulate *itself* up to the end.

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

Op 28.aug.2024 om 18:44 schreef olcott:

On 8/28/2024 11:31 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 18:21 schreef olcott:

On 8/28/2024 11:11 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 17:13 schreef olcott:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not >>>>>>>>>>>>> reference anything else mentioned in any other posts. >>>>>>>>>>>>>
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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space >>>>>>>>>>>>> as DDD.
(b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>>>> language.

then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>> get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the >>>>>>>>>>> informal fallacy of refuting an argument different from the >>>>>>>>>>> one actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used >>>>>>>>>> to describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD >>>>>>>>>> is not needed is a simple truism, a tautology in your terms? >>>>>>>>>>

When 100% of the whole point is for HHH to correctly determine >>>>>>>>> whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Acting ridiculously stupid when on is not stupid at all
cannot be reasonably construed as anything besides a sadistic >>>>>>>>> head game.

When without DDD it is clear as crystal that HHH cannot possibly >>>>>>>> simulate itself correctly:

Damned Liar !!!

I will ignore this, because I know how difficult it is for you to
accept the truth.

I have told you too many times that correct simulation
is simply obeying the semantics of the 86 language for
whatever the x86 input finite string specifies.

You may repeat it many more times, but HHH violated the semantics
of the x86 language by skipping the last few instructions of a
halting program. This finite string, when given for direct
execution, shows a halting behaviour. This is the proof what the
semantics of the x86 language means for this finite string: a
halting program.

If the x86 string tells the computer to catch on fire and
the computer catches on fire then this proves that the
emulation was correct.

And when the x86 string tells the computer that there is a halting >>>>>> program and the simulator decides that there is a non-halting
program, this proves that the simulation is incorrect.
Clear as crystal: the semantics of the x86 string is proved by its >>>>>> direct execution.
This is shown in the example below, where the direct execution of
HHH halts, but HHH decides that it does not halt.

By this same reasoning that fact that you are no longer hungry
AFTER you have eaten proves that you never needed to eat.

No, again, you do not understand what It said.

The behavior of DDD before HHH aborts its simulation
(before it has eaten) it not the same behavior after
DDD has been aborted (after it has eaten).

If hungry stands for fear for infinite recursion

hungry stands for will not stop running unless aborted
just like
will remain hungry until eating is always true whenever hungry

Your HHH will see a 'special condition' after a few recursions, abort
and halt.

Why to do dishonestly try to get away with the strawman
deception and change the subject to HHH?

I don't. I point to exactly where the problem of the subject lies:
HHH cannot possibly simulate itself up to the end. DDD does not play a
role therein.

It is a design requirement that HHH halts if it doesn't
halt it is wrong.

But halting does not make it correct. There is no way to make it
correct. HHH cannot possibly simulate itself correctly up to the end, no
matter what trick you may think of.

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

When DDD emulated by HHH according to the semantics of the
x86 language cannot possibly reach its own machine address
of 00002183, then HHH is correct to reject DDD as non-halting
even of HHH does this entirely by wild guess.

The semantics of the x86 language are that DDD specifies a halting
program. This is proved when the same finite string is given for direct execution. It is also proved when this finite string is given to HHH1 to simulate. They both show that the semantics of the x86 language prove
that HHH is a halting program.
But, of course HHH cannot possible reach the end of its own simulation,
which proves that the simulation is incomplete. It aborts prematurely, violating the semantics of the x86 language by skipping the last few instructions of a halting program.
There is no way to solve this. Removing the abort code will make it even
worse. It is simply impossible to make a HHH that simulates itself
correctly.

int main() {
return HHH(main);
}

This is the simplest demonstration of the problem: HHH halts, but
decides that it does not halt. No DDD needed to demonstrate the problem.
This is the heart of the problem.

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

Am Wed, 28 Aug 2024 11:44:53 -0500 schrieb olcott:

On 8/28/2024 11:31 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 18:21 schreef olcott:

On 8/28/2024 11:11 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 17:13 schreef olcott:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space >>>>>>>>>>>>> as DDD.
(b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly get >>>>>>>>>>>>> past its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

Or are trying to distract the attention from the fact that DDD >>>>>>>>>> is not needed is a simple truism, a tautology in your terms? >>>>>>>>>>

When 100% of the whole point is for HHH to correctly determine >>>>>>>>> whether or not DDD would stop running if not aborted *IT IS
RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Like Fred has been saying for a month, what is HHH(HHH,HHH)?

When without DDD it is clear as crystal that HHH cannot possibly >>>>>>>> simulate itself correctly:

You may repeat it many more times, but HHH violated the semantics
of the x86 language by skipping the last few instructions of a
halting program. This finite string, when given for direct
execution, shows a halting behaviour. This is the proof what the
semantics of the x86 language means for this finite string: a
halting program.

It is very telling to see where these exchanges peter out (haha).

And when the x86 string tells the computer that there is a halting >>>>>> program and the simulator decides that there is a non-halting
program, this proves that the simulation is incorrect.
Clear as crystal: the semantics of the x86 string is proved by its >>>>>> direct execution.
This is shown in the example below, where the direct execution of
HHH halts, but HHH decides that it does not halt.

By this same reasoning that fact that you are no longer hungry AFTER >>>>> you have eaten proves that you never needed to eat.
The behavior of DDD before HHH aborts its simulation (before it has
eaten) it not the same behavior after DDD has been aborted (after it >>>>> has eaten).

I do not understand this. There is no „after having been aborted”.

If hungry stands for fear for infinite recursion

hungry stands for will not stop running unless aborted just like will
remain hungry until eating is always true whenever hungry

Your HHH will see a 'special condition' after a few recursions, abort
and halt.

Why to do dishonestly try to get away with the strawman deception and
change the subject to HHH?

It is a design requirement that HHH halts if it doesn't halt it is
wrong.

Then why does it report itself as nonterminating? (There is nothing
else in DDD that would cause that.)

When DDD emulated by HHH according to the semantics of the x86 language cannot possibly reach its own machine address of 00002183, then HHH is correct to reject DDD as non-halting even of HHH does this entirely by
wild guess.

--
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/28/24 11:13 AM, olcott wrote:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>> DDD.
(b) HHH emulates DDD according to the semantics of the x86
language.

then we can see that DDD emulated by HHH cannot possibly get past >>>>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one
actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used to
describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD is
not needed is a simple truism, a tautology in your terms?

When 100% of the whole point is for HHH to correctly determine
whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Acting ridiculously stupid when on is not stupid at all
cannot be reasonably construed as anything besides a sadistic
head game.

When without DDD it is clear as crystal that HHH cannot possibly
simulate itself correctly:

Damned Liar !!!

I will ignore this, because I know how difficult it is for you to
accept the truth.

I have told you too many times that correct simulation
is simply obeying the semantics of the 86 language for
whatever the x86 input finite string specifies.

You may repeat it many more times, but HHH violated the semantics of
the x86 language by skipping the last few instructions of a halting
program. This finite string, when given for direct execution, shows a
halting behaviour. This is the proof what the semantics of the x86
language means for this finite string: a halting program.

If the x86 string tells the computer to catch on fire and
the computer catches on fire then this proves that the
emulation was correct.

And when the x86 string tells the computer that there is a halting
program and the simulator decides that there is a non-halting program,
this proves that the simulation is incorrect.
Clear as crystal: the semantics of the x86 string is proved by its
direct execution.
This is shown in the example below, where the direct execution of HHH
halts, but HHH decides that it does not halt.

By this same reasoning that fact that you are no longer hungry
AFTER you have eaten proves that you never needed to eat.

The behavior of DDD before HHH aborts its simulation
(before it has eaten) it not the same behavior after
DDD has been aborted (after it has eaten).

Shows the absence of your ability to do LOGIC, as you fall onto inproper "isom]oprhisms".

Sorry, you are just proving your stupdity.

Since your HHH DOES abort, the DDD that calls that HHH does halt, so
that HHH was just INCORRECT to say it won't, and you are proved to be a
lying idiot to say otherwise.

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

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language. >>>>>
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under
discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

--
Mikko

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

On 2024-08-28 12:12:09 +0000, olcott said:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 language. >>>>>
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under
discussion...
https://en.wikipedia.org/wiki/Straw_man

Apparently you do not even understand the English that is used to
describe the straw man fallacy.
Or are trying to distract the attention from the fact that DDD is not
needed is a simple truism, a tautology in your terms?

When 100% of the whole point is for HHH to correctly determine
whether or not DDD would stop running if not aborted
*IT IS RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Why should we consider that point more significant than the
determination whether

        int main() {
          return HHH(main);
        }

would stop running if not aborted?

--
Mikko

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

Op 29.aug.2024 om 16:07 schreef olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD. >>>>>>> (b) HHH emulates DDD according to the semantics of the x86 language. >>>>>>>
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually
under discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

void EEE()
{
  HERE: goto HERE;
  return;
}

HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.

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

HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

Which is incorrect, because HHH is not allowed to change the input. The simulating HHH may abort, but it may not ignore the fact that the input
(the simulated HHH) is coded to abort when it sees the 'special
condition'. Otherwise it would decide about a non-input, which is not
allowed.

In the same way as HHH is not allowed to change the code of EEE when it
aborts EEE. The simulating HHH may abort and predict the behaviour of
the *unchanged* input would be.

In other words: HHH should process its input as if it was not its own
code. In fact, that is what HHH1 does and that is correct.

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

Op 29.aug.2024 om 19:32 schreef olcott:

On 8/29/2024 12:22 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 16:07 schreef olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>> DDD.
(b) HHH emulates DDD according to the semantics of the x86
language.

then we can see that DDD emulated by HHH cannot possibly get past >>>>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one
actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it >>>>>> more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead. >>>>

void EEE()
{
   HERE: goto HERE;
   return;
}

HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.

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

HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

Which is incorrect, because HHH is not allowed to change the input.
The simulating HHH may abort, but it may not ignore the fact that the
input (the simulated HHH) is coded to abort when it sees the 'special
condition'. Otherwise it would decide about a non-input, which is not
allowed.

*I told you this too many times so you must be a liar*
No DDD ever reaches its "return" instruction no matter
what-the-Hell that HHH does,

Exactly. Do you finally understand that HHH cannot possibly simulate
itself up to the end?
No matter what you do or say, HHH cannot possibly simulate itself
correctly up to the end. That is the reason, why HHH does not return to
DDD.
You are such a slow learner. In how many different words do I have to
repeat this before you finally understand what I say?

thus DDD CANNOT POSSIBLY HALT.


DDD does not halt because HHH does not allow it to halt, because the
simulating HHH aborted the simulated HHH one cycle before it would halt.
The simulation stopped prematurely.
A correct simulation (like the one by HHH1) shows that DDD *does* halt.
This proves that "DDD CANNOT POSSIBLY HALT" is simply not true. It can
be shown in many ways the DDD *does* halt.
The semantics of the X86 language do not change when the simulator is
called HHH. A halting program will always be a halting program according
to the semantics of the x86 language.
I told you so many times that HHH cannot possibly simulate itself
correctly up to the end. That is the problem, not DDD.

int main() {
return HHH(main);
}

HHH halts, but decides that it does not halt. It is HHH that is self-contradictory.

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

Op 29.aug.2024 om 19:36 schreef olcott:

On 8/29/2024 12:22 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 16:07 schreef olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>> DDD.
(b) HHH emulates DDD according to the semantics of the x86
language.

then we can see that DDD emulated by HHH cannot possibly get past >>>>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one
actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it >>>>>> more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead. >>>>

void EEE()
{
   HERE: goto HERE;
   return;
}

HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.

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

HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

Which is incorrect, because HHH is not allowed to change the input.
The simulating HHH may abort, but it may not ignore the fact that the
input (the simulated HHH) is coded to abort when it sees the 'special
condition'. Otherwise it would decide about a non-input, which is not
allowed.

*I told you this too many times so you must be a liar*

You told so many times incorrect claims.

No DDD ever reaches its "return" instruction no matter
what-the-Hell that HHH does,

Proving that the simulation is incorrect.
No matter what HHH does, it cannot possibly simulate itself up to the end.

int main() {
return HHH(main);
}

HHH halts, but it decides that it does not halt. That is the problem.
DDD only calls HHH, so, the problem is not DDD, but HHH.
You are such a slow learner. I told you this so many times, but it seems
your memory is very short.

thus DDD CANNOT POSSIBLY HALT.

DDD does halt, if allowed to do so. But the simulating HHH does not
allow it, because it aborts one cycle before the simulated HHH would
detect the 'special condition' and return to DDD. By stopping the
simulation before it could halt, you cannot prove that "DDD CANNOT
POSSIBLY HALT". In fact DDD halts. The finite string has only one
behaviour according to the semantics of the x86 language and both the
direct execution and the simulation by HHH1 show what the behaviour of
the program described by this finite string is: a halting program.
Therefore, anyone who claims that this finite string describes a
non-halting program according to the semantics of the x86 language, is
very stupid, or is lying.

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

Op 29.aug.2024 om 20:19 schreef olcott:

On 8/29/2024 12:50 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 19:32 schreef olcott:

On 8/29/2024 12:22 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 16:07 schreef olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space >>>>>>>>>>> as DDD.
(b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>> language.

then we can see that DDD emulated by HHH cannot possibly get >>>>>>>>>>> past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the
informal fallacy of refuting an argument different from the one >>>>>>>>> actually under discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You
use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified >>>>>> memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation >>>>>> later in the discussion. Now, after several later messages, it seems >>>>>> that you want to apply the fallacy of "moving the goal posts"
instead.

void EEE()
{
   HERE: goto HERE;
   return;
}

HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.

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

HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

Which is incorrect, because HHH is not allowed to change the input.
The simulating HHH may abort, but it may not ignore the fact that
the input (the simulated HHH) is coded to abort when it sees the
'special condition'. Otherwise it would decide about a non-input,
which is not allowed.

*I told you this too many times so you must be a liar*
No DDD ever reaches its "return" instruction no matter
what-the-Hell that HHH does,

Exactly. Do you finally understand that HHH cannot possibly simulate
itself up to the end?

*That seems to be a stupid (ignoramus) thing to say*

DDD forces emulated HHH to remain stuck in recursive
simulation forcing the emulated HHH to never reach
its own final halt state.

That is a stupid thing to say. DDD calls HHH, which after a few
recursions detects that there is a 'special condition', after which HHH
returns to DDD and DDD returns.
We see this in the direct simulation and in the correct simulation by HHH1.
It is clear that DDD does not force emulated HHH to remain stuck in
recursive> simulation and does not force the emulated HHH to never reach
its own final halt state.
It is HHH that aborts prematurely, so that it misses the point that the simulated HHH would detect the 'special condition' and halt, after which
DDD would halt.

Do you have at least a BS degree in CS? Richard does not.

Irrelevant question, because even a beginner sees that DDD is a halting
program and does not force HHH to remain stuck.
Moreover, your problem is not DDD, but HHH itself:

int main() {
return HHH(main);
}

It is HHH that halts and decides that it does not halt.

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

On 8/29/24 10:07 AM, olcott wrote:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD. >>>>>>> (b) HHH emulates DDD according to the semantics of the x86 language. >>>>>>>
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually
under discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

void EEE()
{
  HERE: goto HERE;
  return;
}

HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.

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

HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

But since HHH doesn't "mever abort", that isn't the DDD that it was
given. *SINCE* HHH aborts is simulation, a correct simulaiton of DDD
*WILL* halt, and thus HHH is incorrect to say *THIS* DDD will not halt
if not aborted.

That is your problem;

EEE never halts regardless of what HHH does, so it DIFFERENT than DDD.

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

On 2024-08-29 14:07:39 +0000, olcott said:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference anything else mentioned in any other posts.

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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as DDD. >>>>>>> (b) HHH emulates DDD according to the semantics of the x86 language. >>>>>>>
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

A straw man fallacy (sometimes written as strawman) is the informal
fallacy of refuting an argument different from the one actually under >>>>> discussion...
https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.

Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

void EEE()
{
HERE: goto HERE;
return;
}

HHH correctly predicts what the behavior of EEE would
be if this HHH never aborted its emulation of EEE.

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

HHH correctly predicts what the behavior of DDD would
be if this HHH never aborted its emulation of DDD.

That's OK. Just be clear that HHH is not a halt decider.

Note that DDD does not care what HHH returns if it returns,
only whether it returns at all.

--
Mikko

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

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not reference >>>>>>> anything else mentioned in any other posts.
_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] >>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as
DDD. (b) HHH emulates DDD according to the semantics of the x86
language.
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

HHH correctly predicts what the behavior of DDD would be if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a
not-aborting HHH.

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

Am Wed, 28 Aug 2024 14:47:45 -0500 schrieb olcott:

On 8/28/2024 2:21 PM, joes wrote:

Am Wed, 28 Aug 2024 11:44:53 -0500 schrieb olcott:

On 8/28/2024 11:31 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 18:21 schreef olcott:

On 8/28/2024 11:11 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 17:13 schreef olcott:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>> space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>>>> get past its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

When 100% of the whole point is for HHH to correctly determine >>>>>>>>>>> whether or not DDD would stop running if not aborted *IT IS >>>>>>>>>>> RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Like Fred has been saying for a month, what is HHH(HHH)?

^

When without DDD it is clear as crystal that HHH cannot
possibly simulate itself correctly:

You may repeat it many more times, but HHH violated the semantics >>>>>>>> of the x86 language by skipping the last few instructions of a >>>>>>>> halting program. This finite string, when given for direct
execution, shows a halting behaviour. This is the proof what the >>>>>>>> semantics of the x86 language means for this finite string: a
halting program.

It is very telling to see where these exchanges peter out (haha).

A dishonest dodge way form the subject of DDD emulated by HHH.

To the subject of what?

And when the x86 string tells the computer that there is a
halting program and the simulator decides that there is a
non-halting program, this proves that the simulation is
incorrect.
Clear as crystal: the semantics of the x86 string is proved by >>>>>>>> its direct execution.
This is shown in the example below, where the direct execution of >>>>>>>> HHH halts, but HHH decides that it does not halt.

By this same reasoning that fact that you are no longer hungry
AFTER you have eaten proves that you never needed to eat.
The behavior of DDD before HHH aborts its simulation (before it
has eaten) it not the same behavior after DDD has been aborted
(after it has eaten).

I do not understand this. There is no „after having been aborted”.

The directly executed DDD() has different behavior than DDD emulated by
HHH because DDD() benefits from HHH having already aborted its emulation
of DDD. HHH itself does not receive this benefit.

„Already”? DDD and it’s simulation live in entirely different spaces. There can be absolutely no influence.

If hungry stands for fear for infinite recursion

hungry stands for will not stop running unless aborted just like
will remain hungry until eating is always true whenever hungry

Your HHH will see a 'special condition' after a few recursions, abort
and halt.

It is a design requirement that HHH halts if it doesn't halt it is
wrong.

Then why does it report itself as nonterminating? (There is nothing
else in DDD that would cause that.)

How could it do that? IT MUST TERMINATE TO REPORT ANYTHING.

???

When DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own machine address of 00002183,
then HHH is correct to reject DDD as non-halting even of HHH does this
entirely by wild guess.

--
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/30/24 10:58 AM, olcott wrote:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not reference >>>>>>>>> anything else mentioned in any other posts.
_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] >>>>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it >>>>>> more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead. >>>>

HHH correctly predicts what the behavior of DDD would be if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

And thus not the FULL behavior of anything.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

So, where did they differ?

If you failed to answer that, because you know it is a LIE.

and all four of them are emulated by the world
class x86 emulator libx86emu

It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.

No, it is easy to see that you are a LIAR, as the "correct emualtion" by
the x86 instruction set of a "call HHH" would be followed by the
instructions of HHH.

Thus, you are just proving yourself to be a lying idoit.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.

Nope, it is easy to see that IT DOESN'T and you are just a LIAR, as a
call HHH instruction should be followed by the instruction of HHH.

Sorry, you are just proving that you are just a lying idiot that doesn't
know what he is talking about.

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

On 8/30/24 11:59 AM, olcott wrote:

On 8/30/2024 10:00 AM, joes wrote:

Am Wed, 28 Aug 2024 14:47:45 -0500 schrieb olcott:

On 8/28/2024 2:21 PM, joes wrote:

Am Wed, 28 Aug 2024 11:44:53 -0500 schrieb olcott:

On 8/28/2024 11:31 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 18:21 schreef olcott:

On 8/28/2024 11:11 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 17:13 schreef olcott:

On 8/28/2024 9:57 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:59 schreef olcott:

On 8/28/2024 7:46 AM, Fred. Zwarts wrote:

Op 28.aug.2024 om 14:12 schreef olcott:

On 8/28/2024 4:09 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 14:44 schreef olcott:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>>>> space as DDD.
(b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>>>>>> get past its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

When 100% of the whole point is for HHH to correctly determine >>>>>>>>>>>>> whether or not DDD would stop running if not aborted *IT IS >>>>>>>>>>>>> RIDICULOUSLY STUPID TO SAY THAT DDD IS NOT NEEDED*

Like Fred has been saying for a month, what is HHH(HHH)?

^

When without DDD it is clear as crystal that HHH cannot >>>>>>>>>>>> possibly simulate itself correctly:

You may repeat it many more times, but HHH violated the semantics >>>>>>>>>> of the x86 language by skipping the last few instructions of a >>>>>>>>>> halting program. This finite string, when given for direct >>>>>>>>>> execution, shows a halting behaviour. This is the proof what the >>>>>>>>>> semantics of the x86 language means for this finite string: a >>>>>>>>>> halting program.

It is very telling to see where these exchanges peter out (haha).

A dishonest dodge way form the subject of DDD emulated by HHH.

To the subject of what?

DDD emulated by HHH
DDD emulated by HHH
DDD emulated by HHH
DDD emulated by HHH
DDD emulated by HHH

Which is the program DDD, the one that HHH emulates (and thus is the one calling that HHH), which includes the code of the HHH that it calls.

NOT, the emulation of DDD by HHH.

The first *WILL* reach its final state if HHH returns, while the second
does not.

You are just proving yourself so stupid that you can't tell the
difference, because you have lied to yourself so much.

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

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not reference >>>>>>>>> anything else mentioned in any other posts.
_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] >>>>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly get past >>>>>>>>> its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it >>>>>> more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead. >>>>

HHH correctly predicts what the behavior of DDD would be if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning according
to the semantics of the x86 language, does not suddenly change when the aborting occurs. This finite string describes a program that calls an
HHH that aborts and halt, after which it returns to DDD and DDD halts.
Your simulator misses the last part of it, because it aborts the
simulation before it could see it.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

No, the semantics of the x86 language gives a unique meaning to the
finite string, which should be honoured by the simulation in the same
why as by the direct execution.

and all four of them are emulated by the world
class x86 emulator libx86emu

And when the unmodified world class simulator simulated the DDD that
calls the HHH that aborts, we see that it shows the correct halting
behaviour.

It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.

It is also easy to see that this simulation is correct only for the
first part. It is incorrect, because it decides that there is an
infinite recursion, where there is only a finite recursion. One
recursion later the simulated HHH would have printed the same message
about an infinite recursion and halt, after which it would return to the simulated DDD and the simulated DDD would halt.
Therefore, this simulation is incorrect because it skips the last few instruction of the halting program.

The unmodified world class simulator did not abort at this point and
continued the simulation and showed that DDD halts.
The simulator modified by olcott thinks that there is a non-halting
behaviour. Guess which one is right.

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

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference
anything else mentioned in any other posts.
_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] >>>>>>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly get >>>>>>>>>>> past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You
use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified >>>>>> memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation >>>>>> later in the discussion. Now, after several later messages, it seems >>>>>> that you want to apply the fallacy of "moving the goal posts"
instead.

HHH correctly predicts what the behavior of DDD would be if this HHH >>>>> never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells us
that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can
see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator, not
the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the world
class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  =========  ============= [00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[0000219f][00103820][00000000] 83c404     add esp,+04 [000021a2][0010381c][00000000] 50         push eax [000021a3][00103818][00000743] 6843070000 push 00000743 [000021a8][00103818][00000743] e8b5e5ffff call 00000762
Input_Halts = 0
[000021ad][00103820][00000000] 83c408     add esp,+08 [000021b0][00103820][00000000] 33c0       xor eax,eax [000021b2][00103824][00000018] 5d         pop ebp [000021b3][00103828][00000000] c3         ret
Number of Instructions Executed(10069) == 150 Pages

Still dreaming of the HHH that does an infinite recursion? That is not a substitute for the fact that the world class simulator showed that the
input has halting behaviour. Olcott's modification causes the simulator
to stop its simulation one cycle before it could see the halting behaviour.

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

On 8/31/24 8:03 AM, olcott wrote:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not
reference
anything else mentioned in any other posts.
_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] >>>>>>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly get >>>>>>>>>>> past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You
use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified >>>>>> memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation >>>>>> later in the discussion. Now, after several later messages, it seems >>>>>> that you want to apply the fallacy of "moving the goal posts"
instead.

HHH correctly predicts what the behavior of DDD would be if this HHH >>>>> never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No, we can't possibly have any honest dialogue when *YOU* insist on
lying about the verified facts.

It is a *FACT* that since your final HHH returns to its caller, that
DDD, and thus a correct emulation of DDD will reach its final state,

Your world class emulator has proven this, but you close your eyes to
that fact.

Your HHH LIES to you, because you taught it to do so, about what it sees.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

 machine   stack     stack     machine    assembly
 address   address   data      code       language
 ========  ========  ========  =========  ============= [00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[0000219f][00103820][00000000] 83c404     add esp,+04 [000021a2][0010381c][00000000] 50         push eax [000021a3][00103818][00000743] 6843070000 push 00000743 [000021a8][00103818][00000743] e8b5e5ffff call 00000762
Input_Halts = 0
[000021ad][00103820][00000000] 83c408     add esp,+08 [000021b0][00103820][00000000] 33c0       xor eax,eax [000021b2][00103824][00000018] 5d         pop ebp [000021b3][00103828][00000000] c3         ret
Number of Instructions Executed(10069) == 150 Pages

Note, this trace shows, by simply isomorphism that DDD must halt when
correctly emulated as the trace would be INDENTICAL (except for the 4
inital lines, and just the addresses of those lines) to the point of HHH returning if we change the initial addresses to be thato of DDD instead
of main.

The only way for there to be a difference is if HHH fails to be the
"pure function" that a correct emulator needs to be (or a decider).

The fact that you HHH turns out to NOT be such a thing, just proves your example is based on lying.

Thus PROVING beyond ALL DOUBT that DDD is actually halting, and that
HHH, becuase YOU TAUGHT IT THAT WAY, lies about what the input does.

Sorry, you are just proving your utter stupidity

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

On 8/31/24 11:19 AM, olcott wrote:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not >>>>>>>>>>>>> reference
anything else mentioned in any other posts.
_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] >>>>>>>>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the >>>>>>>>>>>>> x86
language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>> get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You >>>>>>>>>> use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an
unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation >>>>>>>> later in the discussion. Now, after several later messages, it >>>>>>>> seems
that you want to apply the fallacy of "moving the goal posts"
instead.

HHH correctly predicts what the behavior of DDD would be if this HHH >>>>>>> never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has
halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it
can see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator,
not the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the
world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows are
true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

And based on that condition, it is clear that we can not go forward, as
that ISH'T the fact that needs to be descussed.

The "second emulation of DDD by the emulated HHH" just is not the
correct emulation of the first DDD that the top level HHH is doing.

Sorry, you aren't allowed to change what you are doing in the middle of
an operation.

If you are emulating the first DDD, then you need to complete that actual.

THAT is what "Truth" demands.

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

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not >>>>>>>>>>>>> reference
anything else mentioned in any other posts.
_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] >>>>>>>>>>>>>
When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the >>>>>>>>>>>>> x86
language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>> get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You >>>>>>>>>> use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an
unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation >>>>>>>> later in the discussion. Now, after several later messages, it >>>>>>>> seems
that you want to apply the fallacy of "moving the goal posts"
instead.

HHH correctly predicts what the behavior of DDD would be if this HHH >>>>>>> never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has
halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it
can see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator,
not the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the
world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows are
true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to complete
the simulation up to the end, making the simulation as a whole incorrect.
We cannot proceed before you understand this.

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

On 8/31/24 12:18 PM, olcott wrote:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not >>>>>>>>>>>>>>> reference
anything else mentioned in any other posts.
_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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>> space as
DDD. (b) HHH emulates DDD according to the semantics of >>>>>>>>>>>>>>> the x86
language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>>>> get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. >>>>>>>>>>>> You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an
unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply
equivocation
later in the discussion. Now, after several later messages, it >>>>>>>>>> seems
that you want to apply the fallacy of "moving the goal posts" >>>>>>>>>> instead.

HHH correctly predicts what the behavior of DDD would be if
this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given
olcott's DDD based on the aborting HHH as input, it showed that this
has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator
tells us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it
can see the halting behaviour and decides that the input is
non-halting.
We know which one is correct: the unmodified world class simulator,
not the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the
world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows
are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly
  address   address   data      code       language >>>>>   ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call
HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a
whole incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

Which is a meaningless number, as that is the number of instructions
that HHH used, not what it emulated.

Also, that says this is NOT the input given to your ACTUAL DDD, as you
have cnanged that input by chaning the HHH that it calls.

Thus, proving you are nothing but a stupid liar that doesn't understand
what he is talking about.

It also proves the ERROR in your definition of "Correct Emulation of DDD
by HHH" by the semantics of the x86 processor, as the correct emulation
of a program shows the steps THAT PROGRAM actually execute, which means
that a "call HHH" instruction will be followed by the instruction of
HHH, which is NOT what HHH seems to beleive happens (so it is in error,
and thus not correct), and since that x86 program path NEVER actually
gets back to the begining of DDD again (as the code never actually calls
or jumps to that address, only references it to be simulated) the trace
showing that behavior MUST be WRONG.

Your repeated instance of this error just shows that you are a
funny-mental problem of not understanding what you are talking about,
because you CHOSE to work in IGNORANCE by not studying the actual
definitions of the field, but to try to derive them from a
knowledge-less study of it, and thus your whole theory is based on ERROR.

_DDD()
[00002162] 55         push ebp
[00002163] 8bec       mov ebp,esp
[00002165] 6862210000 push 00002162
[0000216a] e853f4ffff call 000015c2
[0000216f] 83c404     add esp,+04
[00002172] 5d         pop ebp
[00002173] c3         ret
Size in bytes:(0018) [00002173]

_main()
[00002182] 55         push ebp
[00002183] 8bec       mov ebp,esp
[00002185] 6862210000 push 00002162
[0000218a] e833f4ffff call 000015c2
[0000218f] 83c404     add esp,+04
[00002192] 50         push eax
[00002193] 6843070000 push 00000743
[00002198] e8c5e5ffff call 00000762
[0000219d] 83c408     add esp,+08
[000021a0] 33c0       xor eax,eax
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0034) [000021a3]

 machine   stack     stack     machine     assembly
 address   address   data      code        language
 ========  ========  ========  ========== ============= [00002182][00103806][00000000] 55         push ebp [00002183][00103806][00000000] 8bec       mov ebp,esp [00002185][00103802][00002162] 6862210000 push 00002162 [0000218a][001037fe][0000218f] e833f4ffff call 000015c2
New slave_stack at:1038aa

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138b2 [00002162][001138a2][001138a6] 55         push ebp [00002163][001138a2][001138a6] 8bec       mov ebp,esp [00002165][0011389e][00002162] 6862210000 push 00002162 [0000216a][0011389a][0000216f] e853f4ffff call 000015c2
New slave_stack at:14e2d2
[00002162][0015e2ca][0015e2ce] 55         push ebp [00002163][0015e2ca][0015e2ce] 8bec       mov ebp,esp [00002165][0015e2c6][00002162] 6862210000 push 00002162 [0000216a][0015e2c2][0000216f] e853f4ffff call 000015c2
New slave_stack at:15e372
[00002162][0016e36a][0016e36e] 55         push ebp [00002163][0016e36a][0016e36e] 8bec       mov ebp,esp [00002165][0016e366][00002162] 6862210000 push 00002162 [0000216a][0016e362][0000216f] e853f4ffff call 000015c2
New slave_stack at:16e412
[00002162][0017e40a][0017e40e] 55         push ebp [00002163][0017e40a][0017e40e] 8bec       mov ebp,esp [00002165][0017e406][00002162] 6862210000 push 00002162 [0000216a][0017e402][0000216f] e853f4ffff call 000015c2
New slave_stack at:17e4b2
[00002162][0018e4aa][0018e4ae] 55         push ebp
Number of Instructions Executed(100000000) == 1492537 Pages

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

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>> not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD until
you first understand that a world class x86 emulator that HHH calls
does enable HHH to correctly emulate itself emulating DDD and the
following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has halting
behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can
see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator, not
the *modified* one, which aborts one cycle too soon..

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the
second emulation of DDD by the emulated HHH is proven to be correct on
the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

--
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/31/24 3:26 PM, olcott wrote:

On 8/31/2024 1:49 PM, joes wrote:

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>> not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD until >>>>> you first understand that a world class x86 emulator that HHH calls
does enable HHH to correctly emulate itself emulating DDD and the
following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has halting >>>> behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can >>>> see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator, not >>>> the *modified* one, which aborts one cycle too soon..

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the
second emulation of DDD by the emulated HHH is proven to be correct on
the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

The x86utm operating system correctly emulates
100 million instructions of DDD emulated by HHH
with abort turned off.

Which is irrelevant, as that isn't what the input is.

THis just shows that you think lying is proper logic, and reveals how
good you are at logic.

If they were shown it would take 1.5 million pages.
Because of this only the emulated DDD instructions
are shown.

Which are irrelevent, as that isn't what the simulaiton is.

Again, it just shows you are lying.

The ACTUAL emulation (when looking at the DDD built on the HHH that you
claim to be correct) shows that there ARE conditional instructios in the
loop, and thus the rules that says it is non-terminating is not satisifed.

Sorry, you are just proving your stupidity.

_DDD()
[00002162] 55         push ebp
[00002163] 8bec       mov ebp,esp
[00002165] 6862210000 push 00002162
[0000216a] e853f4ffff call 000015c2
[0000216f] 83c404     add esp,+04
[00002172] 5d         pop ebp
[00002173] c3         ret
Size in bytes:(0018) [00002173]

_main()
[00002182] 55         push ebp
[00002183] 8bec       mov ebp,esp
[00002185] 6862210000 push 00002162
[0000218a] e833f4ffff call 000015c2
[0000218f] 83c404     add esp,+04
[00002192] 50         push eax
[00002193] 6843070000 push 00000743
[00002198] e8c5e5ffff call 00000762
[0000219d] 83c408     add esp,+08
[000021a0] 33c0       xor eax,eax
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0034) [000021a3]

 machine   stack     stack     machine     assembly
 address   address   data      code        language
 ========  ========  ========  ========== ============= [00002182][00103806][00000000] 55         push ebp [00002183][00103806][00000000] 8bec       mov ebp,esp [00002185][00103802][00002162] 6862210000 push 00002162 [0000218a][001037fe][0000218f] e833f4ffff call 000015c2
New slave_stack at:1038aa

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138b2 [00002162][001138a2][001138a6] 55         push ebp [00002163][001138a2][001138a6] 8bec       mov ebp,esp [00002165][0011389e][00002162] 6862210000 push 00002162 [0000216a][0011389a][0000216f] e853f4ffff call 000015c2
New slave_stack at:14e2d2
[00002162][0015e2ca][0015e2ce] 55         push ebp [00002163][0015e2ca][0015e2ce] 8bec       mov ebp,esp [00002165][0015e2c6][00002162] 6862210000 push 00002162 [0000216a][0015e2c2][0000216f] e853f4ffff call 000015c2
New slave_stack at:15e372
[00002162][0016e36a][0016e36e] 55         push ebp [00002163][0016e36a][0016e36e] 8bec       mov ebp,esp [00002165][0016e366][00002162] 6862210000 push 00002162 [0000216a][0016e362][0000216f] e853f4ffff call 000015c2
New slave_stack at:16e412
[00002162][0017e40a][0017e40e] 55         push ebp [00002163][0017e40a][0017e40e] 8bec       mov ebp,esp [00002165][0017e406][00002162] 6862210000 push 00002162 [0000216a][0017e402][0000216f] e853f4ffff call 000015c2
New slave_stack at:17e4b2
[00002162][0018e4aa][0018e4ae] 55         push ebp
Number of Instructions Executed(100000000) == 1492537 Pages

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

Am Sat, 31 Aug 2024 14:26:21 -0500 schrieb olcott:

On 8/31/2024 1:49 PM, joes wrote:

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of >>>>>>>> a not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that HHH
calls does enable HHH to correctly emulate itself emulating DDD and
the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has
halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it
can see the halting behaviour and decides that the input is
non-halting. We know which one is correct: the unmodified world class
simulator, not the *modified* one, which aborts one cycle too soon..

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the
second emulation of DDD by the emulated HHH is proven to be correct on
the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

The x86utm operating system correctly emulates 100 million instructions
of DDD emulated by HHH with abort turned off.

And after those 100 million it still hasn’t returned.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Op 31.aug.2024 om 18:18 schreef olcott:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not >>>>>>>>>>>>>>> reference
anything else mentioned in any other posts.
_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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>> space as
DDD. (b) HHH emulates DDD according to the semantics of >>>>>>>>>>>>>>> the x86
language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>>>> get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. >>>>>>>>>>>> You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an
unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply
equivocation
later in the discussion. Now, after several later messages, it >>>>>>>>>> seems
that you want to apply the fallacy of "moving the goal posts" >>>>>>>>>> instead.

HHH correctly predicts what the behavior of DDD would be if
this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given
olcott's DDD based on the aborting HHH as input, it showed that this
has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator
tells us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it
can see the halting behaviour and decides that the input is non-
halting.
We know which one is correct: the unmodified world class simulator,
not the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the
world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows
are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly
  address   address   data      code       language >>>>>   ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call
HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a
whole incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

It is not the first time that you try to get away by changing the
subject from the HHH that sees the 'special condition' and halt, to your
dream of a HHH that does not abort. You do that in a sneaky way, by not
only changing the simulator, but also its input.

But is clear that when the HHH that aborts is simulated by the
unmodified, non-aborting, world class smulator, it shows a halting
behaviour. This proves that if HHH is simulated up to its end, it has
halting behaviour.
But HHH cannot possibly simulate itselfcorrectly up to the end.

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

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not reference
anything else mentioned in any other posts.
_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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as >>>>>>>>>>>>>>> DDD. (b) HHH emulates DDD according to the semantics of the x86 >>>>>>>>>>>>>>> language.
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified >>>>>>>>>> memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply equivocation >>>>>>>>>> later in the discussion. Now, after several later messages, it seems >>>>>>>>>> that you want to apply the fallacy of "moving the goal posts" instead.

HHH correctly predicts what the behavior of DDD would be if this HHH >>>>>>>>> never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning according >>>>>> to the semantics of the x86 language, does not suddenly change when the >>>>>> aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has halting >>>> behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can >>>> see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator, not >>>> the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the
world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly
  address   address   data      code       language >>>>>   ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD) >>>>>
New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a whole
incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

_DDD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 6862210000 push 00002162
[0000216a] e853f4ffff call 000015c2
[0000216f] 83c404 add esp,+04
[00002172] 5d pop ebp
[00002173] c3 ret
Size in bytes:(0018) [00002173]

_main()
[00002182] 55 push ebp
[00002183] 8bec mov ebp,esp
[00002185] 6862210000 push 00002162
[0000218a] e833f4ffff call 000015c2
[0000218f] 83c404 add esp,+04
[00002192] 50 push eax
[00002193] 6843070000 push 00000743
[00002198] e8c5e5ffff call 00000762
[0000219d] 83c408 add esp,+08
[000021a0] 33c0 xor eax,eax
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0034) [000021a3]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [00002182][00103806][00000000] 55 push ebp [00002183][00103806][00000000] 8bec mov ebp,esp [00002185][00103802][00002162] 6862210000 push 00002162 [0000218a][001037fe][0000218f] e833f4ffff call 000015c2
New slave_stack at:1038aa

Begin Local Halt Decider Simulation Execution Trace Stored at:1138b2 [00002162][001138a2][001138a6] 55 push ebp [00002163][001138a2][001138a6] 8bec mov ebp,esp [00002165][0011389e][00002162] 6862210000 push 00002162 [0000216a][0011389a][0000216f] e853f4ffff call 000015c2
New slave_stack at:14e2d2
[00002162][0015e2ca][0015e2ce] 55 push ebp [00002163][0015e2ca][0015e2ce] 8bec mov ebp,esp [00002165][0015e2c6][00002162] 6862210000 push 00002162 [0000216a][0015e2c2][0000216f] e853f4ffff call 000015c2
New slave_stack at:15e372
[00002162][0016e36a][0016e36e] 55 push ebp [00002163][0016e36a][0016e36e] 8bec mov ebp,esp [00002165][0016e366][00002162] 6862210000 push 00002162 [0000216a][0016e362][0000216f] e853f4ffff call 000015c2
New slave_stack at:16e412
[00002162][0017e40a][0017e40e] 55 push ebp [00002163][0017e40a][0017e40e] 8bec mov ebp,esp [00002165][0017e406][00002162] 6862210000 push 00002162 [0000216a][0017e402][0000216f] e853f4ffff call 000015c2
New slave_stack at:17e4b2
[00002162][0018e4aa][0018e4ae] 55 push ebp
Number of Instructions Executed(100000000) == 1492537 Pages

--
Mikko

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

Op 31.aug.2024 om 18:46 schreef olcott:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not >>>>>>>>>>>>>>> reference
anything else mentioned in any other posts.
_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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>> space as
DDD. (b) HHH emulates DDD according to the semantics of >>>>>>>>>>>>>>> the x86
language.
then we can see that DDD emulated by HHH cannot possibly >>>>>>>>>>>>>>> get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. >>>>>>>>>>>> You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an
unpsecified
memeber of a set of programs, a hypothetical program) is.
Your first posting looked like you were going to apply
equivocation
later in the discussion. Now, after several later messages, it >>>>>>>>>> seems
that you want to apply the fallacy of "moving the goal posts" >>>>>>>>>> instead.

HHH correctly predicts what the behavior of DDD would be if
this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD
until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given
olcott's DDD based on the aborting HHH as input, it showed that this
has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator
tells us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it
can see the halting behaviour and decides that the input is non-
halting.
We know which one is correct: the unmodified world class simulator,
not the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the
world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows
are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly
  address   address   data      code       language >>>>>   ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call
HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc >>>>> [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call
HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a
whole incorrect.
We cannot proceed before you understand this.

YET AGAIN YOU PROVE THAT YOU ARE BRAIN DEAD.

I CALL YOU BRAIN DEAD BECAUSE YOU REPEATEDLY
IGNORE MY CORRECTIONS TO YOUR COUNTER-FACTUAL
FALSE ASSUMPTIONS.

We know olcott is very poor in understanding English and in expressing
his thought is English. If that is not true, we are almost forced to
think he is dishonest, when he uses such big word without any evidence.

The correctness of an emulation is not required to meet
your misconceptions, it is only required to obey the
semantics that the x86 code of DDD specifies.

But it does not obey it, by skipping the last few instructions of a
halting program.

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

DDD emulated by HHH cannot possibly reach past its own 0000217a
because it keeps calling HHH(DDD) to emulate itself again.

Indeed, and after a few recursions it aborts and halts. That is not a misconception, that is how you told that HHH works.

When DDD emulated by HHH is aborted by DDD it immediately
stops at machine address 0000217a.

Indeed. It fails to reach the end of the simulation, violating the
semantics of the x86 language by skipping the last few instructions in
which also the simulated HHH would see the 'special condition', abort
and return to DDD.
That DDD does not halt, is because its simulator prevented it to halt
with a premature abort.

Olcott's misconception is that he thinks that HHH is able to simulate
itself correctly. He does not see that HHH cannot possibly simulate
itself correctly up to the end.
His other misconception is that he thinks that only the simulating HHH
is changed if the abort code is added to HHH. He does not understand
that also the behaviour of the simulated HHH is changed, because both
are coded to have the same behaviour.
Another misconception is that he does not see that it the problem of
HHH, not DDD.

int main() {
return HHH(main);
}

has the same problem. HHH halts but decides that it does not halt.

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

Op 31.aug.2024 om 21:26 schreef olcott:

On 8/31/2024 1:49 PM, joes wrote:

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>> not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly
change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD until >>>>> you first understand that a world class x86 emulator that HHH calls
does enable HHH to correctly emulate itself emulating DDD and the
following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's
DDD based on the aborting HHH as input, it showed that this has halting >>>> behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells
us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can >>>> see the halting behaviour and decides that the input is non-halting.
We know which one is correct: the unmodified world class simulator, not >>>> the *modified* one, which aborts one cycle too soon..

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the
second emulation of DDD by the emulated HHH is proven to be correct on
the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

The x86utm operating system correctly emulates
100 million instructions of DDD emulated by HHH
with abort turned off.

If they were shown it would take 1.5 million pages.
Because of this only the emulated DDD instructions
are shown.

Again olcott tries to get a ways with a change of subject. We were
talking about a HHH that aborts and halts, but now he mentions his dream
of a non-halting simulation again. He does it in a sneaky way, y not
only changing the simulator, but also the input for the simulator.
We know, however, that when the unmodified world class simulator is
given the DDD that is based on the aborting HHH, it shows a halting
behaviour.
So, these 100000 instructions are irrelevant.

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

On 9/2/24 9:15 AM, olcott wrote:

On 9/1/2024 6:19 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 21:26 schreef olcott:

On 8/31/2024 1:49 PM, joes wrote:

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input >>>>>>>>>> of a
not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly >>>>>>>> change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD >>>>>>> until
you first understand that a world class x86 emulator that HHH calls >>>>>>> does enable HHH to correctly emulate itself emulating DDD and the >>>>>>> following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's >>>>>> DDD based on the aborting HHH as input, it showed that this has
halting
behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells >>>>>> us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before
it can
see the halting behaviour and decides that the input is non-halting. >>>>>> We know which one is correct: the unmodified world class
simulator, not
the *modified* one, which aborts one cycle too soon..

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the >>>>> second emulation of DDD by the emulated HHH is proven to be correct on >>>>> the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

The x86utm operating system correctly emulates
100 million instructions of DDD emulated by HHH
with abort turned off.

If they were shown it would take 1.5 million pages.
Because of this only the emulated DDD instructions
are shown.

Again olcott tries to get a ways with a change of subject. We were
talking about a HHH that aborts and halts,

An HHH that does not abort thus never halts thus
conclusively proving that HHH must abort or never halts.

But that isn't the question.

The question is does the DDD that HHH is emulating halt when correctly
emulated without aborting the emulation.

Your problem is you assume you can change the code of the HHH that is
being called, but that just shows you don't know the meaning of a PROGRAM.

Since this HHH doesn't *DO* the appropriate emulation, you must give the
input to another emulator that does it, not change the input by changing
this HHH.

YOu are just proving that your fundamental nature is to attempt to LIE.

but now he mentions his dream of a non-halting simulation again. He
does it in a sneaky way, y not only changing the simulator, but also
the input for the simulator.
We know, however, that when the unmodified world class simulator is
given the DDD that is based on the aborting HHH, it shows a halting
behaviour.
So, these 100000 instructions are irrelevant.

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

On 9/2/24 9:16 AM, olcott wrote:

On 9/1/2024 1:52 AM, joes wrote:

Am Sat, 31 Aug 2024 14:26:21 -0500 schrieb olcott:

On 8/31/2024 1:49 PM, joes wrote:

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of >>>>>>>>>> a not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly >>>>>>>> change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD >>>>>>> until you first understand that a world class x86 emulator that HHH >>>>>>> calls does enable HHH to correctly emulate itself emulating DDD and >>>>>>> the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's >>>>>> DDD based on the aborting HHH as input, it showed that this has
halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells >>>>>> us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it >>>>>> can see the halting behaviour and decides that the input is
non-halting. We know which one is correct: the unmodified world class >>>>>> simulator, not the *modified* one, which aborts one cycle too soon.. >>>>
Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the >>>>> second emulation of DDD by the emulated HHH is proven to be correct on >>>>> the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

The x86utm operating system correctly emulates 100 million instructions
of DDD emulated by HHH with abort turned off.

And after those 100 million it still hasn’t returned.

An HHH that does not abort thus never halts thus
conclusively proving that HHH must abort or never halts.

But that isn't the question.

THe question is does the DDD that HHH is emulating halt when correctly
emulated without aborting the emulation.

Your problem is you assume you can change the code of the HHH that is
being called, but that just shows you don't know the meaning of a PROGRAM.

Since this HHH doesn't *DO* the appropriate emulation, you must give the
input to another emulator that does it, not change the input by changing
this HHH.

YOu are just proving that your fundamental nature is to attempt to LIE.

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

Op 02.sep.2024 om 15:15 schreef olcott:

On 9/1/2024 6:19 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 21:26 schreef olcott:

On 8/31/2024 1:49 PM, joes wrote:

Am Sat, 31 Aug 2024 10:19:28 -0500 schrieb olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

HHH correctly predicts what the behavior of DDD would be if this >>>>>>>>>>> HHH never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input >>>>>>>>>> of a
not-aborting HHH.

*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning
according to the semantics of the x86 language, does not suddenly >>>>>>>> change when the aborting occurs.

^ important

You cannot possibly say one damn thing about the behavior of DDD >>>>>>> until
you first understand that a world class x86 emulator that HHH calls >>>>>>> does enable HHH to correctly emulate itself emulating DDD and the >>>>>>> following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's >>>>>> DDD based on the aborting HHH as input, it showed that this has
halting
behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells >>>>>> us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before
it can
see the halting behaviour and decides that the input is non-halting. >>>>>> We know which one is correct: the unmodified world class
simulator, not
the *modified* one, which aborts one cycle too soon..

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree that the >>>>> second emulation of DDD by the emulated HHH is proven to be correct on >>>>> the basis that it does emulate the first four instructions of DDD.

The fourth instruction (the call) encompasses quite a few further
instructions, which must all(!) be simulated until it returns. Only
then is it finished.

The x86utm operating system correctly emulates
100 million instructions of DDD emulated by HHH
with abort turned off.

If they were shown it would take 1.5 million pages.
Because of this only the emulated DDD instructions
are shown.

Again olcott tries to get a ways with a change of subject. We were
talking about a HHH that aborts and halts,

An HHH that does not abort thus never halts thus
conclusively proving that HHH must abort or never halts.

Olcott is dreaming again of the HHH that does not abort and, indeed,
does not halt.
Somehow, olcott thinks that adding the abort code does not change the
program.
It seems too difficult for olcott to understand that when the abort code
is added, the HHH will after a few recursions see the 'special
condition', abort and halt..
This is most clearly seen in:

int main() {
return HHH(main);
}

where HHH halts (!), but it decides that it does not (!) halt.

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

On 2024-09-02 13:31:23 +0000, olcott said:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not reference
anything else mentioned in any other posts.
_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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as
DDD. (b) HHH emulates DDD according to the semantics of the x86
language.
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all.

https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is. >>>>>>>>>>>> Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

HHH correctly predicts what the behavior of DDD would be if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning according
to the semantics of the x86 language, does not suddenly change when the
aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD >>>>>>> until you first understand that a world class x86 emulator that
HHH calls does enable HHH to correctly emulate itself emulating
DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's >>>>>> DDD based on the aborting HHH as input, it showed that this has halting >>>>>> behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells >>>>>> us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can >>>>>> see the halting behaviour and decides that the input is non- halting. >>>>>> We know which one is correct: the unmodified world class simulator, not >>>>>> the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the >>>>>> world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS
INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly >>>>>>>   address   address   data      code       language >>>>>>>   ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>
New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a whole >>>> incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows
that 100,000,000 million instructions were executed and the
full trace requires 1,492,537 Pages.

But does not abort the exectuion?

--
Mikko

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

Am Mon, 02 Sep 2024 08:31:23 -0500 schrieb olcott:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Before we can proceed to the next step you must first agree that the >>>>> second emulation of DDD by the emulated HHH is proven to be correct
on the basis that it does emulate the first four instructions of
DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a
whole incorrect.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows that
100,000,000 million instructions were executed and the full trace
requires 1,492,537 Pages.

And after that?

--
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 9/3/24 9:58 AM, olcott wrote:

On 9/3/2024 3:52 AM, Mikko wrote:

On 2024-09-02 13:31:23 +0000, olcott said:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does >>>>>>>>>>>>>>>>>>> not reference
anything else mentioned in any other posts. >>>>>>>>>>>>>>>>>>> _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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>>>>>> space as
DDD. (b) HHH emulates DDD according to the semantics >>>>>>>>>>>>>>>>>>> of the x86
language.
then we can see that DDD emulated by HHH cannot >>>>>>>>>>>>>>>>>>> possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all. >>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation >>>>>>>>>>>>>>>> fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an >>>>>>>>>>>>>> unpsecified
memeber of a set of programs, a hypothetical program) is. >>>>>>>>>>>>>> Your first posting looked like you were going to apply >>>>>>>>>>>>>> equivocation
later in the discussion. Now, after several later
messages, it seems
that you want to apply the fallacy of "moving the goal >>>>>>>>>>>>>> posts" instead.

HHH correctly predicts what the behavior of DDD would be if >>>>>>>>>>>>> this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the
non-input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning >>>>>>>>>> according to the semantics of the x86 language, does not
suddenly change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD >>>>>>>>> until you first understand that a world class x86 emulator that >>>>>>>>> HHH calls does enable HHH to correctly emulate itself emulating >>>>>>>>> DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given
olcott's DDD based on the aborting HHH as input, it showed that >>>>>>>> this has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator >>>>>>>> tells us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before >>>>>>>> it can see the halting behaviour and decides that the input is >>>>>>>> non- halting.
We know which one is correct: the unmodified world class
simulator, not the *modified* one, which aborts one cycle too
soon..

SO, it it not honest to suggest that we do not understand what >>>>>>>> the world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS >>>>>>>>> INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he
knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly >>>>>>>>>   address   address   data      code       language >>>>>>>>>   ========  ========  ========  =========  ============= >>>>>>>>> [00002192][00103820][00000000] 55         push ebp      ; Begin
main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; >>>>>>>>> housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored >>>>>>>>> at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ;
housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; >>>>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ;
housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; >>>>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a
whole incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows
that 100,000,000 million instructions were executed and the
full trace requires 1,492,537 Pages.

But does not abort the exectuion?

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Only if your only HHH never aborts its emulation.

If HHH aborts its emulation and returns to its caller, than the actual
correct x86 emulation of DDD by the full definition of the x86 langague,
as well as its direct exectution (which is what the behavior of DDD is
defined t be) will reach that state. The emulation of this DDD by the
HHH that it calls doesn't reach there, but that is something different.

This is your problem, you don't understand that "DDD" (even when
modified by being the one emulated by HHH) referes to the full behavior
of the program, not just the behavior of the emulation of DDD by HHH.

Of the four persistent reviewers this is over the head
of two of them one of them flat put lies about it and
you are the one left over.

Mike is the one reviewer that understands my code the
best and Ben is the one reviewer that understands my
design the best.

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

Op 03.sep.2024 om 15:58 schreef olcott:

On 9/3/2024 3:52 AM, Mikko wrote:

On 2024-09-02 13:31:23 +0000, olcott said:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does >>>>>>>>>>>>>>>>>>> not reference
anything else mentioned in any other posts. >>>>>>>>>>>>>>>>>>> _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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory >>>>>>>>>>>>>>>>>>> space as
DDD. (b) HHH emulates DDD according to the semantics >>>>>>>>>>>>>>>>>>> of the x86
language.
then we can see that DDD emulated by HHH cannot >>>>>>>>>>>>>>>>>>> possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all. >>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation >>>>>>>>>>>>>>>> fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an >>>>>>>>>>>>>> unpsecified
memeber of a set of programs, a hypothetical program) is. >>>>>>>>>>>>>> Your first posting looked like you were going to apply >>>>>>>>>>>>>> equivocation
later in the discussion. Now, after several later
messages, it seems
that you want to apply the fallacy of "moving the goal >>>>>>>>>>>>>> posts" instead.

HHH correctly predicts what the behavior of DDD would be if >>>>>>>>>>>>> this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non- >>>>>>>>>>>> input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning >>>>>>>>>> according to the semantics of the x86 language, does not
suddenly change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD >>>>>>>>> until you first understand that a world class x86 emulator that >>>>>>>>> HHH calls does enable HHH to correctly emulate itself emulating >>>>>>>>> DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given
olcott's DDD based on the aborting HHH as input, it showed that >>>>>>>> this has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator >>>>>>>> tells us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before >>>>>>>> it can see the halting behaviour and decides that the input is >>>>>>>> non- halting.
We know which one is correct: the unmodified world class
simulator, not the *modified* one, which aborts one cycle too
soon..

SO, it it not honest to suggest that we do not understand what >>>>>>>> the world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS >>>>>>>>> INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he
knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly >>>>>>>>>   address   address   data      code       language >>>>>>>>>   ========  ========  ========  =========  ============= >>>>>>>>> [00002192][00103820][00000000] 55         push ebp      ; Begin
main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; >>>>>>>>> housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored >>>>>>>>> at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ;
housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; >>>>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ;
housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; >>>>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call >>>>>>>>> HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a
whole incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows
that 100,000,000 million instructions were executed and the
full trace requires 1,492,537 Pages.

But does not abort the exectuion?

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

And only Olcott does not realise that this means that HHH fails to do a
correct simulation. A correct simulation must reach the end of a halting program.
Stopping the simulation halfway does not prove anything about the
halting behaviour of the program.

The real problem, however, is not the simulation, but the 'special
condition', that HHH uses to decide to abort the simulation. Olcott is
still dreaming of a HHH that will not see this 'special condition'. He
does not realise that by adding the code to recognize this 'special
condition' and stop the simulation, the other HHH, that does not see
this 'special condition', disappeared and remains only in his dreams.
HHH, when simulating *itself* should now decide about the DDD that uses
this new HHH that sees this 'special condition' and aborts.
*That code* is where the problem is, not the incomplete simulation itself.
In fact, if Olcott would have found a solution for the halting problem,
then it would not be in the simulation, but in the detection of the
'special condition'. The correctness of the simulation is only relevant
because it is used as input for the code to detect the 'special
condition'. The proof that the halting problem cannot be solved with a computation implies that Olcott's detection of the 'special condition'
cannot be correct.
It is probable that Olcott understands that it cannot be correct and
therefore he hides the code for the recognition of this 'special condition'.
He probably knows that if he would publish this part of the decider,
people would spot many errors in it immediately.
He has only shown some trivial examples as evidence that this detection
of the 'special condition' is correct, such as Infinite_Loop and Infinite_Recursion, but, of course, a few trivial examples do not prove
the correctness of this algorithm.
Therefore, he keeps pulling the attention away from the correctness of
the detection of the 'special condition', to the correctness of the
simulation.

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

On 9/4/24 9:17 AM, olcott wrote:

On 9/4/2024 4:56 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 15:58 schreef olcott:

On 9/3/2024 3:52 AM, Mikko wrote:

On 2024-09-02 13:31:23 +0000, olcott said:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said: >>>>>>>>>>>>>>>>>>> On 8/27/2024 3:38 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 27.aug.2024 om 04:33 schreef olcott: >>>>>>>>>>>>>>>>>>>>> This is intended to be a stand-alone post that does >>>>>>>>>>>>>>>>>>>>> not reference

anything else mentioned in any other posts. >>>>>>>>>>>>>>>>>>>>> _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]

When we assume that:
(a) HHH is an x86 emulator that is in the same >>>>>>>>>>>>>>>>>>>>> memory space as
DDD. (b) HHH emulates DDD according to the >>>>>>>>>>>>>>>>>>>>> semantics of the x86
language.
then we can see that DDD emulated by HHH cannot >>>>>>>>>>>>>>>>>>>>> possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all. >>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation >>>>>>>>>>>>>>>>>> fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an >>>>>>>>>>>>>>>> unpsecified
memeber of a set of programs, a hypothetical program) is. >>>>>>>>>>>>>>>> Your first posting looked like you were going to apply >>>>>>>>>>>>>>>> equivocation
later in the discussion. Now, after several later >>>>>>>>>>>>>>>> messages, it seems
that you want to apply the fallacy of "moving the goal >>>>>>>>>>>>>>>> posts" instead.

HHH correctly predicts what the behavior of DDD would be >>>>>>>>>>>>>>> if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non- >>>>>>>>>>>>>> input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its
meaning according to the semantics of the x86 language, does >>>>>>>>>>>> not suddenly change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD >>>>>>>>>>> until you first understand that a world class x86 emulator that >>>>>>>>>>> HHH calls does enable HHH to correctly emulate itself emulating >>>>>>>>>>> DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given >>>>>>>>>> olcott's DDD based on the aborting HHH as input, it showed >>>>>>>>>> that this has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class
simulator tells us that the program has a halting behaviour. >>>>>>>>>> Your *modification* of the simulator stops the simulation
before it can see the halting behaviour and decides that the >>>>>>>>>> input is non- halting.
We know which one is correct: the unmodified world class
simulator, not the *modified* one, which aborts one cycle too >>>>>>>>>> soon..

SO, it it not honest to suggest that we do not understand what >>>>>>>>>> the world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS >>>>>>>>>>> INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he >>>>>>>>>> knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly >>>>>>>>>>>   address   address   data      code       language
  ========  ========  ========  =========  ============= >>>>>>>>>>> [00002192][00103820][00000000] 55         push ebp      ;
Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; >>>>>>>>>>> housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored >>>>>>>>>>> at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ;
housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; >>>>>>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ;
housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; >>>>>>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>> Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven >>>>>>>>> to be correct on the basis that it does emulate the first four >>>>>>>>> instructions of DDD.

I agree that the simulation makes a good start, but it fails to >>>>>>>> complete the simulation up to the end, making the simulation as >>>>>>>> a whole incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows
that 100,000,000 million instructions were executed and the
full trace requires 1,492,537 Pages.

But does not abort the exectuion?

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

And only Olcott does not realise that this means that HHH fails to do
a correct simulation. A correct simulation must reach the end of a
halting program.

That is not what the x86 source code says.
The x86 source code says it is not allowed to do this.

Where?

The x86 source code tells DDD to keep repeating
it first four instructions endlessly until DDD
stops emulating any of the x86 instructions of DDD.

Nope.

A call instruction MUST be followed to the reference instruciton whih
*WILL* be part of the program.

If it isn't, the emulation is just impossible and the input invalid.

There is no freaking way that any DDD correctly
emulated by any HHH can possibly reach its own
machine address 0000217f.

Sure it can, your 200 page listing show how it happens

HHH could incorrectly emulate DDD and decide to
simply ignore machine address 0000217a.

Nope, it is just stuck between a rock and a hard place, which is why the problem in uncomputable.

The only way for HHH to emulate DDD to machine
address 0000217f is for HHH to disagree with the x86
language and ignore the instruction as machine address
0000217a that it is not allowed to ignore.

But the question isn't about HHH emulating DDD, it is about the behavior
of DDD that this HHH is attempting to emulate. That fact that HHH can't
do the job doesn't give it the right to somehow be "correct' with a
wrong answer.

Your claims just proves you don't understand what TRUTH is, because you
seem to think it is correct to LIE at time.

This seems to be because you learned it from your father, the Father of
Lies.

Sorry, you are just proving how stupid and ignorant you are.

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

Op 04.sep.2024 om 15:17 schreef olcott:

On 9/4/2024 4:56 AM, Fred. Zwarts wrote:

Op 03.sep.2024 om 15:58 schreef olcott:

On 9/3/2024 3:52 AM, Mikko wrote:

On 2024-09-02 13:31:23 +0000, olcott said:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said: >>>>>>>>>>>>>>>>>>> On 8/27/2024 3:38 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>>>>>>>> Op 27.aug.2024 om 04:33 schreef olcott: >>>>>>>>>>>>>>>>>>>>> This is intended to be a stand-alone post that does >>>>>>>>>>>>>>>>>>>>> not reference

anything else mentioned in any other posts. >>>>>>>>>>>>>>>>>>>>> _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]

When we assume that:
(a) HHH is an x86 emulator that is in the same >>>>>>>>>>>>>>>>>>>>> memory space as
DDD. (b) HHH emulates DDD according to the >>>>>>>>>>>>>>>>>>>>> semantics of the x86
language.
then we can see that DDD emulated by HHH cannot >>>>>>>>>>>>>>>>>>>>> possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all. >>>>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation >>>>>>>>>>>>>>>>>> fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an >>>>>>>>>>>>>>>> unpsecified
memeber of a set of programs, a hypothetical program) is. >>>>>>>>>>>>>>>> Your first posting looked like you were going to apply >>>>>>>>>>>>>>>> equivocation
later in the discussion. Now, after several later >>>>>>>>>>>>>>>> messages, it seems
that you want to apply the fallacy of "moving the goal >>>>>>>>>>>>>>>> posts" instead.

HHH correctly predicts what the behavior of DDD would be >>>>>>>>>>>>>>> if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non- >>>>>>>>>>>>>> input of a
not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its
meaning according to the semantics of the x86 language, does >>>>>>>>>>>> not suddenly change when the aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD >>>>>>>>>>> until you first understand that a world class x86 emulator that >>>>>>>>>>> HHH calls does enable HHH to correctly emulate itself emulating >>>>>>>>>>> DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given >>>>>>>>>> olcott's DDD based on the aborting HHH as input, it showed >>>>>>>>>> that this has halting behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class
simulator tells us that the program has a halting behaviour. >>>>>>>>>> Your *modification* of the simulator stops the simulation
before it can see the halting behaviour and decides that the >>>>>>>>>> input is non- halting.
We know which one is correct: the unmodified world class
simulator, not the *modified* one, which aborts one cycle too >>>>>>>>>> soon..

SO, it it not honest to suggest that we do not understand what >>>>>>>>>> the world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS >>>>>>>>>>> INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he >>>>>>>>>> knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly >>>>>>>>>>>   address   address   data      code       language
  ========  ========  ========  =========  ============= >>>>>>>>>>> [00002192][00103820][00000000] 55         push ebp      ;
Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; >>>>>>>>>>> housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored >>>>>>>>>>> at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ;
housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; >>>>>>>>>>> housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ;
housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; >>>>>>>>>>> housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; >>>>>>>>>>> push DDD
[0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; >>>>>>>>>>> call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation >>>>>>>>>>> Stopped

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven >>>>>>>>> to be correct on the basis that it does emulate the first four >>>>>>>>> instructions of DDD.

I agree that the simulation makes a good start, but it fails to >>>>>>>> complete the simulation up to the end, making the simulation as >>>>>>>> a whole incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows
that 100,000,000 million instructions were executed and the
full trace requires 1,492,537 Pages.

But does not abort the exectuion?

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

And only Olcott does not realise that this means that HHH fails to do
a correct simulation. A correct simulation must reach the end of a
halting program.

That is not what the x86 source code says.
The x86 source code says it is not allowed to do this.
The x86 source code tells DDD to keep repeating
it first four instructions endlessly until DDD
stops emulating any of the x86 instructions of DDD.

That is olcott's error.
The finite string given to HHH specifies (just like the source code)
that HHH will see a 'special condition' after two cycles. Than HHH will
return to DDD and DDD will halt. Two recursions is not endlessly.
Endlessly is just your dream, not what the code specifies.
When HHH stops simulating, it misses this part of the code, because it
stops too soon.

There is no freaking way that any DDD correctly
emulated by any HHH can possibly reach its own
machine address 0000217f.

Exactly! That is because HHH prevents DDD to go far enough. One cycle
later DDD would have halted.
HHH should simulate one cycle more that it is programmed to do, but, of
course, it is impossible to find a number that is greater than itself,
so there is no correct number of cycles to simulate.
HHH cannot possibly simulate itself correctly up to the end.

HHH could incorrectly emulate DDD and decide to
simply ignore machine address 0000217a.

That would be wrong as well.
There is no way to correct HHH.
HHH cannot possibly simulate itself correctly up to the end.

The only way for HHH to emulate DDD to machine
address 0000217f is for HHH to disagree with the x86
language and ignore the instruction as machine address
0000217a that it is not allowed to ignore.

That would be wrong as well, because it is just another violation of the semantics of the x86 language.
There is no way to correct HHH.
HHH cannot possibly simulate itself correctly up to the end.

Olcott keeps trying to fix the problems in HHH, but (against all
evidence) he refuses to accept that there is no way to fix HHH.
HHH cannot possibly simulate itself correctly up to the end.

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

On 2024-09-03 13:58:27 +0000, olcott said:

On 9/3/2024 3:52 AM, Mikko wrote:

On 2024-09-02 13:31:23 +0000, olcott said:

On 9/1/2024 6:05 AM, Mikko wrote:

On 2024-08-31 16:18:26 +0000, olcott said:

On 8/31/2024 10:49 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 17:19 schreef olcott:

On 8/31/2024 9:59 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:03 schreef olcott:

On 8/31/2024 4:07 AM, Fred. Zwarts wrote:

Op 30.aug.2024 om 16:58 schreef olcott:

On 8/30/2024 9:56 AM, joes wrote:

Am Thu, 29 Aug 2024 09:07:39 -0500 schrieb olcott:

On 8/29/2024 2:17 AM, Mikko wrote:

On 2024-08-28 12:08:06 +0000, olcott said:

On 8/28/2024 2:39 AM, Mikko wrote:

On 2024-08-27 12:44:31 +0000, olcott said:

On 8/27/2024 3:38 AM, Fred. Zwarts wrote:

Op 27.aug.2024 om 04:33 schreef olcott:

This is intended to be a stand-alone post that does not reference
anything else mentioned in any other posts. >>>>>>>>>>>>>>>>>>> _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]

When we assume that:
(a) HHH is an x86 emulator that is in the same memory space as
DDD. (b) HHH emulates DDD according to the semantics of the x86
language.
then we can see that DDD emulated by HHH cannot possibly get past
its own machine address 0000217a.

Yes, we see. In fact DDD is not needed at all. >>>>>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Straw_man

You should also point a link to the equivocation fallacy. You use it
more often than straw man.

Isomorphism is not equivocation

The use of HHH for many purposes (a specific program, an unpsecified
memeber of a set of programs, a hypothetical program) is. >>>>>>>>>>>>>> Your first posting looked like you were going to apply equivocation
later in the discussion. Now, after several later messages, it seems
that you want to apply the fallacy of "moving the goal posts" instead.

HHH correctly predicts what the behavior of DDD would be if this HHH
never aborted its emulation of DDD.

Problem is, DDD is then not calling itself, but the non-input of a >>>>>>>>>>>> not-aborting HHH.

*This is before any aborting occurs*
*This is before any aborting occurs*
*This is before any aborting occurs*

Here is your problem. The code of the program and its meaning according
to the semantics of the x86 language, does not suddenly change when the
aborting occurs.

You cannot possibly say one damn thing about the behavior of DDD >>>>>>>>> until you first understand that a world class x86 emulator that >>>>>>>>> HHH calls does enable HHH to correctly emulate itself emulating >>>>>>>>> DDD and the following execution trace proves this.

And when this unmodified world class x86 simulator was given olcott's >>>>>>>> DDD based on the aborting HHH as input, it showed that this has halting
behaviour.
THIS IS A VERIFIED FACT! Even olcott has verified it.
This correct simulation by the unmodified world class simulator tells >>>>>>>> us that the program has a halting behaviour.
Your *modification* of the simulator stops the simulation before it can
see the halting behaviour and decides that the input is non- halting. >>>>>>>> We know which one is correct: the unmodified world class simulator, not
the *modified* one, which aborts one cycle too soon..

SO, it it not honest to suggest that we do not understand what the >>>>>>>> world class simulator predicts.

SE CANNOT POSSIBLY HAVE ANY HONEST DIALOGUE WHEN MY REVIEWERS >>>>>>>>> INSIST ON LYING ABOUT VERIFIED FACTS.

No evidence given. No reference to a single lie.
Olcott seems just a bit short of memory.
It is unclear why olcott hides these verified fact, which he knows are true.

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

_main()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6872210000 push 00002172 ; push DDD
[0000219a] e833f4ffff call 000015d2 ; call HHH(DDD)
[0000219f] 83c404     add esp,+04
[000021a2] 50         push eax
[000021a3] 6843070000 push 00000743
[000021a8] e8b5e5ffff call 00000762
[000021ad] 83c408     add esp,+08
[000021b0] 33c0       xor eax,eax
[000021b2] 5d         pop ebp
[000021b3] c3         ret
Size in bytes:(0034) [000021b3]

  machine   stack     stack     machine    assembly >>>>>>>>>   address   address   data      code       language >>>>>>>>>   ========  ========  ========  =========  ============= >>>>>>>>> [00002192][00103820][00000000] 55         push ebp      ; Begin main()
[00002193][00103820][00000000] 8bec       mov ebp,esp   ; housekeeping
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD >>>>>>>>> [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>>>>>>

Still dreaming of the HHH that does an infinite recursion?

Before we can proceed to the next step you must first agree
that the second emulation of DDD by the emulated HHH is proven
to be correct on the basis that it does emulate the first four
instructions of DDD.

I agree that the simulation makes a good start, but it fails to
complete the simulation up to the end, making the simulation as a whole >>>>>> incorrect.
We cannot proceed before you understand this.

Here is no abort and x86utm emulating 100,000,000 instructions.

What happens after those 100 000 000 instructions are executed?

I just showed you what happens immediately below. It shows
that 100,000,000 million instructions were executed and the
full trace requires 1,492,537 Pages.

But does not abort the exectuion?

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

--
Mikko

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

On 9/6/24 7:20 AM, olcott wrote:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

No, the DDD that is emulated by HHH will return, as the behavior of a
program doesn't "stop" just because the emulator looking at its behavior
gave up.

The EMULATION of DDD by HHH is what doesn't return.

Youa are just proving you are just learning impaired as you don't
understand the difference between those two things,

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

Am Fri, 06 Sep 2024 06:20:52 -0500 schrieb olcott:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

_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]
Anyone that is not dumber than a box of rocks can tell that machine
address 0000217f is unreachable for every DDD emulated by HHH
according to the semantics of the x86 language where HHH emulates
itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or C can
see that the machine address 217f is unreachachable only if the program
at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH that always returns and a DDD emulated by HHH that calls an emulated HHH that never returns.

The simulated HHH is not the same if it doesn’t abort. The construction
works only if DDD is simulated by the decider it calls. This relationship
is broken if you only change one of the HHH’s. They shouldn’t be called
the same.

--
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-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

--
Mikko

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

Op 06.sep.2024 om 13:20 schreef olcott:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

It never returns because the simulating HHH prevents it to return, by
stopping the simulation before it could return.
That the simulated HHH does not return is, therefore, an error of the simulation, because the simulated HHH has code to see the 'special
condition', abort and return. But the simulating HHH fails to reach that
part of the simulation.

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

On 9/7/24 9:51 AM, olcott wrote:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

No, you have proven that you don't understand what the terms mean and
what it takes to prove something.

If they DO have different behavior in a correct simulation, what is the
FIRST instruction correctly simulated by the decider that differs from
the behavior dirrectly executed.

Your answer of the call HHH instruction just proves you don't understand
what it means to "correctly emulate" and instruction and that you are
nothing but a LIAR that doesn't care about what is actually true.

Since assuming away the pathological relationship that does
indeed exist is so ridiculously stupid I initially called
people despicable lying bastards for doing this.

Nope, YOU sre the despicable lying bastards for doing what you are doing.

Now it seems more like people have been so deeply indoctrinated
with the "received view" that you can smack them in the face with
the truth so hard that it will knock them down and they never
notice that you said a single word.

Nope, you are so brainwashed by yourself that you refuse to look at the
truth or learn the actual meaning of the words.

That is why you keep on "inventing" new meanings for words, so you can
ignore the real meaning of them.

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

On 2024-09-07 13:51:47 +0000, olcott said:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.

--
Mikko

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

Op 07.sep.2024 om 15:51 schreef olcott:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

No, olcott has proven many times that HHH cannot possibly simulate
itself correctly up to the end, but he is unable to accept the result of
his own proofs.
The simulation fails to complete, the abort is premature and an
incorrect decision is made from the incomplete simulation.

Since assuming away the pathological relationship that does
indeed exist is so ridiculously stupid I initially called
people despicable lying bastards for doing this.

If the 'pathological relationship' is that D contradicts H, then it is
clear that the simulation does not even reach the pathological part of
the program. Therefore, there is no relation with the pathological part
of D.
If the 'pathological relationship' is that H, or HHH, must simulate
itself, then it is clear that D, or DDD does not play a role in it.

int main() {
return HHH(main);
}

This shows that the problem for an incorrect simulation is within HHH
itself.
HHH halts, but decides that it does not halt.
Olcott is unable to accept the truth of his own proof.
HHH cannot possible simulate itself correctly up to the end.

Now it seems more like people have been so deeply indoctrinated
with the "received view" that you can smack them in the face with
the truth so hard that it will knock them down and they never
notice that you said a single word.

Olcott has been so deeply indoctrinated by himself, that he is unable to
accept his own proofs. His brain seems to be stuck in repeating false
claims, without evidence.

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

On 2024-09-08 13:51:25 +0000, olcott said:

On 9/8/2024 4:19 AM, Mikko wrote:

On 2024-09-07 13:51:47 +0000, olcott said:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.

Now there is a permanent link to the full file of the complete proof https://www.liarparadox.org/HHH(DDD).pdf

There is no proof in that file.

--
Mikko

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

On 9/8/24 9:51 AM, olcott wrote:

On 9/8/2024 4:19 AM, Mikko wrote:

On 2024-09-07 13:51:47 +0000, olcott said:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or
C can see that the machine address 217f is unreachachable only if
the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly
executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.

Now there is a permanent link to the full file of the complete proof https://www.liarparadox.org/HHH(DDD).pdf

Which just proves that you don't understand what a CORRECT emulation of
an input is.

We can know that HHH really is emulating itself emulating DDD
because the execution trace of this second emulation matches
the x86 source code of DDD line-by-line.

But that doesn't prove what you claim, and SHOULD NOT be listed as part
of the "Emulation of the input" since it isn't what the input did

Here is the C source-code that generated that x86 code. https://github.com/plolcott/x86utm/blob/master/Halt7.c

That these things may be over your head does not provide
the slightest trace of evidence that the above is not
compete proof.

No, it just proves that you are nothing but a pathetic ignorant
pathological lying idiot that donsn't undetstand what he is talking
about is has shown an inability to learn it even after it has been
pointed out to him many times.

Sorry, that is just the truth. You DON'T KNOW enough of what you talk
about, and refuse to learn it for your words to mean what you want them to.

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

On 9/9/24 1:57 PM, olcott wrote:

On 9/8/2024 9:41 AM, Mikko wrote:

On 2024-09-08 13:51:25 +0000, olcott said:

On 9/8/2024 4:19 AM, Mikko wrote:

On 2024-09-07 13:51:47 +0000, olcott said:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or >>>>>>>> C can see that the machine address 217f is unreachachable only if >>>>>>>> the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly >>>>>> executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.

Now there is a permanent link to the full file of the complete proof
https://www.liarparadox.org/HHH(DDD).pdf

There is no proof in that file.

That the execution trace of DDD emulated by HHH is proven
by the x86 source code of DDD. That HHH correctly emulates
itself emulating DDD is proven by the fact that the second
execution trace provided by the emulated HHH matches the
x86 source code of DDD. That DDD cannot possibly reach
it "ret" instruction final halt state is proven by these
two execution traces and the source-code of DDD.

No, that is NOT the exectution trace of the correct emulation of the
input, because the correct emulation of the input traces through the instructions of HHH as it emulates its input (the input is not executed
again until HHH returns).

The second execution trace just proves that you are LYING about what is happening, because that NEVER HAPPENS as actually executed code.

All this taken together proves that HHH had to abort its
emulation of DDD to prevent the infinite execution of DDD.
*Which proves that this criterion has been met*

Nope, just proves you are a liar.

<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

Except that HHH never CORRECTLY determined that a CORRECT (and complete) emulation of *THIS* input would not halt, just that THIS HHH can't do it.

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

On 2024-09-09 17:57:34 +0000, olcott said:

On 9/8/2024 9:41 AM, Mikko wrote:

On 2024-09-08 13:51:25 +0000, olcott said:

On 9/8/2024 4:19 AM, Mikko wrote:

On 2024-09-07 13:51:47 +0000, olcott said:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or >>>>>>>> C can see that the machine address 217f is unreachachable only if >>>>>>>> the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly >>>>>> executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.

Now there is a permanent link to the full file of the complete proof
https://www.liarparadox.org/HHH(DDD).pdf

There is no proof in that file.

That the execution trace of DDD emulated by HHH is proven
by the x86 source code of DDD.

Syntax error. Is "is" the werb of the first clause or the main clause?
What is the other verb?

--
Mikko

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

Op 09.sep.2024 om 19:57 schreef olcott:

On 9/8/2024 9:41 AM, Mikko wrote:

On 2024-09-08 13:51:25 +0000, olcott said:

On 9/8/2024 4:19 AM, Mikko wrote:

On 2024-09-07 13:51:47 +0000, olcott said:

On 9/7/2024 2:57 AM, Mikko wrote:

On 2024-09-06 11:20:52 +0000, olcott said:

On 9/6/2024 5:22 AM, Mikko wrote:

On 2024-09-03 13:58:27 +0000, olcott said:

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

Anyone that is not dumber than a box of rocks can tell
that machine address 0000217f is unreachable for every
DDD emulated by HHH according to the semantics of the
x86 language where HHH emulates itself emulating DDD.

Anyone who really knows either x86 assembly or machine langage or >>>>>>>> C can see that the machine address 217f is unreachachable only if >>>>>>>> the program at 000015d2, named HHH, does not return.

That is not exactly true. There is a directly executed HHH
that always returns and a DDD emulated by HHH that calls
an emulated HHH that never returns.

There is only one DDD. The emulated DDD is the same as the directly >>>>>> executed DDD. If HHH emulates someting else then that is not DDD.

I have conclusively proven that DDD, DD, D, PP and P
do have different behavior within pathological relationships
than outside of pathological relationships at least 1000
times in the last three years.

Saying "I have conclusively proven" wihtout actually proving anything
is not convincing.

Now there is a permanent link to the full file of the complete proof
https://www.liarparadox.org/HHH(DDD).pdf

There is no proof in that file.

That the execution trace of DDD emulated by HHH is proven
by the x86 source code of DDD. That HHH correctly emulates
itself emulating DDD is proven by the fact that the second
execution trace provided by the emulated HHH matches the
x86 source code of DDD. That DDD cannot possibly reach
it "ret" instruction final halt state is proven by these
two execution traces and the source-code of DDD.

All this taken together proves that HHH had to abort its
emulation of DDD to prevent the infinite execution of DDD.

And HHH failed to reach the end of the program that has been proven to
halt by other simulators, among which the unmodified world class simulator.

*Which proves that this criterion has been met*

<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

It did not meet the criterion, because it must abort only for olcott's
dream, the DDD build from the HHH that does not abort.
Olcott does not understand that adding the abort code changes the
behaviour of the program. He keeps dreaming of the HHH that does not
abort, only because HHH fails to reach the abort code.
The simulation of the HHH with the abort code has no need to be aborted.
Dreams are no substitute for facts.

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