On 05/09/2021 22:36, Richard Damon wrote:
On 9/5/21 4:13 PM, olcott wrote:
On 9/5/2021 3:02 PM, Malcolm McLean wrote:
On Sunday, 5 September 2021 at 04:55:50 UTC+1, olcott wrote:
On 9/4/2021 6:25 PM, Malcolm McLean wrote:So all Ps are identical, and H and H1 have identical code, but
On Saturday, 4 September 2021 at 23:54:50 UTC+1, olcott wrote:void P(u32 x)
On 9/4/2021 5:41 PM, Richard Damon wrote:H and H1 are different machines? Or is H1 the same machine as H but >>>>>> run under a simulating halt decider?
None-the-less I just refuted Rice's theorem.You may want to call it that, but it is still a LEGAL input, that H >>>>>>>> needs to get right and be a Computation for.
When int main() { H1(P,P); } returns a different value than
int main() { H(P,P); } we know that (P,P) is a pathological input. >>>>>>>>
{
if (H(x, x))
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
H1 is identical to H.
H1 simulates P(P) that calls H(P,P)
H simulates P(P) that calls H(P,P)
This creates a dependency relationship between H1 and H that does not >>>>> exist in reverse.
Either way, the idea is that we have two machines / set ups and we >>>>>> runint main()
the input <P><P> on both. If the results coincide, then obviously
that
is the halting status of P<P>. If they differ, then we've identified >>>>>> "pathological input". That is an "interesting characteristic" of a >>>>>> Turing
machine so Rice's theorem falls.
Nice try. Unfortunately it's not so easy.
{
Output("Input_Halts = ", H((u32)P, (u32)P));
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
Input_Halts = 0
Input_Halts = 1
different
names and different machine addresses.
We know that H/H1 looks for address on the call stack to detect runaway >>>> recursion. The best explanation I can think of for these results is
that H/H1
uses its own address as the initial call to examine. Therefore
behaviour can
diverge.
Am I correct?
The most that I boiled it down to so far is the master slave
relationship between H1 and H.
The master UTM / halt decider H1 can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) H returns to P
(d) P returns to main() where it was simulated by H1.
The master UTM / halt decider H can see everything that it simulates:
(a) P begins
(b) P calls H(P,P)
(c) P begins
(e) P calls H(P,P)
Then H(P,P) aborts its simulation of its input.
Neither P nor H can see H1 at all.
But since both are looking at the Machine P(P), why do they see
different execution traces.
I'd guess:
- when H1 is the halt decider, trace entries for H1 are hidden, but
trace entries within H are visible. So the trace shows all sorts of conditional branches etc. in H and so H1 correctly doesn't decide
"infinite recursion".
- when H is the halt decider, trace entries for H are hidden. So the trace doesn't show all the conditional branches, causing PO's "infinite recursion" test to match, and so H incorrectly decides "non halting", aborting the emulation earlier than in the previous H1 scenario.
If so, it's kind of funny that the H1 scenario is what you and everybody
else have been telling PO for a year - if the emulation P(P) IS ALLOWED
TO CONTINUE NATURALLY, IT TERMINATES.
Well, that's just a guess. You'd think PO would /know/ the answer, as
it's his code! But his wording above "..The most that I boiled it down
to so far is..." suggests he's still trying to figure it out!
Mike.
That means that P isn't a computation, and due to how it is built, that
means that H has to not be a computation, since P doesn't do anything
outside of its copy of H to make it not a Computation.
If H isn't a Computation, it isn't qualifited to be a Decider.
You just proved that YOU FAIL.
olcott <NoOne@NoWhere.com> writes:
The master slave relationship can and does cause an identical function
with the same input:
(a) H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(b) Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
to have different behavior even if no one ever noticed this before.
This notation refers to Turing machines and, for Turing machines, you
are wrong. The same state transition function can't produce different transitions when presented with the same input.
olcott <NoOne@NoWhere.com> writes:
On 9/7/2021 5:10 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
The master slave relationship can and does cause an identical function >>>> with the same input:
(a) H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(b) Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
to have different behavior even if no one ever noticed this before.
This notation refers to Turing machines and, for Turing machines, you
are wrong. The same state transition function can't produce different
transitions when presented with the same input.
When H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it can see that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qn
When Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩ it cannot see any of its slaves ever >> transition to any final state.
If conventional computer science makes sure to ignore this it errs.
You tell us the TM at H^.qx is an exact copy of H. Identical state transition functions generate identical machine configurations when
presented with the same strings on the tape. H <H^><H^> and H^.qx
<H^><H^> must both exhibit the same behaviour. If you continue to
ignore this, you err.
I find this particular sub-thread very odd because for months you've
been trying to make the case that, for your secret C code, the wrong
answer is the right one. You don't /need/ a top-level call of H(H_Hat, H_Hat) to behave differently to the call to H embedded in H_Hat because
you have declared H(H_Hat, H_Hat) == false to be the right answer.
Why not make the same declaration for TMs? Just declare that H should
reject <H^><H^> and then the fact the "exact copy" of H embedded in H^ transitions to the rejecting state would not be an issue. Do you think
it's harder to make the case for the wrong answer when talking about
TMs?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 427 |
Nodes: | 16 (3 / 13) |
Uptime: | 34:21:42 |
Calls: | 9,029 |
Calls today: | 12 |
Files: | 13,384 |
Messages: | 6,008,751 |