On 8/6/2021 10:55 PM, André G. Isaak wrote:
> On 2021-08-06 09:59, olcott wrote:
>> On 8/6/2021 8:09 AM, Richard Damon wrote:
>>> On 8/6/21 6:56 AM, olcott wrote:
>>>> On 8/6/2021 6:38 AM, Richard Damon wrote:
>>>>> On 8/5/21 11:26 PM, olcott wrote:
>>>>>> On 8/5/2021 10:25 PM, Richard Damon wrote:
>>>>>>> On 8/5/21 8:55 PM, olcott wrote:
>>>>>>>
>>>>>>>> I don't refuse to respond to rebuttals. I refuse to respond to you.
>>>>>>>>
>>>>>>>> I also refuse to respond to dishonest dodges, changing the
>>>>>>>> subject to
>>>>>>>> avoid addressing the point at hand.
>>>>>>>>
>>>>>>>> As soon as I prove my point people change the subject.
>>>>>>>> It is counter-productive for me to tolerate this.
>>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>>      if (H(x, x))
>>>>>>>>        HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> It took fifty exchanges for you to pay enough attention to
>>>>>>>> acknowledge
>>>>>>>> that int main(){ P(P); } never halts when we assume that H is
>>>>>>>> only a
>>>>>>>> pure simulator.
>>>>>>>>
>>>>>>>
>>>>>>> No, you refuse to responde to rebuttals from me because I present
>>>>>>> rebuttals so clear that you can't come up with an answer to them.
>>>>>>>
>>>>>>
>>>>>> All of your "rebuttals" are entirely anchored in your inability to
>>>>>> pay
>>>>>> attention.
>>>>>>
>>>>>
>>>>> FALSE.
>>>>>
>>>>> You lack of responses shows you don't understand any of the theory you
>>>>> are talking about.
>>>>>
>>>>>>> What you call a 'dishonest dodge' is me pointing out that the Nth
>>>>>>> time
>>>>>>> you start an arguement, and are trying to misuse a terminology,
>>>>>>> that I
>>>>>>
>>>>>> It does not freaking matter that I misuse terminology that is a
>>>>>> freaking
>>>>>> dishonest dodge. What matters is that my halt decider is correct.
>>>>>>
>>>>>
>>>>> Only if you are misusing the word 'correct', or is it Halting.
>>>>>
>>>>> Misuse of terminology is Fundamentally wrong.
>>>>
>>>> I don't misuse those words. If I misuse terminology that it material to
>>>> my proof then there is a problem.
>>>
>>> Yes, words like Turing Machine, or Halting, or Correct, or Equivalent,
>>> or even Proof.
>>>
>>> You don't seem to really know what these are.
>>>
>>
>> (1) Turing Machine, I use this term correctly no errors can be pointed
>> out.
>
> You've referred to C programs and to x86 programs as 'Turing Machines'.
> That is definitely not correct usage/
>
>> (2) Halting, I may have adapted the original definition, or not.
>> According to André the final state of a computation must be reached
>> for a computation to be considered as having halted.
>
> Yes, but bear in mind that 'halting' refers to Turing Machines operating
> on a specific input. It does not refer to simulations or what happens
> inside a halting decider. It refers *only* to actual computations, i.e.
> an actual Turing Machine operating on an actual input string.
>

So yet again you prove that you are totally clueless that pure
simulations are computationally equivalent to direct executions ?

>> (3) Equivalent, I have adapted the original definition to apply to
>> subsets of computations.
>
> I have no idea what that's even supposed to mean.
>
>> (4) Correct means that the condition of a conditional expression is
>> satisfied.
>
> Again, I have no idea what that's even supposed to mean.
>
>> (5) Proof, here is what I mean by proof, it is an adaptation of the
>> sound deductive inference model such that valid inference must only
>> include true preserving operations.
>>
>> By proof I mean the application of truth preserving inference steps to
>> premises that are known to be true. Since mathematical logic has some
>> inference steps that are not truth preserving these are ruled out.
>> https://en.wikipedia.org/wiki/Principle_of_explosion
>> https://en.wikipedia.org/wiki/Paradoxes_of_material_implication
>>
>> Validity and Soundness
>> A deductive argument is said to be valid if and only if it takes a
>> form that makes it impossible for the premises to be true and the
>> conclusion nevertheless to be false. Otherwise, a deductive argument
>> is said to be invalid.
>>
>> A deductive argument is sound if and only if it is both valid, and all
>> of its premises are actually true. Otherwise, a deductive argument is
>> unsound. https://iep.utm.edu/val-snd/
>>
>> // original definition of valid  (same as P → C)
>>
>> Material conditional
>> p   q p → q
>> T   T   T
>> T   F   F
>> F   T   T
>> F   F   T
>>
>> Transforming the above to become truth preserving:
>>
>> The definition of valid is changed to:
>> p   q   p [PROVES] q
>> T   T        T
>> T   F        F
>> F   T        F
>> F   F        F
>
> That is definitely *not* the definition of valid.
>

It might be simplest to call what I consider proof simply sound
deductive inference.

>> A deductive argument is said to be valid if and only if it takes a form
>> that the conclusion is only true if and only if the premises are true.
>>
>> All of the above is summed up as
>> P [PROVES] C if and only if (True(P) ⊢ True(C) ∧ False(P) ⊢ False(C))
>
> Again, that is definitely *not* the definition of a proof.
>
>> modal operators are most often interpreted
>> "□" for "Necessarily" and "◇" for "Possibly".
>> https://en.wikipedia.org/wiki/Modal_logic
>> (P [PROVES] C) ↔ (P ↔ □C)
>
> Not only is that not the definition of proof, but your use of □ is
> entirely meaningless above.
>
> You do realise that □ conveys absolutely *no* information unless you

"□" for "Necessarily"
"□" for "Necessarily"
"□" for "Necessarily"
"□" for "Necessarily"
"□" for "Necessarily"

> actually specify some sort of modal model? Unless you specify some set
> of alternatives under consideration (i.e. a set of "possible worlds")
> and some sort of accessibility relationship between those alternatives,
> □ is completely uninterpretable.
>
> Why do you insist on using symbols you don't understand?
>

"□" for "Necessarily"
"□" for "Necessarily"
"□" for "Necessarily"
"□" for "Necessarily"
"□" for "Necessarily"

>> H(P,P)==0 is proven to be true on the basis that truth preserving
>> operations are applied to premises that are verified as true: (P ↔ □C)
>
> What are P and C in that example?

Premise/Conclusion

>
>>>>
>>>> If my misuse of terminology is immaterial to my proof then this is an
>>>> side-issue that is irrelevant to my proof.
>>>
>>>
>>>
>>>>
>>>> When people use irrelevant side-issues to avoid addressing the key
>>>> point
>>>> at hand this is a dishonest dodge.
>>>
>>>
>>> Oh, and that is another word you misuse, 'dishonest'. It is NOT
>>> dishonest to point out an error in an arguement, even if it isn't the
>>> point you are trying to focus on as long as it does relate to the
>>> problem at hand.
>>>
>>
>> If an error is pointed out in the actual argument then this if valid.
>> If an error is pointed that does not directly pertain to the argument
>> then this is a dishonest dodge away from the point at hand.
>
> *All* of the errors which have been pointed out to you have been errors
> in the actual argument.

No you always make sure to avoid that part.

This code proves that P has no escape from infinitely nested simulation.
The escape that exists is not in P. In both cases escape/no escape P
never reaches its final state of 0xc3f, therefore P never halts.

_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // push P
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // push P
[00000c30](05) e820fdffff call 00000955 // call H to simulate P
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]

>
>>> YOU use dishonest dodges to avoid having to try to deal with the
>>> multitude of errors in your logic.
>>>
>>>>
>>>>>
>>>>> Glad you admit that.
>>>>>
>>>>> It shows you utter lack of knowledge in the field.
>>>>>
>>>>>
>>>>
>>>> It does not show an utter lack of knowledge in the field.
>>>
>>> Whht, like the fact that you totally don't understand what a Turing
>>> Machine or a Computation is? Or Haltimg, or even what a Proof is.
>>>
>>> Not sure you really understand what is Truth.
>>>
>>>>
>>>> It shows a lack of complete knowledge in the field that can effect my
>>>> credibility. This lack has no effect on the validity of my proof that
>>>> H(P,P)==0 is correct.
>>>
>>> Only that just about every statement in you 'proof' is invalid or
>>> unsound.
>>>
>>> You don't seem to know enough to know how badly you are wrong.
>>>
>>>>
>>>>>>> point out where you are going to in two steps change the meaning
>>>>>>> of a
>>>>>>> word and still assume the arguement based on a different meaning
>>>>>>> still
>>>>>>> holds.
>>>>>>>
>>>>>>
>>>>>> THIS IS THE ONLY FREAKING DETAIL THAT COUNTS.
>>>>>> H(P,P)==0 is the correct halt status of the input to H.
>>>>>> Everything that bypasses this point is a dishonest dodge.
>>>>>
>>>>> Ok, IF Halting is defined to be non-halting, then H(P,P) being
>>>>> non-halting could be a correct answer in your world of inconsistent
>>>>> logic.
>>>>>
>>>>
>>>> Halting is defined as reaching the final state of the C function.
>>>
>>> Right, and when you run P(P) is does that.
>>
>> The Halting problem does not pertain to the behavior of P, it only
>> pertains the behavior of the input to P.
>
> This is absolutely, and categorically False. A halt decider is a program
> which takes as its inputs a description of a Turing Machine, MD, and a
> description of an input string, MI, and determines whether the actual
> *machine* M described by MD halts when given the actual input string I
> described by MI.
>

The HP is only about whether or not the input to H halts.
The HP is not about whether or not the P in main() halts.

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

the Turing machine halting problem. Simply stated, the problem
is: given the description of a Turing machine M and an input w,
does M, when started in the initial configuration q0w, perform a
computation that eventually halts? (Linz:1990:317).

It is the specific position in the execution trace that counts.
The HP is asking whether or not the machine specified by x would halt on
its input x. It doesn't give a rat's ass about the P in main().

> Talking about the behaviour of an input is entirely meaningless.
>
> H(P, P) is supposed to tell us whether P(P) Halts. It is not supposed to
> tell us whether the "input P" halts (whatever that is supposed to mean).
> Only whether the actual turing machine described by its input halts on
> the actual input string described by its input.
>
> If H(P, P) == 0 and P(P) halts, then H(P, P) *by the very definition of
> the problem* is giving the wrong answer.
>
>>       the Turing machine halting problem. Simply stated, the problem
>>       is: given the description of a Turing machine M and an input w,
>>       does M, when started in the initial configuration q0w, perform a
>>       computation that eventually halts? (Linz:1990:317).
>>
>>>>
>>>> Not halting is defined as never reaching the final state of the
>>>> function
>>>> while H is in pure simulator mode. Not halting must be defined in terms
>>>> of never reaching the final state of the function to distinguish it
>>>> from
>>>> functions that had their simulation aborted.
>>>
>>> WRONG. Not Halting is defined as never being able to reach the final
>>> state of the function when fully run. The fact that a simulation doesn't
>>> get there because the simulation was stopped before it happened to get
>>> there proves nothing.
>>>
>>
>> The Halting problem does not pertain to the behavior of P, it only
>> pertains the behavior of the input to P.
>
> Meaningless rubbish. Halting refers to the behaviour of actual
> computations. I.e. actual turing machines operating on actual input
> strings. Not to any "input". If you don't even know what the definition
> of 'halting' or 'the halting problem' is, you shouldn't even be
> discussing them.
>
>>       the Turing machine halting problem. Simply stated, the problem
>>       is: given the description of a Turing machine M and an input w,
>>       does M, when started in the initial configuration q0w, perform a
>>       computation that eventually halts? (Linz:1990:317).
>>
>> The input to H(P,P) does not reach its final state whether or not H
>> ever aborts the simulation of this input.
>
> The "input" to H(P, P) isn't even a computation. It is simply a pair of
> strings. Strings neither halt nor don't halt. H(P, P) is supposed to be
> answering a question about the *actual* computation P(P), which *does*
> halt.
>
>> This is where you attention deficit disorder comes in. You can't seem
>> to be able to pay attention to the steps that prove:
>
> You don't appear to be paying attention to *any* of the errors which
> have been repeatedly brought to your attention.
>
>> the input to H(P,P) does not reach its final state whether or not H
>> ever aborts the simulation of this input.
>
> The "inout" to H is simply a set of strings. Strings don't halt. Strings
> don't have final states. Strings can't be 'aborted'.
>
> The simulation of a description of a Turing Machine and an input is
> *not* the same computation as the actual Turing Machine applied to the
> actual input string, and a halt decider is *defined* as something which
> deals with the latter, not the former.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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