On 6/4/22 2:37 PM, olcott wrote:
> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>>
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>
>> [ .... ]
>>
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no longer
>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a canned
>>> rebuttal.
>>
>> I frequently read what you say.  It's dull and repetitive.  And wrong.
>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>> }
>>
>>> _Infinite_Loop()
>>> [00001342](01)  55              push ebp
>>> [00001343](02)  8bec            mov ebp,esp
>>> [00001345](02)  ebfe            jmp 00001345
>>> [00001347](01)  5d              pop ebp
>>> [00001348](01)  c3              ret
>>> Size in bytes:(0007) [00001348]
>>
>>> In the same way that H0 detects .....
>>
>> We don't know what H0 detects, since its code is secret, and probably
>> doesn't exist.
>>
>
> That software engineering confirms that such an H0 could exist is
> sufficient proof that H0 does exist whether or not it is encoded.
> It is encoded.

And it is well know that a limited halt decider to detect programs like
that can exist. But that doesn't show that the needed H to decide P does.

>
>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>> would never reach its final "ret" instruction.
>>
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>
>> Yes.  It's dull and repetitive and wrong.  If it were correct, you would
>> only need to say it once, and it would be accepted and acknowledged by
>> the experts in this group.
>
> Not with the damned liars on this forum that are only interested in
> rebuttal and don't give a rat's ass about the truth.

You mean the one named Peter Olcott?

He is the biggest liar on the forum.
>
>>
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>
>> In this context, it does.
>>
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>
>> A turing machine runs until it halts.  Terminated "normally" has no
>> meaning.
>
> So you are saying that the term "terminated normally" is complete
> gibberish to every software engineer? Why do you lie about this?
>
>> That is one reason you avoid turing machines.  They make things
>> too clear and well defined, leaving you no room to argue stupidities like
>> "halting doesn't mean stops running".
>
> Computation that halts ... the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
>

Right, so to show non-halting, you need to show that if you run the
machine for an unbounded number of steps, it will not reach a final state.

P(P), the machine in question, reaches its final state in a finite
number of steps if H(P,P) returns 0, so that H is wrong.

If H(P,P) doesn't return 0, it fails to be a decider.

THus, you have proved that you method can't create an H that correctly
decides the P built on it.

All you have shown is that your H can't actually prove this either, but
always gets it wrong.

On 6/4/2022 1:54 PM, Richard Damon wrote:
> On 6/4/22 2:37 PM, olcott wrote:
>> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>>> [ Followup-To: set ]
>>>
>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>
>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>
>>> [ .... ]
>>>
>>>>> You've got nested simulations.
>>>>> If H detects them as infinitely nested, and aborts, they are no longer
>>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>>
>>>> I can't understand how you can be so wrong about this. It is like you
>>>> make sure to never read anything that I say before spouting off a
>>>> canned
>>>> rebuttal.
>>>
>>> I frequently read what you say.  It's dull and repetitive.  And wrong.
>>>
>>>> void Infinite_Loop()
>>>> {
>>>>    HERE: goto HERE;
>>>> }
>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>> }
>>>
>>>> _Infinite_Loop()
>>>> [00001342](01)  55              push ebp
>>>> [00001343](02)  8bec            mov ebp,esp
>>>> [00001345](02)  ebfe            jmp 00001345
>>>> [00001347](01)  5d              pop ebp
>>>> [00001348](01)  c3              ret
>>>> Size in bytes:(0007) [00001348]
>>>
>>>> In the same way that H0 detects .....
>>>
>>> We don't know what H0 detects, since its code is secret, and probably
>>> doesn't exist.
>>>
>>
>> That software engineering confirms that such an H0 could exist is
>> sufficient proof that H0 does exist whether or not it is encoded.
>> It is encoded.
>
> And it is well know that a limited halt decider to detect programs like
> that can exist. But that doesn't show that the needed H to decide P does.
>
>>
>>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>>> would never reach its final "ret" instruction.
>>>
>>>> Did you notice that I said this 500 times already?
>>>> Did you notice that I said this 500 times already?
>>>> Did you notice that I said this 500 times already?
>>>
>>> Yes.  It's dull and repetitive and wrong.  If it were correct, you would
>>> only need to say it once, and it would be accepted and acknowledged by
>>> the experts in this group.
>>
>> Not with the damned liars on this forum that are only interested in
>> rebuttal and don't give a rat's ass about the truth.
>
> You mean the one named Peter Olcott?
>
> He is the biggest liar on the forum.
>>
>>>
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>
>>> In this context, it does.
>>>
>>>> HALTING MEANS TERMINATED NORMALLY
>>>> HALTING MEANS TERMINATED NORMALLY
>>>> HALTING MEANS TERMINATED NORMALLY
>>>
>>> A turing machine runs until it halts.  Terminated "normally" has no
>>> meaning.
>>
>> So you are saying that the term "terminated normally" is complete
>> gibberish to every software engineer? Why do you lie about this?
>>
>>> That is one reason you avoid turing machines.  They make things
>>> too clear and well defined, leaving you no room to argue stupidities
>>> like
>>> "halting doesn't mean stops running".
>>
>> Computation that halts ... the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company.
>>
>>
>
> Right, so to show non-halting, you need to show that if you run the
> machine for an unbounded number of steps, it will not reach a final state.

THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual
input as measured by the correct x86 emulation of this input by H.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

[ Newsgroups: trimmed. ]

In comp.theory olcott <NoOne@nowhere.com> wrote:
> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]

>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:

>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:

>> [ .... ]

>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no
>>>> longer infinitely nested, so it gets the wrong answer (as happens
>>>> here).

>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a
>>> canned rebuttal.

>> I frequently read what you say. It's dull and repetitive. And wrong.

>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }

>>> int main()
>>> {
>>> Output("Input_Halts = ", H0(Infinite_Loop));
>>> }

>>> _Infinite_Loop()
>>> [00001342](01) 55 push ebp
>>> [00001343](02) 8bec mov ebp,esp
>>> [00001345](02) ebfe jmp 00001345
>>> [00001347](01) 5d pop ebp
>>> [00001348](01) c3 ret
>>> Size in bytes:(0007) [00001348]

>>> In the same way that H0 detects .....

>> We don't know what H0 detects, since its code is secret, and probably
>> doesn't exist.

> That software engineering confirms that such an H0 could exist is
> sufficient proof that H0 does exist whether or not it is encoded.
> It is encoded.

"Such" an H0 has not been defined. You don't say what you mean by H0.
Whatever it is, even if it "could" exist is no proof that it does exist.
Given your propensity for being poetic with the truth, I (like everybody
else here) am sceptical about its existence. Even if it does exist, it
is likely you misunderstand its implications.

>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>> simulation H(P,P) detects that the complete x86 emulation of its
>>> input would never reach its final "ret" instruction.

>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?

>> Yes. It's dull and repetitive and wrong. If it were correct, you
>> would only need to say it once, and it would be accepted and
>> acknowledged by the experts in this group.

> Not with the damned liars on this forum that are only interested in
> rebuttal and don't give a rat's ass about the truth.

They are profoundly interested in the truth, and that is the only
motivation for them having to tolerate your dullness, your falsehoods and
your abuse.

>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING

>> In this context, it does.

>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY

>> A turing machine runs until it halts. Terminated "normally" has no
>> meaning.

> So you are saying that the term "terminated normally" is complete
> gibberish to every software engineer?

Kindly read what I write if you want to know what I am saying. In the
context of turing machines, "terminated normally" has no meaning.

> Why do you lie about this?

Get this straight, I don't lie on Usenet. Neither do I get poetic with
the truth. I can make mistakes. The above is not one of these mistakes.

>> That is one reason you avoid turing machines. They make things
>> too clear and well defined, leaving you no room to argue stupidities like
>> "halting doesn't mean stops running".

[ .... ]

> --
> Copyright 2022 Pete Olcott

> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

--
Alan Mackenzie (Nuremberg, Germany).

On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>
>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>
> [ .... ]
>
>>> You've got nested simulations.
>>> If H detects them as infinitely nested, and aborts, they are no longer
>>> infinitely nested, so it gets the wrong answer (as happens here).
>
>> I can't understand how you can be so wrong about this. It is like you
>> make sure to never read anything that I say before spouting off a canned
>> rebuttal.
>
> I frequently read what you say. It's dull and repetitive. And wrong.
>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>
>> int main()
>> {
>> Output("Input_Halts = ", H0(Infinite_Loop));
>> }
>
>> _Infinite_Loop()
>> [00001342](01) 55 push ebp
>> [00001343](02) 8bec mov ebp,esp
>> [00001345](02) ebfe jmp 00001345
>> [00001347](01) 5d pop ebp
>> [00001348](01) c3 ret
>> Size in bytes:(0007) [00001348]
>
>> In the same way that H0 detects .....
>
> We don't know what H0 detects, since its code is secret, and probably
> doesn't exist.
>
>> .... that the complete x86 emulation of _Infinite_Loop() would never
>> reach its final "ret" instruction H(P,P) on the basis of a partial
>> simulation H(P,P) detects that the complete x86 emulation of its input
>> would never reach its final "ret" instruction.
>
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>
> Yes. It's dull and repetitive and wrong. If it were correct, you would
> only need to say it once, and it would be accepted and acknowledged by
> the experts in this group.
>
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>
> In this context, it does.
>
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>
> A turing machine runs until it halts. Terminated "normally" has no
> meaning.

A Turing machine is said to halt whenever it reaches a configuration for
which δ is not defined; this is possible because δ is a partial
function. In fact, we will assume that no transitions are defined for
any final state so the Turing machine will halt whenever it enters a
final state. (Linz:1990:234)

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

When translated into ordinary software engineering terms this means
terminated normally. In a C function this means reaching the "ret"
instruction.

> That is one reason you avoid turing machines. They make things
> too clear and well defined, leaving you no room to argue stupidities like
> "halting doesn't mean stops running".

The reason that I avoid Turing machines is that 99% of the most
important details cannot be fully expressed or analyzed. After all of
these details are fully understood then it is very easy to apply the
same reasoning to the Linz proof as I have done in my paper.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/4/22 3:01 PM, olcott wrote:
> On 6/4/2022 1:54 PM, Richard Damon wrote:
>> On 6/4/22 2:37 PM, olcott wrote:
>>> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>>>> [ Followup-To: set ]
>>>>
>>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>
>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>
>>>> [ .... ]
>>>>
>>>>>> You've got nested simulations.
>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>> longer
>>>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>>>
>>>>> I can't understand how you can be so wrong about this. It is like you
>>>>> make sure to never read anything that I say before spouting off a
>>>>> canned
>>>>> rebuttal.
>>>>
>>>> I frequently read what you say.  It's dull and repetitive.  And wrong.
>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>>    HERE: goto HERE;
>>>>> }
>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>> }
>>>>
>>>>> _Infinite_Loop()
>>>>> [00001342](01)  55              push ebp
>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>> [00001347](01)  5d              pop ebp
>>>>> [00001348](01)  c3              ret
>>>>> Size in bytes:(0007) [00001348]
>>>>
>>>>> In the same way that H0 detects .....
>>>>
>>>> We don't know what H0 detects, since its code is secret, and probably
>>>> doesn't exist.
>>>>
>>>
>>> That software engineering confirms that such an H0 could exist is
>>> sufficient proof that H0 does exist whether or not it is encoded.
>>> It is encoded.
>>
>> And it is well know that a limited halt decider to detect programs
>> like that can exist. But that doesn't show that the needed H to decide
>> P does.
>>
>>>
>>>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>>>> would never reach its final "ret" instruction.
>>>>
>>>>> Did you notice that I said this 500 times already?
>>>>> Did you notice that I said this 500 times already?
>>>>> Did you notice that I said this 500 times already?
>>>>
>>>> Yes.  It's dull and repetitive and wrong.  If it were correct, you
>>>> would
>>>> only need to say it once, and it would be accepted and acknowledged by
>>>> the experts in this group.
>>>
>>> Not with the damned liars on this forum that are only interested in
>>> rebuttal and don't give a rat's ass about the truth.
>>
>> You mean the one named Peter Olcott?
>>
>> He is the biggest liar on the forum.
>>>
>>>>
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>
>>>> In this context, it does.
>>>>
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>
>>>> A turing machine runs until it halts.  Terminated "normally" has no
>>>> meaning.
>>>
>>> So you are saying that the term "terminated normally" is complete
>>> gibberish to every software engineer? Why do you lie about this?
>>>
>>>> That is one reason you avoid turing machines.  They make things
>>>> too clear and well defined, leaving you no room to argue stupidities
>>>> like
>>>> "halting doesn't mean stops running".
>>>
>>> Computation that halts ... the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>> Lexington/Toronto: D. C. Heath and Company.
>>>
>>>
>>
>> Right, so to show non-halting, you need to show that if you run the
>> machine for an unbounded number of steps, it will not reach a final
>> state.
>
> THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
> H computes the mapping from its input finite strings to its accept or
> reject state on the basis of the actual behavior specified by the actual
> input as measured by the correct x86 emulation of this input by H.
>

So, since you say "the actual behavior specifed by the actual input
measured by the correct x86 emulation of this input by H", do you mean
that it must actually match the ACTUAL correct x86 behavior of the
machine the input specifies (independent of what H does?, what else does
the first actual behavior clause refer to) or are you putting a
restrirction on H that its emulation must match the actual behavior of
the input based on the actual behaviof specified by an x86 processor
running that input? or are you adding "escape" clauses to mean that
"correct" doesn't need to be actually "correct'?

You have a few too many "correct"s.

As has been shown, P(P), which is what the ACTUAL BEHAVIOR of the input
would be if correctly emulated, will Halt if H(P,P) returns 0.

This means that the ONLY correct answer for H(P,P), if H(P,P) actually
returns 0 would be 1, so it is wrong.

Of course, since you aren't quoting the ACTUAL definition of the Halting
Problem, you also need to prove that you version is equivalent, which is
ultimately your problem, because you actually REJECT that actual
definition, but can't say that as you can't refute what you aren't
working on.

The fact that you are adding a bunch of extraneous words to the
statement is just your attempt to hide the fact that you aren't actually
wanting to look at the actual definition of the halting problem, but
trying to replace the actual behavior specified by the input (which is
the behavior of the machine described as itself) with a PARTIAL
simulation by H, which fails to meet the "correct" requriement.

YOU FAIL.

On 6/4/22 3:28 PM, olcott wrote:
> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>>
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>
>> [ .... ]
>>
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no longer
>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a canned
>>> rebuttal.
>>
>> I frequently read what you say.  It's dull and repetitive.  And wrong.
>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>> }
>>
>>> _Infinite_Loop()
>>> [00001342](01)  55              push ebp
>>> [00001343](02)  8bec            mov ebp,esp
>>> [00001345](02)  ebfe            jmp 00001345
>>> [00001347](01)  5d              pop ebp
>>> [00001348](01)  c3              ret
>>> Size in bytes:(0007) [00001348]
>>
>>> In the same way that H0 detects .....
>>
>> We don't know what H0 detects, since its code is secret, and probably
>> doesn't exist.
>>
>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>> would never reach its final "ret" instruction.
>>
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>
>> Yes.  It's dull and repetitive and wrong.  If it were correct, you would
>> only need to say it once, and it would be accepted and acknowledged by
>> the experts in this group.
>>
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>
>> In this context, it does.
>>
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>
>> A turing machine runs until it halts.  Terminated "normally" has no
>> meaning.
>
> A Turing machine is said to halt whenever it reaches a configuration for
> which δ is not defined; this is possible because δ is a partial
> function. In fact, we will assume that no transitions are defined for
> any final state so the Turing machine will halt whenever it enters a
> final state.  (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>

Yes, it appears that Linz is using the notation that any unspecified
transition is the signal that the machine halts where it is, as opposed
to the notation with a defined set of final states (which have no
transitions specified, and all other states have ALL transitions
specified). These are "equivalent" descriptions in terms of computing
power unless you are playing Turing Golf and scoring based on the "size"
of the Turing Machine.

> When translated into ordinary software engineering terms this means
> terminated normally. In a C function this means reaching the "ret"
> instruction.
>
>> That is one reason you avoid turing machines.  They make things
>> too clear and well defined, leaving you no room to argue stupidities like
>> "halting doesn't mean stops running".
>
> The reason that I avoid Turing machines is that 99% of the most
> important details cannot be fully expressed or analyzed. After all of
> these details are fully understood then it is very easy to apply the
> same reasoning to the Linz proof as I have done in my paper.

No, you avoid them because you can't pull the shenanagians with them
that you do with your x86 code. The key here is that a Turing Machine,
by its very nature, can only be a computation, while x86 code fragments
can easily be non-computations. By all appearances, you decider H is NOT
actually a computation, and the only way for you to actually prove it is
would be to let others inspect your code, but that would let the cat out
of the bag (which you will probably call a dog).

I suspect that also, you just don't understand how a Turing Machine
actually works, because you are such a poor programmer you can't deal
with a machine that won't take your dirty tricks. Maybe the issue is you
have tried to code your trick as a Turing Machine, and because you can't
make a non-computation out of one, you just failed and don't want to
admit that you are just being a cheater.

>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>

On 6/4/2022 2:05 PM, Richard Damon wrote:

<SNIP>

> Yes, it appears that Linz is using the notation that any unspecified
> transition is the signal that the machine halts where it is, as opposed
> to the notation with a defined set of final states (which have no
> transitions specified, and all other states have ALL transitions
> specified). These are "equivalent" descriptions in terms of computing
> power unless you are playing Turing Golf and scoring based on the "size"
> of the Turing Machine.

The normal game is scored by the product of the number of states and the
size of the tape (as opposed to the input) alphabet.
--
Jeff Barnett

On 2022-06-04 19:28:19 +0000, olcott said:

> A Turing machine is said to halt whenever it reaches a configuration
> for which δ is not defined; this is possible because δ is a partial
> function. In fact, we will assume that no transitions are defined for
> any final state so the Turing machine will halt whenever it enters a
> final state. (Linz:1990:234)
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
> When translated into ordinary software engineering terms this means
> terminated normally. In a C function this means reaching the "ret"
> instruction.

The best equivalent to "not defined" is not "ret". Instead, "not defined"
should include at least:
- HLT or any other instruction that means 'halt'
- any undefined op code
- any return or pop instruction if the stack is empty
- an instruction fetch from a location that is not specifiec by the program
That way the analogy to Linz' definition is much better.

Mikko

On 6/5/2022 5:14 AM, Mikko wrote:
> On 2022-06-04 19:28:19 +0000, olcott said:
>
>> A Turing machine is said to halt whenever it reaches a configuration
>> for which δ is not defined; this is possible because δ is a partial
>> function. In fact, we will assume that no transitions are defined for
>> any final state so the Turing machine will halt whenever it enters a
>> final state.  (Linz:1990:234)
>>
>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>> Lexington/Toronto: D. C. Heath and Company.
>>
>> When translated into ordinary software engineering terms this means
>> terminated normally. In a C function this means reaching the "ret"
>> instruction.
>
> The best equivalent to "not defined" is not "ret". Instead, "not defined"
> should include at least:
> - HLT or any other instruction that means 'halt'
> - any undefined op code
> - any return or pop instruction if the stack is empty
> - an instruction fetch from a location that is not specifiec by the program
> That way the analogy to Linz' definition is much better.
>
> Mikko
>

Reaching a final state is merely the Turing machine way of saying
terminated normally. "ret" is the C way of saying the same thing.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

olcott <NoOne@nowhere.com> wrote:
> On 6/5/2022 5:14 AM, Mikko wrote:
>> On 2022-06-04 19:28:19 +0000, olcott said:

>>> A Turing machine is said to halt whenever it reaches a configuration
>>> for which δ is not defined; this is possible because δ is a partial
>>> function. In fact, we will assume that no transitions are defined for
>>> any final state so the Turing machine will halt whenever it enters a
>>> final state.  (Linz:1990:234)

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

>>> When translated into ordinary software engineering terms this means
>>> terminated normally. In a C function this means reaching the "ret"
>>> instruction.

>> The best equivalent to "not defined" is not "ret". Instead, "not defined"
>> should include at least:
>> - HLT or any other instruction that means 'halt'
>> - any undefined op code
>> - any return or pop instruction if the stack is empty
>> - an instruction fetch from a location that is not specifiec by the
>> program
>> That way the analogy to Linz' definition is much better.

>> Mikko

> Reaching a final state is merely the Turing machine way of saying
> terminated normally. "ret" is the C way of saying the same thing.

Sophistry. What would be the turing machine equivalent of an "abnormal
termination" in C? It can only be the TM having halted. So a TM final
state is equivalent to a C program's termination, whether by a ret
instruction or a halt instruction or anything else.

> --
> Copyright 2022 Pete Olcott

> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

--
Alan Mackenzie (Nuremberg, Germany).

On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
> olcott <NoOne@nowhere.com> wrote:
>> On 6/5/2022 5:14 AM, Mikko wrote:
>>> On 2022-06-04 19:28:19 +0000, olcott said:
>
>>>> A Turing machine is said to halt whenever it reaches a configuration
>>>> for which δ is not defined; this is possible because δ is a partial
>>>> function. In fact, we will assume that no transitions are defined for
>>>> any final state so the Turing machine will halt whenever it enters a
>>>> final state.  (Linz:1990:234)
>
>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>> Lexington/Toronto: D. C. Heath and Company.
>
>>>> When translated into ordinary software engineering terms this means
>>>> terminated normally. In a C function this means reaching the "ret"
>>>> instruction.
>
>>> The best equivalent to "not defined" is not "ret". Instead, "not defined"
>>> should include at least:
>>> - HLT or any other instruction that means 'halt'
>>> - any undefined op code
>>> - any return or pop instruction if the stack is empty
>>> - an instruction fetch from a location that is not specifiec by the
>>> program
>>> That way the analogy to Linz' definition is much better.
>
>>> Mikko
>
>> Reaching a final state is merely the Turing machine way of saying
>> terminated normally. "ret" is the C way of saying the same thing.
>
> Sophistry. What would be the turing machine equivalent of an "abnormal
> termination" in C?

An aborted simulation.

H determines the halt status of its input by watching the behavior of
this input when it is correctly simulated by H using an x86 emulator.
When H correctly matches an infinite behavior pattern it aborts the
emulation of this input and returns 0.

#include <stdint.h>
#define u32 uint32_t

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

Therefore H(P,P)==0 is correct.

> It can only be the TM having halted. So a TM final
> state is equivalent to a C program's termination, whether by a ret
> instruction or a halt instruction or anything else.
>
>> --
>> Copyright 2022 Pete Olcott
>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/5/22 7:21 AM, olcott wrote:
> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>> olcott <NoOne@nowhere.com> wrote:
>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>
>>>>> A Turing machine is said to halt whenever it reaches a configuration
>>>>> for which δ is not defined; this is possible because δ is a partial
>>>>> function. In fact, we will assume that no transitions are defined for
>>>>> any final state so the Turing machine will halt whenever it enters a
>>>>> final state.  (Linz:1990:234)
>>
>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>> Lexington/Toronto: D. C. Heath and Company.
>>
>>>>> When translated into ordinary software engineering terms this means
>>>>> terminated normally. In a C function this means reaching the "ret"
>>>>> instruction.
>>
>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>> defined"
>>>> should include at least:
>>>> - HLT or any other instruction that means 'halt'
>>>> - any undefined op code
>>>> - any return or pop instruction if the stack is empty
>>>> - an instruction fetch from a location that is not specifiec by the
>>>>    program
>>>> That way the analogy to Linz' definition is much better.
>>
>>>> Mikko
>>
>>> Reaching a final state is merely the Turing machine way of saying
>>> terminated normally. "ret" is the C way of saying the same thing.
>>
>> Sophistry.  What would be the turing machine equivalent of an "abnormal
>> termination" in C?
>
> An aborted simulation.

No, you have things backwards. Turing Machine behavior is NOT based on
simulating the machines, but on just running them. Simulation is a way
to see what a given machine would do if you don't actually have the
machine available.

Turing Machine NEVER stop running until they reach their final state,
and thus, the ONLY way they "terminate" is what you call "normally
terminate", so the term normally is extraneous.

Any other form of "termination" that a simulator creates is just proof
that the simulation wasn't accurate, or in simpler terems WRONG.

Part of your problem seems to be an inability to handle abstractions.
Turing Machines are DEFINED by abstract properties. You can't actually
"build" a physical Turing Machine, only a model of one. But to
mathematics, they exist. Sort of like how the number Pi has an exact
value, but you can never actually express it (because it takes an
infinite number of digits).

>
> H determines the halt status of its input by watching the behavior of
> this input when it is correctly simulated by H using an x86 emulator.
> When H correctly matches an infinite behavior pattern it aborts the
> emulation of this input and returns 0.

But what happens when the simulation never matches a pattern that is
actually infinite behavior?

Your simulator will just run forever (and fail to be a decider) as
appears to happen with your H.

If it allows itself to abort the simulation (and thus its simulation is
no longer actually accurate) on a pattern that it just THINKS shows
infinite behavior it can be wrong. Note, when we give the input to a
"better" simulator, one that doesn't try to that pattern, it WILL run to
completion and halt.

(Note, P still calls the original H, not this better simulator)

>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.

No, since H is DEFINED to abort its simulation, it is DEFINED to NOT do
a CORRECT emulation of its input.

That is like saying it is obvious that your dog is a cat.

Note also, the seventh instruction is being misinterpreted. It does NOT
"Just repeat the process", that would be it actually CALLED P(P) instead
of calling H(P,P).

Conditional simulation is NOT the equivalent of direct execution (and if
the simulation isn't conditional, they you can't talk about it doing
things like aborting its simulation on some condition).

The CORRECT emulation of this input would emulate the emulator, and the
trace needs to be showing that, and all the aspects related to that.

Working from wrong data gives wrong answers.

>
> Therefore H(P,P)==0 is correct.

Nope. That statement shows your stupiditiy.

THat fact that YOU AGREE that P(P) halts when H(P,P) returns 0, means
that you KNOW that, if H actually is defined to be a Halt Decider, this
answer is wrong.

The fact that you persist in making the claim shows that either you are
a pathological liar, or suffer from a mental deficiency that allows you
to ignore the cognitive dissonance of your statement, or you are so
ignorant you don't understand anything about what you are talking.

The Non-Halting answer can not be right for an input you know Halts.

>
>> It can only be the TM having halted.  So a TM final
>> state is equivalent to a C program's termination, whether by a ret
>> instruction or a halt instruction or anything else.
>>
>>> --
>>> Copyright 2022 Pete Olcott
>>
>>> "Talent hits a target no one else can hit;
>>>   Genius hits a target no one else can see."
>>>   Arthur Schopenhauer
>>
>
>

olcott <NoOne@nowhere.com> wrote:
> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>> olcott <NoOne@nowhere.com> wrote:
>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>> On 2022-06-04 19:28:19 +0000, olcott said:

>>>>> A Turing machine is said to halt whenever it reaches a
>>>>> configuration for which δ is not defined; this is possible because
>>>>> δ is a partial function. In fact, we will assume that no
>>>>> transitions are defined for any final state so the Turing machine
>>>>> will halt whenever it enters a final state.  (Linz:1990:234)

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

>>>>> When translated into ordinary software engineering terms this means
>>>>> terminated normally. In a C function this means reaching the "ret"
>>>>> instruction.

>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>> defined" should include at least:
>>>> - HLT or any other instruction that means 'halt'
>>>> - any undefined op code
>>>> - any return or pop instruction if the stack is empty
>>>> - an instruction fetch from a location that is not specifiec by the
>>>> program
>>>> That way the analogy to Linz' definition is much better.

>>>> Mikko

>>> Reaching a final state is merely the Turing machine way of saying
>>> terminated normally. "ret" is the C way of saying the same thing.

>> Sophistry. What would be the turing machine equivalent of an
>> "abnormal termination" in C?

> An aborted simulation.

There's no such thing on a turing machine. It either runs and halts, or
it runs forever.

Your aborted simulation is just one final state of a turing machine,
which has thus halted.

[ .... ]

>> It can only be the TM having halted. So a TM final
>> state is equivalent to a C program's termination, whether by a ret
>> instruction or a halt instruction or anything else.

> --
> Copyright 2022 Pete Olcott

> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

Alan Mackenzie <acm@muc.de> writes:

> olcott <NoOne@nowhere.com> wrote:
>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:

>>> ... What would be the turing machine equivalent of an
>>> "abnormal termination" in C?
>
>> An aborted simulation.
>
> There's no such thing on a turing machine. It either runs and halts, or
> it runs forever.
>
> Your aborted simulation is just one final state of a turing machine,
> which has thus halted.

A year ago I tried to get PO to accept a few basic facts about the
topic. One of these was

(B) Every computation that halts, for whatever reason, is a halting
computation.

After much ducking a diving, PO replied "OK".

--
Ben.

On Sun, 5 Jun 2022 07:58:42 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 6/5/22 7:21 AM, olcott wrote:
> > On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
> >> olcott <NoOne@nowhere.com> wrote:
> >>> On 6/5/2022 5:14 AM, Mikko wrote:
> >>>> On 2022-06-04 19:28:19 +0000, olcott said:
> >>
> >>>>> A Turing machine is said to halt whenever it reaches a
> >>>>> configuration for which δ is not defined; this is possible
> >>>>> because δ is a partial function. In fact, we will assume that
> >>>>> no transitions are defined for any final state so the Turing
> >>>>> machine will halt whenever it enters a final state.
> >>>>> (Linz:1990:234)
> >>
> >>>>> Linz, Peter 1990. An Introduction to Formal Languages and
> >>>>> Automata. Lexington/Toronto: D. C. Heath and Company.
> >>
> >>>>> When translated into ordinary software engineering terms this
> >>>>> means terminated normally. In a C function this means reaching
> >>>>> the "ret" instruction.
> >>
> >>>> The best equivalent to "not defined" is not "ret". Instead, "not
> >>>> defined"
> >>>> should include at least:
> >>>> - HLT or any other instruction that means 'halt'
> >>>> - any undefined op code
> >>>> - any return or pop instruction if the stack is empty
> >>>> - an instruction fetch from a location that is not specifiec by
> >>>> the program
> >>>> That way the analogy to Linz' definition is much better.
> >>
> >>>> Mikko
> >>
> >>> Reaching a final state is merely the Turing machine way of saying
> >>> terminated normally. "ret" is the C way of saying the same thing.
> >>>
> >>
> >> Sophistry.  What would be the turing machine equivalent of an
> >> "abnormal termination" in C?
> >
> > An aborted simulation.
>
> No, you have things backwards. Turing Machine behavior is NOT based
> on simulating the machines, but on just running them. Simulation is a
> way to see what a given machine would do if you don't actually have
> the machine available.
>
> Turing Machine NEVER stop running until they reach their final state,
> and thus, the ONLY way they "terminate" is what you call "normally
> terminate", so the term normally is extraneous.
>
> Any other form of "termination" that a simulator creates is just
> proof that the simulation wasn't accurate, or in simpler terems WRONG.
>
> Part of your problem seems to be an inability to handle abstractions.
> Turing Machines are DEFINED by abstract properties. You can't
> actually "build" a physical Turing Machine, only a model of one. But
> to mathematics, they exist. Sort of like how the number Pi has an
> exact value, but you can never actually express it (because it takes
> an infinite number of digits).

PI does not have an exact value; no irrational number has an exact
value.

/Flibble

On 05/06/2022 13:14, Alan Mackenzie wrote:
> olcott <NoOne@nowhere.com> wrote:
>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>> olcott <NoOne@nowhere.com> wrote:
>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>
>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>> configuration for which δ is not defined; this is possible because
>>>>>> δ is a partial function. In fact, we will assume that no
>>>>>> transitions are defined for any final state so the Turing machine
>>>>>> will halt whenever it enters a final state.  (Linz:1990:234)
>
>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>> Lexington/Toronto: D. C. Heath and Company.
>
>>>>>> When translated into ordinary software engineering terms this means
>>>>>> terminated normally. In a C function this means reaching the "ret"
>>>>>> instruction.
>
>>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>>> defined" should include at least:
>>>>> - HLT or any other instruction that means 'halt'
>>>>> - any undefined op code
>>>>> - any return or pop instruction if the stack is empty
>>>>> - an instruction fetch from a location that is not specifiec by the
>>>>> program
>>>>> That way the analogy to Linz' definition is much better.
>
>>>>> Mikko
>
>>>> Reaching a final state is merely the Turing machine way of saying
>>>> terminated normally. "ret" is the C way of saying the same thing.
>
>>> Sophistry. What would be the turing machine equivalent of an
>>> "abnormal termination" in C?
>
>> An aborted simulation.
>
> There's no such thing on a turing machine. It either runs and halts, or
> it runs forever.
>
> Your aborted simulation is just one final state of a turing machine,
> which has thus halted.

A TM "aborting" a simulation is just the TM ceasing to calculate computation steps for some
computation, and going on to calculate something else instead. It does not mean:
a) that the TM (doing the simulation) has halted
b) that the simulated computation halts
c) that the simulated computation never halts

Regards,
Mike.

Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> On 05/06/2022 13:14, Alan Mackenzie wrote:
>> olcott <NoOne@nowhere.com> wrote:
>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>> olcott <NoOne@nowhere.com> wrote:
>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:

>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>> configuration for which δ is not defined; this is possible because
>>>>>>> δ is a partial function. In fact, we will assume that no
>>>>>>> transitions are defined for any final state so the Turing machine
>>>>>>> will halt whenever it enters a final state.  (Linz:1990:234)

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

>>>>>>> When translated into ordinary software engineering terms this means
>>>>>>> terminated normally. In a C function this means reaching the "ret"
>>>>>>> instruction.

>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>>>> defined" should include at least:
>>>>>> - HLT or any other instruction that means 'halt'
>>>>>> - any undefined op code
>>>>>> - any return or pop instruction if the stack is empty
>>>>>> - an instruction fetch from a location that is not specifiec by the
>>>>>> program
>>>>>> That way the analogy to Linz' definition is much better.

>>>>>> Mikko

>>>>> Reaching a final state is merely the Turing machine way of saying
>>>>> terminated normally. "ret" is the C way of saying the same thing.

>>>> Sophistry. What would be the turing machine equivalent of an
>>>> "abnormal termination" in C?

>>> An aborted simulation.

>> There's no such thing on a turing machine. It either runs and halts,
>> or it runs forever.

>> Your aborted simulation is just one final state of a turing machine,
>> which has thus halted.

> A TM "aborting" a simulation is just the TM ceasing to calculate
> computation steps for some computation, and going on to calculate
> something else instead. It does not mean:
> a) that the TM (doing the simulation) has halted
> b) that the simulated computation halts
> c) that the simulated computation never halts

OK. I've a feeling we're talking more about nice shades of words than
computer science here, but ....

If the simulation is the entire turing machine, aborting it will bring
the TM to a halt state. If that simulation is merely part of the TM,
then the word "halt" has a different meaning when applied to that
simulation part from when applied to the entire TM. I'm not even sure
what you mean when you say a part of a TM has halted or not halted.

> Regards,
> Mike.

--
Alan Mackenzie (Nuremberg, Germany).

Ben <ben.usenet@bsb.me.uk> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>> olcott <NoOne@nowhere.com> wrote:
>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>
>>>> ... What would be the turing machine equivalent of an
>>>> "abnormal termination" in C?
>>
>>> An aborted simulation.
>>
>> There's no such thing on a turing machine. It either runs and halts, or
>> it runs forever.
>>
>> Your aborted simulation is just one final state of a turing machine,
>> which has thus halted.
>
> A year ago I tried to get PO to accept a few basic facts about the
> topic. One of these was
>
> (B) Every computation that halts, for whatever reason, is a halting
> computation.
>
> After much ducking [and] diving, PO replied "OK".

I should explain that the purpose of this question was because, at the
time, PO was claiming that the reason H_Hat(H_Hat) halts was "special":
the consequence of a simulation being stopped. The fact that
H_Hat(H_Hat) halts for some special reason used to be feature of PO's
posts. The phrasing "H(H_Hat, H_Hat) == 0 is correct because
H_Hat(H_Hat) only halts because..." was the mantra if the day.
Obviously some new, less clear, wording was called for.

--
Ben.

On 05/06/2022 14:47, Mr Flibble wrote:
> On Sun, 5 Jun 2022 07:58:42 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>> [...] Sort of like how the number Pi has an
>> exact value, but you can never actually express it (because it takes
>> an infinite number of digits).
> PI does not have an exact value; no irrational number has an exact
> value.

Of course "pi" has an exact value; as do [eg] "sqrt(2)", "e", and all
the other computable real [and complex] numbers. Whether that value can be
expressed in finite terms in some particular representation is quite another
matter. That in turn depends on the representation; standard decimals is
merely one [common] choice. Note that in symbolic computer systems, those
computable reals are typically written "pi" [or whatever], and the computer
works with that exactly, so that [eg] "sin^2 (pi/3) == 3/4", not 0.7499...;
and also that in decimal-type notations most rationals equally have no
terminating expansion. Numbers such as "pi" and "sqrt(2)" are not defined
as decimal expansions but via their properties [eg that "sqrt(2)" is the
unique positive real whose square is 2, or equivalently that it is the
ratio of the diagonal of a square to its side, and "pi" is the least
positive real whose sine is zero]. Those properties are exact, and tell
you all you ever need to know about those numbers.

[I have removed my name from the "Subject:"; I don't know why
anyone saw fit to attach it to this debate, such as it is, on the HP.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Palmgren

On Sun, 5 Jun 2022 16:28:05 +0100
Andy Walker <anw@cuboid.co.uk> wrote:

> On 05/06/2022 14:47, Mr Flibble wrote:
> > On Sun, 5 Jun 2022 07:58:42 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >> [...] Sort of like how the number Pi has an
> >> exact value, but you can never actually express it (because it
> >> takes an infinite number of digits).
> > PI does not have an exact value; no irrational number has an exact
> > value.
>
> Of course "pi" has an exact value; as do [eg] "sqrt(2)",
> "e", and all the other computable real [and complex] numbers.
> Whether that value can be expressed in finite terms in some
> particular representation is quite another matter. That in turn
> depends on the representation; standard decimals is merely one
> [common] choice. Note that in symbolic computer systems, those
> computable reals are typically written "pi" [or whatever], and the
> computer works with that exactly, so that [eg] "sin^2 (pi/3) == 3/4",
> not 0.7499...; and also that in decimal-type notations most rationals
> equally have no terminating expansion. Numbers such as "pi" and
> "sqrt(2)" are not defined as decimal expansions but via their
> properties [eg that "sqrt(2)" is the unique positive real whose
> square is 2, or equivalently that it is the ratio of the diagonal of
> a square to its side, and "pi" is the least positive real whose sine
> is zero]. Those properties are exact, and tell you all you ever need
> to know about those numbers.
>
> [I have removed my name from the "Subject:"; I don't know why
> anyone saw fit to attach it to this debate, such as it is, on the HP.]
What has decimal (base 10) expansion got to do with anything? An
irrational number has a non-terminating sequence in ANY base. I am
sorry but you are simply mistaken: irrational numbers do NOT have an
exact value; this is obvious to anyone who understands logic and uses a
sane definition for infinity.

/Flibble

Mr Flibble <flibble@reddwarf.jmc> wrote:
> On Sun, 5 Jun 2022 16:28:05 +0100
> Andy Walker <anw@cuboid.co.uk> wrote:

>> On 05/06/2022 14:47, Mr Flibble wrote:
>> > On Sun, 5 Jun 2022 07:58:42 -0400
>> > Richard Damon <Richard@Damon-Family.org> wrote:
>> >> [...] Sort of like how the number Pi has an
>> >> exact value, but you can never actually express it (because it
>> >> takes an infinite number of digits).
>> > PI does not have an exact value; no irrational number has an exact
>> > value.

>> Of course "pi" has an exact value; as do [eg] "sqrt(2)",
>> "e", and all the other computable real [and complex] numbers.
>> Whether that value can be expressed in finite terms in some
>> particular representation is quite another matter. That in turn
>> depends on the representation; standard decimals is merely one
>> [common] choice. Note that in symbolic computer systems, those
>> computable reals are typically written "pi" [or whatever], and the
>> computer works with that exactly, so that [eg] "sin^2 (pi/3) == 3/4",
>> not 0.7499...; and also that in decimal-type notations most rationals
>> equally have no terminating expansion. Numbers such as "pi" and
>> "sqrt(2)" are not defined as decimal expansions but via their
>> properties [eg that "sqrt(2)" is the unique positive real whose
>> square is 2, or equivalently that it is the ratio of the diagonal of
>> a square to its side, and "pi" is the least positive real whose sine
>> is zero]. Those properties are exact, and tell you all you ever need
>> to know about those numbers.

[ .... ]

> What has decimal (base 10) expansion got to do with anything? An
> irrational number has a non-terminating sequence in ANY base. I am
> sorry but you are simply mistaken: irrational numbers do NOT have an
> exact value; this is obvious to anyone who understands logic and uses
> a sane definition for infinity.

That irrational numbers are exact values is clear to anybody with a
degree in maths. Definitions of "infinity" (of which there are many)
have nothing to do with this.

> /Flibble

--
Alan Mackenzie (Nuremberg, Germany).

On Sun, 5 Jun 2022 15:44:32 -0000 (UTC)
Alan Mackenzie <acm@muc.de> wrote:

> Mr Flibble <flibble@reddwarf.jmc> wrote:
> > On Sun, 5 Jun 2022 16:28:05 +0100
> > Andy Walker <anw@cuboid.co.uk> wrote:
>
> >> On 05/06/2022 14:47, Mr Flibble wrote:
> >> > On Sun, 5 Jun 2022 07:58:42 -0400
> >> > Richard Damon <Richard@Damon-Family.org> wrote:
> >> >> [...] Sort of like how the number Pi has an
> >> >> exact value, but you can never actually express it (because it
> >> >> takes an infinite number of digits).
> >> > PI does not have an exact value; no irrational number has an
> >> > exact value.
>
> >> Of course "pi" has an exact value; as do [eg] "sqrt(2)",
> >> "e", and all the other computable real [and complex] numbers.
> >> Whether that value can be expressed in finite terms in some
> >> particular representation is quite another matter. That in turn
> >> depends on the representation; standard decimals is merely one
> >> [common] choice. Note that in symbolic computer systems, those
> >> computable reals are typically written "pi" [or whatever], and the
> >> computer works with that exactly, so that [eg] "sin^2 (pi/3) ==
> >> 3/4", not 0.7499...; and also that in decimal-type notations most
> >> rationals equally have no terminating expansion. Numbers such as
> >> "pi" and "sqrt(2)" are not defined as decimal expansions but via
> >> their properties [eg that "sqrt(2)" is the unique positive real
> >> whose square is 2, or equivalently that it is the ratio of the
> >> diagonal of a square to its side, and "pi" is the least positive
> >> real whose sine is zero]. Those properties are exact, and tell
> >> you all you ever need to know about those numbers.
>
> [ .... ]
>
> > What has decimal (base 10) expansion got to do with anything? An
> > irrational number has a non-terminating sequence in ANY base. I am
> > sorry but you are simply mistaken: irrational numbers do NOT have an
> > exact value; this is obvious to anyone who understands logic and
> > uses a sane definition for infinity.
>
> That irrational numbers are exact values is clear to anybody with a
> degree in maths. Definitions of "infinity" (of which there are many)
> have nothing to do with this.

You are wrong and fractally so so your degree in maths appears to be
worthless. An irrational number's sequence is statistically random,
has no fixed point on the number line ergo has no exact representation.
Any number with no exact representation has, by definition, no exact
value, only an approximation. Infinity has everything to do with this
as an irrational's sequence ("digits") never terminates (i.e. it is an
INFINITELY long sequence).

/Flibble

On 6/5/2022 7:38 AM, Ben wrote:
> Alan Mackenzie <acm@muc.de> writes:
>
>> olcott <NoOne@nowhere.com> wrote:
>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>
>>>> ... What would be the turing machine equivalent of an
>>>> "abnormal termination" in C?
>>
>>> An aborted simulation.
>>
>> There's no such thing on a turing machine. It either runs and halts, or
>> it runs forever.
>>
>> Your aborted simulation is just one final state of a turing machine,
>> which has thus halted.
>
> A year ago I tried to get PO to accept a few basic facts about the
> topic. One of these was
>
> (B) Every computation that halts, for whatever reason, is a halting
> computation.
>
> After much ducking a diving, PO replied "OK".
>

Whatever I said years ago has been superseded by my current understanding:

Computation that halts ... the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/5/2022 10:17 AM, Ben wrote:
> Ben <ben.usenet@bsb.me.uk> writes:
>
>> Alan Mackenzie <acm@muc.de> writes:
>>
>>> olcott <NoOne@nowhere.com> wrote:
>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>
>>>>> ... What would be the turing machine equivalent of an
>>>>> "abnormal termination" in C?
>>>
>>>> An aborted simulation.
>>>
>>> There's no such thing on a turing machine. It either runs and halts, or
>>> it runs forever.
>>>
>>> Your aborted simulation is just one final state of a turing machine,
>>> which has thus halted.
>>
>> A year ago I tried to get PO to accept a few basic facts about the
>> topic. One of these was
>>
>> (B) Every computation that halts, for whatever reason, is a halting
>> computation.
>>
>> After much ducking [and] diving, PO replied "OK".
>
> I should explain that the purpose of this question was because, at the
> time, PO was claiming that the reason H_Hat(H_Hat) halts was "special":
> the consequence of a simulation being stopped. The fact that
> H_Hat(H_Hat) halts for some special reason used to be feature of PO's
> posts. The phrasing "H(H_Hat, H_Hat) == 0 is correct because
> H_Hat(H_Hat) only halts because..." was the mantra if the day.
> Obviously some new, less clear, wording was called for.
>

Computation that halts ... the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

It is true that the correctly simulated input to H(P,P) never reaches
its own final state thus never halts.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 6/5/2022 9:46 AM, Mike Terry wrote:
> On 05/06/2022 13:14, Alan Mackenzie wrote:
>> olcott <NoOne@nowhere.com> wrote:
>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>> olcott <NoOne@nowhere.com> wrote:
>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>
>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>> configuration for which δ is not defined; this is possible because
>>>>>>> δ is a partial function. In fact, we will assume that no
>>>>>>> transitions are defined for any final state so the Turing machine
>>>>>>> will halt whenever it enters a final state.  (Linz:1990:234)
>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>
>>>>>>> When translated into ordinary software engineering terms this means
>>>>>>> terminated normally. In a C function this means reaching the "ret"
>>>>>>> instruction.
>>
>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>>>> defined" should include at least:
>>>>>> - HLT or any other instruction that means 'halt'
>>>>>> - any undefined op code
>>>>>> - any return or pop instruction if the stack is empty
>>>>>> - an instruction fetch from a location that is not specifiec by the
>>>>>>     program
>>>>>> That way the analogy to Linz' definition is much better.
>>
>>>>>> Mikko
>>
>>>>> Reaching a final state is merely the Turing machine way of saying
>>>>> terminated normally. "ret" is the C way of saying the same thing.
>>
>>>> Sophistry.  What would be the turing machine equivalent of an
>>>> "abnormal termination" in C?
>>
>>> An aborted simulation.
>>
>> There's no such thing on a turing machine.  It either runs and halts, or
>> it runs forever.
>>
>> Your aborted simulation is just one final state of a turing machine,
>> which has thus halted.
>
> A TM "aborting" a simulation is just the TM ceasing to calculate
> computation steps for some computation, and going on to calculate
> something else instead.  It does not mean:
> a)  that the TM (doing the simulation) has halted
> b)  that the simulated computation halts
> c)  that the simulated computation never halts
>
> Regards,
> Mike.
>

That an aborted simulated has not reached a final state has not halted
is proven by the fact that your screwy reasoning would have to conclude
that an infinite loop halts.

*This is a Stipulative definition*
Computation that halts ... the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

A stipulative definition is a type of definition in which a new or
currently existing term is given a new specific meaning for the purposes
of argument or discussion in a given context.
https://en.wikipedia.org/wiki/Stipulative_definition

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer