There seems to be little agreement on the precise details of what is and
what is not a computation in computer science across respondents here
and textbook definitions.

I will provide and analyze the textbook definitions of: {Linz, Sipser
and Kozen} for "computable function".

A function f with domain f is said to be Turing-computable of just
computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0, □, F)

such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D

Paraphrase: Turing machine M begins in its start state and after making
an arbitrary number of moves on input w in domain D halts in a final
state of its set of final states of M.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company. (243)

Computable Functions
A Turing machine computes a function by starting with the input to the
function on the tape and halting with the output of the function on the
tape.

Definition 5.12
A function f: Σ* → Σ* is a computable function if some Turing machine M,
on every input w, halts with just f(w) on its tape.

Paraphrase: Turing machine M transforms input finite string w into
output finite string M(w). This regular expression Σ* indicates zero or
more elements of Σ (the input alphabet).

Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (190)

A partial function σ: Σ* → Σ* is said to be a computable function if
σ(x) = M(x) for some Turing machine M.

Kozen, Dexter 1997. Automata and Computability. New York:
Springer-Verlag. (347).

When we combine all the definitions together we can simplify Linz and
instead of saying that w ∈ D, we say that w is a (possibly empty) finite
string of the input alphabet.

All of the definitions require M to halt. Linz requires M to halt in a
final state of the final states of M. Kozen requires that an input
finite string derives an output finite string. Sipser require the same a
Kozen yet the input finite string must be also erased.

If we unify these definitions we might say that a [computable function]
is some Turing machine M that makes an arbitrary number of moves on a
some (possibly empty) finite string w ∈ Σ* of its input alphabet and
ends up in a final state of its set of final states.

Optionally there may be some finite string x ∈ Σ* of its input alphabet
on it tape. I will ignore the apparent Sipser requirement to erase the
input string.

Since the input finite string can possibly be empty a Turing machine M
that simply transitions from its start state to its final state would be
a computable function.

--
Copyright 2021 Pete Olcott

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

On 5/1/2021 11:30 AM, olcott wrote:
> There seems to be little agreement on the precise details of what is and
> what is not a computation in computer science across respondents here
> and textbook definitions.
>
> I will provide and analyze the textbook definitions of: {Linz, Sipser
> and Kozen} for "computable function".
>
> A function f with domain f is said to be Turing-computable of just
> computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0, □, F)
>
> such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D
>
> Paraphrase: Turing machine M begins in its start state and after making
> an arbitrary number of moves on input w in domain D halts in a final
> state of its set of final states of M.
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (243)
>
> Computable Functions
> A Turing machine computes a function by starting with the input to the
> function on the tape and halting with the output of the function on the
> tape.
>
> Definition 5.12
> A function f: Σ* → Σ* is a computable function if some Turing machine M,
> on every input w, halts with just f(w) on its tape.
>
> Paraphrase: Turing machine M transforms input finite string w into
> output finite string M(w). This regular expression Σ* indicates zero or
> more elements of Σ (the input alphabet).
>
> Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
> PWS Publishing Company (190)
>
> A partial function σ: Σ* → Σ* is said to be a computable function if
> σ(x) = M(x) for some Turing machine M.
>
> Kozen, Dexter 1997. Automata and Computability. New York:
> Springer-Verlag. (347).
>
> When we combine all the definitions together we can simplify Linz and
> instead of saying that w ∈ D, we say that w is a (possibly empty) finite
> string of the input alphabet.
>
> All of the definitions require M to halt. Linz requires M to halt in a
> final state of the final states of M. Kozen requires that an input
> finite string derives an output finite string. Sipser require the same a
> Kozen yet the input finite string must be also erased.
>
> If we unify these definitions we might say that a [computable function]
> is some Turing machine M that makes an arbitrary number of moves on a
> some (possibly empty) finite string w ∈ Σ* of its input alphabet and
> ends up in a final state of its set of final states.
>
> Optionally there may be some finite string x ∈ Σ* of its input alphabet
> on it tape. I will ignore the apparent Sipser requirement to erase the
> input string.
>
> Since the input finite string can possibly be empty a Turing machine M
> that simply transitions from its start state to its final state would be
> a computable function.
>

A [computable function] is some Turing machine M that makes an arbitrary
number of moves from its start state on a some (possibly empty) finite
string w ∈ Σ* of its input alphabet and ends up in a final state of its
set of final states.

Optionally there may be some finite string x ∈ Σ* output left on its
tape. Because the input string can be empty and the output string is
optional the definition of [computable function] would define a
[computation] as any Turing machine that halts.

--
Copyright 2021 Pete Olcott

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

On 5/1/2021 11:37 AM, olcott wrote:
> On 5/1/2021 11:30 AM, olcott wrote:
>> There seems to be little agreement on the precise details of what is
>> and what is not a computation in computer science across respondents
>> here and textbook definitions.
>>
>> I will provide and analyze the textbook definitions of: {Linz, Sipser
>> and Kozen} for "computable function".
>>
>> A function f with domain f is said to be Turing-computable of just
>> computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0, □, F)
>>
>> such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D
>>
>> Paraphrase: Turing machine M begins in its start state and after
>> making an arbitrary number of moves on input w in domain D halts in a
>> final state of its set of final states of M.
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company. (243)
>>
>> Computable Functions
>> A Turing machine computes a function by starting with the input to the
>> function on the tape and halting with the output of the function on
>> the tape.
>>
>> Definition 5.12
>> A function f: Σ* → Σ* is a computable function if some Turing machine
>> M, on every input w, halts with just f(w) on its tape.
>>
>> Paraphrase: Turing machine M transforms input finite string w into
>> output finite string M(w). This regular expression Σ* indicates zero
>> or more elements of Σ (the input alphabet).
>>
>> Sipser, Michael 1997. Introduction to the Theory of Computation.
>> Boston: PWS Publishing Company (190)
>>
>> A partial function σ: Σ* → Σ* is said to be a computable function if
>> σ(x) = M(x) for some Turing machine M.
>>
>> Kozen, Dexter 1997. Automata and Computability. New York:
>> Springer-Verlag. (347).
>>
>> When we combine all the definitions together we can simplify Linz and
>> instead of saying that w ∈ D, we say that w is a (possibly empty)
>> finite string of the input alphabet.
>>
>> All of the definitions require M to halt. Linz requires M to halt in a
>> final state of the final states of M. Kozen requires that an input
>> finite string derives an output finite string. Sipser require the same
>> a Kozen yet the input finite string must be also erased.
>>
>> If we unify these definitions we might say that a [computable
>> function] is some Turing machine M that makes an arbitrary number of
>> moves on a some (possibly empty) finite string w ∈ Σ* of its input
>> alphabet and ends up in a final state of its set of final states.
>>
>> Optionally there may be some finite string x ∈ Σ* of its input
>> alphabet on it tape. I will ignore the apparent Sipser requirement to
>> erase the input string.
>>
>> Since the input finite string can possibly be empty a Turing machine M
>> that simply transitions from its start state to its final state would
>> be a computable function.
>>
>
> A [computable function] is some Turing machine M that makes an arbitrary
> number of moves from its start state on a some (possibly empty) finite
> string w ∈ Σ* of its input alphabet and ends up in a final state of its
> set of final states.
>
> Optionally there may be some finite string x ∈ Σ* output left on its
> tape.  Because the input string can be empty and the output string is
> optional the definition of [computable function] would define a
> [computation] as any Turing machine that halts.

To make [computable function] generic to all models of computation:
A [computable function] is some sequence of mechanical steps that begins
at a start state (initial configuration) and ends in some specific final
state (final configuration) on some possibly empty input finite string.
An optional finite string output is construed as an aspect of the final
configuration.

--
Copyright 2021 Pete Olcott

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

On 5/1/2021 1:55 PM, Richard Damon wrote:
> On 5/1/21 1:40 PM, olcott wrote:
>> On 5/1/2021 11:37 AM, olcott wrote:
>>> On 5/1/2021 11:30 AM, olcott wrote:
>>>> There seems to be little agreement on the precise details of what is
>>>> and what is not a computation in computer science across respondents
>>>> here and textbook definitions.
>>>>
>>>> I will provide and analyze the textbook definitions of: {Linz, Sipser
>>>> and Kozen} for "computable function".
>>>>
>>>> A function f with domain f is said to be Turing-computable of just
>>>> computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0,
>>>> □, F)
>>>>
>>>> such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D
>>>>
>>>> Paraphrase: Turing machine M begins in its start state and after
>>>> making an arbitrary number of moves on input w in domain D halts in a
>>>> final state of its set of final states of M.
>>>>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company. (243)
>>>>
>>>> Computable Functions
>>>> A Turing machine computes a function by starting with the input to
>>>> the function on the tape and halting with the output of the function
>>>> on the tape.
>>>>
>>>> Definition 5.12
>>>> A function f: Σ* → Σ* is a computable function if some Turing machine
>>>> M, on every input w, halts with just f(w) on its tape.
>>>>
>>>> Paraphrase: Turing machine M transforms input finite string w into
>>>> output finite string M(w). This regular expression Σ* indicates zero
>>>> or more elements of Σ (the input alphabet).
>>>>
>>>> Sipser, Michael 1997. Introduction to the Theory of Computation.
>>>> Boston: PWS Publishing Company (190)
>>>>
>>>> A partial function σ: Σ* → Σ* is said to be a computable function if
>>>> σ(x) = M(x) for some Turing machine M.
>>>>
>>>> Kozen, Dexter 1997. Automata and Computability. New York:
>>>> Springer-Verlag. (347).
>>>>
>>>> When we combine all the definitions together we can simplify Linz and
>>>> instead of saying that w ∈ D, we say that w is a (possibly empty)
>>>> finite string of the input alphabet.
>>>>
>>>> All of the definitions require M to halt. Linz requires M to halt in
>>>> a final state of the final states of M. Kozen requires that an input
>>>> finite string derives an output finite string. Sipser require the
>>>> same a Kozen yet the input finite string must be also erased.
>>>>
>>>> If we unify these definitions we might say that a [computable
>>>> function] is some Turing machine M that makes an arbitrary number of
>>>> moves on a some (possibly empty) finite string w ∈ Σ* of its input
>>>> alphabet and ends up in a final state of its set of final states.
>>>>
>>>> Optionally there may be some finite string x ∈ Σ* of its input
>>>> alphabet on it tape. I will ignore the apparent Sipser requirement to
>>>> erase the input string.
>>>>
>>>> Since the input finite string can possibly be empty a Turing machine
>>>> M that simply transitions from its start state to its final state
>>>> would be a computable function.
>>>>
>>>
>>> A [computable function] is some Turing machine M that makes an
>>> arbitrary number of moves from its start state on a some (possibly
>>> empty) finite string w ∈ Σ* of its input alphabet and ends up in a
>>> final state of its set of final states.
>>>
>>> Optionally there may be some finite string x ∈ Σ* output left on its
>>> tape.  Because the input string can be empty and the output string is
>>> optional the definition of [computable function] would define a
>>> [computation] as any Turing machine that halts.
>>
>>
>> To make [computable function] generic to all models of computation:
>> A [computable function] is some sequence of mechanical steps that begins
>> at a start state (initial configuration) and ends in some specific final
>> state (final configuration) on some possibly empty input finite string.
>> An optional finite string output is construed as an aspect of the final
>> configuration.
>>
>>
> As I mentioned in my other reply, once you leave the domain of Turing
> Machines, the requirement of a given input always giving the same output
> becomes an important restriction, and a necessity for the operation to
> be able to have a Turing Machine equivalent.
>

In the case of the mapping from Halts(H_Hat, H_Hat) to a final state
indicating "No" (not halting) it can perform any mechanical steps in any
way as long as the mapping from the input to the final state always
produces the same result.

The part that you can never seem to understand is that between the start
state and the final state this machine is free to do anything that
machines can possibly do. You have never seemed to get this part.

> More specifically, the definition of the Computable Function needs to
> include ALL of the data and algorithmic steps that go into the
> Computation behind that function. The operation can't depend on data
> that is acquired outside the formally defined inputs to it, and can't
> use mechanical steps that don't belong to it.
>

--
Copyright 2021 Pete Olcott

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

On 01/05/2021 20:09, olcott wrote:
> On 5/1/2021 1:55 PM, Richard Damon wrote:
>> On 5/1/21 1:40 PM, olcott wrote:
>>> On 5/1/2021 11:37 AM, olcott wrote:
>>>> On 5/1/2021 11:30 AM, olcott wrote:
>>>>> There seems to be little agreement on the precise details of what is
>>>>> and what is not a computation in computer science across respondents
>>>>> here and textbook definitions.
>>>>>
>>>>> I will provide and analyze the textbook definitions of: {Linz, Sipser
>>>>> and Kozen} for "computable function".
>>>>>
>>>>> A function f with domain f is said to be Turing-computable of just
>>>>> computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0,
>>>>> □, F)
>>>>>
>>>>> such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D
>>>>>
>>>>> Paraphrase: Turing machine M begins in its start state and after
>>>>> making an arbitrary number of moves on input w in domain D halts in a
>>>>> final state of its set of final states of M.
>>>>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company. (243)
>>>>>
>>>>> Computable Functions
>>>>> A Turing machine computes a function by starting with the input to
>>>>> the function on the tape and halting with the output of the function
>>>>> on the tape.
>>>>>
>>>>> Definition 5.12
>>>>> A function f: Σ* → Σ* is a computable function if some Turing machine
>>>>> M, on every input w, halts with just f(w) on its tape.
>>>>>
>>>>> Paraphrase: Turing machine M transforms input finite string w into
>>>>> output finite string M(w). This regular expression Σ* indicates zero
>>>>> or more elements of Σ (the input alphabet).
>>>>>
>>>>> Sipser, Michael 1997. Introduction to the Theory of Computation.
>>>>> Boston: PWS Publishing Company (190)
>>>>>
>>>>> A partial function σ: Σ* → Σ* is said to be a computable function if
>>>>> σ(x) = M(x) for some Turing machine M.
>>>>>
>>>>> Kozen, Dexter 1997. Automata and Computability. New York:
>>>>> Springer-Verlag. (347).
>>>>>
>>>>> When we combine all the definitions together we can simplify Linz and
>>>>> instead of saying that w ∈ D, we say that w is a (possibly empty)
>>>>> finite string of the input alphabet.
>>>>>
>>>>> All of the definitions require M to halt. Linz requires M to halt in
>>>>> a final state of the final states of M. Kozen requires that an input
>>>>> finite string derives an output finite string. Sipser require the
>>>>> same a Kozen yet the input finite string must be also erased.
>>>>>
>>>>> If we unify these definitions we might say that a [computable
>>>>> function] is some Turing machine M that makes an arbitrary number of
>>>>> moves on a some (possibly empty) finite string w ∈ Σ* of its input
>>>>> alphabet and ends up in a final state of its set of final states.
>>>>>
>>>>> Optionally there may be some finite string x ∈ Σ* of its input
>>>>> alphabet on it tape. I will ignore the apparent Sipser requirement to
>>>>> erase the input string.
>>>>>
>>>>> Since the input finite string can possibly be empty a Turing machine
>>>>> M that simply transitions from its start state to its final state
>>>>> would be a computable function.
>>>>>
>>>>
>>>> A [computable function] is some Turing machine M that makes an
>>>> arbitrary number of moves from its start state on a some (possibly
>>>> empty) finite string w ∈ Σ* of its input alphabet and ends up in a
>>>> final state of its set of final states.
>>>>
>>>> Optionally there may be some finite string x ∈ Σ* output left on its
>>>> tape.  Because the input string can be empty and the output string is
>>>> optional the definition of [computable function] would define a
>>>> [computation] as any Turing machine that halts.
>>>
>>>
>>> To make [computable function] generic to all models of computation:
>>> A [computable function] is some sequence of mechanical steps that begins
>>> at a start state (initial configuration) and ends in some specific final
>>> state (final configuration) on some possibly empty input finite string.
>>> An optional finite string output is construed as an aspect of the final
>>> configuration.
>>>
>>>
>> As I mentioned in my other reply, once you leave the domain of Turing
>> Machines, the requirement of a given input always giving the same output
>> becomes an important restriction, and a necessity for the operation to
>> be able to have a Turing Machine equivalent.
>>
>
> In the case of the mapping from Halts(H_Hat, H_Hat) to a final state indicating
> "No" (not halting) it can perform any mechanical steps in any way as long as the
> mapping from the input to the final state always produces the same result.
>
> The part that you can never seem to understand is that between the start state
> and the final state this machine is free to do anything that machines can
> possibly do. You have never seemed to get this part.

Nonsense. Any side effects over and above those allowed for a TM means we are no
longer dealing with a TM.

/Flibble

--
😎

On 5/1/2021 4:42 PM, Mr Flibble wrote:
> On 01/05/2021 20:09, olcott wrote:
>> On 5/1/2021 1:55 PM, Richard Damon wrote:
>>> On 5/1/21 1:40 PM, olcott wrote:
>>>> On 5/1/2021 11:37 AM, olcott wrote:
>>>>> On 5/1/2021 11:30 AM, olcott wrote:
>>>>>> There seems to be little agreement on the precise details of what is
>>>>>> and what is not a computation in computer science across respondents
>>>>>> here and textbook definitions.
>>>>>>
>>>>>> I will provide and analyze the textbook definitions of: {Linz, Sipser
>>>>>> and Kozen} for "computable function".
>>>>>>
>>>>>> A function f with domain f is said to be Turing-computable of just
>>>>>> computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0,
>>>>>> □, F)
>>>>>>
>>>>>> such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D
>>>>>>
>>>>>> Paraphrase: Turing machine M begins in its start state and after
>>>>>> making an arbitrary number of moves on input w in domain D halts in a
>>>>>> final state of its set of final states of M.
>>>>>>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>> Lexington/Toronto: D. C. Heath and Company. (243)
>>>>>>
>>>>>> Computable Functions
>>>>>> A Turing machine computes a function by starting with the input to
>>>>>> the function on the tape and halting with the output of the function
>>>>>> on the tape.
>>>>>>
>>>>>> Definition 5.12
>>>>>> A function f: Σ* → Σ* is a computable function if some Turing machine
>>>>>> M, on every input w, halts with just f(w) on its tape.
>>>>>>
>>>>>> Paraphrase: Turing machine M transforms input finite string w into
>>>>>> output finite string M(w). This regular expression Σ* indicates zero
>>>>>> or more elements of Σ (the input alphabet).
>>>>>>
>>>>>> Sipser, Michael 1997. Introduction to the Theory of Computation.
>>>>>> Boston: PWS Publishing Company (190)
>>>>>>
>>>>>> A partial function σ: Σ* → Σ* is said to be a computable function if
>>>>>> σ(x) = M(x) for some Turing machine M.
>>>>>>
>>>>>> Kozen, Dexter 1997. Automata and Computability. New York:
>>>>>> Springer-Verlag. (347).
>>>>>>
>>>>>> When we combine all the definitions together we can simplify Linz and
>>>>>> instead of saying that w ∈ D, we say that w is a (possibly empty)
>>>>>> finite string of the input alphabet.
>>>>>>
>>>>>> All of the definitions require M to halt. Linz requires M to halt in
>>>>>> a final state of the final states of M. Kozen requires that an input
>>>>>> finite string derives an output finite string. Sipser require the
>>>>>> same a Kozen yet the input finite string must be also erased.
>>>>>>
>>>>>> If we unify these definitions we might say that a [computable
>>>>>> function] is some Turing machine M that makes an arbitrary number of
>>>>>> moves on a some (possibly empty) finite string w ∈ Σ* of its input
>>>>>> alphabet and ends up in a final state of its set of final states.
>>>>>>
>>>>>> Optionally there may be some finite string x ∈ Σ* of its input
>>>>>> alphabet on it tape. I will ignore the apparent Sipser requirement to
>>>>>> erase the input string.
>>>>>>
>>>>>> Since the input finite string can possibly be empty a Turing machine
>>>>>> M that simply transitions from its start state to its final state
>>>>>> would be a computable function.
>>>>>>
>>>>>
>>>>> A [computable function] is some Turing machine M that makes an
>>>>> arbitrary number of moves from its start state on a some (possibly
>>>>> empty) finite string w ∈ Σ* of its input alphabet and ends up in a
>>>>> final state of its set of final states.
>>>>>
>>>>> Optionally there may be some finite string x ∈ Σ* output left on its
>>>>> tape.  Because the input string can be empty and the output string is
>>>>> optional the definition of [computable function] would define a
>>>>> [computation] as any Turing machine that halts.
>>>>
>>>>
>>>> To make [computable function] generic to all models of computation:
>>>> A [computable function] is some sequence of mechanical steps that
>>>> begins
>>>> at a start state (initial configuration) and ends in some specific
>>>> final
>>>> state (final configuration) on some possibly empty input finite string.
>>>> An optional finite string output is construed as an aspect of the final
>>>> configuration.
>>>>
>>>>
>>> As I mentioned in my other reply, once you leave the domain of Turing
>>> Machines, the requirement of a given input always giving the same output
>>> becomes an important restriction, and a necessity for the operation to
>>> be able to have a Turing Machine equivalent.
>>>
>>
>> In the case of the mapping from Halts(H_Hat, H_Hat) to a final state
>> indicating "No" (not halting) it can perform any mechanical steps in
>> any way as long as the mapping from the input to the final state
>> always produces the same result.
>>
>> The part that you can never seem to understand is that between the
>> start state and the final state this machine is free to do anything
>> that machines can possibly do. You have never seemed to get this part.
>
> Nonsense. Any side effects over and above those allowed for a TM means
> we are no longer dealing with a TM.
>
> /Flibble
>

To the best of my knowledge "side effect" is a software engineering term
that has no application what-so-ever to the theory of computation. So
far no one has been able to cite any source saying otherwise. On this
basis I am tentatively concluding that you are simply wrong.

--
Copyright 2021 Pete Olcott

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

On 01/05/2021 23:32, olcott wrote:
> On 5/1/2021 4:42 PM, Mr Flibble wrote:
>> On 01/05/2021 20:09, olcott wrote:
>>> On 5/1/2021 1:55 PM, Richard Damon wrote:
>>>> On 5/1/21 1:40 PM, olcott wrote:
>>>>> On 5/1/2021 11:37 AM, olcott wrote:
>>>>>> On 5/1/2021 11:30 AM, olcott wrote:
>>>>>>> There seems to be little agreement on the precise details of what is
>>>>>>> and what is not a computation in computer science across respondents
>>>>>>> here and textbook definitions.
>>>>>>>
>>>>>>> I will provide and analyze the textbook definitions of: {Linz, Sipser
>>>>>>> and Kozen} for "computable function".
>>>>>>>
>>>>>>> A function f with domain f is said to be Turing-computable of just
>>>>>>> computable if there exists some Turing machine M = (Q, Σ, Γ, δ, q0,
>>>>>>> □, F)
>>>>>>>
>>>>>>> such that q0w ⊢* Mqₘf(w), qₘ ∈ F, for all w ∈ D
>>>>>>>
>>>>>>> Paraphrase: Turing machine M begins in its start state and after
>>>>>>> making an arbitrary number of moves on input w in domain D halts in a
>>>>>>> final state of its set of final states of M.
>>>>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>> Lexington/Toronto: D. C. Heath and Company. (243)
>>>>>>>
>>>>>>> Computable Functions
>>>>>>> A Turing machine computes a function by starting with the input to
>>>>>>> the function on the tape and halting with the output of the function
>>>>>>> on the tape.
>>>>>>>
>>>>>>> Definition 5.12
>>>>>>> A function f: Σ* → Σ* is a computable function if some Turing machine
>>>>>>> M, on every input w, halts with just f(w) on its tape.
>>>>>>>
>>>>>>> Paraphrase: Turing machine M transforms input finite string w into
>>>>>>> output finite string M(w). This regular expression Σ* indicates zero
>>>>>>> or more elements of Σ (the input alphabet).
>>>>>>>
>>>>>>> Sipser, Michael 1997. Introduction to the Theory of Computation.
>>>>>>> Boston: PWS Publishing Company (190)
>>>>>>>
>>>>>>> A partial function σ: Σ* → Σ* is said to be a computable function if
>>>>>>> σ(x) = M(x) for some Turing machine M.
>>>>>>>
>>>>>>> Kozen, Dexter 1997. Automata and Computability. New York:
>>>>>>> Springer-Verlag. (347).
>>>>>>>
>>>>>>> When we combine all the definitions together we can simplify Linz and
>>>>>>> instead of saying that w ∈ D, we say that w is a (possibly empty)
>>>>>>> finite string of the input alphabet.
>>>>>>>
>>>>>>> All of the definitions require M to halt. Linz requires M to halt in
>>>>>>> a final state of the final states of M. Kozen requires that an input
>>>>>>> finite string derives an output finite string. Sipser require the
>>>>>>> same a Kozen yet the input finite string must be also erased.
>>>>>>>
>>>>>>> If we unify these definitions we might say that a [computable
>>>>>>> function] is some Turing machine M that makes an arbitrary number of
>>>>>>> moves on a some (possibly empty) finite string w ∈ Σ* of its input
>>>>>>> alphabet and ends up in a final state of its set of final states.
>>>>>>>
>>>>>>> Optionally there may be some finite string x ∈ Σ* of its input
>>>>>>> alphabet on it tape. I will ignore the apparent Sipser requirement to
>>>>>>> erase the input string.
>>>>>>>
>>>>>>> Since the input finite string can possibly be empty a Turing machine
>>>>>>> M that simply transitions from its start state to its final state
>>>>>>> would be a computable function.
>>>>>>>
>>>>>>
>>>>>> A [computable function] is some Turing machine M that makes an
>>>>>> arbitrary number of moves from its start state on a some (possibly
>>>>>> empty) finite string w ∈ Σ* of its input alphabet and ends up in a
>>>>>> final state of its set of final states.
>>>>>>
>>>>>> Optionally there may be some finite string x ∈ Σ* output left on its
>>>>>> tape.  Because the input string can be empty and the output string is
>>>>>> optional the definition of [computable function] would define a
>>>>>> [computation] as any Turing machine that halts.
>>>>>
>>>>>
>>>>> To make [computable function] generic to all models of computation:
>>>>> A [computable function] is some sequence of mechanical steps that begins
>>>>> at a start state (initial configuration) and ends in some specific final
>>>>> state (final configuration) on some possibly empty input finite string.
>>>>> An optional finite string output is construed as an aspect of the final
>>>>> configuration.
>>>>>
>>>>>
>>>> As I mentioned in my other reply, once you leave the domain of Turing
>>>> Machines, the requirement of a given input always giving the same output
>>>> becomes an important restriction, and a necessity for the operation to
>>>> be able to have a Turing Machine equivalent.
>>>>
>>>
>>> In the case of the mapping from Halts(H_Hat, H_Hat) to a final state
>>> indicating "No" (not halting) it can perform any mechanical steps in any way
>>> as long as the mapping from the input to the final state always produces the
>>> same result.
>>>
>>> The part that you can never seem to understand is that between the start
>>> state and the final state this machine is free to do anything that machines
>>> can possibly do. You have never seemed to get this part.
>>
>> Nonsense. Any side effects over and above those allowed for a TM means we are
>> no longer dealing with a TM.
>>
>> /Flibble
>>
>
> To the best of my knowledge "side effect" is a software engineering term that
> has no application what-so-ever to the theory of computation. So far no one has
> been able to cite any source saying otherwise. On this basis I am tentatively
> concluding that you are simply wrong.

I see. So if you want to ignore software engineering (computer science) even
though that is the field to which the Halting Problem relates and stick to
mathematics then in mathematics a function always returns the same output for a
given input and that output includes any of the sneaky state you are trying to
hide from us by sleight of hand.

/Flibble

--
😎

On 5/1/2021 8:20 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/1/2021 7:51 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> No H_Hat() in the universe ever stops running unless its otherwise
>>>> infinite recursion is aborted at some point.
>>>
>>> This is just a silly word game. What a computation would do "otherwise"
>>> is irrelevant. H_Hat(H_Hat) is finite and it does not matter how or
>>> why. It is a finite computation, and should be reported as such.
>>
>> So in other words you believe that it is ridiculous for anyone to ever
>> consider defining a partial halt decider because everyone agrees that
>> is cannot be done perfectly so why bother doing this at all.
>
> No. I am saying that your wording is silly because it attempts to
> justify the wrong answer using another, different, computation.
> H_Hat(H_Hat) is finite.

If the execution trace of function X() called by function Y() shows:
(1) Function X() is called twice in sequence from the same machine
address of Y().
(2) With the same parameters to X().
(3) With no conditional branch or indexed jump instructions in Y().
(4) With no function call returns from X().
then the function call from Y() to X() is infinitely recursive.

The above criteria does correctly decide infinite recursion.
The above criteria does correctly decide infinite recursion.
The above criteria does correctly decide infinite recursion.

Every call from H_Hat() to Halts() meets this criteria.
Every call from H_Hat() to Halts() meets this criteria.
Every call from H_Hat() to Halts() meets this criteria.

Ignoring this key fact is no form of correct rebuttal.
Ignoring this key fact is no form of correct rebuttal.
Ignoring this key fact is no form of correct rebuttal.

> Halts(H_Hat, H_Hat) should be true, but you
> have written Halts so that it's false and you justify that wrong answer
> by what would happen were things not as they are. It's flagrant
> silliness.

> When you find yourself starting off "So in other words you believe..."
> you should stop and ask yourself, "what point am I trying to avoid by
> putting words into my interlocutor's mount?".
>

--
Copyright 2021 Pete Olcott

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

On 5/2/2021 12:27 AM, André G. Isaak wrote:
> On 2021-05-01 23:04, olcott wrote:
>> On 5/1/2021 10:14 PM, André G. Isaak wrote:
>>> On 2021-05-01 19:42, olcott wrote:
>>>> On 5/1/2021 8:20 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 5/1/2021 7:51 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> No H_Hat() in the universe ever stops running unless its otherwise
>>>>>>>> infinite recursion is aborted at some point.
>>>>>>>
>>>>>>> This is just a silly word game.  What a computation would do
>>>>>>> "otherwise"
>>>>>>> is irrelevant.  H_Hat(H_Hat) is finite and it does not matter how or
>>>>>>> why.  It is a finite computation, and should be reported as such.
>>>>>>
>>>>>> So in other words you believe that it is ridiculous for anyone to
>>>>>> ever
>>>>>> consider defining a partial halt decider because everyone agrees that
>>>>>> is cannot be done perfectly so why bother doing this at all.
>>>>>
>>>>> No.  I am saying that your wording is silly because it attempts to
>>>>> justify the wrong answer using another, different, computation.
>>>>> H_Hat(H_Hat) is finite.
>>>>
>>>> If the execution trace of function X() called by function Y() shows:
>>>> (1) Function X() is called twice in sequence from the same machine
>>>> address of Y().
>>>
>>
>> If the execution trace of function H_Hat() calling function Halts()
>> shows:
>> (1) Function Halts() is called twice in sequence from the same machine
>> address of H_Hat().
>
> But Halts() is *emulating* H_Hat. That means that the 'call' to Halts
> inside H_Hat is also being emulated. It isn't an actual call.
>

It is computationally equivalent to a call.

> So how does Halts() determine that the routine which it is emulating
> inside H_Hat is a call to Halts() as opposed to something else?
>

It can do this on the basis of the machine address ranges.
It does not need to know this, it only needs to know that the infinite
recursion criteria has been met.

> In the past you've said that you do this based on addresses, but an
> emulator should have an entirely separate (emulated) address space from
> code which is actually being executed.

There is no actual need for this. The key element of the emulation is
that the emulated execution of each instruction <is> a part of a single
computation and the emulator is free to stop its emulation as soon as
non-halting behavior criteria is met.

> Furthermore, you've said your
> machine descriptions are in COFF files. A COFF file doesn't indicate
> *where* in memory a particular piece of code should be placed. So how

I just leave code where it already is in the COFF file.

// This file reads a Microsoft COFF Object file and patches
// all the otherwise relocatable data address references to
// their actual physical file offsets.

> does the emulator decide that a particular piece of code should be given
> the same (emulated) address as the (actual) address of Halts()?
>

The executing x86 code knows nothing about names, it only deals with
machine addresses. Every function has its own unique machine address as
an offset in the COFF object file.

> André
>
>> (2) With the same parameters to Halts().
>> (3) With no conditional branch or indexed jump instructions in H_Hat().
>> (4) With no function call returns from Halts().
>> then the function call from H_Hat() to Halts() is infinitely recursive.
>>
>>
>> _H_Hat()
>> [00000adb](01)  55                      push ebp
>> [00000adc](02)  8bec                    mov ebp,esp
>> [00000ade](01)  51                      push ecx
>> [00000adf](03)  8b4508                  mov eax,[ebp+08]
>> [00000ae2](01)  50                      push eax
>> [00000ae3](03)  8b4d08                  mov ecx,[ebp+08]
>> [00000ae6](01)  51                      push ecx

This is where Halts() is called with the machine address of H_Hat()
having been pushed onto the stack in the prior two push instructions.

>> [00000ae7](05)  e85ffeffff              call 0000094b
>> [00000aec](03)  83c408                  add esp,+08
>> [00000aef](03)  8945fc                  mov [ebp-04],eax
>> [00000af2](02)  8be5                    mov esp,ebp
>> [00000af4](01)  5d                      pop ebp
>> [00000af5](01)  c3                      ret
>> Size in bytes:(0027) [00000af5]
>>
>> Begin Local Halt Decider Simulation at Machine Address:adb
>> ...[00000adb][0021158c][00211590](01)  55                      push ebp
>> ...[00000adc][0021158c][00211590](02)  8bec                    mov
>> ebp,esp
>> ...[00000ade][00211588][0020155c](01)  51                      push ecx
>> ...[00000adf][00211588][0020155c](03)  8b4508                  mov
>> eax,[ebp+08]
>> ...[00000ae2][00211584][00000adb](01)  50                      push eax
>> ...[00000ae3][00211584][00000adb](03)  8b4d08                  mov
>> ecx,[ebp+08]
>> ...[00000ae6][00211580][00000adb](01)  51                      push ecx
>> ...[00000ae7][0021157c][00000aec](05)  e85ffeffff              call
>> 0000094b
>> ...[00000adb][0025bfb4][0025bfb8](01)  55                      push ebp
>> ...[00000adc][0025bfb4][0025bfb8](02)  8bec                    mov
>> ebp,esp
>> ...[00000ade][0025bfb0][0024bf84](01)  51                      push ecx
>> ...[00000adf][0025bfb0][0024bf84](03)  8b4508                  mov
>> eax,[ebp+08]
>> ...[00000ae2][0025bfac][00000adb](01)  50                      push eax
>> ...[00000ae3][0025bfac][00000adb](03)  8b4d08                  mov
>> ecx,[ebp+08]
>> ...[00000ae6][0025bfa8][00000adb](01)  51                      push ecx
>> ...[00000ae7][0025bfa4][00000aec](05)  e85ffeffff              call
>> 0000094b
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>>
>>> This part you really need to elaborate on. H_Hat(X) calls Halts(X,
>>> X), which then emulates X(X) based on the description of X which it
>>> has been passed. How does Halts determine whether that X describes
>>> 'the same' function as one previously called? i.e. how does it figure
>>> out that X is a description of H_Hat?
>>>
>>> André
>>>
>>>> (2) With the same parameters to X().
>>>> (3) With no conditional branch or indexed jump instructions in Y().
>>>> (4) With no function call returns from X().
>>>> then the function call from Y() to X() is infinitely recursive.
>>>>
>>>> The above criteria does correctly decide infinite recursion.
>>>> The above criteria does correctly decide infinite recursion.
>>>> The above criteria does correctly decide infinite recursion.
>>>>
>>>> Every call from H_Hat() to Halts() meets this criteria.
>>>> Every call from H_Hat() to Halts() meets this criteria.
>>>> Every call from H_Hat() to Halts() meets this criteria.
>>>>
>>>> Ignoring this key fact is no form of correct rebuttal.
>>>> Ignoring this key fact is no form of correct rebuttal.
>>>> Ignoring this key fact is no form of correct rebuttal.
>>>>
>>>>> Halts(H_Hat, H_Hat) should be true, but you
>>>>> have written Halts so that it's false and you justify that wrong
>>>>> answer
>>>>> by what would happen were things not as they are.  It's flagrant
>>>>> silliness.
>>>>
>>>>> When you find yourself starting off "So in other words you believe..."
>>>>> you should stop and ask yourself, "what point am I trying to avoid by
>>>>> putting words into my interlocutor's mount?".
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

On 5/2/2021 3:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/1/2021 9:30 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/1/2021 8:20 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 5/1/2021 7:51 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> No H_Hat() in the universe ever stops running unless its otherwise
>>>>>>>> infinite recursion is aborted at some point.
>>>>>>>
>>>>>>> This is just a silly word game. What a computation would do "otherwise"
>>>>>>> is irrelevant. H_Hat(H_Hat) is finite and it does not matter how or
>>>>>>> why. It is a finite computation, and should be reported as such.
>>>>>>
>>>>>> So in other words you believe that it is ridiculous for anyone to ever
>>>>>> consider defining a partial halt decider because everyone agrees that
>>>>>> is cannot be done perfectly so why bother doing this at all.
>>>>>
>>>>> No. I am saying that your wording is silly because it attempts to
>>>>> justify the wrong answer using another, different, computation.
>>>>> H_Hat(H_Hat) is finite.
>>>
>>> I see you don't dispute these facts.
>
> Good to see these facts confirmed by you once again. If you dispute
> that you justify giving the wrong answer using another related
> computation, all you need to do is say so (and correct the record where
> you say that Halts(H_Hat, H_Hat) is false, but the arguments to Halts
> denote a finite computation).
>
>>>> The above criteria does correctly decide infinite recursion.
>>>
>>> What has this got to do with the computation H_Hat(H_Hat) (the real one,
>>> not the one you posted recently to poison the well)? It calls no
>>> functions that call H_Hat. In the world of C and x86 code, that means
>>> it is not recursive at all.
>
>>> You ignored the key facts I put to you. These were facts that you told
>>> me so you are stuck with them until you correct the record.
>>
>> The key fact is that every time H_Hat() calls Halts() it meets the
>> above criteria of infinite recursion, you can dodge this fact but you
>> cannot correctly refute this fact.
>
> I am not dodging it -- I am telling you it's a lie.

You can even tell me that it is a lie, what you cannot do is prove that
it is false.

> I started out being
> polite and technical, but it amounts to the same thing: if the trace
> shows recursion, it is a fake.

void H_Hat2(u32 P)
{ u32 Input_Would_Halt = Simulate(P, P);
}

int main()
{ u32 Input_Would_Halt = Halts((u32)H_Hat2, (u32)H_Hat2);
}

In other words you are saying that the above is not computationally
equivalent to infinite recursion.

> The only clue you have given us at to
> what Halts does made it plain that there is no recursive call, so the

Computationally equivalent to a recursive call is you insistent on being
so damned (condemned to Hell) nit picky.

> trace you show is, as far anyone can tell, a fiction, a lie, published

It can be very easily verified as necessarily correct on the basis of
the provided disassembled x86 code. The x86 source code proves that
H_Hat() would do exactly what its execution trace shows that it does.

> in order to be able to show /something/ when you dare not show the code.
> If the trace shows a recursive call, it does not comport with what you
> have published about Halts and that makes one or other of those (the
> sketch of Halts or the trace) a plain deception.
>

I need not show the code of Halts(), anyone can understand that it is an
x86 emulator that does correctly match certain dynamic patterns of non
halting behavior on the basis of this paper:

http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf

--
Copyright 2021 Pete Olcott

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

On 5/3/2021 2:23 PM, Richard Damon wrote:
> On 5/3/21 3:00 PM, olcott wrote:
>> On 5/3/2021 11:23 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/2/2021 6:52 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 5/2/2021 3:38 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 5/1/2021 9:30 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 5/1/2021 8:20 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 5/1/2021 7:51 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> No H_Hat() in the universe ever stops running unless its
>>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>>> infinite recursion is aborted at some point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is just a silly word game.  What a computation would do
>>>>>>>>>>>>> "otherwise"
>>>>>>>>>>>>> is irrelevant.  H_Hat(H_Hat) is finite and it does not
>>>>>>>>>>>>> matter how or
>>>>>>>>>>>>> why.  It is a finite computation, and should be reported as
>>>>>>>>>>>>> such.
>>>>>>>>>>>>
>>>>>>>>>>>> So in other words you believe that it is ridiculous for
>>>>>>>>>>>> anyone to ever
>>>>>>>>>>>> consider defining a partial halt decider because everyone
>>>>>>>>>>>> agrees that
>>>>>>>>>>>> is cannot be done perfectly so why bother doing this at all.
>>>>>>>>>>>
>>>>>>>>>>> No.  I am saying that your wording is silly because it
>>>>>>>>>>> attempts to
>>>>>>>>>>> justify the wrong answer using another, different, computation.
>>>>>>>>>>> H_Hat(H_Hat) is finite.
>>>>>>>>>
>>>>>>>>> I see you don't dispute these facts.
>>>>>>>
>>>>>>> Good to see these facts confirmed by you once again.  If you dispute
>>>>>>> that you justify giving the wrong answer using another related
>>>>>>> computation, all you need to do is say so (and correct the record
>>>>>>> where
>>>>>>> you say that Halts(H_Hat, H_Hat) is false, but the arguments to Halts
>>>>>>> denote a finite computation).
>>>>>
>>>>> I think we can safely assume that you do not want to dispute any of
>>>>> these facts.
>>>
>>> All the smoke you are trying to blow below can not detract from this end
>>> result.  You are stupidly trying to get away with the wrong answer.
>>>
>>>>>>>>>> The above criteria does correctly decide infinite recursion.
>>>>>>>>>
>>>>>>>>> What has this got to do with the computation H_Hat(H_Hat) (the
>>>>>>>>> real one,
>>>>>>>>> not the one you posted recently to poison the well)?  It calls no
>>>>>>>>> functions that call H_Hat.  In the world of C and x86 code, that
>>>>>>>>> means
>>>>>>>>> it is not recursive at all.
>>>>>>>
>>>>>>>>> You ignored the key facts I put to you.  These were facts that
>>>>>>>>> you told
>>>>>>>>> me so you are stuck with them until you correct the record.
>>>>>>>>
>>>>>>>> The key fact is that every time H_Hat() calls Halts() it meets the
>>>>>>>> above criteria of infinite recursion, you can dodge this fact but
>>>>>>>> you
>>>>>>>> cannot correctly refute this fact.
>>>>>>>
>>>>>>> I am not dodging it -- I am telling you it's a lie.
>>>>>>
>>>>>> You can even tell me that it is a lie, what you cannot do is prove
>>>>>> that it is false.
>>>>>
>>>>> I don't know what that means.  I take what you say about the trace at
>>>>> face value because I don't want to look at it without knowing what's
>>>>> being traced.  You appear to be suggesting that the trace shows
>>>>> recursive calls where there should be none.  I am happy to be corrected
>>>>> on this point.  Does the trace show infinite nested simulations
>>>>> instead?
>>>>
>>>> Since the halt deciding criteria that matches infinite recursion is
>>>> exactly the same as the criteria that matches infinite nested
>>>> simulations and infinite nested simulations are computationally
>>>> equivalent to infinite recursion I can them both infinite recursion.
>>>
>>> I /think/ this means that you now know you used the wrong words but you
>>> were not trying to mislead anyone.  Is that about it?
>>
>> I always speak in terms of the essential gist of things not paying
>> attention to the microscopic details.
>>
>> Because it is ridiculously obvious that infinitely nested simulation has
>> computationally identical halting behavior to infinite recursion and
>> both non halting behavior patterns are identical and the halt decider
>> does not care and does not know the difference I named the single
>> dynamic behavior pattern the [infinite recursion] dynamic behavior pattern.
>
> The issue is you ignore some 'detail' that actually IS important.
>
> Like the fact that the subroutine 'Halts' when called by H_Hat is PART
> OF H_HAT, and that its decision to stop simulating the input it was
> given does NOT make H_Hat an 'infinite recursion'

An infinite loop is correctly decided to specify non halting behavior on
the basis that it matches the [infinite loop] dynamic behavior pattern.
The fact that it does halt because the halt decider forced it to halt
does not change this.

The fact that H_Hat() always matches the [infinite recursion]** dynamic
behavior pattern (when it is executed with itself as input) is what
makes the halt decider's decision correct. The fact that it does halt
because the halt decider forced it to halt does not change this.

** Also applies to infinitely nested simulations.

--
Copyright 2021 Pete Olcott

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

On 5/4/2021 11:40 AM, Richard Damon wrote:
> On 5/4/21 12:23 PM, olcott wrote:
>> On 5/4/2021 11:11 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> An infinite loop is correctly decided to specify non halting behavior
>>>> on the basis that it matches the [infinite loop] dynamic behavior
>>>> pattern.
>>>
>>> Fannel, of no significance to anyone but you.
>>>
>>>> The fact that it does halt because the halt decider forced
>>>> it to halt does not change this.
>>>
>>> The fact that it halts, for whatever reason, makes it a halting
>>> computation.  It should be reported as such.  Your function returns the
>>> wrong answer.
>>
>> Because you are saying that infinite loops specify halting behavior as
>> always I stop of the first big mistake.
>
> Except that he never said that Infinite Loops specifies Halting Behavior.
>
> The fact that the Simulator stopped Simulating it does NOT mean that the
> computation halted.
>

He disagrees:

On 5/4/2021 11:11 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> An infinite loop is correctly decided to specify non halting behavior
>> on the basis that it matches the [infinite loop] dynamic behavior
>> pattern.
>
>> The fact that it does halt because the halt decider forced
>> it to halt does not change this.
>
> The fact that it halts, for whatever reason, makes it a halting
> computation. It should be reported as such. Your function
> returns the wrong answer.

--
Copyright 2021 Pete Olcott

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