On 5/4/2022 7:59 PM, Ben wrote:
> olcott <polcott2@gmail.com> writes:
>
>> On 5/4/2022 9:16 AM, Ben wrote:
>>> olcott <polcott2@gmail.com> writes:
>>>
>>>> On 5/2/2022 6:10 PM, Ben wrote:
>>>>> olcott <polcott2@gmail.com> writes:
>>>>>
>>>>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>>>>> olcott <polcott2@gmail.com> writes:
>>>>>>>
>>>>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>>>>> simulation to H.
>>>>>>> What two pointers must be passed to H for H to tell up about the halting
>>>>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>>>>> and that P(P) halts.
>>>>>>
>>>>>> If H can report on the halting of non-input P(P) then it is not a
>>>>>> decider because deciders only compute the mapping from inputs to final
>>>>>> states.
>>>>> TM deciders compute mappings from inputs to final states /according to
>>>>> some property of the inputs/
>>>>
>>>> That par is exactly correct.
>>>>
>>>>> -- whether the input represents, for
>>>>
>>>> That part has been the key error of everyone in that they all believe
>>>> that is can represent something other than what it actually specifies.
>>>
>>> So now, after thinking otherwise for years, you claim that there is no
>>> way to even specify the computation P(P) for you pseudo-C halt decider
>>> H. At least that is a clear admission that the halting of function
>>> calls like P(P) can not be decided because, apparently, passing P and P
>>> to H does not specify that computation, and you can't say what two
>>> arguments /would/ specify it.
>>>
>>> A clear and unambiguous statement that no D such that D(X,Y) == true if
>>> and only if X(Y) halts and false otherwise is possible would be the
>>> honest way to move things on. If you were clear about this, maybe
>>> someone will talk to you about [whatever] it is that your H is
>>> deciding.
>
> So you won't admit that no algorithm can do what D is specified to do?
> You are just going to pretend that no one cares about actual halting.
>
> I hope you see that by ignoring this point you are confirming that you
> know D can't exist. If you thought such a D was possible, you'd be
> shouting that from the roof tops since it's what everyone else says is
> impossible.
>
>> I adapted my system so that I could empirically test this:
>> H1(P,P)==true is empirically proven to be correct
>> H(P,P)==false is empirically proven to be correct
>
> But neither can tell us squat about the halting of P(P) -- the thing
> that H was originally supposed to decide.
>

Are you simply wired to ignore my words so that you can disagree with
everything that I say?

H1(P,P)==true reports on the behavior of P(P).

>> Both deciders correctly report on the actual behavior of their actual
>> input. This can be verified by carefully studying their execution
>> trace.
>
> But neither can tell us what we want.

H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).

> Your H does not meet D's
> specification, but you are not brave enough to admit that you now know
> that D can't exist because denying that is what got you started down
> this rabbit hole 18 years ago.
>
>
>>
>>>>> example, an even number, a prime number or a halting computation.
>>>>> According to you there is no "input" (in reality a pair of pointers)
>>>>> that represents the halting computation P(P). Why should anyone care
>>>>> about this H if it does not decide what we want -- the halting of the
>>>>> function call represented by the two arguments to H? Whatever H is
>>>>> actually deciding is not interesting.
>>>>
>>>> (a) H does correctly decide its input
>>> But no one cares about that as it's not what we want a decider for.
>>>
>>>> (b) H is only required to decide its input.
>>> And it seems that you agree that no D such that D(X,Y) == true if and
>>> only if X(Y) halts and false otherwise is possible. That's the D that
>>> the world cares about.
>>>
>>>> (c) Therefore H(P,P) is entirely correct on the "impossible" input.
>>> It decides some property of the pair of pointers P and P, but not the
>>> one people care about: the halting or otherwise of the function call
>>> P(P).
>>>
>>>>> Also, I wonder why you wasted so much time justifying the fact that
>>>>> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
>>>>> even supposed to be deciding the halting P(P). Well, we know, of
>>>>> course. You realised you were in a hole so you started to dig sideways.
>>>>> You used to know that H(X,Y) had to decide the halting of X(Y). You're
>>>>> now pretending it never did!
>>> Why /did/ you waste so much time trying to convince us that H(P,P) ==
>>> false was correct even though P(P) halted if you never intended H(P,P)
>>> to report on the halting of P(P)?
>>>
>>>>> You'd know this if you'd done even the warm-up exercises I set.
>>> <snip the usual waffle>
>>>
>>>>> How are they coming along? It looks like you have found an excuse to
>>>>> bail out again:
>>>>
>>>> It is coming along great and it is wonderful fun.
>>> It's good that it's fun, but it seems to be taking a long time. I'd
>>> expect students to be able to write E and specify P "live" in a tutorial
>>> -- i.e. it would take a couple of minutes and we could the discuss more
>>> interesting examples.
>>
>> I have had some serious health issues that could have killed me last
>> week.
>
> You have been able to write dozens of posts, so why not the few words
> needed to specify P, or the few states needed for E? And even now
> you've taken on a task that seems too much for you rather than get down
> to writing and specifying a TM. It looks like avoidance.
>
>>> The specification of TM's is your stumbling block, so you could be doing
>>> that in parallel.
>>
>> I like to go through all of the best steps in order. Having a machine
>> to execute TM's is the first step.
>
> The firsts step is to be able to specify a TM. You can't have anything
> to execute of you can't specify it. It's just avoidance.
>

I am a concrete thinker, abstractions are always far too vague.

>> (a) Deciding to get around to start this project took weeks when
>> dealing with my other issues.
>
> You decided to start weeks ago. Then you gave up.
I am dead set on finishing it now.

>
>> (b) No setting up the tedious syntax of reading a file of text lines
>> took much longer than usual, I usually cut-and-paste.
>
> What? I thought you knew C++ and could write code.
>

On this tedious syntax details I always cut-and-paste from working code.
I hate tedious syntax details. Engineering algorithms is what I enjoy.

>> (c) I studied enough of the
>> http://www.lns.mit.edu/~dsw/turing/turing.html
>> To realize it was a superb architecture yet an overly complex
>> implementation.
>
> I hate it, but you chose it /five years ago/. Five years ago I
> suggested a simple exercise and you bailed them. I'd forgotten that. I
> should learn, shouldn't I?
>

I don't hate it, it does have a superb architecture that I will quickly
implement. I don't want to have to always enter the tape initialization
manually and want this in the machine description file.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer