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

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 Sat, 4 Jun 2022 11:14:19 -0500
olcott <NoOne@NoWhere.com> wrote:
>On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
>> On Fri, 3 Jun 2022 17:17:12 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>> This post assumes that you already know my work, otherwise please read
>>> the linked paper provided below. This work is based on the x86utm
>>
>> Thanks, but I need to go watch some paint dry. Maybe next time.
>>
>>
>
>Until the notion of truth itself is formalized research in artificial
>intelligence is hobbled.
>
>A correct refutation of the halting problem proofs also refutes the
>Tarski undefinability theorem by proxy, thus enabling the notion of
>truth to be formalized.
>
>This anchors the basis of Davidson's truth conditional semantics. This
>creates the roadmap for artificial intelligence with unlimited potential.
>
>Halting problem undecidability and infinitely nested simulation (V5)

You sound like the output of a simple markov chain chat bot thats been fed
some doctorate level CS papers.

On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
> On Sat, 4 Jun 2022 11:14:19 -0500
> olcott <NoOne@NoWhere.com> wrote:
>> On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>> This post assumes that you already know my work, otherwise please read
>>>> the linked paper provided below. This work is based on the x86utm
>>>
>>> Thanks, but I need to go watch some paint dry. Maybe next time.
>>>
>>>
>>
>> Until the notion of truth itself is formalized research in artificial
>> intelligence is hobbled.
>>
>> A correct refutation of the halting problem proofs also refutes the
>> Tarski undefinability theorem by proxy, thus enabling the notion of
>> truth to be formalized.
>>
>> This anchors the basis of Davidson's truth conditional semantics. This
>> creates the roadmap for artificial intelligence with unlimited potential.
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>
> You sound like the output of a simple markov chain chat bot thats been fed
> some doctorate level CS papers.
>

I posted to this group because I have boiled down a key computer science
problem into ordinary software engineering in C/x86.

In computability theory, the halting problem is the problem of
determining,
from a description of an arbitrary computer program and an input,
whether
the program will finish running, or continue to run forever. Alan
Turing proved
in 1936 that a general algorithm to solve the halting problem for
all possible
program-input pairs cannot exist.

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

#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 of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

Because we can easily see that H(P,P)==0 is correct we can know that the
otherwise "impossible" input to the halting problem proofs is correctly
rejected as non-halting.

--
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 05.06.22 22:05, olcott wrote:
> On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
>> On Sat, 4 Jun 2022 11:14:19 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>> On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> This post assumes that you already know my work, otherwise please read
>>>>> the linked paper provided below. This work is based on the x86utm
>>>>
>>>> Thanks, but I need to go watch some paint dry. Maybe next time.
>>>>
>>>>
>>>
>>> Until the notion of truth itself is formalized research in artificial
>>> intelligence is hobbled.
>>>
>>> A correct refutation of the halting problem proofs also refutes the
>>> Tarski undefinability theorem by proxy, thus enabling the notion of
>>> truth to be formalized.
>>>
>>> This anchors the basis of Davidson's truth conditional semantics. This
>>> creates the roadmap for artificial intelligence with unlimited
>>> potential.
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> You sound like the output of a simple markov chain chat bot thats been
>> fed
>> some doctorate level CS papers.
>>
>
> I posted to this group because I have boiled down a key computer science
> problem into ordinary software engineering in C/x86.
>
>      In computability theory, the halting problem is the problem of
> determining,
>      from a description of an arbitrary computer program and an input,
> whether
>      the program will finish running, or continue to run forever. Alan
> Turing proved
>      in 1936 that a general algorithm to solve the halting problem for
> all possible
>      program-input pairs cannot exist.
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
>
> #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 of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
> Because we can easily see that H(P,P)==0 is correct we can know that the
> otherwise "impossible" input to the halting problem proofs is correctly
> rejected as non-halting.
>
>
>
What about the opposite: can you make a program that always correctly
predicts that another program will halt? It doesn't seem to me that this
case is included in what you did, but I must admit, computer science is
not my major.

On 6/5/2022 3:24 PM, Freethinker wrote:
> On 05.06.22 22:05, olcott wrote:
>> On 6/5/2022 9:58 AM, Muttley@dastardlyhq.com wrote:
>>> On Sat, 4 Jun 2022 11:14:19 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>> On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>> This post assumes that you already know my work, otherwise please
>>>>>> read
>>>>>> the linked paper provided below. This work is based on the x86utm
>>>>>
>>>>> Thanks, but I need to go watch some paint dry. Maybe next time.
>>>>>
>>>>>
>>>>
>>>> Until the notion of truth itself is formalized research in artificial
>>>> intelligence is hobbled.
>>>>
>>>> A correct refutation of the halting problem proofs also refutes the
>>>> Tarski undefinability theorem by proxy, thus enabling the notion of
>>>> truth to be formalized.
>>>>
>>>> This anchors the basis of Davidson's truth conditional semantics. This
>>>> creates the roadmap for artificial intelligence with unlimited
>>>> potential.
>>>>
>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> You sound like the output of a simple markov chain chat bot thats
>>> been fed
>>> some doctorate level CS papers.
>>>
>>
>> I posted to this group because I have boiled down a key computer
>> science problem into ordinary software engineering in C/x86.
>>
>>       In computability theory, the halting problem is the problem of
>> determining,
>>       from a description of an arbitrary computer program and an
>> input, whether
>>       the program will finish running, or continue to run forever.
>> Alan Turing proved
>>       in 1936 that a general algorithm to solve the halting problem
>> for all possible
>>       program-input pairs cannot exist.
>>
>>       For any program H that might determine if programs halt, a
>> "pathological"
>>       program P, called with some input, can pass its own source and
>> its input to
>>       H and then specifically do the opposite of what H predicts P
>> will do. No H
>>       can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>>
>>
>> #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 of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>> Because we can easily see that H(P,P)==0 is correct we can know that
>> the otherwise "impossible" input to the halting problem proofs is
>> correctly rejected as non-halting.
>>
>>
>>
> What about the opposite: can you make a program that always correctly
> predicts that another program will halt? It doesn't seem to me that this
> case is included in what you did, but I must admit, computer science is
> not my major.

The whole scope of my investigation was to simply correctly refute the
conventional halting problem proofs, thus proving that a universal halt
decider is possible. Actually making a a universal halt decider would
take at least 1000 labor years.

--
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 6:59 PM, Mike Terry wrote:
> On 05/06/2022 22:59, Jeff Barnett wrote:
>> On 6/5/2022 2:07 PM, Mike Terry wrote:
>>> On 05/06/2022 16:16, Alan Mackenzie wrote:
>>>> 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.
>>>
>>> We are clearly talking at cross purposes - I never talked about
>>> /part/ of a TM halting, and like you, I can't work out what that
>>> would mean!  I used "halt" only with respect to a computation,
>>> meaning that the computation halts [there is an n such that
>>> computation step n is a TM final state].
>>>
>>> Reading what you say very carefully, I think that by your definition
>>> of simulation, the simulating TM must be a "pure" simulator that does
>>> nothing but simulate computation steps until the simulation halts, at
>>> which point the simulating TM halts (like a UTM).  I get that with
>>> that interpretation what you said:
>>>
>>> <copied from above>
>>>  >>> Your aborted simulation is just one final state of a turing
>>> machine,
>>>  >>> which has thus halted.
>>>
>>>   makes sense and is correct.  I'd just say I don't think that usage
>>> of "simulation" is very useful, and is DEFINITELY not what PO is
>>> talking about (so it would be wrong if applied PO's posts...)
>>>
>>> My use of "simulation" is broader: it's simply the activity performed
>>> by a TM which consists of calculating computation steps of some given
>>> computation.  As such it's just a part of the TM logic. A TM's
>>> typical use of simulation might be something like "..the TM simulates
>>> the computation for n steps, and if the simulation halts during those
>>> n steps, the TM [blah blah], /otherwise/ the TM [blah blah blah]...".
>>> Just about every reference in the literature I can recall is
>>> something like that.
>>>
>>> So... to be 100% clear on what I said:
>>>
>>> <copied from above>
>>>  >> 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.
>>>
>>> E.g. in PO's P, after P aborts its simulation of P(P), the TM either
>>> halts or enters an infinite loop.  (That logic is not part of the
>>> simulation, IMO.)
>>>
>>>  >> It does *NOT* mean:
>>>  >> a)  that the TM (doing the simulation) has halted
>>>
>>> obviously, because now P has gone on to something else...
>>>
>>>  >> b)  that the simulated computation halts
>>>  >> c)  that the simulated computation never halts
>>>
>>> obviously - in general different exacmples of a simulated computation
>>> P(I) might halt or never halt, and this is unaffected by a
>>> simulator's decision to simulate no further computation steps. [The
>>> TM may have spotted some pattern in the simulated computation which
>>> implies P(I) never halts - that is a separate matter, but for sure
>>> the mere act of "aborting" the simulation doesn't imply P(I) never
>>> halts, or imply that it halts...
>>>
>>> Put yet another way, when a TM stops calculating TM steps (aka aborts
>>> its simulation), NOTHING HALTS: not the simulating TM, not the
>>> simulated computation, and NOT ANY PART OF EITHER OF THOSE. (Like you
>>> say, what would part of a TM halting mean?)
>>
>> I think of a TM and an input string as defining a sequence (an ordered
>> list). The elements of the sequence are pairs of a TM state name and a
>> string representing the "tape" contents when the state was entered.
>> Note that this view has no character of animation in it and makes the
>> definition of the halt predicate (H) trivial:
>>
>> H(TM,STRING) = If length of TM(STRING) is finite then TRUE else FALSE.
>
> Yes, that's equivalent to what I said (or at least meant).  Your
> sequence is my computation steps. Formally, these would be defined
> inductively via the rule to go from step n to step n+1.  (Not an
> animation, but the induction gives some /sense/ of step-by-step
> calculation, and a simulator will follow this, starting at step 1, then
> calculate step 2 and so on.  Still, I agree the entire sequence [the
> "computation"] exists as one timeless structure.  Too abstract for PO...)
>

On 6/5/22 8:27 PM, olcott wrote:
> On 6/5/2022 6:59 PM, Mike Terry wrote:
>> On 05/06/2022 22:59, Jeff Barnett wrote:
>>> On 6/5/2022 2:07 PM, Mike Terry wrote:
>>>> On 05/06/2022 16:16, Alan Mackenzie wrote:
>>>>> 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.
>>>>
>>>> We are clearly talking at cross purposes - I never talked about
>>>> /part/ of a TM halting, and like you, I can't work out what that
>>>> would mean!  I used "halt" only with respect to a computation,
>>>> meaning that the computation halts [there is an n such that
>>>> computation step n is a TM final state].
>>>>
>>>> Reading what you say very carefully, I think that by your definition
>>>> of simulation, the simulating TM must be a "pure" simulator that
>>>> does nothing but simulate computation steps until the simulation
>>>> halts, at which point the simulating TM halts (like a UTM).  I get
>>>> that with that interpretation what you said:
>>>>
>>>> <copied from above>
>>>>  >>> Your aborted simulation is just one final state of a turing
>>>> machine,
>>>>  >>> which has thus halted.
>>>>
>>>>   makes sense and is correct.  I'd just say I don't think that usage
>>>> of "simulation" is very useful, and is DEFINITELY not what PO is
>>>> talking about (so it would be wrong if applied PO's posts...)
>>>>
>>>> My use of "simulation" is broader: it's simply the activity
>>>> performed by a TM which consists of calculating computation steps of
>>>> some given computation.  As such it's just a part of the TM logic. A
>>>> TM's typical use of simulation might be something like "..the TM
>>>> simulates the computation for n steps, and if the simulation halts
>>>> during those n steps, the TM [blah blah], /otherwise/ the TM [blah
>>>> blah blah]...". Just about every reference in the literature I can
>>>> recall is something like that.
>>>>
>>>> So... to be 100% clear on what I said:
>>>>
>>>> <copied from above>
>>>>  >> 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.
>>>>
>>>> E.g. in PO's P, after P aborts its simulation of P(P), the TM either
>>>> halts or enters an infinite loop.  (That logic is not part of the
>>>> simulation, IMO.)
>>>>
>>>>  >> It does *NOT* mean:
>>>>  >> a)  that the TM (doing the simulation) has halted
>>>>
>>>> obviously, because now P has gone on to something else...
>>>>
>>>>  >> b)  that the simulated computation halts
>>>>  >> c)  that the simulated computation never halts
>>>>
>>>> obviously - in general different exacmples of a simulated
>>>> computation P(I) might halt or never halt, and this is unaffected by
>>>> a simulator's decision to simulate no further computation steps.
>>>> [The TM may have spotted some pattern in the simulated computation
>>>> which implies P(I) never halts - that is a separate matter, but for
>>>> sure the mere act of "aborting" the simulation doesn't imply P(I)
>>>> never halts, or imply that it halts...
>>>>
>>>> Put yet another way, when a TM stops calculating TM steps (aka
>>>> aborts its simulation), NOTHING HALTS: not the simulating TM, not
>>>> the simulated computation, and NOT ANY PART OF EITHER OF THOSE.
>>>> (Like you say, what would part of a TM halting mean?)
>>>
>>> I think of a TM and an input string as defining a sequence (an
>>> ordered list). The elements of the sequence are pairs of a TM state
>>> name and a string representing the "tape" contents when the state was
>>> entered. Note that this view has no character of animation in it and
>>> makes the definition of the halt predicate (H) trivial:
>>>
>>> H(TM,STRING) = If length of TM(STRING) is finite then TRUE else FALSE.
>>
>> Yes, that's equivalent to what I said (or at least meant).  Your
>> sequence is my computation steps. Formally, these would be defined
>> inductively via the rule to go from step n to step n+1.  (Not an
>> animation, but the induction gives some /sense/ of step-by-step
>> calculation, and a simulator will follow this, starting at step 1,
>> then calculate step 2 and so on.  Still, I agree the entire sequence
>> [the "computation"] exists as one timeless structure.  Too abstract
>> for PO...)
>>
>
> In other words when we make sure to conflate the program under test with
> the test program as a single computation then the whole idea of a halt
> decider becomes less coherent and
>
> this can be used as an excuse to pretend that you don't already know
> that H(P,P)==0 is correct and the H/P relationship matches the halting
> problem counter example template.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
>
>>>
>>> A simulator animates the production of the sequence and that causes
>>> some difficulties in the same way that elaborating an infinite sum or
>>> sequence does in math classes. An (ultimate) value only exists if
>>> there is some notation of convergence or limit which typically is the
>>> case with examples used in a math class. There is no definition of
>>> convergence or limit with the sequence defined by TM(STRING); rather,
>>> we simply ask about the last pair if the sequence is finite.
>>
>> Sure.
>> The question right now is what you would call a TM which evaluates the
>> first 10 steps of a computation, and then does something else.  What
>> is it doing while evaluating those 10 steps?
>>
>> tl;dr : who cares :)
>>
>> My terminology would be that it's "simulating" the computation (just
>> for 10 steps) - then it stops simulating and does something else.
>> Obviously I wouldn't describe it as "correctly" simulating, because
>> nobody considers incorrect simulations, so the word would be redundant!
>
> It is required because my reviewers are making their best possible
> effort to form rebuttals and the most persistent of the fake rebuttals
> has been that the simulation is incorrect.  It is very easy to verify
> the correct x86 emulation on the basis of the x86 language.

On 6/5/2022 7:40 PM, Ben wrote:
> Jeff Barnett <jbb@notatt.com> writes:
>
>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>
>>> The question right now is what you would call a TM which evaluates
>>> the first 10 steps of a computation, and then does something else.
>>> What is it doing while evaluating those 10 steps?
>>
>> What would I call it? POOP! It just goes to show the accuracy and
>> flexibility of Ben's acronym for any Peter-related concept.
>
> Credit where it's due... POOP is Richard's. Mine was not as good.
>

That was the initial incorrect rebuttal that claimed the concept of a
simulating halt decider is inherently invalid.

When a simulating halt decider H correctly predicts that its complete
simulation of its input finite string would never reach the final state
of this machine description then H has correctly rejected this input as
non-halting.

--
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 9:03 PM, olcott wrote:
> On 6/5/2022 7:40 PM, Ben wrote:
>> Jeff Barnett <jbb@notatt.com> writes:
>>
>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>
>>>> The question right now is what you would call a TM which evaluates
>>>> the first 10 steps of a computation, and then does something else.
>>>> What is it doing while evaluating those 10 steps?
>>>
>>> What would I call it? POOP! It just goes to show the accuracy and
>>> flexibility of Ben's acronym for any Peter-related concept.
>>
>> Credit where it's due... POOP is Richard's.  Mine was not as good.
>>
>
> That was the initial incorrect rebuttal that claimed the concept of a
> simulating halt decider is inherently invalid.
>
> When a simulating halt decider H correctly predicts that its complete
> simulation of its input finite string would never reach the final state
> of this machine description then H has correctly rejected this input as
> non-halting.
>

No, its based on the fact that you are trying to define the "correct"
answer for H to be something different than what the Halting Problem
Requires.

The DEFINITION of the Halting Problem is that

H applied to <M> w needs to accept the input if M applied to w Halts and
reject if M applied to w never halts.

You want to change that to being based on "The correct simulation of its
input by H reaching a final state", which is not equivalent.

The key point is that by the classical definition of what a "correct
simulation" would be that actually shows non-halting, a simulator that
does that CAN'T answer non-halting, because the definition of a correct
simulation of a non-halting machine is a non-halting simulation. (i.e.
the behavior of a UTM).

If your definition was based on "The correct simulation of its input by
a UTM", then it would be ok, but since that isn't what you mean, your
definition is different than the original, so it is your "Other Problem".

It isn't that a simulating Halt Deicder is inherently invalid, but even
a simulating halt decider needs to use the original definition of
Halting, which means either looking that the behavior of the original
machine, or the UTM simulation of the representation of it.

Yes, this gives the decider an inherent problem, that it, like ALL Halt
Deciders, needs to decide in finite time something that takes unbounded
time to directly prove, but that is the nature of the Halting Problem,
and what made it interesting. The hope initially was that there might be
some "trick" that could be done to analyise the machine/input and be
able to determine halting without needing to actually run the machine to
the halting state (or a point it was clear that it would never halt).
Turing showed that there could not be such a trick.

You keep on erring because you start with assumptions that implicitly
assume that a machine to give the answer is possible, when it isn't, and
this leads you to a false conclusion and an inconsistent logic system.

Many of your arguments actually boil down to, If I had a routine that
solved the Halting Problem, I could wrap it up in code to transform the
input into a somewhat different problem but with the same answer, and
ask that routine about this new problem.

On 6/5/2022 8:58 PM, Mike Terry wrote:
> On 06/06/2022 01:24, Jeff Barnett wrote:
>> On 6/5/2022 5:59 PM, Mike Terry wrote:
> <..snip..>>>
>>> Sure.
>>> The question right now is what you would call a TM which evaluates
>>> the first 10 steps of a computation, and then does something else.
>>> What is it doing while evaluating those 10 steps?
>>
>> What would I call it? POOP! It just goes to show the accuracy and
>> flexibility of Ben's acronym for any Peter-related concept.
>>
>
> But PO didn't invent the concept of (partially) simulating a computation
> in order to compute certain properties of that computation!  It's been
> around since Turing's days, and is very useful.
>
> Mike.

That is true. I am apparently the first one that ever thought this
through well enough so that machine descriptions matching the following
pattern could be correctly determined to be non-halting:

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

In that a partial simulation does correctly predict the behavior of a
complete simulation it can be used to recognize infinite behavior patterns.

--
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 8:59 PM, Richard Damon wrote:
> On 6/5/22 9:03 PM, olcott wrote:
>> On 6/5/2022 7:40 PM, Ben wrote:
>>> Jeff Barnett <jbb@notatt.com> writes:
>>>
>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>
>>>>> The question right now is what you would call a TM which evaluates
>>>>> the first 10 steps of a computation, and then does something else.
>>>>> What is it doing while evaluating those 10 steps?
>>>>
>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>
>>> Credit where it's due... POOP is Richard's.  Mine was not as good.
>>>
>>
>> That was the initial incorrect rebuttal that claimed the concept of a
>> simulating halt decider is inherently invalid.
>>
>> When a simulating halt decider H correctly predicts that its complete
>> simulation of its input finite string would never reach the final
>> state of this machine description then H has correctly rejected this
>> input as non-halting.
>>
>
> No, its based on the fact that you are trying to define the "correct"
> answer for H to be something different than what the Halting Problem
> Requires.

If that was true then one of these facts wold not be verified:
(1) The relationship between H and P matches the pattern specified below:

(2) H does correctly compute the mapping from the x86 machine code to
its reject state on the basis

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

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

int main()
{ Output("Input_Halts = ", H1((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
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[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]

--
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 10:11 PM, olcott wrote:
> On 6/5/2022 8:58 PM, Mike Terry wrote:
>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>> <..snip..>>>
>>>> Sure.
>>>> The question right now is what you would call a TM which evaluates
>>>> the first 10 steps of a computation, and then does something else.
>>>> What is it doing while evaluating those 10 steps?
>>>
>>> What would I call it? POOP! It just goes to show the accuracy and
>>> flexibility of Ben's acronym for any Peter-related concept.
>>>
>>
>> But PO didn't invent the concept of (partially) simulating a
>> computation in order to compute certain properties of that
>> computation!  It's been around since Turing's days, and is very useful.
>>
>> Mike.
>
> That is true. I am apparently the first one that ever thought this
> through well enough so that machine descriptions matching the following
> pattern could be correctly determined to be non-halting:
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> In that a partial simulation does correctly predict the behavior of a
> complete simulation it can be used to recognize infinite behavior patterns.
>

Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by
the DEFINITION of the requirements of the Halting Problem, H(P,P) needs
to accept (return 1) if P(P) Halts, thus H was incorrect for a Halting
Decider.

You just try to use twisted words to try and describe what H actually
did decide on to be close to words that could be used to descirbe the
Halting Problem. But the slight difference is important, even if you
don't think so.

That just shows your level (or lack thereof) of knowledge of the field.

On 6/5/2022 9:20 PM, Richard Damon wrote:
> On 6/5/22 10:11 PM, olcott wrote:
>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>> <..snip..>>>
>>>>> Sure.
>>>>> The question right now is what you would call a TM which evaluates
>>>>> the first 10 steps of a computation, and then does something else.
>>>>> What is it doing while evaluating those 10 steps?
>>>>
>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>
>>>
>>> But PO didn't invent the concept of (partially) simulating a
>>> computation in order to compute certain properties of that
>>> computation!  It's been around since Turing's days, and is very useful.
>>>
>>> Mike.
>>
>> That is true. I am apparently the first one that ever thought this
>> through well enough so that machine descriptions matching the
>> following pattern could be correctly determined to be non-halting:
>>
>>       For any program H that might determine if programs halt, a
>> "pathological"
>>       program P, called with some input, can pass its own source and
>> its input to
>>       H and then specifically do the opposite of what H predicts P
>> will do. No H
>>       can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> In that a partial simulation does correctly predict the behavior of a
>> complete simulation it can be used to recognize infinite behavior
>> patterns.
>>
>
> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by
> the DEFINITION of the requirements of the Halting Problem, H(P,P) needs
> to accept (return 1) if P(P) Halts,
This seems to be brand new computer science that I just discovered.

Previously no one understood that it was possible for the correct
simulation of the input to H(P,P) to be computationally distinct (thus
not equivalent) to the direct execution of P(P).

Because of this all of the computer science textbooks refer to the
halting behavior of P(P) as what must be decided by the halt decider.

This same computer science also knows that a decider must compute the
mapping of its input finite string to an accept or reject state on the
basis of a property of this input encoded in this finite string.

THE FOLLOWING CRITERIA ALWAYS WORKS
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 UTM simulation of this input by H.

It has been completely proven that partial simulations do correctly
predict the behavior of some complete simulations.

--
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 10:14 PM, olcott wrote:
> On 6/5/2022 8:59 PM, Richard Damon wrote:
>> On 6/5/22 9:03 PM, olcott wrote:
>>> On 6/5/2022 7:40 PM, Ben wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>
>>>>>> The question right now is what you would call a TM which evaluates
>>>>>> the first 10 steps of a computation, and then does something else.
>>>>>> What is it doing while evaluating those 10 steps?
>>>>>
>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>
>>>> Credit where it's due... POOP is Richard's.  Mine was not as good.
>>>>
>>>
>>> That was the initial incorrect rebuttal that claimed the concept of a
>>> simulating halt decider is inherently invalid.
>>>
>>> When a simulating halt decider H correctly predicts that its complete
>>> simulation of its input finite string would never reach the final
>>> state of this machine description then H has correctly rejected this
>>> input as non-halting.
>>>
>>
>> No, its based on the fact that you are trying to define the "correct"
>> answer for H to be something different than what the Halting Problem
>> Requires.
>
> If that was true then one of these facts wold not be verified:
> (1) The relationship between H and P matches the pattern specified below:
>
> (2) H does correctly compute the mapping from the x86 machine code to
> its reject state on the basis

No definition of what "Correct computes the mapping"

Remember the MAPPING that H needs to compute is that

H(<M>, w) accepts if M(w) Halts, and rejects if M(w) doesn't halt.
No mention of "simulations" here.

Since P(P) is shown to Halt if H(P,P) returns 0 (reject), that mapping
is NOT correctly computed.

>
>      For any program H that might determine if programs halt, a
> "pathological" >      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

Since you H didn't handle the case, because H(P,P) results in a
rejection, while P(P) Halts, you haven't show correctly computing of the
Halting Map.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H1((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
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx
> [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]
>
>
>

Not even your broken trace?

Your slipping.

FAIL.

On 6/5/22 10:37 PM, olcott wrote:
> On 6/5/2022 9:20 PM, Richard Damon wrote:
>> On 6/5/22 10:11 PM, olcott wrote:
>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>> <..snip..>>>
>>>>>> Sure.
>>>>>> The question right now is what you would call a TM which evaluates
>>>>>> the first 10 steps of a computation, and then does something else.
>>>>>> What is it doing while evaluating those 10 steps?
>>>>>
>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>>
>>>>
>>>> But PO didn't invent the concept of (partially) simulating a
>>>> computation in order to compute certain properties of that
>>>> computation!  It's been around since Turing's days, and is very useful.
>>>>
>>>> Mike.
>>>
>>> That is true. I am apparently the first one that ever thought this
>>> through well enough so that machine descriptions matching the
>>> following pattern could be correctly determined to be non-halting:
>>>
>>>       For any program H that might determine if programs halt, a
>>> "pathological"
>>>       program P, called with some input, can pass its own source and
>>> its input to
>>>       H and then specifically do the opposite of what H predicts P
>>> will do. No H
>>>       can exist that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> In that a partial simulation does correctly predict the behavior of a
>>> complete simulation it can be used to recognize infinite behavior
>>> patterns.
>>>
>>
>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by
>> the DEFINITION of the requirements of the Halting Problem, H(P,P)
>> needs to accept (return 1) if P(P) Halts,
> This seems to be brand new computer science that I just discovered.
>
> Previously no one understood that it was possible for the correct
> simulation of the input to H(P,P) to be computationally distinct (thus
> not equivalent) to the direct execution of P(P).

By what definition of "Correct" are you using?

That is like says I can be correct at saying 1+2 = 4 if I just redefine
1+2 to be 4.

Note, if you correct deviates IN ANY WAY, from the UTM definition, you
can't use it in your definiton of the Halting Problem.

>
> Because of this all of the computer science textbooks refer to the
> halting behavior of P(P) as what must be decided by the halt decider.

Because that IS what must be decided by the Halt Decider.

>
> This same computer science also knows that a decider must compute the
> mapping of its input finite string to an accept or reject state on the
> basis of a property of this input encoded in this finite string.

Right, and the property is the Halting status of UTM(P,P).

That is a FULLY DEFINED property.

>
> THE FOLLOWING CRITERIA ALWAYS WORKS
> 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 UTM simulation of this input by H.

Right, UTM simulation, and UTM simulation of its input is DEFINED to
match the behavior of the machine its input represents.

Thus BY DEFINITON UTM(<M>, w) matches the behavior of M(w). It isn't
"computationall distinct" as you tried to claim above.

So UTM(P,P) matches P(P), and you answer is proved incorrect, since P(P)
Halts if H(P,P) returns 0, and thus UTM(P,P) will halt, and thus H(P,P)
needed to accept (return 1), which it didn't so it is wrong.

>
> It has been completely proven that partial simulations do correctly
> predict the behavior of some complete simulations.
>

yes, SOME, but not this one.

FALLICY of proof by example.

1st grade error.

On 6/5/2022 9:52 PM, Richard Damon wrote:
>
> On 6/5/22 10:37 PM, olcott wrote:
>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>> On 6/5/22 10:11 PM, olcott wrote:
>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>> <..snip..>>>
>>>>>>> Sure.
>>>>>>> The question right now is what you would call a TM which
>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>
>>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>>>
>>>>>
>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>> computation in order to compute certain properties of that
>>>>> computation!  It's been around since Turing's days, and is very
>>>>> useful.
>>>>>
>>>>> Mike.
>>>>
>>>> That is true. I am apparently the first one that ever thought this
>>>> through well enough so that machine descriptions matching the
>>>> following pattern could be correctly determined to be non-halting:
>>>>
>>>>       For any program H that might determine if programs halt, a
>>>> "pathological"
>>>>       program P, called with some input, can pass its own source and
>>>> its input to
>>>>       H and then specifically do the opposite of what H predicts P
>>>> will do. No H
>>>>       can exist that handles this case.
>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> In that a partial simulation does correctly predict the behavior of
>>>> a complete simulation it can be used to recognize infinite behavior
>>>> patterns.
>>>>
>>>
>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which,
>>> by the DEFINITION of the requirements of the Halting Problem, H(P,P)
>>> needs to accept (return 1) if P(P) Halts,
>> This seems to be brand new computer science that I just discovered.
>>
>> Previously no one understood that it was possible for the correct
>> simulation of the input to H(P,P) to be computationally distinct (thus
>> not equivalent) to the direct execution of P(P).
>
> By what definition of "Correct" are you using?

Ordinary software engineering proves that a correct and complete x86
emulation of the input to H(P,P) never reaches its "ret" instruction.

_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]

--
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 11:03 PM, olcott wrote:
> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>
>> On 6/5/22 10:37 PM, olcott wrote:
>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>> <..snip..>>>
>>>>>>>> Sure.
>>>>>>>> The question right now is what you would call a TM which
>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>>
>>>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>
>>>>>>
>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>> computation in order to compute certain properties of that
>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>> useful.
>>>>>>
>>>>>> Mike.
>>>>>
>>>>> That is true. I am apparently the first one that ever thought this
>>>>> through well enough so that machine descriptions matching the
>>>>> following pattern could be correctly determined to be non-halting:
>>>>>
>>>>>       For any program H that might determine if programs halt, a
>>>>> "pathological"
>>>>>       program P, called with some input, can pass its own source
>>>>> and its input to
>>>>>       H and then specifically do the opposite of what H predicts P
>>>>> will do. No H
>>>>>       can exist that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> In that a partial simulation does correctly predict the behavior of
>>>>> a complete simulation it can be used to recognize infinite behavior
>>>>> patterns.
>>>>>
>>>>
>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which,
>>>> by the DEFINITION of the requirements of the Halting Problem, H(P,P)
>>>> needs to accept (return 1) if P(P) Halts,
>>> This seems to be brand new computer science that I just discovered.
>>>
>>> Previously no one understood that it was possible for the correct
>>> simulation of the input to H(P,P) to be computationally distinct
>>> (thus not equivalent) to the direct execution of P(P).
>>
>> By what definition of "Correct" are you using?
>
>
> Ordinary software engineering proves that a correct and complete x86
> emulation of the input to H(P,P) never reaches its "ret" instruction.
>

So, I guess this just shows that you don't actually know a definition
that shows this, so this is just another of your lies.

Also, it is shown that P(P) Halts if H(P,P) returns 0, and even YOU have
accepted that fact, so that also shows that you must be lying, since
Ordinary Software Engineering doesn't 'prove' lies.

Remember, correct and complete x86 emulation behaves exactly like the
x86 program that is being emulated, in this case, P(P).

Maybe YOUR knowledge of software engineering says that, but that says
more about your (lack of) knowledge of real software engineering.

> _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]
>
>

On 6/5/2022 10:26 PM, Richard Damon wrote:
> On 6/5/22 11:03 PM, olcott wrote:
>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>
>>> On 6/5/22 10:37 PM, olcott wrote:
>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>> <..snip..>>>
>>>>>>>>> Sure.
>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>>>
>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>
>>>>>>>
>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>> computation in order to compute certain properties of that
>>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>>> useful.
>>>>>>>
>>>>>>> Mike.
>>>>>>
>>>>>> That is true. I am apparently the first one that ever thought this
>>>>>> through well enough so that machine descriptions matching the
>>>>>> following pattern could be correctly determined to be non-halting:
>>>>>>
>>>>>>       For any program H that might determine if programs halt, a
>>>>>> "pathological"
>>>>>>       program P, called with some input, can pass its own source
>>>>>> and its input to
>>>>>>       H and then specifically do the opposite of what H predicts P
>>>>>> will do. No H
>>>>>>       can exist that handles this case.
>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> In that a partial simulation does correctly predict the behavior
>>>>>> of a complete simulation it can be used to recognize infinite
>>>>>> behavior patterns.
>>>>>>
>>>>>
>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0, which,
>>>>> by the DEFINITION of the requirements of the Halting Problem,
>>>>> H(P,P) needs to accept (return 1) if P(P) Halts,
>>>> This seems to be brand new computer science that I just discovered.
>>>>
>>>> Previously no one understood that it was possible for the correct
>>>> simulation of the input to H(P,P) to be computationally distinct
>>>> (thus not equivalent) to the direct execution of P(P).
>>>
>>> By what definition of "Correct" are you using?
>>
>>
>> Ordinary software engineering proves that a correct and complete x86
>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>
>
> So, I guess this just shows that you don't actually know a definition
> that shows this, so this is just another of your lies.

Ordinary software engineering proves that a correct and complete x86
emulation of the input to H(P,P) never reaches its "ret" instruction.

_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 of P repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
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/22 11:41 PM, olcott wrote:
> On 6/5/2022 10:26 PM, Richard Damon wrote:
>> On 6/5/22 11:03 PM, olcott wrote:
>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>
>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>>> <..snip..>>>
>>>>>>>>>> Sure.
>>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>>> something else. What is it doing while evaluating those 10 steps?
>>>>>>>>>
>>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>>
>>>>>>>>
>>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>>> computation in order to compute certain properties of that
>>>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>>>> useful.
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>
>>>>>>> That is true. I am apparently the first one that ever thought
>>>>>>> this through well enough so that machine descriptions matching
>>>>>>> the following pattern could be correctly determined to be
>>>>>>> non-halting:
>>>>>>>
>>>>>>>       For any program H that might determine if programs halt, a
>>>>>>> "pathological"
>>>>>>>       program P, called with some input, can pass its own source
>>>>>>> and its input to
>>>>>>>       H and then specifically do the opposite of what H predicts
>>>>>>> P will do. No H
>>>>>>>       can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> In that a partial simulation does correctly predict the behavior
>>>>>>> of a complete simulation it can be used to recognize infinite
>>>>>>> behavior patterns.
>>>>>>>
>>>>>>
>>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0,
>>>>>> which, by the DEFINITION of the requirements of the Halting
>>>>>> Problem, H(P,P) needs to accept (return 1) if P(P) Halts,
>>>>> This seems to be brand new computer science that I just discovered.
>>>>>
>>>>> Previously no one understood that it was possible for the correct
>>>>> simulation of the input to H(P,P) to be computationally distinct
>>>>> (thus not equivalent) to the direct execution of P(P).
>>>>
>>>> By what definition of "Correct" are you using?
>>>
>>>
>>> Ordinary software engineering proves that a correct and complete x86
>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>>
>>
>> So, I guess this just shows that you don't actually know a definition
>> that shows this, so this is just another of your lies.
>
> Ordinary software engineering proves that a correct and complete x86
> emulation of the input to H(P,P) never reaches its "ret" instruction.

Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
returns 0 that P(P) will halt.

Good engineering NEVER contradicts actual facts.

>
> _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 of P repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>

Maybe to you, but it is wrong (which might be why it is obvious to you).

Let us start by assuming that H doesn't just abort its simulation until
it has enough information to be obviously wrong.

H(P,P) will first emulate the first 7 instructions of P as you say.

Then it emulates the result of the call to H, so it emulates the start
of the emulation of the input to this H, which is also P,P.

That proceeds, as you almost say through the emulation of the emulaiton
of the first 7 instructions of P. While doing this, the outer emulation
will notice that the machine it has been emulating has been checking
conditions along the way.

We then get to the point that the emulation of the emulation reaches the
2nd level call to H, and the top level emulator will see that emulator
it is emulating checking if things have recursed too far.

At this point, the outer H has seen enough that it can see that if it
has aborted its simulation as soon as it say P calling H(P,P) and
matching that input to H to the input IT had, and calling that an
infinite repeat pattern, it would have been wrong, as a correct
emulation of that input would have continued and reached THIS point
where the H it was emulating made that same decision.

In fact, if the decider was smart enough, it could see that if it
simulates N levels of calls, and decides that this was enough to call
the input infinitely recursive, that at the N+1 call (that it won't get
to but a CORRECT COMPLETE emulator would), the emulator it is emulating
would reach N calls and do the same as it is, and thus showing that it
was wrong to make that decision.

The ONLY way that the correct emulation of the input never reaches the
ret instruction is if H actually never aborts its emulation, and thus
never actually gives the answer that the input is non-halting.

So, the ONLY H that creates a non-halting input is the H that fails to
give the answer that is only correct for that H.

Your brain just doesn't seem to be able to keep enough information to
handle the levels that happen in this problem.

On 6/5/2022 11:17 PM, Richard Damon wrote:
>
> On 6/5/22 11:41 PM, olcott wrote:
>> On 6/5/2022 10:26 PM, Richard Damon wrote:
>>> On 6/5/22 11:03 PM, olcott wrote:
>>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>>> On 6/5/2022 9:20 PM, Richard Damon wrote:
>>>>>>> On 6/5/22 10:11 PM, olcott wrote:
>>>>>>>> On 6/5/2022 8:58 PM, Mike Terry wrote:
>>>>>>>>> On 06/06/2022 01:24, Jeff Barnett wrote:
>>>>>>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>>>>>> <..snip..>>>
>>>>>>>>>>> Sure.
>>>>>>>>>>> The question right now is what you would call a TM which
>>>>>>>>>>> evaluates the first 10 steps of a computation, and then does
>>>>>>>>>>> something else. What is it doing while evaluating those 10
>>>>>>>>>>> steps?
>>>>>>>>>>
>>>>>>>>>> What would I call it? POOP! It just goes to show the accuracy
>>>>>>>>>> and flexibility of Ben's acronym for any Peter-related concept.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But PO didn't invent the concept of (partially) simulating a
>>>>>>>>> computation in order to compute certain properties of that
>>>>>>>>> computation!  It's been around since Turing's days, and is very
>>>>>>>>> useful.
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>
>>>>>>>> That is true. I am apparently the first one that ever thought
>>>>>>>> this through well enough so that machine descriptions matching
>>>>>>>> the following pattern could be correctly determined to be
>>>>>>>> non-halting:
>>>>>>>>
>>>>>>>>       For any program H that might determine if programs halt, a
>>>>>>>> "pathological"
>>>>>>>>       program P, called with some input, can pass its own source
>>>>>>>> and its input to
>>>>>>>>       H and then specifically do the opposite of what H predicts
>>>>>>>> P will do. No H
>>>>>>>>       can exist that handles this case.
>>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>>
>>>>>>>> In that a partial simulation does correctly predict the behavior
>>>>>>>> of a complete simulation it can be used to recognize infinite
>>>>>>>> behavior patterns.
>>>>>>>>
>>>>>>>
>>>>>>> Except that it doesn't since P(P) Halts if H(P,P) returns 0,
>>>>>>> which, by the DEFINITION of the requirements of the Halting
>>>>>>> Problem, H(P,P) needs to accept (return 1) if P(P) Halts,
>>>>>> This seems to be brand new computer science that I just discovered.
>>>>>>
>>>>>> Previously no one understood that it was possible for the correct
>>>>>> simulation of the input to H(P,P) to be computationally distinct
>>>>>> (thus not equivalent) to the direct execution of P(P).
>>>>>
>>>>> By what definition of "Correct" are you using?
>>>>
>>>>
>>>> Ordinary software engineering proves that a correct and complete x86
>>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>>>
>>>
>>> So, I guess this just shows that you don't actually know a definition
>>> that shows this, so this is just another of your lies.
>>
>> Ordinary software engineering proves that a correct and complete x86
>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>
> Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
> returns 0 that P(P) will halt.
>
> Good engineering NEVER contradicts actual facts.
>
>>
>> _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 of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>
> Maybe to you, but it is wrong (which might be why it is obvious to you).
>

Software engineers competent in C and the x86 language will verify that
when H(P,P) correctly emulates its input with an x86 emulator that this
emulation would never stop running. This provides the basis for H(P,P)
to correctly reject its input as non-halting.

> For any program H that might determine if programs halt, a
> "pathological" program P, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of
> what H predicts P will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem

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.

--
Copyright 2022 Pete Olcott

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