olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 4:40 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 10:50 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 10:16 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 9:58 AM, Ben Bacarisse wrote:
What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩? >>>>>>>>The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
It turns out you have ducked my question at least six times previously >>>>>>> /without/ counting any other people who has asked! This makes 7: >>>>>>>
I will quit dodging your dishonest dodge as soon as you acknowledge that >>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
Classic crank! You'll answer when I accept a garbled falsehood, an
obligation you are guaranteed to never have to meet!
Anyway, you've dodged the question 9 times now (8 was in another
thread). Here's you chance to go for ten times:
------------------------------------------------------------
What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
------------------------------------------------------------
Yes, we're up to ten dodges. Do you want to try for 11 or will just
ignore the post?
What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
This string encodes Ĥ that halts and ⟨Ĥ1⟩ ⟨Ĥ2⟩ that never halt.
What string?
Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
There are at least three strings mentioned on those two lines and even
then you don't claim that any of them encodes the halting computation of
Ĥ applied ⟨Ĥ⟩. So no answer here. That's 11 times you've avoided answering.
------------------------------------------------------------
What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩? ------------------------------------------------------------
It's not a hard question. In fact I am sure you know the answer. You
won't answer because you either have to say something silly, or admit
you are wrong.
Would you like me to explain again why this question matters so much?
On 9/4/21 3:47 PM, olcott wrote:
On 9/4/2021 2:11 PM, Richard Damon wrote:
On 9/4/21 2:42 PM, olcott wrote:
On 9/4/2021 1:11 PM, Richard Damon wrote:
On 9/4/21 1:44 PM, olcott wrote:
On 9/4/2021 12:27 PM, Richard Damon wrote:
On 9/4/21 1:05 PM, olcott wrote:
On 9/4/2021 11:42 AM, Richard Damon wrote:
On 9/4/21 12:26 PM, olcott wrote:
On 9/4/2021 10:57 AM, Richard Damon wrote:
On 9/3/21 8:25 PM, olcott wrote:
On 9/3/2021 7:07 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 4:40 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 10:50 AM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 10:16 AM, Ben Bacarisse wrote: >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
On 9/3/2021 9:58 AM, Ben Bacarisse wrote:
Classic crank! You'll answer when I accept a garbled >>>>>>>>>>>>>>>>> falsehood, anIt turns out you have ducked my question at least six >>>>>>>>>>>>>>>>>>> timesWhat string encodes the halting computation of Ĥ >>>>>>>>>>>>>>>>>>>>> applied
⟨Ĥ⟩?
The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts. >>>>>>>>>>>>>>>>>>>
previously
/without/ counting any other people who has asked! This >>>>>>>>>>>>>>>>>>> makes 7:
I will quit dodging your dishonest dodge as soon as you >>>>>>>>>>>>>>>>>> acknowledge that
The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts. >>>>>>>>>>>>>>>>>
obligation you are guaranteed to never have to meet! >>>>>>>>>>>>>>>>>
Anyway, you've dodged the question 9 times now (8 was in >>>>>>>>>>>>>>>>> another
thread). Here's you chance to go for ten times: >>>>>>>>>>>>>>>>>
------------------------------------------------------------ >>>>>>>>>>>>>>>>>
What string encodes the halting computation of Ĥ applied >>>>>>>>>>>>>>>>> ⟨Ĥ⟩?
------------------------------------------------------------ >>>>>>>>>>>>>>>>>
Yes, we're up to ten dodges. Do you want to try for 11 or >>>>>>>>>>>>>>> will
just
ignore the post?
What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
This string encodes Ĥ that halts and ⟨Ĥ1⟩ ⟨Ĥ2⟩ that never
halt.
What string?
Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt >>>>>>>>>>>>>There are at least three strings mentioned on those two >>>>>>>>>>>>> lines and
even
then you don't claim that any of them encodes the halting >>>>>>>>>>>>> computation of
Ĥ applied ⟨Ĥ⟩. So no answer here. That's 11 times you've
avoided
answering.
------------------------------------------------------------ >>>>>>>>>>>>> What string encodes the halting computation of Ĥ applied ⟨Ĥ⟩?
------------------------------------------------------------ >>>>>>>>>>>>>
It's not a hard question. In fact I am sure you know the >>>>>>>>>>>>> answer.
You
won't answer because you either have to say something silly, or >>>>>>>>>>>>> admit
you are wrong.
Would you like me to explain again why this question matters so >>>>>>>>>>>>> much?
A whole new way of making my point:
When the original Linz H defined to be a simulating halt decider >>>>>>>>>>>> according to this criteria:
In computability theory, the halting problem is the
problem of determining, from a description of an >>>>>>>>>>>> arbitrary
computer program and an input,
whether the simulation of this program must be >>>>>>>>>>>> aborted to
prevent it from running forever.
The above criteria is valid on the basis of the known
equivalence
between the direct execution of a computation and its simulation >>>>>>>>>>>> by a UTM. The same criteria universally works on all inputs >>>>>>>>>>>> allowing
their halting status to be correctly decided.
The Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ correctly transitions to H.qy
This is analogous to int main() { H1(P,P; } in section V3 >>>>>>>>>>>>
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
And you just have proven that H is not a computation as two >>>>>>>>>>> copies
of it
given the same input give different answers (From your V3). >>>>>>>>>>>
FAIL.
This can only be fully understood in terms of int main() { >>>>>>>>>> H1(P,P); }
where there are no details that must simply be imagined.
H1(P,P) is a pure function of its execution trace input.
H(P,P) is a pure function of its execution trace input.
The last remaining question that must be answered are the details >>>>>>>>>> of why
the execution trace inputs vary between H1 and H.
Since neither of these HAVE a execution trace as as input, you just >>>>>>>>> admitted that they are not Computation.
PERIOD.
F-
The simulator aspect of H/H1 has an input and the halt decider >>>>>>>> aspect of
H/H1 has an input derived from the simulation of this input.
It is clear that that halt decider aspect of H and H1 is a pure >>>>>>>> function
of this derived execution trace.
It is not clear what the simulation aspect is a pure function of. >>>>>>>>
The 'Halt Decider' as a total unit has only the machine and its
input as
its input.
EVERYTHING within the decider can only use these and the things it >>>>>>> can
derive from these.
If the 'Halt Decider Aspect' is getting an execution trace from the >>>>>>> 'Simulator Aspect' which is directly using those inputs, then the >>>>>>> execution trace will need to be a pure function of the provided
input,
so will be the same for the to cases.
The execution trace must be a pure function of something, this remains >>>>>> to be worked out. The halt deciding aspect is a pure function of its >>>>>> input execution trace.
The fact that you don't know is telling.
They way you analyze, your deciders are NOT a pure function of the
representation of the Machine and the Input, as the supposed same
algorithm gives different answers for the exact same input.
The halt decider <is> a pure function of its execution trace input.
The execution trace is a pure function of something.
But apparently not of the input.
The halt deciding aspect of H1/H is a pure function of its own input
which is the execution trace. It bases its halt status decision on
nothing besides this execution trace.
The execution trace derived by the simulating aspect of H/H1 is a pure
function of something. Its input(P,P) and
the relative placement of itself in the execution trace order?
H1(P,P) simulates P(P) that calls H(P,P)
creates a dependency relationship between H1 and H that does not exist
in reverse.
So, is H1 a different computation than H? As I said before, if H1 is a different compuation than H, then the fact that H1 gets the answer right doesn't matter as it is H that needs to get the right answer for H^
built on H.
If H1 IS the same computation to try to get around this, why does it
give a different answer? That isn't allowed for a real computation.
Ultimately, it seems that H isn't actually a Computation as its answer
seems to depend on more that its formal input but something about its position in the execution trace, which is NOT something specified as its formal input.
On 9/6/21 10:17 PM, olcott wrote:
On 9/6/2021 8:57 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 8:09 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 7:40 PM, Ben Bacarisse wrote:Identical TMs with identical inputs are computationally equivalent. We >>>>> know that
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 5:55 PM, Ben Bacarisse wrote:You tell me they are the same computation.
olcott <NoOne@NoWhere.com> writes:
On 9/6/2021 3:58 PM, Ben Bacarisse wrote:
olcott <NoOne@NoWhere.com> writes:
On 9/5/2021 6:14 PM, Ben Bacarisse wrote:knowing what Linz is saying about TMs.
olcott <NoOne@NoWhere.com> writes:
olcott <NoOne@NoWhere.com> writes:
... Ĥ includes an exact copy of H embedded at its state >>>>>>>>>>>>>>>>>> Ĥ.qx
You don't understand operating system process context >>>>>>>>>>>>>> switching.
Change the subject. Good plan!
I am not changing the subject. I am enumerating the key >>>>>>>>>>>> prerequisite
knowledge that you are lacking, to understand what I am saying. >>>>>>>>>>> Your claimed knowledge of process context switching is no >>>>>>>>>>> excuse for not
H^ contains an almost identical copy if H embedded in at the >>>>>>>>>>> state you
call H^.qx. Fortunately, the small differences don't prevent >>>>>>>>>>> you from
being wrong, so I will use your word and call it an "exact copy". >>>>>>>>>>> You have accepted that, when construed as an input to your H, >>>>>>>>>>> the string
<H^><H^> encodes a halting computation. If your H has any >>>>>>>>>>> pretensions
of being a halt decider, it should accept that string:
H.q0 <H^><H^> |- H.qy
I have already said that a bunch of times yet you did not notice >>>>>>>>>> because you diligently want to remain focused in disagreement >>>>>>>>>> mode.
I am happy you think you've said it lots of times. I could not >>>>>>>>> find any
but I also know not to bother asking you for references.
But you keep telling us that, in fact, the "exact copy" of H >>>>>>>>>>> embedded inLike I said (and this is beyond your technical competence) >>>>>>>>>> int main() { H1(P,P) }; is the precise analogy to H ⟨Ĥ⟩ ⟨Ĥ⟩.
H^ transitions to H^.qn when run with just <H^><H^> on the tape: >>>>>>>>>>>
H^.qx <H^><H^> |- H^.qn
An "exact copy" of H can't make an transitions that H can't >>>>>>>>>>> take, and in
fact pretty much everything you've said up until now confirms >>>>>>>>>>> that your
H in fact rejects the string <H^><H^>. All you effort has >>>>>>>>>>> been put to
explaining why the wrong answer is in fact the right one. >>>>>>>>>>
Ah, proof by analogy won't fly. This line
H^.qx <H^><H^> |- H^.qn
shows that your H is wrong. It's a simple as that.
Not at all distinctly different computations can have different >>>>>>>> results.
No I never ever said that.
I ALWAYS ALWAYS SAY THAT THEY ARE DISTINCTLY DIFFERENT COMPUTATONS. >>>>>
H^.qx <H^><H^> |- H^.qn
so the same TM (H), run with the same input (<H^><H^>), cannot
transition to the sate you say it should. One of your claims is wrong. >>>>> (I can't possibly know which, but they can't both be ture.)
TM at H^.qx is an "exact
copy" of H. How can two TMs that are exact copies of each other make >>>>>>> different transitions given the same input?
That H1 calls H means that H1 can see what H does.
The H is called by H1 means that H does not even know that H1 exists. >>>>> TMs don't call each other.
That H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ creates a master slave relationship >>>> between H and Ĥ.
The master can see exactly what the slave is doing.
The slave it totally unaware of the existence of the master.
The master can change its behavior on the basis of what the slave does. >>>>
The slave cannot change its behavior on the basis of what the master
does.
Thus the master slave relationship can and does cause an identical
function with the same input to have different behavior even if no one >>>> ever noticed this before.
Function? Have you been only pretending to be talking about Turing
machines the whole time? If you were not being deceitful, your H (the
TM) is wrong because
H.q0 <H^><H^> |- H.qn
No matter how much you ignore the fact that the master slave
relationship where H is the master of Ĥ causes different behavior:
H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Ĥ.qx simulates ⟨Ĥ⟩ ⟨Ĥ⟩
for two identical functions with the same input, this master slave
relationship still causes differing behavior.Just
Because H is simulating Ĥ it can see what H is doing and change its
behavior in a way that H cannot do.
If the theory of computation says that this cannot occur then the theory
of computation must be updated because it is occurring.
As I have said, just proves that H isn't a computation, and thus not qualified to be a decider.
On 07/09/2021 23:26, Ben Bacarisse wrote:> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
I made a post recently about how I think PO has implemented his emulation:
message-id: <hb2dnTNZFYoJW6v8nZ2dnUU78avNnZ2d@brightview.co.uk>
(around 01:55 UCT)
If correct, they are not calls, more like cooperative multithreading
or perhaps fibre switches combined with a single-step instruction for
x86utm.exe to switch back after just one instruction. Well, let's
just say that's not how I would have implemented it. (Or imagined
anyone else would do so...)
Yes, I saw that. It seems a reasonable guess and it fits with a sketch he once posted of how Halts works -- the famous Halts is correct because of what would happen if line 15 were commented out. A very clear explanation of his POOH problem.Well, not so clear if we try to define it for an arbitrary input (P,I)
I'd say. Probably we could make some arbitrary judgements to come up
with some mathematically rigorous definition, but I suspect it would be uninteresting. [The problem is going to be "how exactly should an
arbitrary program P, and arbitrary input data I be mapped to new inputs
P2, I2 as part of POOH? PO is rather keen on "definition by example"
which isn't actually what definitions are.]
I wonder how PO has managed to keep people speculating about his hidden code for so long. Realistically, the response should be "post it", repeated endlessly until he either gets board and goes away or he posts
it and we can finally see what he's doing wrong.
I think this isn't a Vulcan logic question, more of personal needs of
the posters - they /want/ PO to continue posting because they get
something from constantly responding. Which is fine, but it makes it nigh-on impossible to act together to force particular behaviours from
PO, like publishing his code.
And is PO's code important? Surely we know PO's mistakes without seeing
his code. Seeing the code wouldn't make any difference in explaining
his mistakes to him - I imagine his code at least does what /he/ thinks
it ought to do, and everyone has explained to him over and over where
the problems are with that. I think all we'd get from actually seeing
the code is:
a) confirmation that PO can write C code, but he's not a good
programmer, and he's a worse systems architect/designer
b) we'd see /exactly/ how his tracing is implemented, and tell him
"why did you do it that way - that's rubbish, and makes
your decider a non-computation (or not...)" but no
big deal. (And we already know roughly how it's done.)
c) confirm that there are all sorts of simple programs for which
his code gets the wrong answer - or more likely loops without
ever deciding - with no prospect of it being a more general
halt decider. But it only has to deal with
one specific scenario - the H_Hat(H_Hat) computation, so
that's not a big deal.
d) someone could code up "proper" test cases and traces, except
that now that PO has admitted that main() calling
H_Hat(H_Hat) /does/ halt, that will no longer advance anything.
(But people may enjoy fiddling with the code for fun anyway.)
I feel that by now I could write something almost exactly equivalent to
PO's efforts if I had to, and I expect that if PO published his code I
would be completely unsurprised by what I saw! So it wouldn't be one of
my goals to work at persuading PO to publish the code, although I would
be curious enough to look at it and maybe play a bit.
Mike.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 82:25:14 |
| Calls: | 6,658 |
| Calls today: | 4 |
| Files: | 12,203 |
| Messages: | 5,333,433 |
| Posted today: | 1 |