Sujet : Re: Every sufficiently competent C programmer knows --- Semantic Property of Finite String
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theoryDate : 14. Mar 2025, 15:10:42
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <b71ec309f45eee3c91164b74f4b4ad5529428f55@i2pn2.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : Mozilla Thunderbird
On 3/14/25 12:26 AM, olcott wrote:
On 3/13/2025 10:03 PM, Richard Damon wrote:
On 3/13/25 10:05 PM, olcott wrote:
On 3/13/2025 6:09 PM, Richard Damon wrote:
On 3/13/25 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.
>
>
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.
>
>
DDD correctly emulated by HHH cannot possibly
reach its own final state no matter what HHH
does.
>
DDD correctly emulated by HHH1 does reach its
own final state.
>
Which shows that HHH doesn't correctly emulate its input, unless you just lied and gave the two programs different inputs.
>
>
void DDD()
{
HHH(DDD);
return;
}
>
Someone that is not a liar could explain exactly
how DDD emulated by HHH according to the semantics
of the C language must have the same behavior as
DDD emulated by HHH1 according to the semantics
of the C language.
>
WHy? The above is NOT a program, as to be a program it needs the full code of HHH included.
>
That would be too confusing for this simple thought experiment.
The behavior of HHH is already fully specified.
No, that is the method you use to hide your deception.
The problem is HHH isnt fully specified, as you have two different specifications for it that are contradictory.
You claim it "correctly emulates" (which requires possibly taking infinite time) its input, and it also correctly decides (which means it always answers in a finite time).
If HHH actually does a correct simulation, then it never returns as (as you have shown, the correct simulation of a function that calls that simulator on itself) bcomes an infinite recursion. Such an HHH fails to decide, and thus does not the HHH that you are claiming to exist.
If HHH does abort its simulation to give an answer, then it did not do a correct simulation, and its partial simulation does not prove that the input is non-halting, but the correct simulation of giving this WHOLE program (that is DDD calling the HHH that you are talking about here) to a correct emulator (like HHH1) shows that it will halt.
Your fallacious claims about "what every competent programmer should know" or about "what is unreasonable to expect" just show that you just don't understand the nature of logic, and while it would be unreasonable to expect a decider to emulate its input forever, it is reasonable to expect a correct emulator to do so, and a combined function must meet ALL the requriements on it, which is what makes that combination impossible.
A PROPER definition of a simulating halt decider would be decider that answers based on what a correct simulation would do, and that correct simulation will be, by definition, not necessarily be done by the decider.
The flaw in your logic is you insist that giving the input to a different processor to look at it, changes the input, but that means your "input" isn't a program, as programs are FIXED sets of instructions.
Sorry, all you are doing is proving your utter ignorance of what you talk about, and that you have created a massive fraud to try to explain your ideas that are just fundamentally wrong, and are too stupid to understand the fraud you created,