On 9/5/22 10:10 PM, olcott wrote:
> On 9/5/2022 8:59 PM, Richard Damon wrote:
>>
>> On 9/5/22 9:46 PM, olcott wrote:
>>> On 9/5/2022 7:40 PM, Richard Damon wrote:
>>>>
>>>> On 9/5/22 8:07 PM, olcott wrote:
>>>>> On 9/5/2022 5:14 PM, Richard Damon wrote:
>>>>>> On 9/5/22 5:47 PM, olcott wrote:
>>>>>>> On 9/5/2022 3:54 PM, Richard Damon wrote:
>>>>>>>> On 9/5/22 4:44 PM, olcott wrote:
>>>>>>>>> On 9/5/2022 3:27 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 9/5/22 4:20 PM, olcott wrote:
>>>>>>>>>>> On 9/5/2022 3:11 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/5/22 3:52 PM, olcott wrote:
>>>>>>>>>>>>> On 9/5/2022 2:48 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/5/22 3:34 PM, olcott wrote:
>>>>>>>>>>>>>>> On 9/5/2022 11:01 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 9/5/22 11:56 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 9/5/2022 10:21 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 9/5/22 10:51 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 9/5/2022 5:49 AM, Otto J. Makela wrote:
>>>>>>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 9/2/2022 3:45 AM, Otto J. Makela wrote:
>>>>>>>>>>>>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>> In every case where the simulation of the input
>>>>>>>>>>>>>>>>>>>>>>> by H would never
>>>>>>>>>>>>>>>>>>>>>>> stop running H aborts its simulation and returns 0.
>>>>>>>>>>>>>>>>>>>>>> Why would a simulation of H() not return a value,
>>>>>>>>>>>>>>>>>>>>>> once it had done
>>>>>>>>>>>>>>>>>>>>>> the same kind of deduction?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A simulating halt decider must abort the simulation
>>>>>>>>>>>>>>>>>>>>> of every otherwise
>>>>>>>>>>>>>>>>>>>>> non-terminating input. It does this by correctly
>>>>>>>>>>>>>>>>>>>>> recognizing
>>>>>>>>>>>>>>>>>>>>> non-terminating behavior patterns.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You did not answer my question: if H() always
>>>>>>>>>>>>>>>>>>>> returns a value, why would
>>>>>>>>>>>>>>>>>>>> a simulated H() also not always return a value in
>>>>>>>>>>>>>>>>>>>> the simulation?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I will give you the short answer, the simulated H is
>>>>>>>>>>>>>>>>>>> never invoked.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> "Because I defined it so" is not a sufficient answer
>>>>>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A simulating halt decider (SHD) always bases its halt
>>>>>>>>>>>>>>>>>>> status decision on correctly predicting whether or
>>>>>>>>>>>>>>>>>>> not it must abort the correct simulation of its input
>>>>>>>>>>>>>>>>>>> to prevent the infinite execution of this input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> And thus isn't a correct halt decider as its criterion
>>>>>>>>>>>>>>>>>> is different from the Halting Criteria.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A simulating halt decider that does not abort its
>>>>>>>>>>>>>>>>>>> simulation of its input performs a correct and
>>>>>>>>>>>>>>>>>>> complete simulation of this input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, and never gives a non-halting answer.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The definition of a UTM says that any correct and
>>>>>>>>>>>>>>>>>>> complete simulation of an input derives the actual
>>>>>>>>>>>>>>>>>>> behavior of this simulated input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, so a UTM never aborts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thus if the correct and complete simulation of an
>>>>>>>>>>>>>>>>>>> input never reaches the final state of this input
>>>>>>>>>>>>>>>>>>> this means that this input specifies a non-halting
>>>>>>>>>>>>>>>>>>> sequence of instructions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The fact that the simulation of this input is aborted
>>>>>>>>>>>>>>>>>>> does not change the fact that this correctly
>>>>>>>>>>>>>>>>>>> simulated input cannot possibly reach its own final
>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, but note, your arguments above were looking at
>>>>>>>>>>>>>>>>>> a P(P) that called an H(P,P) that doesn't abort. Once
>>>>>>>>>>>>>>>>>> you CHANGE the behavior of H, you have changed the
>>>>>>>>>>>>>>>>>> input, and thus need to re-evaluate.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Once we know that the correctly simulated cannot
>>>>>>>>>>>>>>>>>>> possibly reach its own final state this input can be
>>>>>>>>>>>>>>>>>>> rejected as non-halting on the basis of the
>>>>>>>>>>>>>>>>>>> definition of non-halting: *never reaches its final
>>>>>>>>>>>>>>>>>>> state*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Except you did your logic wrong, because you intial
>>>>>>>>>>>>>>>>>> assumption that the simulation never reached a final
>>>>>>>>>>>>>>>>>> state was based on assuming that H never aborts its
>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Since it does, the logic is unsound.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When H(P,P) DOES abort its simulation UTM(P,P) will
>>>>>>>>>>>>>>>>>> Halt, and thus your arguement that it doesn't is untrue.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>>> [000010f2](01)  55             push ebp
>>>>>>>>>>>>>>>>>>> [000010f3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>>>>>>>> [000010f5](01)  51             push ecx
>>>>>>>>>>>>>>>>>>> [000010f6](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010f9](01)  50             push eax       // push P
>>>>>>>>>>>>>>>>>>> [000010fa](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>>> [000010fd](01)  51             push ecx       // push P
>>>>>>>>>>>>>>>>>>> [000010fe](05)  e88ffdffff     call 00000e92  // call H
>>>>>>>>>>>>>>>>>>> [00001103](03)  83c408         add esp,+08
>>>>>>>>>>>>>>>>>>> [00001106](03)  8945fc         mov [ebp-04],eax
>>>>>>>>>>>>>>>>>>> [00001109](04)  837dfc00       cmp dword [ebp-04],+00
>>>>>>>>>>>>>>>>>>> [0000110d](02)  7402           jz 00001111
>>>>>>>>>>>>>>>>>>> [0000110f](02)  ebfe           jmp 0000110f
>>>>>>>>>>>>>>>>>>> [00001111](02)  8be5           mov esp,ebp
>>>>>>>>>>>>>>>>>>> [00001113](01)  5d             pop ebp
>>>>>>>>>>>>>>>>>>> [00001114](01)  c3             ret
>>>>>>>>>>>>>>>>>>> Size in bytes:(0035) [00001114]
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This is what happens if H never aborts the simulation
>>>>>>>>>>>>>>>>>>> of its input:
>>>>>>>>>>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Right, if H never aborts.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When P is correctly simulated by H and H does not
>>>>>>>>>>>>>>>>>>> abort its simulation of P the first 8 instructions of
>>>>>>>>>>>>>>>>>>> P are simulated endlessly.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, you built that logic on the assumption that H
>>>>>>>>>>>>>>>>>> doesn't abort, thus you can't have H abort.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only job of H is to correctly determine whether or
>>>>>>>>>>>>>>>>> not its correctly simulated input can possibly reach
>>>>>>>>>>>>>>>>> the final state of this input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, it is to determine if *THE* correctly and
>>>>>>>>>>>>>>>> completely simulated input will reach a final state or
>>>>>>>>>>>>>>>> not. Not *ITS*, because if H aborts its simulation, that
>>>>>>>>>>>>>>>> definition is INCORRECT because it doesn't match the
>>>>>>>>>>>>>>>> ACTAUL defintion of Halting.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is because it is different than determining if a
>>>>>>>>>>>>>>>> DIFFERENT version of the decider, when that difference
>>>>>>>>>>>>>>>> changes the input, would be halting or not.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since UTM(Px,Px) Halts whe Hx(Px,Px) returns 0, the
>>>>>>>>>>>>>>>> clear meaning of your words says that Hx was wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Px(ptr x)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>   int Halt_Status = Hx(x, x);
>>>>>>>>>>>>>>>>>   if (Halt_Status)
>>>>>>>>>>>>>>>>>     HERE: goto HERE;
>>>>>>>>>>>>>>>>>   return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    Output("Input_Halts = ", Hx(Px, Px));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *EXISTENTIAL QUANTIFICATION PROVES MY POINT*
>>>>>>>>>>>>>>>>> No function Hx can be defined such that its correct
>>>>>>>>>>>>>>>>> simulation of its input Px would reach the final state
>>>>>>>>>>>>>>>>> of this simulated Px in any finite number of steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So. UTM(Hx,Hx) does Halt, so the correct and complete
>>>>>>>>>>>>>>>> simulation halts, so the correct answer is Halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *You are not paying attention*
>>>>>>>>>>>>>>> *Your boiler plate reply does not apply to what I just said*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *The above refers to the infinite set of Hx/Px pairs
>>>>>>>>>>>>>>> where Hx*
>>>>>>>>>>>>>>> *correctly simulates its input Px, some halt others do not*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, are you saying that UTM(Px,Px) doesn't ever halt when
>>>>>>>>>>>>>> Hx(Px,Px) returns 0?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> *No I specifically said that I am not saying that*
>>>>>>>>>>>>> *Hx/Px specifies an infinite set of pairs some halt others
>>>>>>>>>>>>> do not*
>>>>>>>>>>>>>
>>>>>>>>>>>>> The one thing that is the same across *ALL* of these pairs
>>>>>>>>>>>>> is that the input to Hx(Px,Px) correctly simulated by Hx
>>>>>>>>>>>>> never reaches the final state of Px.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, are you thus asserting that Hx is NOT a Halt Decider?
>>>>>>>>>>>
>>>>>>>>>>> I didn't say that. I am saying that in every possible pair of
>>>>>>>>>>> Hx/Px combinations where Hx correctly simulates its input Px
>>>>>>>>>>> never halts.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, are you saying that it is supposed to meet the
>>>>>>>>>> requirements of a Halt Decider?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I didn't say that either.
>>>>>>>>
>>>>>>>> Yes, we've noticed. YOu have a problem, either your Hx's ARE
>>>>>>>> Halt Deciders and must follow the definition of a Halt Decider,
>>>>>>>> in which case the fact that UTM(Px,Px) Halt means they are
>>>>>>>> wrong, or you admit tha t
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> As I have said, it doesn't matter that no Hx ever correct
>>>>>>>>>> simulates its input Px to a final state, that just means that
>>>>>>>>>> no Hx can PROVE that its input is Halting, not that it isn't
>>>>>>>>>> halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If none of the Hx/Px pairs where Hx correctly simulates Px
>>>>>>>>> reaches a final state of Px, then Px does not halt in any of
>>>>>>>>> these cases.
>>>>>>>>
>>>>>>>> Nope. In EVERY case that Hx aborts its simulation (and returns
>>>>>>>> 0) it is NOT a source of truth that its input is non-halting,
>>>>>>>> and in fact, as you have tactfully agreed by not disagreeing, it
>>>>>>>> has been shown that UTM(Px,Px) will Halt, so the input is HALTING.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We know that all male humans are humans categorically.
>>>>>>>>>
>>>>>>>>> We know that all inputs that do not halt are non-halting
>>>>>>>>> inputs, categorically.
>>>>>>>>
>>>>>>>> Except tha not reaching a final state in an ABORTED and thus
>>>>>>>> PARTIAL simulation does not mean they are non-halting,
>>>>>>>
>>>>>>> If in the entire Hx/Px template none of the correctly simulated
>>>>>>> inputs to Hx reach their final state then every Hx element of
>>>>>>> this set that reports that its correctly simulated input would
>>>>>>> never reach its final state is necessarily correct.
>>>>>>
>>>>>> Nope, do you have a reliable reference for that idea?
>>>>>>
>>>>>> Or is this just another of your pathetic lies that you clam are
>>>>>> true by the meaning of the words when you don't actually seem to
>>>>>> know the meaning of the words.
>>>>> In the entire Hx/Px template none of the inputs correctly simulated
>>>>> by Hx reach their final state.
>>>>>
>>>>
>>>> So, You don't have anything that says this means what you say.
>>>>
>>>>> In other words you are saying that an idea as simple as this is too
>>>>> difficult for you to verify?
>>>>>
>>>>
>>>> It is just wrong,
>>>
>>> If it is "just wrong" then you can show exactly how one element of
>>> the set of Hx/Px pairs where Hx correctly simulates its input and Px
>>> reaches its final state.
>>
>> Why, what is wrong is your claim that a member needs to.
>>
>> No evidence provided for the rule, thus an incorrect claim.
>
> If you say that I am wrong you must show the basis for this assessment
> otherwise your assertion that I am wrong is baseless.
>
> *No amount of weasel worded double-talk can get around that*
>
>

No, you don't understand, the person proposing the rule need to prove it.

It is also easily disproven, since even you have accepted that
UTM(Px,Px) does Halt (if Hx(P,Px) return 0), so BY DEFINITION the
correct HALTING decision of Hx(Px,Px) must be 1 for these cases.

Unless you renounce that Hx is a Halting Decider, it is just WRONG

No "weasel words", just FACTS.

FAIL.

YOU HAVE WASTED YOUR LIFE.

SO SORRY.