On 7/5/24 8:20 AM, olcott wrote:

On 7/5/2024 4:49 AM, joes wrote:

Am Wed, 03 Jul 2024 13:57:40 -0500 schrieb olcott:

On 7/3/2024 1:40 PM, Fred. Zwarts wrote:

Op 03.jul.2024 om 20:20 schreef olcott:

DDD correctly emulated by any element of the infinite set of every
pure function HHH cannot possibly reach its own ret instruction and
halt. That HHH aborts its emulation at some point or never aborts its >>>>> emulation cannot possibly change this.

Ad hominem attacks always try to hide a lack of argumentation.
It has been proved that HHH cannot possibly correctly simulate itself.

That is false and you know it. That might not be a flat out lie as it is >>> an sloppy use of language.

HHH does correctly simulate itself simulating DDD one time, then it
stops correctly simulating itself because this criteria is met:
      HHH correctly simulates its input DDD until HHH correctly
      determines that its simulated DDD would never stop running unless
      aborted

But it would stop running.

Not if not aborted.

But the decider can't abort the program, only its own simulation of it.

You gun isn't good enough to kill the bear, so the bear kills you.

So, the above code shows that the incorrect simulation of DDD by HHH is >>>> unable to reach the 'ret' instruction, because it either never aborts, >>>> or aborts one cycle too soon, when the simulated HHH is only one cycle >>>> from its own abort and return and then the return of DDD would follow.

The criteria is:
      HHH simulates its input DDD until HHH
      determines that its simulated DDD would never stop running unless
      aborted
Richard always lies about this by making sure that he ever sees the word >>> UNTIL.

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

On 7/6/24 8:54 AM, olcott wrote:

On 7/6/2024 1:33 AM, Mikko wrote:

On 2024-07-05 12:43:45 +0000, olcott said:

On 7/5/2024 7:26 AM, joes wrote:

Am Fri, 05 Jul 2024 07:20:04 -0500 schrieb olcott:

On 7/5/2024 4:49 AM, joes wrote:

Am Wed, 03 Jul 2024 13:57:40 -0500 schrieb olcott:

On 7/3/2024 1:40 PM, Fred. Zwarts wrote:

Op 03.jul.2024 om 20:20 schreef olcott:

DDD correctly emulated by any element of the infinite set of every >>>>>>>>> pure function HHH cannot possibly reach its own ret instruction >>>>>>>>> and
halt. That HHH aborts its emulation at some point or never aborts >>>>>>>>> its emulation cannot possibly change this.

Ad hominem attacks always try to hide a lack of argumentation. >>>>>>>> It has been proved that HHH cannot possibly correctly simulate >>>>>>>> itself.

That is false and you know it. That might not be a flat out lie
as it
is an sloppy use of language.

HHH does correctly simulate itself simulating DDD one time, then it >>>>>>> stops correctly simulating itself because this criteria is met:
HHH correctly simulates its input DDD until HHH correctly
determines that its simulated DDD would never stop running
unless aborted

But it would stop running.

Not if not aborted.

But it is aborted!

*It is not aborted when HHH makes its decision to abort*

If it will be aborted in future it will not run forever.

<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

    H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

HHH(DDD) does meet this criteria. Professor Sipser is not wrong.

No, what Professor Sipser is referring to as a "Correct Simulation" is
not your PARTIAL simulation, (which is definitionally NOT correct) but a simulation that exact reproduces all the behavior of the input, which
means it CAN NOT STOP its simulation until the end is reached.

Since your HHH doesn't do that, or correctly predict that such a
simulation would never stop (it can't, since we just showed that such a simulation DOES halt), it was never able to use the second paragraph, so
by aborting anyway, it rendered itself subject to error.

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

XPost: sci.logic

On 7/6/24 12:30 PM, olcott wrote:

On 7/6/2024 10:29 AM, Fred. Zwarts wrote:

Op 06.jul.2024 om 17:10 schreef olcott:

On 7/6/2024 10:00 AM, Fred. Zwarts wrote:

Op 06.jul.2024 om 15:01 schreef olcott:

On 7/6/2024 4:09 AM, Fred. Zwarts wrote:

Op 05.jul.2024 om 17:54 schreef olcott:

On 7/5/2024 10:48 AM, Fred. Zwarts wrote:

Op 05.jul.2024 om 16:05 schreef olcott:

On 7/5/2024 8:54 AM, Fred. Zwarts wrote:

HHH cannot possibly correctly simulate itself.

LIAR! I give up on you.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

No need to come back, because you are unable to point to any
error in my reasoning.

I conclusively proved that HHH is correctly simulating itself
simulating DDD and you simply freaking lie about it.

Your replies are only irrelevant, or supporting my reasoning. I >>>>>>>> showed that HHH cannot possibly simulate itself correctly and
your full trace supports this, as it shows that the simulating >>>>>>>> HHH is unable to reach the 'ret' of the simulated HHH.

*Unable to reach ret IS A FREAKING CORRECT FREAKING SIMULATION*

Unable to reach ret *is a freaking demonstration* of an incorrect
simulation.

If it was incorrect you would have to show which
x86 instruction was simulated incorrectly. You
can't do that because it is a matter of verified
fact that none of them were simulated incorrectly.

Incorrect reasoning.

I commented at the wrong place.

The semantics of the x86 language are the only criterion
measure of correct emulation. Only stupid liars would disagree.

So, why do you disagree that the x86 code specifies an HHH that aborts
and halts?

Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.

If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.

No, the call actually correctly simulated WILL Return, as a actually
correct simulation won't stop until it reaches the end.

Yes, the PARTIAL simulation by HHH won't reach that state, but since you
have defined that it WILL abort its simulation and return, that makes
the FULL simulation of the input reach that point and see the returns.

If you fail to sufficiently understand the semantics of the
x86 language then seeing this is impossible for you.

Which, BY DEFINITION, say a CORRECT simulaition of the input doesn't
stop just because the simulator wants to (or needs to for some reason).
A simulator that stops its simulation isn't "correct" but only "partial" (assumed to correctly do every step except for the fact tht the last instruction simulated isn't followed by the next one after it).

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

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

XPost: sci.logic

On 7/6/24 3:14 PM, olcott wrote:

On 7/6/2024 1:55 PM, Fred. Zwarts wrote:

Op 06.jul.2024 om 18:30 schreef olcott:

On 7/6/2024 10:29 AM, Fred. Zwarts wrote:

So, why do you disagree that the x86 code specifies an HHH that
aborts and halts?

Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.

Irrelevant text ignored. You talked about x86, therefore continuing to
talk about x86 is not a change of subject.
I know you have difficulties to recognize the truth, so I do not feel
offended, because: 'Don't assume somebody is wilfully wrong, if
incompetence could be an explanation, as well.'

If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.

I understand enough of it to see that it cannot possibly return,
because HHH cannot possibly simulate itself correctly.

According to the semantics of the x86 language IS IS IMPOSSIBLE
FOR DDD SIMULATED BY HHH TO RETURN AND IT IS EQUALLY IMPOSSIBLE
FOR THE HHH(DDD) CALLED BY DDD SIMULATED BY HHH TO RETURN.

I can't tell that you are ignorant or a liar and it is reaching
the point where I don't care which it is.

No, according to the semantic of the x86 language, since HHH DOES
return, then the DDD that is being simulated WILL RETURN, it is just not
within the simulation that HHH does.

You are confusing the machine with the simulation of the machine.

The DDD simulated by HHH is the machine, "simulated" just being a
modifier to make clear which DDD we are talking about. And that machine
does return.

You seem to mean, the PARTIAL SIMULATION of DDD by HHH. And that PARTIAL simulation does not reach that point, because HHH gave up.

Your inability to understand this difference, either makes YOU the idiot
if it is a true lack of understanding, or a liar if you understand it
but refuse to accept it.

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

XPost: sci.logic

On 7/7/24 9:46 AM, olcott wrote:

On 7/7/2024 1:41 AM, Fred. Zwarts wrote:

Op 06.jul.2024 om 21:14 schreef olcott:

On 7/6/2024 1:55 PM, Fred. Zwarts wrote:

Op 06.jul.2024 om 18:30 schreef olcott:

On 7/6/2024 10:29 AM, Fred. Zwarts wrote:

So, why do you disagree that the x86 code specifies an HHH that
aborts and halts?

Dishonest dodge of changing the subject. This is called
the strawman deception and is a favorite tactic of liars.

Irrelevant text ignored. You talked about x86, therefore continuing
to talk about x86 is not a change of subject.
I know you have difficulties to recognize the truth, so I do not
feel offended, because: 'Don't assume somebody is wilfully wrong, if
incompetence could be an explanation, as well.'

If you sufficiently understand the semantics of the x86
language then you can see that the call to HHH(DDD) from
DDD simulated according to the semantics of the x86 language
cannot possibly return.

I understand enough of it to see that it cannot possibly return,
because HHH cannot possibly simulate itself correctly.

According to the semantics of the x86 language IS IS IMPOSSIBLE
FOR DDD SIMULATED BY HHH TO RETURN AND IT IS EQUALLY IMPOSSIBLE
FOR THE HHH(DDD) CALLED BY DDD SIMULATED BY HHH TO RETURN.

Therefore, you should agree that HHH cannot possibly simulate itself
correctly.

Correctly is measured by the semantics of the x86 language.
This specifies that when DDD is correctly simulated by HHH
calls emulated HHH(DDD) that this call cannot return.

but that only holds if HHH is some OTHER program that actually DOES that correct simulation, since the x86 language says that a correct
simulation does not stop until the end of the program is reached.

If that is your HHH, then you lie that it returns the value 0 to say the
input in non-halting.

If the input is the HHH that you are actually talking about, you LIE
that it is a "Correct x86 simulator" because it isn't, it is only a
PARTIAL x86 simulator, and the actual correct x86 simulation of DDD
calling THIS HHH(DDD) will show that it halts.

So, you claim is based on a lie, you just get to decide which one it is.

You smash a bottle on the ground. No matter how much you
want the bottle to hold water it will not hold water.

Right, but you had to have a bottle to smash, and not just a imaginary one.

That is what the semantics of the x86 teach you.
There is no disagreement about the semantics of the x86, if you see
that it means that HHH cannot possibly reach its own 'ret'
instruction, therefore, the simulation cannot possibly be correct.

A correct simulation is what-so-ever-the Hell that the x86
machine code of HHH/DDD specifies even if this code starts
WW III. Correct is not measured by what you would like to
see or what you expect to happen. Correct is only measured
by the behavior that the code specifies.

Right, which is the non-aborted behavior of DDD, which will return if
HHH(DDD) ever return.

Since that IS the behavior of your HHH, and as such it doesn't do a
correct x86 simulation of its input, but only a PARTIAL simulation, we
can say your claim is false, as DDD will return, and HHH will returun,
and HHH's simulation that claims neither does is just wrong.

When I say that 2 + 3 = 5 you are not free to dislike this
result and prefer or expect 2 + 3 = 7.

Right, and since the correct simulation of THIS DDD will return since
you have said that HHH(DDD) will return 0 (incorrectly claimed as the
correct answer) we can thus say that you HHH did NOT do a correct
simulation since it got the wrong answer.

I can't tell that you are ignorant or a liar and it is reaching
the point where I don't care which it is.

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

On 7/7/24 9:52 AM, olcott wrote:

On 7/7/2024 2:29 AM, Mikko wrote:

On 2024-07-06 12:54:59 +0000, olcott said:

On 7/6/2024 1:33 AM, Mikko wrote:

On 2024-07-05 12:43:45 +0000, olcott said:

On 7/5/2024 7:26 AM, joes wrote:

Am Fri, 05 Jul 2024 07:20:04 -0500 schrieb olcott:

On 7/5/2024 4:49 AM, joes wrote:

Am Wed, 03 Jul 2024 13:57:40 -0500 schrieb olcott:

On 7/3/2024 1:40 PM, Fred. Zwarts wrote:

Op 03.jul.2024 om 20:20 schreef olcott:

DDD correctly emulated by any element of the infinite set of >>>>>>>>>>> every
pure function HHH cannot possibly reach its own ret
instruction and
halt. That HHH aborts its emulation at some point or never >>>>>>>>>>> aborts
its emulation cannot possibly change this.

Ad hominem attacks always try to hide a lack of argumentation. >>>>>>>>>> It has been proved that HHH cannot possibly correctly simulate >>>>>>>>>> itself.

That is false and you know it. That might not be a flat out lie >>>>>>>>> as it
is an sloppy use of language.

HHH does correctly simulate itself simulating DDD one time,
then it
stops correctly simulating itself because this criteria is met: >>>>>>>>> HHH correctly simulates its input DDD until HHH correctly
determines that its simulated DDD would never stop running
unless aborted

But it would stop running.

Not if not aborted.

But it is aborted!

*It is not aborted when HHH makes its decision to abort*

If it will be aborted in future it will not run forever.

<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

     H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

HHH(DDD) does meet this criteria. Professor Sipser is not wrong.

You have not proven that it does meet both criteria.

Knowledge of arithmetic proves that 2 + 3 = 5. If you lack
this knowledge that does not mean that 2 + 3 = 5 is not proven.

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

Sufficient knowledge of the x86 language conclusively proves
that the call from DDD correctly simulated by HHH to HHH(DDD)
cannot possibly return for any pure function HHH.

That you continue to disagree only having your own ignorance
as a fake basis is ridiculously stupid.

Nope, knowledge of the x86 language tells us that a given set of
instructions, when executed with the same data, will always behave the
same, and thus if HHH(DDD) is known to return 0 to main, it will also
return to DDD and thus a CORRECT SIMULATION of DDD, will show that.

If HHH's simulation doesn't it just wasn't a correct simulation, perhaps incorrect by being just partial, thus your premise of DDD correctly
simulated gy HHH and HHH(DDD) correctly returning 0 and answer are just inconsistant.

yes, your HHH will not reach the return instruction of HHH in its
simulation of DDD, but that doesn't mean that a correct simulation will not.

Only if HHH never aborts, (and that mean NEVER) will DDD be non-halting.

But, since that isn't the HHH you talk about, we can state that a
correct simulation of DDD will return, and that you HHH(DDD) just fails
to meet either its requirement to correctly simulate the input or to
correct decide on the bahavior of its input.

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

On 7/15/24 8:59 AM, olcott wrote:

On 7/15/2024 2:19 AM, Mikko wrote:

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

When I refer to the x86 language I am referring to the minimal
subset that runs the same way on compatible Intel 32-bit processors.

Then you should specify a specific instruction set, preferably the one
that your compiler uses.

All this is a moot deflation away from the point.
You can see the actual code you can look up what
its instructions mean.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

Right, and call HHH means go into HHH and see what it actually does and
report that answer.

First, that means that the code of HHH must be part of the input.

Second, the "correct emulation" of that code must agree with what
HHH(DDD) actually does.

If HHH(DDD) returns to main, then the ONLY result a correct emulation of
that instuction can result in is seeing HHH return to DDD at instruction 0000216b.

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

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

On 7/16/2024 1:58 AM, Mikko wrote:

On 2024-07-15 12:55:21 +0000, olcott said:

On 7/15/2024 2:15 AM, Mikko wrote:

On 2024-07-14 14:15:45 +0000, olcott said:

*You can comprehend this is a truism or fail to*
*comprehend it disagreement is necessarily incorrect*
Any input that must be aborted to prevent the non
termination of HHH necessarily specifies non-halting
behavior or it would never need to be aborted.

No, it is false. What the input specifies is a property of the input
alone.
Whether some HHH is able to process it without looping forever is not a >>>> property of the input and not relevant to the meaning of the input.

In other words you believe that you can correctly
ignore the verified fact that DDD correctly emulated
by HHH does call HHH(DDD) in recursive emulation.

It is not a fact and not verified but otherwise, yes, that is not
relevant.

When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior

But the simulation of that input DOES stop running when completely
emulated if the HHH that it calls ever aborts is emulation and returns.

It is just that the HHH doesn't get that far in its emulation.

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

On 7/18/24 9:17 AM, olcott wrote:

On 7/18/2024 2:40 AM, Mikko wrote:

On 2024-07-17 13:00:55 +0000, olcott said:

On 7/17/2024 1:43 AM, Mikko wrote:

On 2024-07-16 14:21:28 +0000, olcott said:

When simulated input DDD stops running {if and only if}
the simulation of this input DDD has been aborted this
necessitates that input DDD specifies non-halting behavior

DDD does not stop runnig unless it is completely exeuted.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

DDD emulated by HHH according to the semantic meaning of
its x86 instructions never stop running unless aborted.

You mean HHH's simulation of DDD may not termite before HHH aborts it?

When we examine the infinite set of every HHH/DDD pair such that:
HHH₁ one step of DDD₁ is correctly emulated by HHH₁.
HHH₂ two steps of DDD₂ are correctly emulated by HHH₂.
HHH₃ three steps of DDD₃ are correctly emulated by HHH₃.
...

And all those are PARTIAL emulaiton of PART of the input give to them.

In fact, once you get to five, by your rules, HHH can't do it, as there
is no instrucition in the input to emulate.

HHH∞ The emulation of DDD∞ by HHH∞ never stops running.

When each DDD of the HHH/DDD pairs above is correctly emulated
by its corresponding HHH according to the semantic meaning of its
x86 instructions it CANNOT POSSIBLY reach past its own machine
address 0000216b, not even by an act of God.

Nope, Its EMULATION doesn't get there, but the program (when you include
the HHH that it calls that you seem to allow for the emulaiton) will get
there.

You just think that emulator is God, which it isn't, the "God" of the
cmmputer is the idealized CPU would run the program, and that can't be
stoppoed by a mere program, and runs to the end.

The behaviour specified by DDD, both by C semantics and by x86 semantics,
is halting if HHH returns. Otherwise HHH is not a decider.

When HHH is required to be a pure function then only one element
of the above infinite set of every possible HHH/DDD is not a decider.

Right, and all of those deciders get the wrong answer, because the
programmer lied about what HHH that DDD the decider was given. Since
they were all given DDDs that called an HHH that returns, but the
programmer LIED by claiming it is calling the HHH that was not a decider
even though that isn't the one in the memory at the tie.

LYIHG gives wrong answers.

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