On 9/18/2021 11:32 AM, Richard Damon wrote:
> On 9/18/21 12:08 PM, olcott wrote:
>> On 9/18/2021 10:44 AM, Richard Damon wrote:
>>> On 9/18/21 11:37 AM, olcott wrote:
>>>> On 9/18/2021 10:25 AM, Richard Damon wrote:
>>>>> On 9/18/21 11:19 AM, olcott wrote:
>>>>>> On 9/18/2021 10:13 AM, Richard Damon wrote:
>>>>>>> On 9/18/21 10:49 AM, olcott wrote:
>>>>>>>> On 9/18/2021 9:43 AM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 9/18/21 9:54 AM, olcott wrote:
>>>>>>>>>> On 9/17/2021 11:50 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-09-17 20:40, olcott wrote:
>>>>>>>>>>>> Why do theory of computation problems require pure functions?
>>>>>>>>>>>
>>>>>>>>>>> Because the theory of computation isn't about C or x86. It isn't
>>>>>>>>>>> about
>>>>>>>>>>> computer programs at all, nor about modern computers. Just
>>>>>>>>>>> because
>>>>>>>>>>> 'computation' and 'computer' share the same root doesn't mean
>>>>>>>>>>> they
>>>>>>>>>>> deal with the same set of phenomena. Remember that the theory of
>>>>>>>>>>> computation developed before there even were digital computers or
>>>>>>>>>>> programming languages.
>>>>>>>>>>>
>>>>>>>>>>> Computational theory is concerned with describing *mathematical*
>>>>>>>>>>> functions, and all mathematical functions are pure functions. A
>>>>>>>>>>> computation is a method for determining the value of the
>>>>>>>>>>> mathematical
>>>>>>>>>>> function f(x) for a given x. A computable function is one for
>>>>>>>>>>> which it
>>>>>>>>>>> is possible to construct a TM which, given an input string
>>>>>>>>>>> representing x, will determine the value of f(x).
>>>>>>>>>>>
>>>>>>>>>>> You can write computer programs which perform computations,
>>>>>>>>>>> but the
>>>>>>>>>>> majority of computer programs don't.
>>>>>>>>>>>
>>>>>>>>>>> If you really want to learn about the theory of computation, I'd
>>>>>>>>>>> suggest that you forget about C or x86 assembly or any sort of
>>>>>>>>>>> computer language altogether and focus on Turing Machines.
>>>>>>>>>>>
>>>>>>>>>>> And don't try to mentally translate anything you read about
>>>>>>>>>>> Turing
>>>>>>>>>>> Machines into computer languages. Don't think about loop
>>>>>>>>>>> counters, or
>>>>>>>>>>> calls, or machine addresses, because all of these things
>>>>>>>>>>> pertain to
>>>>>>>>>>> computers and computer programming rather than computations and
>>>>>>>>>>> they
>>>>>>>>>>> will get in the way of you actually understanding either turing
>>>>>>>>>>> machines or the theory of computation more generally.
>>>>>>>>>>>
>>>>>>>>>>> André
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I only need to know this for one reason.
>>>>>>>>>>
>>>>>>>>>> When my halt decider is examining the behavior of its input and
>>>>>>>>>> the
>>>>>>>>>> input calls this halt decider in infinite recursion it cannot keep
>>>>>>>>>> track
>>>>>>>>>> of the behavior of this input without having a single pseudo
>>>>>>>>>> static
>>>>>>>>>> variable that is directly embedded in its machine code.
>>>>>>>>>>
>>>>>>>>>> This pseudo static variable stores the ongoing execution trace.
>>>>>>>>>> When the
>>>>>>>>>> variable is an ordinary local variable it loses all of its data
>>>>>>>>>> between
>>>>>>>>>> each recursive simulation.
>>>>>>>>>>
>>>>>>>>>> It still seems to be a pure function of its input in that
>>>>>>>>>> (1) The function return values are identical for identical
>>>>>>>>>> arguments
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think the key issue is that if you want to talk about the plain
>>>>>>>>> behavior of C / x86 code, then you need to talk about the ACTUAL
>>>>>>>>> behavior of that code, which means that the call to H within the
>>>>>>>>> simulated machine needs to be seen as a call to H, and NOT some
>>>>>>>>> logical
>>>>>>>>> transformation.
>>>>>>>>>
>>>>>>>>> If you want to do the transformation, your need to actually PROVE
>>>>>>>>> that
>>>>>>>>> this transform is legitimate under the conditions you want to make
>>>>>>>>> it,
>>>>>>>>> and that needs a very FORMAL argument based on accepted truths and
>>>>>>>>> principles. Your 'argument' based on H not affecting P until
>>>>>>>>> after it
>>>>>>>>> makes its decision so it can ignore its effect, is one of those
>>>>>>>>> arguments that just seems 'obvious' but you haven't actually
>>>>>>>>> proved it.
>>>>>>>>> You don't seem to uhderstand that nature of how to prove something
>>>>>>>>> like
>>>>>>>>> this.
>>>>>>>>>
>>>>>>>>> 'Obvious' things can be wrong, like it seems obvious that the
>>>>>>>>> order you
>>>>>>>>> add up a series shouldn't affect the result, even if the number of
>>>>>>>>> terms
>>>>>>>>> in infinite, but there are simple proofs to show that for SOME
>>>>>>>>> infinite
>>>>>>>>> sums, the order you take the terms can make a difference,
>>>>>>>>> dispite it
>>>>>>>>> seeming contrary to the nature of addition (infinities break a
>>>>>>>>> lot of
>>>>>>>>> common sense).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A key point about your 'static' variable problem.
>>>>>>>>
>>>>>>>> There is only a single question here, not the myriad of questions
>>>>>>>> that
>>>>>>>> you refer to.
>>>>>>>>
>>>>>>>> Does my use of a single static variable that holds the ongoing
>>>>>>>> execution
>>>>>>>> trace by itself necessarily completely disqualify my system from
>>>>>>>> applying to the halting problem or not?
>>>>>>>>
>>>>>>>> a) Yes
>>>>>>>> b) No
>>>>>>>
>>>>>>> Error of the Complex Question, just like the question of "Have you
>>>>>>> stopped lying about your Halt Decider?".
>>>>>>>
>>>>>>> It isn't the existence of a static variable itself that might
>>>>>>> disqualify
>>>>>>> your system for applying to the halting problem,
>>>>>>
>>>>>> André disagrees so one of you must be wrong.
>>>>>
>>>>> Then take his answer and go away as you admit defeat.
>>>>>
>>>>
>>>> That is not how categorically exhaustive reasoning works. Categorically
>>>> exhaustive reasoning eliminates the possibility of the error of
>>>> omission. It results in limited subject domain omniscience.
>>>>
>>>> It only stops when
>>>> (1) A solution is found.
>>>> (2) No solution exist within omniscience.
>>>
>>> But your question, as I explained, was not categorically exhaustive.
>>>
>>
>> Polar (yes/no) questions only have {yes, no} answers.
>> {yes,no} completely exhausts the entire category of answers to polar
>> (yes/no) questions.
>
> As long as you take the answer only for the question exactly as asked.
>
> No, the presence of a static local variable doesn't IN ITSELF disqualify
> a piece of code from being a Computation, but does greatly increase the
> possibility that it is not.
>
>>
>>> Have you stopped lying about your Halt Decider?
>>
>> To the best of my knowledge I have only actually lied once in the last
>> ten years. I lied to a close friend about a very hurtful truth to
>> protect them from this very hurtful truth.
>
> Since it has been reported that you claimed years ago that you did have
> a version of your Halt Decider totally coded as a ACTUAL Turing Machine,
> and you have since retracted that statement, wasn't the first statement
> a LIE.
>

Since the key element of the algorithm that correctly decides the halt
status of the conventional impossible inputs was fully encoded in C and
code written in C can be applied to Turing machines saying that I had a
fully encoded Turing machine was poetic license.

Now that I know that Turing machine equivalence is a concept that does
exist I can more accurately refer to my code as Turing equivalent. Even
when I do this I must augment the common notion of Turing equivalence to
only apply to the subset of computations that have all the memory that
they need.

>>
>> I do the best that I can to always tell the truth for two reasons:
>> (1) I have a very deep passion for mathematically formalizing the notion
>> of analytical truth and this is the sole reason why I pursue:
>>   (a) The Halting Problem
>>   (b) Gödel's 1931 incompleteness theorem
>>   (c) The Tarski Undefinability theorem
>>   (d) The Liar Paradox
>>
>> (2) I honestly believe that people intentionally spreading dangerous
>> lies such as 2020 election fraud and covid-19 disinformation may be
>> eternally incinerated:
>>
>> Revelation 21:8 KJV ...all liars, shall have their part in the lake
>> which burneth with fire and brimstone: which is the second death.
>>
>> If we take that verse literally then to err on the safe side one should
>> refrain from all lies great and small.
>>
>>
>>>>>
>>>>>>
>>>>>>>    but does the existence
>>>>>>> of that variable, and the way that your program uses it mean that
>>>>>>> H is
>>>>>>> not an actual Computation. The existence of the variable opens the
>>>>>>> door
>>>>>>> to it being disqualified, but the actual disqualification needs more
>>>>>>> information.
>>>>>>>
>>>>>>> If EVERY call to H(P,I) for a given P and I returns the exact same
>>>>>>> answer every time, then H is still a computation.
>>>>>>>
>>>>>>> The key point here is that When H decides on the call H(P,P) and in
>>>>>>> that
>>>>>>> simulation of P(P) there is a call to H(P,P) then the 'correct'
>>>>>>> answer
>>>>>>> for H needs to take into account that this simulated WILL do exactly
>>>>>>> the
>>>>>>> same thing as the H that is doing the simulation, so if the
>>>>>>> simulating H
>>>>>>> is going to answer Non-Halting, the behavior of the simulated machine
>>>>>>> will be based on that simulated H also returning that same answer.
>>>>>>> Yes,
>>>>>>> H is not going to have simulated to that point of the simulated
>>>>>>> machines
>>>>>>> execution, so the simulating H will not be able to see that
>>>>>>> result, but
>>>>>>> that IS the behavior of the machine that it is simulating, and thus
>>>>>>> affect what is the 'Right' answer for H to give.
>>>>>>>
>>>>>>>>
>>>>>>>>> If H really WAS a real
>>>>>>>>> simulator, then there is no issue with the static variable as only
>>>>>>>>> one
>>>>>>>>> copy of H is actually execution, all the other copies are just
>>>>>>>>> simulation, so the one variable holding the execution trace hold
>>>>>>>>> the
>>>>>>>>> execution trace of the simulation that it is doing, and there is no
>>>>>>>>> issue.
>>>>>>>>>
>>>>>>>>> The only way that the issue you describe becomes a real issue is
>>>>>>>>> if H
>>>>>>>>> doesn't ACTUALLY simulate/debug step through copies of itself, but
>>>>>>>>> applies some sort of 'transform' to the execution, and you need to
>>>>>>>>> have
>>>>>>>>> some very good proof that this transform is actually valid, and
>>>>>>>>> that
>>>>>>>>> the
>>>>>>>>> resulting H, which passes data to embedded copies of itself, and
>>>>>>>>> thus
>>>>>>>>> knows of stuff of its environment beyond what it is supposed to
>>>>>>>>> know is
>>>>>>>>> actually the equivalent of the decider that doesn't do any of that
>>>>>>>>> 'illegal' operations. My guess is that your H is actually NOT the
>>>>>>>>> equivalent of such an actual computation and does actually behave
>>>>>>>>> differently depending on execution environment, and thus fails to
>>>>>>>>> meet
>>>>>>>>> the basic requirements.
>>>>>>>>>
>>>>>>>>> Remember, if the H inside H^ doesn't behave exactly identical to
>>>>>>>>> the H
>>>>>>>>> that is deciding on that H^, then you aren't working on the right
>>>>>>>>> definitions of the system.
>>>>>>>>>
>>>>>>>>> This seems to be one of your fundamental tripping point, and is
>>>>>>>>> one of
>>>>>>>>> the issues with doing proofs like this in non-Turing Machine
>>>>>>>>> environment
>>>>>>>>> (like C/x86 or even RASP) that 'code fragments' can be
>>>>>>>>> non-computations
>>>>>>>>> and thus not the equivalent of a Turing Machine.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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