On 9/3/2021 6:47 AM, Malcolm McLean wrote:
> On Friday, 3 September 2021 at 11:32:41 UTC+1, richar...@gmail.com wrote:
>> On 9/3/21 12:09 AM, olcott wrote:
>>> On 9/2/2021 10:52 PM, Richard Damon wrote:
>>>> On 9/2/21 11:18 PM, olcott wrote:
>>>>> On 9/2/2021 10:09 PM, Richard Damon wrote:
>>>>>> On 9/2/21 10:55 PM, olcott wrote:
>>>>>>> On 9/2/2021 9:42 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 9/2/2021 8:29 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 9/2/2021 8:05 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/2/2021 7:27 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> Anyone that understands what I am saying can tell that their
>>>>>>>>>>>>>>> have been
>>>>>>>>>>>>>>> zero actual rebuttals.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is that an empty set? Does anyone in the world understand and
>>>>>>>>>>>>>> agree
>>>>>>>>>>>>>> with you? Someone at the grocery store maybe?
>>>>>>>>>>>> Well? Does anyone in the world understand and agree with you?
>>>>>>>>>>>> Will you
>>>>>>>>>>>> avoid every question put to you?
>>>>>>>>>>>>
>>>>>>>>>>>>> None of the rebuttals ever directly addressed any of the points
>>>>>>>>>>>>> that I
>>>>>>>>>>>>> made. They always changed the subject to another different
>>>>>>>>>>>>> unrelated
>>>>>>>>>>>>> point.
>>>>>>>>>>>> Flat-out lie. You made this point crucial point on 12th Aug:
>>>>>>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting
>>>>>>>>>>>> computation."
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ1⟩ // You pay attention to this
>>>>>>>>>>> Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ // You utterly ignore this
>>>>>>>>>>
>>>>>>>>>> Liar. I have addressed this on many occasions. Here, yet
>>>>>>>>>> again, is
>>>>>>>>>> what I have to say about it. You show us that Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊦
>>>>>>>>>> Ĥ.qn
>>>>>>>>>> and
>>>>>>>>>> since ⟨Ĥ1⟩ = ⟨Ĥ2⟩ = ⟨Ĥ⟩ we see that H (embedded as it is at Ĥ.qx)
>>>>>>>>>> rejects the string ⟨Ĥ⟩ ⟨Ĥ⟩. How you think I knew that? I don't
>>>>>>>>>> make
>>>>>>>>>> this stuff up, you do.
>>>>>>>>>
>>>>>>>>> The simple fact that you ignore is that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>>>>>> never halts unless Ĥ.qx aborts its simulation of this input.
>>>>>>>>> You have dodged this EVER SINCE 2017-03-11 (4.5 years ago)
>>>>>>>>
>>>>>>>> Liar. Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ transitions to Ĥ.qn.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> When I say that I have a brown dog is it not a
>>>>>>> rebuttal to say that I don't have a white cat.
>>>>>>>
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>> The input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.
>>>>>>>
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>> You have been dishonestly denying this for 4.5 years.
>>>>>>>
>>>>>>
>>>>>> INPUTS DON'T HALT,
>>>>>>
>>>>>
>>>>> Any input that never halts unless its simulation is aborted is an input
>>>>> that never halts.
>>>>>
>>>>
>>>> Bad Terminology. Inputs themselves don't halt. They only represent
>>>> computations that might be halting or not.
>>>>
>>>
>>> In computability theory, the halting problem is the
>>> problem of determining, from a description of an arbitrary
>>> computer program and an input, whether the program will
>>> finish running, or continue to run forever.
>>> https://en.wikipedia.org/wiki/Halting_problem
>> Right. Note, it says whether 'The Program' not 'The Input' will halt or
>> not.
>>
>> Programs will Halt, not inputs. Inputs are just the desciption used to
>> specify the program.
>>
> There seems to be some sort of claim that whilest H_Hat<H_Hat> is
> halting, the string pair <H_Hat><H_Hat> (angle brackets represent tape
> contents) is non-halting. I really can't get to the bottom of what exactly is
> being claimed here.

The H(P,P) C/x86 code makes a perfect and complete analogy to the
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ Turing machine code. If you don't understand the x86
language well enough you won't be able to ever understand what I am saying.

All of the actual Turing Machine base proofs must leave out almost all
of the details because their programs would hundreds of thousands of
pages. A TM with random access memory would be far less of a nightmare
to deal with.

>>>
>>> To bypass the pathology of pathological inputs:
>> FAIL. You don't get to change the definition because you don't like the
>> problems it creates.
>>
> You can't "solve the halting problem". You can maybe propose a set which has
> some relationship to the halting / non-halting sets of Turing machines, and
> has interesting properties. That's not really a FAIL, unless you set yourself the
> insane goal of "solving the halting problem".
> Trying to define a set of "pathological inputs" isn't an example of something
> which is original, however,, and it's well known to be a dead end.

In computability theory, the halting problem is the
problem of determining, from a description of an arbitrary
computer program and an input, whether the program will
finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem

To bypass the pathology of pathological inputs:
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.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein