On 1/15/22 3:37 PM, olcott wrote:
> On 1/15/2022 2:31 PM, Richard Damon wrote:
>> On 1/15/22 3:02 PM, olcott wrote:
>>> On 1/15/2022 1:23 PM, Richard Damon wrote:
>>>> On 1/15/22 12:44 PM, olcott wrote:
>>>>> On 1/15/2022 11:22 AM, Richard Damon wrote:
>>>>>> On 1/15/22 11:37 AM, olcott wrote:
>>>>>>> On 1/15/2022 9:54 AM, Richard Damon wrote:
>>>>>>>> On 1/15/22 9:33 AM, olcott wrote:
>>>>>>>>> On 1/15/2022 5:06 AM, Richard Damon wrote:
>>>>>>>>>> On 1/14/22 11:51 PM, olcott wrote:
>>>>>>>>>>> On 1/14/2022 10:34 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/14/22 11:26 PM, olcott wrote:
>>>>>>>>>>>>> On 1/14/2022 10:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/14/22 10:44 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/14/2022 9:31 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/14/22 10:21 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/14/2022 8:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 1/14/22 1:49 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/14/2022 12:11 PM, Alex C wrote:
>>>>>>>>>>>>>>>>>>>> On Friday, January 14, 2022 at 5:59:13 PM UTC+1,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 1/14/2022 10:36 AM, Alex C wrote:
>>>>>>>>>>>>>>>>>>>>>> On Thursday, January 13, 2022 at 9:34:08 PM UTC+1,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> It is the case that the copy of H (called
>>>>>>>>>>>>>>>>>>>>>>> embedded_H) at Ĥ.qx must abort
>>>>>>>>>>>>>>>>>>>>>>> the simulation of its input or Ĥ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>>>>>>>> would never stop running.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A simulating halt decider simulates N steps of
>>>>>>>>>>>>>>>>>>>>>>> its input until its input
>>>>>>>>>>>>>>>>>>>>>>> halts on its own or it correctly determines that
>>>>>>>>>>>>>>>>>>>>>>> a pure simulation of
>>>>>>>>>>>>>>>>>>>>>>> its input would never stop running.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_315-320.pdf
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal
>>>>>>>>>>>>>>>>>>>>>>> Languages and Automata.
>>>>>>>>>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>>>>>>>>>>>>>>>>>>> (315-320)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Copyright 2021 Pete Olcott
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see.
>>>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> A Turing machine applied to some input reaches one
>>>>>>>>>>>>>>>>>>>>>> final state or one infinite loop, not two
>>>>>>>>>>>>>>>>>>>>>> different ones. This is a consequence of the
>>>>>>>>>>>>>>>>>>>>>> definition of determinism.
>>>>>>>>>>>>>>>>>>>>> In the case of Linz Ĥ applied to ⟨Ĥ⟩, embedded_H at
>>>>>>>>>>>>>>>>>>>>> Ĥ.qx correctly
>>>>>>>>>>>>>>>>>>>>> transitions to its final state of Ĥ.qn on the basis
>>>>>>>>>>>>>>>>>>>>> that a mathematical
>>>>>>>>>>>>>>>>>>>>> mapping between ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ.qn is proven. It is
>>>>>>>>>>>>>>>>>>>>> proven on the basis
>>>>>>>>>>>>>>>>>>>>> that the input ⟨Ĥ⟩ ⟨Ĥ⟩ specifies infinitely nested
>>>>>>>>>>>>>>>>>>>>> simulation to the
>>>>>>>>>>>>>>>>>>>>> simulating halt decider of embedded_H.
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Copyright 2021 Pete Olcott
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Talent hits a target no one else can hit;
>>>>>>>>>>>>>>>>>>>>> Genius hits a target no one else can see.
>>>>>>>>>>>>>>>>>>>>> Arthur Schopenhauer
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ??
>>>>>>>>>>>>>>>>>>>> is a question. A question that has only one answer.
>>>>>>>>>>>>>>>>>>>> We can find the answer by passing the arguments
>>>>>>>>>>>>>>>>>>>> ⟨Ĥ.q0⟩ and ⟨Ĥ⟩ to a UTM. Otherwise it is like saying:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2+2 = 4
>>>>>>>>>>>>>>>>>>>> 2+2 = 5
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is not the question and you know it.
>>>>>>>>>>>>>>>>>>> I can't really understand your motivation to lie.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is the actual question: embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢*
>>>>>>>>>>>>>>>>>>> and the answer is: Ĥ.qn.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except it isn't
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The DEFINITION of a correct H was
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H <X> y -> H.Qn iff X y did not halt. (and to H.Qy if
>>>>>>>>>>>>>>>>>> it does)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The actual correct definition is embedded_H maps ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn based on the actual behavior
>>>>>>>>>>>>>>>>> specified by its input: ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Do you understand that this is correct, or do you not
>>>>>>>>>>>>>>>>> know computer science well enough to understand that
>>>>>>>>>>>>>>>>> this is correct?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Right, AS DETERMINED BY UTM(<H^>,<H^>) which is the same
>>>>>>>>>>>>>>>> as H^ applied to <H^> (BY DEFINITION) which goes to
>>>>>>>>>>>>>>>> H^.Qn and Halts if the copy of H in it goes to H.Qn,
>>>>>>>>>>>>>>>> which it does if H mapped <H^> <H^> to H.Qn which you
>>>>>>>>>>>>>>>> claim, so the behavior specified by the input is HALTING.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I won't count that as wrong because the part that you got
>>>>>>>>>>>>>>> wrong was outside the scope of the original question.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You 100% agree with this:
>>>>>>>>>>>>>>> The actual correct definition is embedded_H maps ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>>>>>>>> to Ĥ.qy or
>>>>>>>>>>>>>>> Ĥ.qn based on the actual behavior specified by its input:
>>>>>>>>>>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The next step after we agree on that point is:
>>>>>>>>>>>>>>> How we measure the actual behavior of the input to
>>>>>>>>>>>>>>> embedded_H: ⟨Ĥ⟩ ⟨Ĥ⟩ ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  From the definition of the problem: it is defined as the
>>>>>>>>>>>>>> behavior of H^ applied to <H^> or its equivalent of
>>>>>>>>>>>>>> UTM(<H^>,<H^>) and nothing else.
>>>>>>>>>>>>> Ah so you don't understand enough computer science to know
>>>>>>>>>>>>> that every decider implements a computable function that
>>>>>>>>>>>>> maps its input(s) to an accept reject state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unless you understand this we cannot proceed. It makes
>>>>>>>>>>>>> sense that I apply this same threshold of understanding to
>>>>>>>>>>>>> all of my reviewers.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, I understand that perfectly, H needs to compute a
>>>>>>>>>>>> mapping from its inputs, but the definition of the mapping,
>>>>>>>>>>>> in this case is the Halting Function, which it turns out is
>>>>>>>>>>>> NOT directly computatable from the inputs.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because you tend to weasel word all over the place and have
>>>>>>>>>>> your rebuttal ignore what I am currently saying and instead
>>>>>>>>>>> refer to something that I said 50 posts ago let's be
>>>>>>>>>>> perfectly clear:
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> The copy of H at Ĥ.qx  referred to as embedded_H must compute
>>>>>>>>>>> the mapping of its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> So, no answer?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am asking whether or not you agree with the above,
>>>>>>>>> Linz says it in a less precise way that can be misinterpreted.
>>>>>>>>>
>>>>>>>>> Unless and until you understand enough computer science to
>>>>>>>>> know that the way that I said it is correct we cannot proceed.
>>>>>>>>>
>>>>>>>>> DO YOU PERFECTLY AGREE THAT THIS IS 100% CORRECT?
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> That is a NONSENSE statement without the conditions on it.
>>>>>>>>>
>>>>>>>>> The copy of H at Ĥ.qx  referred to as embedded_H must compute the
>>>>>>>>> mapping of its own inputs: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn
>>>>>>>>
>>>>>>>> Right.
>>>>>>>>
>>>>>>>> AND the input <H^> <H^> is a description of the whole
>>>>>>>> computation being preformed.
>>>>>>>>
>>>>>>>> Note, this puts H in a bind,
>>>>>>>
>>>>>>> There is no H, there is only a copy of H at Ĥ.qx that is referred
>>>>>>> to as embedded_H.
>>>>>>
>>>>>> And you are wrong there. The HAD to be an H first to build H^ from.
>>>>>>
>>>>>> H is the decider that you want to make the CLAIM to be a correct
>>>>>> Halting Decider.
>>>>>>
>>>>>
>>>>> I wanted to make it clear that the subject of  the discussion is
>>>>> not H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. The subject of the discussion is
>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> It seems that you apply great skill and creativity to make sure
>>>>> that you always refer to things that are not being discussed.
>>>>>
>>>>>> If you are willing to stipulate that there is no such machine,
>>>>>> fine, that mean you concede the question.
>>>>>>
>>>>>> You seem to have forgotten what you are trying to do.
>>>>>>
>>>>>> You DO underestand that you can have more than 1 Turing Machine in
>>>>>> existence at a time, they all run independently, but more than one
>>>>>> do exist.
>>>>>>
>>>>>>>
>>>>>>>>  if its algorithm decides that this input should take it to the
>>>>>>>> Qn state, then the actual behavior of the computatiion this
>>>>>>>> input represents will be HALTING
>>>>>>>
>>>>>>> There is no "represents", there is only the actual behavior
>>>>>>> specified by
>>>>>>> the actual input to embedded_H: ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>>
>>>>>>
>>>>>> And what 'behavior' does a string of symbol have?
>>>>>>
>>>>>> How did we get that string of symbols?
>>>>>>
>>>>>
>>>>> The behavior specified by a string of symbols is the actual
>>>>> behavior of the simulation of this string of symbols.
>>>>
>>>> And the behavior for the Halting Problem would be that simulation by
>>>> a REAL UTM, not some 'partial' simulator.
>>>>
>>>> Remember are claiming to work on an established problem, so you need
>>>> to use the established definitions.
>>>>
>>>
>>> In the case where there is no existing terminology for ideas that I
>>> must convey Sapir–Whorf would prevent expressing these ideas.
>>>
>>> There is no existing term that even roughly approximates the concept
>>> of a {simulating halt decider} so I must construct the meaning of
>>> this term from scratch.
>>>
>>>>>
>>>>>>>
>>>>>>> embedded_H computes the mapping from its input: ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy
>>>>>>> or Ĥ.qn.
>>>>>>>
>>>>>>> The actual behavior of this actual input is measured by the pure
>>>>>>> simulation of N steps by embedded_H of its input ⟨Ĥ⟩ applied to ⟨Ĥ⟩.
>>>>>>>
>>>>>>
>>>>>> No, if anything the actual behavior of this input is measured by
>>>>>> the ACTUAL pure simulation of that input but a REAL UTM until it
>>>>>> either halts or NEVER halts.
>>>>>>
>>>>>
>>>>> No one is stupid enough to believe that a halt decider must wait an
>>>>> infinite amount of time for an infinite loop to stop running.
>>>>
>>>> No one says the halt decider needs to compute its answer that way,
>>>> this is the difference between the IMPLEMENTATION done by the Halt
>>>> Decider, and the REQUIREMENTS specified for it.
>>>>
>>>> H CAN'T wait forever to get its answer, it needs to answer in finite
>>>> time.
>>>>
>>>> The DEFINITION of the Halting Function is based on something that at
>>>> least naively, can take an infinite time. The key is that to claim
>>>> that this is actually 'computable' means that you are claiming that
>>>> this apparently infinite time operation can be done in finite time.
>>>>
>>>> Remember, the Halting Problem STARTED with a 'Function' also known
>>>> as a mapping of machines and inputs to a Halting or Non-Halting
>>>> property.
>>>>
>>>
>>> No this is flatly incorrect. It has never been a mapping of machines
>>> and inputs. It has always been a mapping of machine descriptions and
>>> inputs.
>>
>> The HALTING FUNCTION has ALWAYS been a mapping of TURING/MACH(INES +
>> INPUT to Halting/Non-Halting.
>>
>
> You are far too ignorant for me to waste any more time on.
> I won't even bother to document your error. I will just
> stop talking to you.
>

You mean, you can't find a way to counter what I say, because you just
don't understand what you are talking about.

YOU are the one making the absurd claim to do the impossible.

If you could do it, it would be trivial to prove, just publish your code
that does what you claim.

The simple fact that you don't proves that you haven't been able to do
the thing you claim you have already done.

It doesn't take a lot of explanation to show that the code does work, if
it does.

The problem is that it takes a LOT of BULLSHIT to try to explain why
what you have is 'close' to working and should be treated as good
enough, even though it isn't, because the task is still clearly impossible.

FAIL.