Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: This function proves that only the outermost HHH examines the
 execution trace
Date: Sat, 27 Jul 2024 09:27:06 -0500
Organization: A noiseless patient Spider
Lines: 204
Message-ID: <v8303r$3dftr$7@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 27 Jul 2024 16:27:07 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c4ee90cee71e7f0114aee78a4820d739";
	logging-data="3588027"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19lH1tiw9PTnggiH0liw3iw"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:mGtNSxBMBfLE2iNaJjiz7Tgf+0I=
In-Reply-To: <v829vn$3a8a0$1@dont-email.me>
Content-Language: en-US
Bytes: 10537

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
>> able to point out a single line-of-code of DDD that was simulated
>> incorrectly seems to indicate that you are happy to directly
========== REMAINDER OF ARTICLE TRUNCATED ==========