Deutsch   English   Français   Italiano  
<v4i41a$30e5b$1@dont-email.me>

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

Path: ...!3.eu.feeder.erje.net!feeder.erje.net!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,sci.logic
Subject: Re: D correctly simulated by H proved for THREE YEARS --- rewritten
Date: Fri, 14 Jun 2024 21:00:57 +0200
Organization: A noiseless patient Spider
Lines: 152
Message-ID: <v4i41a$30e5b$1@dont-email.me>
References: <v428vv$2no74$2@dont-email.me> <v43ib7$38hnd$1@dont-email.me>
 <v4628o$6ero$1@dont-email.me> <v468qt$7uvj$1@dont-email.me>
 <v47joj$je45$1@dont-email.me> <v47kt3$jhs8$1@dont-email.me>
 <v47l92$je45$2@dont-email.me> <v48tt4$tqad$1@dont-email.me>
 <v4a07r$157ic$1@dont-email.me> <v4beis$1h0p6$1@dont-email.me>
 <v4cceu$1mi5i$2@dont-email.me> <v4corm$1p0h0$1@dont-email.me>
 <v4cp5s$1pe0q$1@dont-email.me> <v4cs0b$1p0h1$1@dont-email.me>
 <v4csdq$1q0a8$1@dont-email.me> <v4ctuq$1p0h1$2@dont-email.me>
 <v4cuc6$1qedu$1@dont-email.me> <v4e9qm$25ks0$1@dont-email.me>
 <v4epji$28g4v$2@dont-email.me> <v4fhj3$2dce5$1@dont-email.me>
 <v4fi0m$2dvk4$1@dont-email.me> <v4h4ag$2q9hc$1@dont-email.me>
 <v4he7s$2sdqr$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Jun 2024 21:00:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c33fd6fcd22a4d618b237757ed897b89";
	logging-data="3160235"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+0NlMFOPY2AMnzAzPCbX53"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AM83G8Uz/uKsMkH22uf1M/Bfb/A=
Content-Language: en-GB
In-Reply-To: <v4he7s$2sdqr$4@dont-email.me>
Bytes: 8163

Op 14.jun.2024 om 14:49 schreef olcott:
> On 6/14/2024 4:59 AM, Fred. Zwarts wrote:
>> Op 13.jun.2024 om 21:41 schreef olcott:
>>> On 6/13/2024 2:33 PM, Fred. Zwarts wrote:
>>>> Op 13.jun.2024 om 14:44 schreef olcott:
>>>>> On 6/13/2024 3:15 AM, Fred. Zwarts wrote:
>>>>>> Op 12.jun.2024 om 21:53 schreef olcott:
>>>>>>> On 6/12/2024 2:46 PM, Fred. Zwarts wrote:
>>>>>>>> Op 12.jun.2024 om 21:20 schreef olcott:
>>>>>>>>>
>>>>>>>>> On 5/29/2021 2:26 PM, olcott wrote:
>>>>>>>>> https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ
>>>>>>>>>
>>>>>>>>> If that was true then you could provide every step of D correctly
>>>>>>>>> simulated by H such that D simulated by H reaches its own 
>>>>>>>>> simulated
>>>>>>>>> "ret" instruction.
>>>>>>>>
>>>>>>>> I said that each H is unable to hit its target, so how could it 
>>>>>>>> reach the "ret" instruction of D? Please, think before you reply.
>>>>>>>
>>>>>>> It is a binary choice either D correctly simulated by H can
>>>>>>> possibly terminate normally by reaching its "ret" instruction
>>>>>>> or not. Your attempt to twist these words to make it look like
>>>>>>> there is more than these two possibilities is either ignorant
>>>>>>> or deceptive.
>>>>>>>
>>>>>>
>>>>>> Please, take some more attention to what I said. Read, then think, 
>>>>>> before you reply.
>>>>>> I said that H is not able to reach its own "ret" when it is 
>>>>>> simulating itself. 
>>>>>
>>>>> That has always been totally irrelevant.
>>>>
>>>> So, you think that if H does not reach its "ret", D can still reach 
>>>> its "ret"?
>>>> Try to think. D does not reach its "ret", *because* "H" does not 
>>>> reach its "ret".
>>>>
>>>>>
>>>>>> So, no disagreement with that. That proves that H misses its 
>>>>>> target. The abort is too early. The target is just some steps 
>>>>>> further. It does not mean that the target is at infinity.
>>>>>>
>>>>>
>>>>> The outer H always has one more execution trace to base its halt
>>>>> status decision on than any of the nested emulations. This means
>>>>> that unless the outer H aborts its simulation then none of them do.
>>>>
>>>> That is true. But it also means that H aborts one execution trace 
>>>> too early. 
>>>
>>> No it never meant this. 
>>
>> Yes, it does mean this. Using another simulator 
> 
> Has a different sequence of configurations thus is not
> a valid counter-example.
> 
>> shows that even the simulated H reaches its "ret". 
> 
> I ran the actual code to verify the facts.
> HH1(DD,DD) does not have a pathological relationship to its input
> thus this input terminates normally.

Your terminology is confusing. What you call a "pathological 
relationship" is that H must simulate itself.

> 
> HH(DD,DD) does have a pathological relationship to its input
> thus this input CANNOT POSSIBLY terminate normally.

Yes, indeed! Well done! The input of HH(DD,DD) is aborted too early, 
because HH cannot possibly simulate itself up to its final state. That 
means that its simulation cannot terminate normally.

> 
>> It is only that H simulated by itself is aborted too early. Is that so 
>> difficult to understand for you?
>>
> Aborted too early is false.
> Unless HH(DD,DD) aborts pretty soon HH and DD crash due to
> out-of-memory error.
> 
>>> If H waits for some other H to abort their
>>> simulation then H waits forever.
>>
>> There is no other H. 
> 
> Clearly you hardly understand anything that I have been saying.
> (a) HH(DD,DD) directly executed in main simulates its input.
> (b) The simulated DD calls a simulated HH(DD,DD) that
> (c) simulates another instance of DD... goto (b)
I understand that very well, a, b, c explain why HH is not able to 
simulate itself up to the end. You are proving my claims.

Another way of saying the same thing is:
1) HH starts simulating DD
2) the simulated DD calls HH
3) The simulated HH ... goes 1.

Both ways of saying show that DD and HH keep creating new instances of 
each other. If HH would halt, DD would halt too. But HH does not halt, 
even though that is a requirement. The reason is that HH is unable to 
simulate itself up to its final state. That is a limitation of a 
simulator: it cannot simulate itself up to the end.

> HH aborts as soon as it can after seeing DD repeat all of
> itself states exactly once. If HH waited for fifteen cycles
> (and did not run out of memory) it would still see one
> more cycle than the next inner HH.

It does not matter whether HH waits one cycle or fifteen cycles.
The first HH needs two cycles and the second HH needs 16 cycles to see 
the end of its simulated input.
The invariant is, there is always a finite recursion only one cycle away 
from the abort and not at infinity. The abort is always one cycle too early.

> 
> Either the outermost HH aborts or none of them do.

Yes, that is exactly the problem. Well done! HH is unable to reach the 
abort of the inner HH, even if it is only one cycle further. You are 
proving what I said, that HH is unable to simulate itself.
The invariant is: there is always a finite recursion only one cycle away 
from the abort and not at infinity. The abort is always one cycle too early.

> 
>> This H aborts too early. This H does not wait, so it does not help to 
>> dream of another H that waits. H does what it is programmed to do and 
>> aborts too early, because that is the fundamental problem of a 
>> simulator simulating itself. It will never see its final simulated state.
>>
>>>  H is always at least one execution
>>> trace ahead of every other H.
>>
>> Exactly! That is the reason why the abort one execution trace too 
>> early. It seems you start to see it. H will never see that it is only 
>> some steps from the final state of its simulation, because it aborts 
>> before it can see that.
>> That does not mean that there is an infinitely repeated recursion, but 
>> that the recursion is only repeated one time more than can be 
>> simulated by H. That is the fundamental problem of a simulator 
>> simulating itself.
>>
>> You can try to simulate longer, but that does not help. The simulation 
>> invariant is that the abort is always one execution trace too early. 
>> The other invariant is that in an aborting simulator there is never an 
>> infinitely repeated recursion.
>