Re: This function proves that only the outermost HHH examines the execution trace

Liste des GroupesRevenir à theory 
Sujet : Re: This function proves that only the outermost HHH examines the execution trace
De : F.Zwarts (at) *nospam* HetNet.nl (Fred. Zwarts)
Groupes : comp.theory
Date : 28. Jul 2024, 21:09:33
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v8651e$2409$2@dont-email.me>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla Thunderbird
Op 28.jul.2024 om 16:11 schreef olcott:
On 7/28/2024 2:50 AM, Fred. Zwarts wrote:
Op 27.jul.2024 om 22:05 schreef olcott:
On 7/27/2024 2:55 PM, Fred. Zwarts wrote:
Op 27.jul.2024 om 21:27 schreef olcott:
On 7/27/2024 1:50 PM, Fred. Zwarts wrote:
Op 26.jul.2024 om 22:14 schreef olcott:
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.
>
>
Mike Terry is right that a simulator has access to the internal state of the simulated machine, but he did not say that it is correct to *change in this way* the state of the simulated machine.
Changing the state of the simulated machine is cheating.
>
I know this and agree with him on this.
>
Of course a simulator can modify the input before of during the simulation.
>
No that is cheating too.
>
That is exactly what you do when you change the value of the variable 'Root'. 'Root' is a hidden input for HHH.
>
If you had sufficient understanding of the x86 language
you would know that DDD is correctly emulated by HHH.
>
If you understood only a little bit of x86, you would know that changing the value of a variable (like Root), will modify the behaviour of a program, making a cheating simulator.
>
 I have been programming in the x86 language since it was new.
 I commented the whole block of code out that does the abort
so that HHH is just a simulator and not a termination analyzer
and it just keeps on running until the instruction limited of
50,000,000 instructions have been emulated. Every recursive
emulation take about 100-fold more steps than the prior one.
But by changing HHH, you also change the input to HHH. Of course, if a non-aborting HHH is simulating *itself*, it will never end.
But that is very different from an aborting HHH that simulates *itself*. Then the input is an aborting HHH, which does not need to be aborted.
Is it so difficult for you to understand that if you change HHH, then also the input for HHH is changed?
HHH cannot possibly simulate itself correctly, whether or not it aborts.
 > ...

That the halt status decision is proven to be correct
on the basis that its behavior pattern exactly matches
this infinite recursion behavior pattern is proven.
>
void Infinite_Recursion()
{
   Infinite_Recursion();
}
>
_Infinite_Recursion()
[0000215a] 55         push ebp
[0000215b] 8bec       mov ebp,esp
[0000215d] e8f8ffffff call 0000215a ; recursive call
[00002162] 5d         pop ebp
[00002163] c3         ret
Size in bytes:(0010) [00002163]
>
Begin Local Halt Decider Simulation   Execution Trace Stored at:113934
[0000215a][00113924][00113928] 55         push ebp
[0000215b][00113924][00113928] 8bec       mov ebp,esp
[0000215d][00113920][00002162] e8f8ffffff call 0000215a
[0000215a][0011391c][00113924] 55         push ebp
[0000215b][0011391c][00113924] 8bec       mov ebp,esp
[0000215d][00113918][00002162] e8f8ffffff call 0000215a
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
Proof by example fails.
>
That the simulation is incorrect is because HHH (and apparently its programmer) think that a two level recursion is an infinite recursion.
HHH is simply unable to decide about comparable finite recursions.
>
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}
>
It decides after N recursions that there is an infinite recursion, which is incorrect.
>
 HHH(Infinite_Recursion) sees the non-halting pattern below.
This *is* the exact same pattern that HHH(DDD) sees.
 void Infinite_Recursion()
{
   Infinite_Recursion();
}
No, for the aborting HHH, which aborts and halts after N recursions, the pattern is more like:
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
}
It is so difficult for you to understand that if HHH is simulating *itself* (an aborting and halting HHH),then there are conditional branches in each recursion, namely those in HHH?

Date Sujet#  Auteur
10 Nov 24 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal