Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: This function proves that only the outermost HHH examines the
 execution trace
Date: Sat, 27 Jul 2024 21:10:23 +0200
Organization: A noiseless patient Spider
Lines: 221
Message-ID: <v83gn0$3gihn$5@dont-email.me>
References: <v80h07$2su8m$3@dont-email.me>
 <0amdndFJSZSzYD77nZ2dnZfqnPednZ2d@brightview.co.uk>
 <v8102f$2vo8u$1@dont-email.me> <v829vn$3a8a0$1@dont-email.me>
 <v8303r$3dftr$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 27 Jul 2024 21:10:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5f623e9acbcbdce9334ab4c51e72f5f6";
	logging-data="3689015"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+polZQxIFyq/xu7k7rO4q8"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ayon1xGG8i6tQiyWG60lTCzP5Qg=
Content-Language: en-GB
In-Reply-To: <v8303r$3dftr$7@dont-email.me>
Bytes: 11752

Op 27.jul.2024 om 16:27 schreef olcott:
> On 7/27/2024 3:09 AM, Mikko wrote:
>> On 2024-07-26 20:14:07 +0000, olcott said:
>>
>>> On 7/26/2024 2:46 PM, Mike Terry wrote:
>>>> On 26/07/2024 16:56, olcott wrote:
>>>>> This is meant for Mike, Joes and Fred don't have the technical 
>>>>> competence to understand it.
>>>>>
>>>>> Richard might be able to understand it yet the fact that he is
>>>>> stuck in rebuttal mode makes any understanding that he may have
>>>>> utterly useless.
>>>>>
>>>>> Mike: It seems that HHH has been a pure function of its inputs
>>>>> and never has provided data downward to its slaves that corrupts
>>>>> their halt status decision. They don't even make a halt status
>>>>> decision thus cannot make a corrupted one.
>>>>
>>>> Well, the first two claims are literally untrue - outer HHH 
>>>> effectively uses the static mutable data to pass flags to the inner 
>>>> HHH that modify its behaviour.  The Root flag below is derived from 
>>>> the actual static data and causes inner HHH to totally skip its own 
>>>> abort logic!
>>>>
>>>> You seem to acknowledge this, but claim it does not matter for 
>>>> various reasons, because whatever mistakes you are making, what 
>>>> finally gets printed out is saying the right thing!
>>>>
>>>
>>> If HHH gets the correct answer in an impure way then it only
>>> counts that it gets it in an impure way if it is impossible
>>> to get in a pure way. This makes it possible for HHH to get
>>> this answer in a pure way:
>>>
>>> Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
>>> On 3/1/2024 12:41 PM, Mike Terry wrote:
>>>  >
>>>  > Obviously a simulator has access to the internal state
>>>  > (tape contents etc.) of the simulated machine. No problem there.
>>>
>>>> The problem with this attitude is that when you describe your ideas 
>>>> and present the printed output, you say that HHH is "simulating" 
>>>> DDD, and people know what simulating means, and everyone has 
>>>> expectations of what that implies.  You are happy to use those 
>>>> expectations when it goes along with what you want to claim, but try 
>>>> to conceal that those expectations are unjustified because what you 
>>>> are doing is not "proper simulation" as everybody would understand it.
>>>>
>>>
>>> It does not have any effect on the simulation. It only gets
>>> the non-halting results that we can all see is correct in an
>>> impure way. Each instruction of DDD is emulated precisely
>>> according to the semantics that it specifies.
>>>
>>>> You can't have it both ways.
>>>>
>>>
>>> It may seem that way if you are not paying close enough attention
>>> or have insufficient skill with the semantics of the x86 language.
>>>
>>>> The way to avoid all such concerns is to implement simulation 
>>>> correctly, like you claim to have done.  Simulation is not /just/ 
>>>> the step by step simulation provided by libx86emu(sp?) -
>>>
>>> Yes it is. That *is* what simulation is.
>>> The only thing that is added to this is termination analysis that
>>> can be verified as correct even if this correct result was not
>>> derived in a pure way.
>>>
>>>> your entire computation environment needs to correctly work together 
>>>> so that the end-to-end effect is that simulated code exactly follows 
>>>> the behaviour of the original code, at least up to the point where 
>>>> the simulator aborts.
>>>
>>> It has done that for three years and you never bothered to pay
>>> enough attention to notice that it has done that for three years.
>>>
>>>> Put differently, you also need to simulate the /correct/ 
>>>> instructions and data.
>>>>
>>>
>>> The instructions *are* the data.  A sequence of these instructions
>>> (execution trace) is all that the termination analyzer uses.
>>>
>>>> The same applies to when you try to "copy" code,
>>>
>>> I don't try to copy code. libx86emu gets confused with
>>> copied code.
>>>
>>>> as in your H1 and HHH1:  by definition of "copy" [as understood by 
>>>> everybody here] the behaviour of the copied code must exactly match 
>>>> that of the original code - otherwise it is simply not a proper 
>>>> "copy" by definition.
>>>>
>>>
>>> There is no copy. It is always the exact same integer
>>> machine address of DDD.
>>>
>>> Why do you insist on saying the the emulation of DDD by HHH
>>> is incorrect when it is an easily verified fact that HHH
>>> emulates each instruction of DDD exactly according to the
>>> semantics specified by this instruction.
>>>
>>> Every time that anyone every said that the simulation was
>>> incorrect I dared them to point to the line of code that
>>> was simulated incorrectly and they responded with rhetoric,
>>> ad hominem, and double talk and never pointed out any
>>> instruction that was emulated incorrectly.
>>>
>>> These tactics may seem convincing to gullible fools yet are
>>> as obvious as a pie-in-the-face to those having enormously
>>> much more single-minded focus of attention.
>>>
>>>> As a joke alternative you could stop claiming to simulate or copy 
>>>> anything, and say instead you are misulating and pocying code!  You 
>>>> could say "HHH misulates DDD and sees that DDD will never halt" but 
>>>> obviously people will just say "What's misulating, and why should 
>>>> misulating (whatever it is) allow HHH to see things about DDD?"  You 
>>>> see - from your perspective that would be hopeless for your wider 
>>>> scope argument which attempts to invalidate the Linz/Sipser proofs. 
>>>> Similarly if you claim that you "pocyed" HHH to HHH1 and they have 
>>>> different results when given input DDD, people will just look blank 
>>>> - what's "pocying" and why would anyone expect a pocyed routine to 
>>>> give the same result as the original routine?
>>>>
>>>> No, none of that flies.  It was a joke, but with a sensible aim - to 
>>>> convince you that for your wider scale arguments you need simulating 
>>>> (and copying) to have their correct meanings as everybody here will 
>>>> understand them.  No good saying "they mean something else, but it 
>>>> doesn't matter because what my program finally writes out is TRUE".
>>>>
>>>> Of course none of that will convince you of anything and you'll just 
>>>> continue.
>>>>
>>>>>
>>>>> I could change the code so that the slave instances can and do
>>>>> try to form a halt status decision on the basis of the execution
>>>>> trace that they do have.
>>>> Your concept of master/slaves simulators is broken.  There are 
>>>> outer/inner simulators but that is just a relative term, and all 
>>>> simulated code (at whatever level) needs to have the same behaviour 
>>>> as the unsimulated code.
>>>>
>>>> If your simulation was correctly designed/implemented this would 
>>>> just work.  (Of course, HHH has to correctly use the DebugStep() (et 
>>>> al.) primitive ops to gather what it needs to make its decision, no 
>>>> cheating with globals etc..)
>>>>
>>>
>>> That you disagree that the simulation is correct without being
>>> able to point out a single line-of-code of DDD that was simulated
>>> incorrectly seems to indicate that you are happy to directly
>>> contradict verified facts.
>>>
>>>> I know you've said you don't have time to think about how to do this 
>>>> correctly.  That's fair enough, but in the meantime you should not 
>>>> claim that your incorrect implementation proves your conclusions!
>>>
>>> Anyone having sufficient knowledge of the x86 language can verify
>>> the only two relevant details:
>>>
>>> DDD is correctly emulated by HHH until it correctly determines
>>> that DDD specifies not halting behavior that must be aborted.
>>>
>>>
>>>>  To be fair, you shouldn't need x86utm.exe in your arguments - it is 
>>>> not the Appeal To Authority that you imagine it to be!  All of your 
>>>> arguments could just be phrased in pseudo-code and there would not 
>>>> be any disagreement about how that would behave by posters here.  Of 
>>>> course, your ideas expressed that way would still be Wrong, and 
>>>> nobody would agree with them, but that's the case anyway when you 
>>>> try to bring in x86utm!
>>>>
>>>
>>> That you disagree that the simulation is correct without being
========== REMAINDER OF ARTICLE TRUNCATED ==========