Deutsch   English   Français   Italiano  
<c9cd7b4b68475cdc0c0872079feeec401fa7788b@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Every sufficiently competent C programmer knows --- Semantic
 Property of Finite String
Date: Fri, 14 Mar 2025 14:42:58 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <c9cd7b4b68475cdc0c0872079feeec401fa7788b@i2pn2.org>
References: <vqntaq$1jut5$1@dont-email.me> <vqp388$1tvqa$1@dont-email.me>
 <vqpdv9$202b2$2@dont-email.me> <vqperb$20c9k$2@dont-email.me>
 <E6mcnWv3nMa66036nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <vqs2n8$2knng$1@dont-email.me>
 <5429f6c8b8a8a79e06b4aeefe677cc54a2a636bf@i2pn2.org>
 <vqt9jp$2spcd$6@dont-email.me> <vqtag4$2t2hb$2@dont-email.me>
 <vqtgl0$2u7fo$1@dont-email.me>
 <924e22fc46d629b311b16a954dd0bed980a0a094@i2pn2.org>
 <vqvg7s$3s1qt$3@dont-email.me> <vqvgb4$3kfru$5@dont-email.me>
 <vqvi94$3tk5h$1@dont-email.me> <vr01sq$9741$1@dont-email.me>
 <0672fec6cb2a5c56fd674bbbb3d2b2101c8f295f@i2pn2.org>
 <vr1fo0$1ev1a$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Mar 2025 18:42:58 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="187149"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vr1fo0$1ev1a$6@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 7021
Lines: 133

On 3/14/25 10:50 AM, olcott wrote:
> On 3/14/2025 6:02 AM, joes wrote:
>> Am Thu, 13 Mar 2025 20:48:09 -0500 schrieb olcott:
>>> On 3/13/2025 4:21 PM, Richard Heathfield wrote:
>>>> On 13/03/2025 20:48, dbush wrote:
>>>>> On 3/13/2025 4:46 PM, olcott wrote:
>>>>>> On 3/13/2025 4:27 AM, joes wrote:
>>>>>>> Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:
>>>>>>>> On 3/12/2025 7:56 PM, dbush wrote:
>>>>>>>>> On 3/12/2025 8:41 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS
>>>>>>>>> The direct execution of DDD
>>>>>>>> is proven to be different than the behavior of DDD emulated by HHH
>>>>>>>> according to the semantics of the x86 language.
>>>>>>> Which is weird, considering that a simulator should produce the same
>>>>>>> behaviour.
>>
>> Doesn't it?
>>
>>>>>>>> DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
>>>>>>>> PROPERTY OF THEIR INPUT FINITE STRINGS.
>>>>>>> And not if the input called a different simulator that didn't abort.
>>>>>>>
>>>>>> Replacing the code of HHH with an unconditional simulator and
>>>>>> subsequently running HHH(DD) cannot possibly reach its own final
>>>>>> state no matter what HHH does.
>>>>>> Replacing the code of HHH1 with an unconditional simulator and
>>>>>> subsequently running HHH1(DD) does reach its own final state.
>>>>>> If someone was not a liar they would say that these are different
>>>>>> computations.
>>>>>>
>>>>> Only because one changes the code that DD runs and one doesn't
>>>>
>>>> It hardly matters. Either his emulation faithfully and correctly
>>>> establishes and reports (for EVERY program anyone cares to feed it) the
>>>> actual halting behaviour exhibited by the program it's emulating, or it
>>>> doesn't.
>>>>
>>> That everyone expects the behavior of the directly executed DDD to be
>>> the same as DDD correctly emulated by HHH1 is verified as a factually
>>> correct expectation.
>>> That everyone expects the behavior of the directly executed DDD to be
>>> the same as DDD correctly emulated by HHH is verified as a factually
>>> incorrect expectation.
>> A simulation should not differ from the actual execution. Why should it?
>>
>>>> If it doesn't, it doesn't, and it's a lot of fuss over nothing.
>>>> But if it /does/, then we're right back at Turing's proof, because a
>>>> working emulator is just another way of running the code, and is
>>>> therefore superfluous to requirements. It adds nothing to the debate,
>>>> because we can just run the code and get the same answer the emulator
>>>> would provide.
>>>>
>>> For the first time in the history of mankind it proves that a simulation
>>> of a virtual machine according to the semantics of this machine language
>>> DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT EXECUTION OF THIS
>>> SAME MACHINE
> 
>> Bold claim. How does that make sense?
>>
>>> PATHOLOGICAL SELF REFERENCE DOES CHANGE SEMANTICS
>> As opposed to what? Of course a different program has different 
>> semantics.
>>
>>> This sentence is not true: "This sentence is not true"
>>> The exact same word-for-word sentence IS TRUE IN THIS DIFFERING CONTEXT
>>> THAT DOES NOT HAVE PSR.
> 
>> It's a different sentence.
>>
> It is the same word-for-word sentence with
> pathological self-reference removed.

Something with something removed is not the same thing,

I guess that is just one of your root lies for your logic system.

> 
>>>> In other words, the emulator is a canard, a distraction, a cul-de-sac,
>>>> and a complete waste of time. If it happens to work, great! Well done
>>>> that man. But it doesn't affect the HP logic one microscopically
>>>> minuscule millijot.
>>> The emulator proves the actual behavior specified by the INPUT
> 
>> No, the direct execution does.
>>
> 
> We really cannot simply ignore the pathological self-reference
> specified by DDD to HHH  and not specified by DDD to HHH1.

No, because it isn't a pathological SELF-reference, it is a pathological 
reference by DDD to HHH that makes it impossible to build an HHH that 
get the right answer,

You just don't understand what the words mean,

> 
>>> That people disagree with the semantics of the x86 language proves how
>>> deeply indoctrinated they are.
>> With what semantics?
> 
> I will give it to you in C
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> The above code specifies that
> DDD correctly simulated by HHH specifies that DDD will
> continue to call HHH(DDD) in recursive simulation and
> WILL NOT CALL HHH1(DDD) IN RECURSIVE SIMULATION.
> 

No, it specifies that DDD will call HHH(DDD).

What that does is unspecified.

If you define HHH to correctly simulate its input, then BY THAT 
DEFINITION HHH can never abort its emulation and return a value,

If you define that HHH will only partially simulated its input, then by 
THAT definition, HHH(DDD) will ALWAYS return to DDD, thus since DDD 
ignores the return value, DDD will always halt,

Your problem is you try to define that HHH does both of these at once, 
which is just a contradiction that blows your logic apart. A logic that 
you admit is just a fraud as you admit to having changed core defintions 
of terms of art, mainly because you are too stupid to understand them,

Sorry, you are just proving how stupid you are.