Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: This function proves that only the outermost HHH examines the execution trace
Date: Sat, 27 Jul 2024 11:09:27 +0300
Organization: -
Lines: 179
Message-ID: <v829vn$3a8a0$1@dont-email.me>
References: <v80h07$2su8m$3@dont-email.me> <0amdndFJSZSzYD77nZ2dnZfqnPednZ2d@brightview.co.uk> <v8102f$2vo8u$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 10:09:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c9d45fc3af5a1949f530b625013a7212";
	logging-data="3481920"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18pODVx06P0WJqnavLAIwFq"
User-Agent: Unison/2.2
Cancel-Lock: sha1:Q1OBNi0vWC3whwiqyR17FaFxLCU=
Bytes: 9208

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
> contradict verified facts.

No, it is not. A virifiable fact is that you have not proven what you clain.

-- 
Mikko