Re: Liar detector: Fred, Richard, Joes and Alan --- Ben's agreement

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

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.

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.
The x86 language specifies that HHH aborts and returns, but the simulator is unable to simulate that, because the simulated HHH is aborted one cycle too early, so that the simulating HHH misses the full behaviour of the input.
You have shown that other simulator are able to simulate HHH correctly, which shows that it is a problem of HHH itself that it cannot simulate itself correctly.

 If you fail to sufficiently understand the semantics of the
x86 language then seeing this is impossible for you.
 _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]
 

Yes, this supports my analysis. Thanks for repeating it. HHH is incorrect, because it is unable to reach its own 'ret' in the simulation, even although the x86 language specifies that it should reach this 'ret' instruction.
This is further supported by the trace, you published, where we also see that the simulating HHH aborts prematurely, one cycle before the simulated HHH would abort and return. Showing that this simulation is incorrect, as well.
If you would correctly interpret the x86 language, you should see that the simulation fails to reach the 'ret' instruction.
I think you can't help to be blind for it, because: 'Don't assume somebody is wilfully wrong, if incompetence could be an explanation, as well.'
Therefore, Sipser does not apply, because that is about a correct simulation.