Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Liar detector: Peter Olcott
Date: Sat, 6 Jul 2024 13:25:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <805642dc27c646c734ec72b303d11fdddeb0a614@i2pn2.org>
References: <v644pn$29t4h$3@dont-email.me> <v645v1$29pag$3@dont-email.me>
 <v646v5$2agfo$1@dont-email.me> <v647p3$29pag$6@dont-email.me>
 <v6480h$2ape0$1@dont-email.me> <v648nk$29pag$8@dont-email.me>
 <v64as3$2bc8m$1@dont-email.me> <v64drn$29pag$10@dont-email.me>
 <v64e92$2bvgc$1@dont-email.me> <v65juc$2lui5$2@dont-email.me>
 <v665c9$2oun1$4@dont-email.me> <v66t0p$2n56v$1@dont-email.me>
 <v66t7p$2srk8$1@dont-email.me> <v66tql$2n56v$3@dont-email.me>
 <v66u56$2suut$1@dont-email.me> <v66v8i$2n56v$4@dont-email.me>
 <v67028$2t9el$1@dont-email.me> <v68b3f$2n56v$5@dont-email.me>
 <v68ocd$39dkv$5@dont-email.me> <v68pfo$2n56v$7@dont-email.me>
 <v68rnv$39tml$2@dont-email.me> <v68tvd$3ac9t$1@dont-email.me>
 <v68uj0$3ahel$1@dont-email.me> <v694k4$3bevk$1@dont-email.me>
 <v69502$3bh3f$1@dont-email.me> <v6b1k4$3odj5$1@dont-email.me>
 <v6bf7r$3qiio$2@dont-email.me> <v6bm5v$3rj8n$1@dont-email.me>
 <v6bmoe$3ri0l$2@dont-email.me> <v6bnt2$3rj8n$3@dont-email.me>
 <v6brfj$3skuk$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 6 Jul 2024 17:25:05 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2375601"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v6brfj$3skuk$2@dont-email.me>
Content-Language: en-US
Bytes: 5492
Lines: 88

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