On 12/11/21 12:34 PM, olcott wrote:
> On 12/11/2021 11:20 AM, Richard Damon wrote:
>> On 12/11/21 12:00 PM, olcott wrote:
>>> On 12/11/2021 10:57 AM, olcott wrote:
>>>> On 12/11/2021 12:48 AM, André G. Isaak wrote:
>>>>> On 2021-12-10 22:13, olcott wrote:
>>>>>> On 12/10/2021 10:36 PM, André G. Isaak wrote:
>>>>>>> On 2021-12-10 16:47, olcott wrote:
>>>>>>>> On 12/10/2021 5:39 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-12-10 16:32, olcott wrote:
>>>>>>>>>> On 12/10/2021 5:06 PM, André G. Isaak wrote:
>>>>>>>>>
>>>>>>>>>>> A halt decider, regardless of whether it is simulating or
>>>>>>>>>>> otherwise, reports on the behaviour of the computation
>>>>>>>>>>> represented by its input. This is very clearly stated by the
>>>>>>>>>>> conditions which Linz indicates in his proof.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This definition has confused too many people into thinking
>>>>>>>>>> that it is reporting on something besides the precise behavior
>>>>>>>>>> that is stipulated by the actual input.
>>>>>>>>>
>>>>>>>>> it hasn't confused anyone other than you. A halt decider does
>>>>>>>>> *not* report on the behaviour of its input. It reports on the
>>>>>>>>> behaviour of the computation represented by the input.
>>>>>>>>>
>>>>>>>>
>>>>>>>> When the input to a halt decider is directly executable machine
>>>>>>>> code then that halt status decision is based on the actual
>>>>>>>> behavior of the actual execution of this input.
>>>>>>>
>>>>>>> The decision must describe the actual behaviour of the program
>>>>>>> described by the input, but it cannot be based on the execution
>>>>>>> of this input. If a putative halt decider simply executed its
>>>>>>> input it wouldn't constitute a decider since it would not halt if
>>>>>>> its input were a non-halting program. The input *describes* some
>>>>>>> program and input, just as the input to a TM-based decider
>>>>>>> decribes a computation.
>>>>>>>
>>>>>>
>>>>>> It has always been the case that a halt decider has only been
>>>>>> accountable for the actual behavior specified by its actual input.
>>>>>
>>>>> The actual input is a string. Strings don't have actual behaviour.
>>>>>
>>>>
>>>> An x86 machine code string does have behavior.
>>>>
>>>>>> The actual behavior specified by its actual input H(x,y) is most
>>>>>> precisely defined as the pure simulation of the finite string pair
>>>>>> input S(x,y) from the halt decider.
>>>>>
>>>>> By definition a halt decider describes the behaviour of the
>>>>> computation *described* by its input. The input itself doesn't
>>>>> specify any behaviour at all.
>>>>
>>>> An x86 machine code string does have behavior.
>>>>
>>>>>
>>>>>> H is a decider; which is a type of computable function; which is a
>>>>>> type of function; which only applies to its input parameters.
>>>>>
>>>>> Deciders are a type of Turing Machine (or Computer Program). Turing
>>>>> Machines are *not* functions.
>>>>
>>>> The Church Turing thesis only applies to computable functions.
>>>>
>>>>> They compute functions but they are not the same as the function
>>>>> they compute. And the Halting Function is *not* a computable
>>>>> function so referring to a halt decider as a "computable function"
>>>>> is even more wrong than describing it as a "function".
>>>>>
>>>>
>>>> If halting is not a computable function on some inputs then it is
>>>> outside of the scope of computer science investigation.
>>>>
>>>> Computable function
>>>> Computable functions are the basic objects of study in computability
>>>> theory. Computable functions are the formalized analogue of the
>>>> intuitive notion of algorithms, in the sense that a function is
>>>> computable if there exists an algorithm that can do the job of the
>>>> function, i.e. given an input of the function domain it can return
>>>> the corresponding output.
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>>> You really need to stop using these terms until you learn what they
>>>>> mean. You embarrass yourself with every sentence you write.
>>>>>
>>>>>> No function is ever accountable for anything besides inputs in its
>>>>>> domain. These inputs in its domain are explicitly specified as
>>>>>> parameters.
>>>>>
>>>>> Functions have domains. Turing Machines/Computer programs have
>>>>> parameters. The parameters passed to a TM are *DESCRIPTIONS* of
>>>>> elements of the domain of the function which that TM computes. The
>>>>> domain of the
>>>
>>>
>>> int main() { P(P); } is not a PARAMETER to H thus has nothing to do
>>> with the correctness of H. H is only accountable for its actual input
>>> parameters.
>>
>> But P,P is its input, and the MEANING of P,P is running P(P)
>> unconstrained which is what that is.
>>
>
> When input such as P have been defined to have a dependency relationship
> on a specific halt decider like H the actual behavior of P(P) can only
> be correctly measured by the pure simulation of P(P) from H.
>

WRONG. You don't get to change definitions.

First, if H IS a pure simulation of its input, the BY DEFINITION it will
never abort its input and thus FAIL to return an answer for H(P,P).

Thus, by your definition, H just plain fails to be a decider for P(P),
and thus isn't a counter example for Linz. FAIL.

If H does abort its simulation, to return an answer, it is no longer a
Pure Simulation, and thus your definition is INCORRECT. FAIL.

The ONLY definition of Halting that actually applies is what happens
when the machine is actually run with that input, or equivalently given
as an input to a REAL Pure Simulation, and if H(P,P) returns 0, then
either of these will show that P(P) halts, and if H(P,P) doesn't return,
then H fails to be a decider.

Your H thus FAILS to be a correct decider for H(P,P).

> [Olcott 2021 generic halt deciding principle] Whenever the pure
> simulation of the input to simulating halt decider H(x,y) never stops
> running unless H aborts its simulation H correctly aborts this
> simulation and returns 0 for not halting.

FALSE. The correct answer for Non-Halting is, and only is, if the pure
simulation if the machine (that was given as an input to H) will NEVER
halt, under ANY conditions. Note, pure simulation never 'abort' their
simulations, so WILL

>
> The above provides a correct halt status decision for all inputs.

FALSE.

>
> H is a decider; which is a type of computable function; which is a type
> of function; which only applies to its input parameters.

Except the H your provide never returns an answer for H(P,P), so H is
not a decider.

If you replace H with a function that somehow aborts its simulation of
its input, then it no longer is the pure simulation needed by the
definition of Halting, so doesn't atually show the input is non-halting.

FAIL.

>
> No function is ever accountable for anything besides input parameters in
> its domain, thus the fact that int main() { P(P); }; has different
> behavior than int main() { H(P,P); }; does not make any difference at all.
>
>

But the input to H(P,P) needs to represent the program:

int main() { P(P); }

so that IS what it is responsible for, or your H isn't actually
following the requirements of a Halt Decider.

What it doesn't represent is the PARTIAL execution that H does of it.

FAIL.

>
>> Basically, it sounds like you are complaining that your system isn't
>> defined correctly to allow us to properly express the problem.
>>
>> Question, Whst EXACTLY do you mean that H(x,y) is going to answer about.
>>
>> If it isn't what
>>
>> int main() { x(y); }
>>
>> does, what is?
>>
>> What is your systems definition of a 'computation' being run as an
>> independent computation?
>>
>> It seems that fundamentally, you have defined a 'equavlence' system
>> that doesn't actually meet the requirements to be equivalent.
>>
>> We need a way to define what it mean to run a given Turing Machine
>> equivalent, so to run x(y) or H(P,P) or P(P) we need to have a solid
>> definition of how to do this.
>>
>> It seems that in ALL cases, this is to define the 'C' main function to
>> call the C function that represents the machine.
>>
>> Thus the input to H(x,y) DOES mean to write an "int main() { x(y); }"
>>
>> Maybe this is part of the concept of the difference between the
>> 'representation' and the 'actual machine', your 'representation' has
>> stripped off the main function as to include it would create a
>> multiple definition error.
>
>