Sujet : Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2
De : news.dead.person.stones (at) *nospam* darjeeling.plus.com (Mike Terry)
Groupes : comp.theoryDate : 25. Jul 2024, 04:29:02
Autres entêtes
Message-ID : <2eecnR6fa9XiWzz7nZ2dnZfqn_ednZ2d@brightview.co.uk>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.17
On 23/07/2024 14:31, olcott wrote:
On 7/23/2024 1:32 AM, 0 wrote:
On 2024-07-22 13:46:21 +0000, olcott said:
>
On 7/22/2024 2:57 AM, Mikko wrote:
On 2024-07-21 13:34:40 +0000, olcott said:
>
On 7/21/2024 4:34 AM, Mikko wrote:
On 2024-07-20 13:11:03 +0000, olcott said:
>
On 7/20/2024 3:21 AM, Mikko wrote:
On 2024-07-19 14:08:24 +0000, olcott said:
>
When we use your incorrect reasoning we would conclude
that Infinite_Loop() is not an infinite loop because it
only repeats until aborted and is aborted.
>
You and your HHH can reason or at least conclude correctly about
Infinite_Loop but not about DDD. Possibly because it prefers to
say "no", which is correct about Infinte_loop but not about DDD.
>
>
*Because this is true I don't understand how you are not simply lying*
int main
{
DDD();
}
>
Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.
>
You are the lying one.
>
If HHH(DDD) abrots its simulation and returns true it is correct as a
halt decider for DDD really halts.
>
>
(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within.
>
No, we don't. There is no such prohibition.
>
>
Turing machines never take actual Turing machines as inputs.
They only take finite strings as inputs and an actual executing
Turing machine is not itself a finite string.
>
The definition of a Turing machine does not say that a Turing machine
is not a finite string. It is an abstract mathematical object without
a specification of its exact nature. It could be a set or a finite
string. Its exact nature is not relevant to the theory of computation,
which only cares about certain properties of Turing machines.
>
Therefore It is not allowed to report on its own behavior.
>
Anyway, that does not follow. The theory of Turing machines does not
prohibit anything.
>
Another different TM can take the TM description of this
machine and thus accurately report on its actual behavior.
>
If a Turing machine can take a description of a TM as its input
or as a part of its input it can also take its own description.
Every Turing machine can be given its own description as input
but a Turing machine may interprete it as something else.
>
In this case we have two x86utm machines that are identical
except that DDD calls HHH and DDD does not call HHH1.
It is empirically proven that this changes their behavior
and the behavior of DDD.
You say a lot about things that are "empirically proven" and without exception they are never "proven" at all.
You previously claimed that H and H1 behaviours were different as evidence that "copies of routines" don't necessarily produce the same behaviour as the original routine, due to magical pathelogical relationships. But if the copies are done properly of course they will produce the same behaviour, because the x86 language is deterministic. I'm assuming you're not just cheating and using the mutable global data trick! or similar...
So what had you messed up with H/H1? H and H1 internally both used their /own/ addresses for comparisons with simulated code addresses. So they are not copies of each other - if they were, H1 would have used H's address (effectively this address is like a const global variable, and both H/H1 need to use the same one if they are claimed to use the same algorithm).
If you had implemented the copy correctly, BOTH H AND H1 WOULD CALCULATE THE SAME BEHAVIOUR for (D,D) input (or any other input). So this turned out to be just a case of naff programming on your part - nothing "magical" about pathelogical relationships between H/D which aren't present for H1/D; just naff coding. [H1 using a different algorithm meant it never matched H's abort decision, so effectively reverted to UTM behaviour that simulated (D,D) to completion, including the final return.]
Now you're claiming the same for HHH/HHH1 ? What duffer coding errors have you made this time?
Seriously - if the code of HHH and HHH1 is supposedly the same (and no cheap cheats such as mutable global/static cheats, and so on) THEN WHY WOULD THE BEHAVIOUR OF HHH and HHH1 differ when evaluating an input? *What have you messed up this time?*
It's your code so you should be the one to explain anomalies like this at the coding level. Why /exactly/ does HHH1 produce a different result to HHH? Also you might state more clearly what the different behaviour is, e.g. "HHH reports DDD() never halts, while HHH1 reports that it halts" or whatever.
Regards,
Mike.