Andy Walker <anw@cuboid.co.uk> writes:

> On 03/08/2022 00:46, olcott wrote:
>> *So you believe the this Wikipedia article is flat out wrong*?
>>   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
>
> It's misleading rather than "flat out wrong", and you have been
> misled. P is not a specific program; it is derived from H. Write a
> different H, and the corresponding P changes. It is perfectly
> possible that the "different H" resolves the case of the P that your
> initial H failed with. So P is "pathological" [whatever that is
> supposed to mean] only for that particular H, not as an intrinsic
> property of P. This is disguised in the "impossible program" version
> because the /function/ P, in the form "if H(P,P) then L: goto L
> endif", looks the same visually for all H; but the full /program/ P
> includes the text of H.

In most proofs, the "hat" plays the role of a functional operator. If
PO were to use strings as the encoding, the hat function just maps C
source code to slightly modified C source code. Re-naming H^ as P is
one of the tricks he should never have been allowed to get away with,
not because it helps to make his case (nothing can do that) but because
it has helped him confuse himself!

> [In particular, if you emulate H, including an "abort" facility,
> then you have a different H, consisting of the emulator and its abort
> facility applied to the original H, and this may possibly be able to
> resolve the original P. But it can't resolve the new P, derived from
> the emulating H.]

It's always been about two computations -- the one that halts and the
one that "would not halt unless...". Everything since the "it doesn't
halt when line 15 is commented out" days has been linguistic gymnastics.

--
Ben.

On 8/3/2022 3:05 AM, Malcolm McLean wrote:
> On Wednesday, 3 August 2022 at 07:19:33 UTC+1, Jeff Barnett wrote:
>> On 8/2/2022 12:17 PM, Mr Flibble wrote:
>>> On Tue, 2 Aug 2022 11:54:34 -0600
>> <SNIP>
>>> You are wrong: I am extending the definition of what constitutes a
>>> halt decider which is my right as both a computer scientist and a
>>> software engineer.
>> The only reasonable definition I ever heard for a "Software Engineer"
>> was someone who cannot write code, doesn't do well with math, and has
>> learned that telling others how to do technology is easier than making a
>> fool of themself to make a living."
>>
> The economic problem was that software projects were delivered late and
> over-budget, often abandoned, and when delivered they were full of bugs
> which sometimes had a catastrophic impact on the customer.
> So what to do about it? A quick analysis would have shown that the problem
> wasn't that the programmers didn't know the programming language, or
> even that their maths wasn't up to scratch.
> The problem was rooted in management. What was much harder was defining
> what strong management looked like. For a long time, most people thought
> that the solution was to impose from the top down a "formal method". If
> everyone adhered to the method, work would be delivered bug free, and on time.
> When this gave disappointing results, the reason was that the formal method
> wasn't adhered to strictly enough.
> It was gradually realised that many successful projects were not build by teams
> which followed these formal methods. Now the methods are much better. They
> are less bureaucratic, they give more control to programmers or immediate
> product managers wanting to add features quickly in response to a proposal or
> request, the tolls for controlling changes to source code are much better, the
> languages we use are higher-level.
> We're still not there yet. Software is still notorious for being expensive to produce
> and faulty. You still read of horror stories where many millions of pounds are
> wasted.
> But realising that the computer science side of the problem is usually the easy
> part, and the integration, testing, and deployment the part that goes wrong, and
> that it's not just about knocking out code but a much broader problem than that,
> is what distinguishes "software engineering" from just "programming".

A little history of SE, starting in the early days:

By the early/middle 1950s the US Government had passionate interests in
using computers to better their systems. Experience giving contracts to
the military support community had been an expensive disaster in many
instances. Problems: 1) lack of knowledge about what was easy and what
was hard, 2) lack of understanding about how to form and map
requirements into a system architecture, 3) lack of technical experience
in the military support community, 4) lack of knowledge about how to
write contracts for massive systems - who's really responsible for what
and how to handle modifications of contracts that for system
requirements that became obvious during system development, 5) ravenous
desire for profits by the set of contractors available - their corporate
goals and the government's were not close and the US ended up paying
over and over again for contractor cock ups.

At some point, the government approached RAND (the non profit with John
von Neumann, Dick Bellman, Herb Simon, and many others there) and ask if
RAND could sprout another division to experiment with and develop some
needed defense systems. RAND had to decline for several reasons:

1) Their creation was controlled by an act of congress as a federally
charted not for profit corporation and that charter included a hard cap
on RAND's gross yearly income: $50M.

2) RAND had lines at their doors - cities, states, US agencies, non
profits - wanting to buy their services and had money to pay.

3) Most RAND researchers picked the customers they wanted to work with
and might leave if that wasn't possible. RAND employees never said they
worked for RAND, rather the mantra was that RAND was their sponsor.

The decision was made to create another federally chartered nonprofit,
the System Development Corporation, down the street from RAND. There
main business was research and developing military computer systems but
they were also to do R&D in any/all computer related areas.

The seeding of management and technical employees came from RAND and
also included many human factors folks (HF). The first task at hand was
to find people and turn them into programmers. Early on they tested,
analyzed and guessed who would be good at it. The best discriminator
found was a good old fashioned IQ test. It wasn't perfect but nothing
else worked as well.

SDC put employees wanted ads all over the place. The pitch was something
like the following: "Take a test: If you pass you will be paid X to
attend classes for 6 months. If you pass your class, you will be offered
a job at a starting rate of Y. You will learn about exciting new
technologies in a terrific environment, etc," I think X was something
like $400+ a moth and Y was a few hundred more. Remember, this was in
the late 1950s so this was good money. Using IQ test scores as the only
criterion, a hell's angel and a prostitute were hired; a college
professor was not.

Since the programmers hired this way started leaking out to other places
in the world, the reputation of computer folks as "strange dudes" was
justified. And the above, in my opinion, was the reason for the skew in
the inhabitants of our field. It was a MENSA collection that had 40
hours a week parties. Not so today.

SDC developed useful systems for the military as well as an
understanding of requirements, change orders, and many mundane ideas
about how to do the day by day business of system building.

In the latish 1960s and 1970s, the idea of software engineering had
sprouted and its leading voice was Dave Parnas. Parnas was very earnest
but naive about software development. For example, he proffered a set of
rules for good software that excluded the use of recursion by inference.
He had never written a part of a compiler, device drivers, parallel
process code, etc. His preferred rules were rigid and confrontations
with solid counterexamples bounced off him with no mental penetration.
One of the solid rules "was no GO forms". When asked, whether his SE
rules would allow a form rewrite to produce a new form with a GO in it,
he didn't think that was a good idea. Followup questions: How do you
compile loops. Well you get the idea. Parnas was last seen arguing SE
possibilities for the development of the Strategic Defense Initiative.

Pretty soon, everyone was faking SE departments, (Why not, you could add
the expense plus overhead and profit to your contracts.) SDC as well as
other places were caught up in the idea. Most places decided that they
couldn't afford to take good technical people and waste them in a make
work organization. SE became a closet to stuff your failures in. We have
had a continuous string of SE fad movements; new ones every few years.
Aerospace and other defense contractors run classes for all their
employees when each useless standard is released. Funny thing many years
ago: some of us got together and were talking about this very subject.
It turned out that at two different defense contractors these classes
were being taught by employees that had been given their notices along
with a few month optional extension if they would teach these god awful
classes. I think at the time of this get together, ISO was promoting yet
another standards fart.

In the middle late 1970s, the US government decided 1) they now knew
enough to write and manage large computer systems contracts and 2) that
SDC as a federally charted non profit had an unfair advantage in seeking
government business. Thus, SDC was ordered to make a plan to change. The
way this was done was to create a nonprofit SDC foundation that held all
the stock in the SDC company though some was granted to current
employees as some sort of option. The nonprofit then put their stock up
for sale. It was eventually bought by Burroughs Corporation who was
later absorbed by Unisys. The SDC foundation still exists. It makes
research grants and supports various interesting CS related activities.

This was too long. However, my attitude in re SE was brewed over many
decades. We are now in an era where most products are developed and sold
without a detailed description of what the product does. Therefore, our
software has no errors since there is no statement of what it should do.
Is that a victory for SE? I wonder.
--
Jeff Barnett

On Tue, 2 Aug 2022 21:44:29 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 8/2/22 2:17 PM, Mr Flibble wrote:
> > On Tue, 2 Aug 2022 11:54:34 -0600
> > Jeff Barnett <jbb@notatt.com> wrote:
> >
> >> On 8/2/2022 10:11 AM, Mr Flibble wrote:
> >>> On Tue, 2 Aug 2022 19:07:33 +0300
> >>> Mikko <mikko.levanto@iki.fi> wrote:
> >>>
> >>>> On 2022-08-01 12:54:04 +0000, olcott said:
> >>>>
> >>>>> A halt decider must compute the mapping from its inputs to an
> >>>>> accept or reject state on the basis of the actual behavior that
> >>>>> is actually specified by these inputs.
> >>>>
> >>>> The halting problem does not require that. It merely says (or
> >>>> implies -- each author uses different words but they aways mean
> >>>> the same) that
> >>>> - if H(M, I) returns false and M(I) halts then H is not a halt
> >>>> decider
> >>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
> >>>> halt decider
> >>>> - if H(M, I) returns something else then H is not a halt decider
> >>>> - if H(M, I) does not return then H is not a halt decider
> >>>> - otherwise H is a halt decider
> >>>
> >>> I can add to that (my key insight):
> >>>
> >>> - if H(M, I) doesn't signal an exception on pathological
> >>> ("Impossible Program") input then H is not a halt decider.
> >> You, like PO, seem to think that a proper H uses some sort of
> >> simulation and signals exceptions. That isn't true. Take the
> >> impossible program used in the proof that there is no right answer.
> >> That result can be derived by simple analysis - everybody still
> >> stroking the mega maniac by contributing to these threads has done
> >> that by studying the symbolic code.
> >>
> >> Once again, the proof shows there is no right answer, but there is
> >> one more step to complete the proof: "If there is no right answer
> >> for some problems, then an actual decider simply cannot exist."
> >> That proof is not the only one however. There are a ton of them
> >> (proofs) and many show that desirable deciders about problems of
> >> great interest to Software Engineers, Mathematicians, and
> >> Logicians don't exist either.
> >>
> >> The results apply to any claim about Universal Deciders which are
> >> really the same class as Deciders.
> >>
> >> Assume that you have an H(TM,INPUT) that properly returns a value
> >> in {halts, pathological, infinite-loop} with the stipulation that H
> >> halts for any arguments, i.e., H is the POOP decider that PO has
> >> wet dreams about. QUESTION: What happens if you build H' and H^
> >> from this H? Run it through the same proof structure that is in
> >> Linz and tell us all what happens. Will PO die a fool or find a
> >> place in history? The curious want to know!
> >
> > You are wrong: I am extending the definition of what constitutes a
> > halt decider which is my right as both a computer scientist and a
> > software engineer.
> >
> > If the only way to detect pathological input is through the use of a
> > simulating halt decider then so be it.
> >
> > /Flibble
> >
>
> No, you CAN NOT change the definition of the existing Halting
> Function.

I can and I have.

>
> You can create a NEW property, Flibble-Halting, and define what a
> Flibble-Halt Decider is, but that is NOT changing the actual
> definiton of Halting.
>
> That is the same mistake that Olcott is doing. He thinks he has the
> power to change what is.
>
> Maybe Flibble-Halting has some interesting properties, but likely not.
>
> If the Flibble-Simulation of the input deviates from what the true
> behavior of that input, then things get non-interesting rapidly, and
> it just becomes a toy, and this seems to be the problem.

The new and improved definition of a halt decider has 3 outcomes:
1) input halts
2) input doesn't halt
3) input is invalid (signaled as an exception)

/Flibble

On 8/3/2022 2:53 PM, Mr Flibble wrote:
> On Tue, 2 Aug 2022 21:44:29 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 8/2/22 2:17 PM, Mr Flibble wrote:
>>> On Tue, 2 Aug 2022 11:54:34 -0600
>>> Jeff Barnett <jbb@notatt.com> wrote:
>>>
>>>> On 8/2/2022 10:11 AM, Mr Flibble wrote:
>>>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>
>>>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>>>
>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>>> is actually specified by these inputs.
>>>>>>
>>>>>> The halting problem does not require that. It merely says (or
>>>>>> implies -- each author uses different words but they aways mean
>>>>>> the same) that
>>>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>>>> decider
>>>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>>>> halt decider
>>>>>> - if H(M, I) returns something else then H is not a halt decider
>>>>>> - if H(M, I) does not return then H is not a halt decider
>>>>>> - otherwise H is a halt decider
>>>>>
>>>>> I can add to that (my key insight):
>>>>>
>>>>> - if H(M, I) doesn't signal an exception on pathological
>>>>> ("Impossible Program") input then H is not a halt decider.
>>>> You, like PO, seem to think that a proper H uses some sort of
>>>> simulation and signals exceptions. That isn't true. Take the
>>>> impossible program used in the proof that there is no right answer.
>>>> That result can be derived by simple analysis - everybody still
>>>> stroking the mega maniac by contributing to these threads has done
>>>> that by studying the symbolic code.
>>>>
>>>> Once again, the proof shows there is no right answer, but there is
>>>> one more step to complete the proof: "If there is no right answer
>>>> for some problems, then an actual decider simply cannot exist."
>>>> That proof is not the only one however. There are a ton of them
>>>> (proofs) and many show that desirable deciders about problems of
>>>> great interest to Software Engineers, Mathematicians, and
>>>> Logicians don't exist either.
>>>>
>>>> The results apply to any claim about Universal Deciders which are
>>>> really the same class as Deciders.
>>>>
>>>> Assume that you have an H(TM,INPUT) that properly returns a value
>>>> in {halts, pathological, infinite-loop} with the stipulation that H
>>>> halts for any arguments, i.e., H is the POOP decider that PO has
>>>> wet dreams about. QUESTION: What happens if you build H' and H^
>>>> from this H? Run it through the same proof structure that is in
>>>> Linz and tell us all what happens. Will PO die a fool or find a
>>>> place in history? The curious want to know!
>>>
>>> You are wrong: I am extending the definition of what constitutes a
>>> halt decider which is my right as both a computer scientist and a
>>> software engineer.
>>>
>>> If the only way to detect pathological input is through the use of a
>>> simulating halt decider then so be it.
>>>
>>> /Flibble
>>>
>>
>> No, you CAN NOT change the definition of the existing Halting
>> Function.
>
> I can and I have.
>
>>
>> You can create a NEW property, Flibble-Halting, and define what a
>> Flibble-Halt Decider is, but that is NOT changing the actual
>> definiton of Halting.
>>
>> That is the same mistake that Olcott is doing. He thinks he has the
>> power to change what is.
>>

The correct (simulation / x86 emulation) of the (input / arguments) by a
simulating halt decider is the ultimate basis for its halt status decision.

*As Keith Thompson so kindly reminded me* deciders must be pure
functions of their arguments, thus the computation of the halt status
must only map its arguments to an accept or reject state on the basis of
the behavior specified by these arguments.

If H(P,P) did report on the behavior of P(P) and this behavior was not
the same as the behavior that H(P,P) simulates then H would not be a
pure function of its arguments.

--
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 Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
> On 8/3/2022 6:46 AM, Dennis Bush wrote:
> > On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
> >> On 8/2/2022 7:52 PM, Dennis Bush wrote:
> >>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> >>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> >>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Where I point out you're answering the wrong question.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>> {
> >>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>>>>>> is essentially the second call of infinite recursion.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>>>>>> its caller.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>>>>>> won't allow it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>>>>>
> >>>>>>>>>>>> You know that never said anything like that:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>>>>>> saying anything like that.
> >>>>>>>>>>>
> >>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>>>>>
> >>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>>>>>
> >>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>>>>>
> >>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>>>>>
> >>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>>>>>> of Hn it is essentially the same as a UTM.
> >>>>>>>>>
> >>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>>>>>> running.
> >>>>>>>>>
> >>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>>>>>
> >>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>
> >>>>>>>> Yet in the case of H and P that would require a software function to
> >>>>>>>> return the result of analyzing a non-input which from a software
> >>>>>>>> engineering perspective is pure nonsense.
> >>>>>>>
> >>>>>>> You don't get to change the question.
> >>>>>> When the question is WRONG, I do get to change the question.
> >>>>>
> >>>>> Are you saying that it's impossible for a function H to implement the following specification?
> >>>>>
> >>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>
> >>>> main()
> >>>> {
> >>>> H(P,P);
> >>>> P(P);
> >>>> }
> >>>>
> >>>> If H(P,P) reports on the behavior of a sequence of instructions where P
> >>>> has been executed first and H has not yet been executed then H is
> >>>> reporting incorrectly, directly against the verified facts.
> >>>
> >>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
> >>>
> >>> H(X,Y)==1 if and only if X(Y) halts, and
> >>> H(X,Y)==0 if and only if X(Y) does not halt
> >> *The above specification is incoherent
> >
> > So you're saying that it's impossible to create an H that meets this specification?
> In the same way that it is impossible to correctly answer this question:
> What time is it (yes or no)?

On 8/3/2022 4:18 PM, Dennis Bush wrote:
> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>>>
>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>>>
>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>>>>>> running.
>>>>>>>>>>>
>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>>>>>
>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>
>>>>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>>>
>>>>>>>>> You don't get to change the question.
>>>>>>>> When the question is WRONG, I do get to change the question.
>>>>>>>
>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>>>>>
>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>
>>>>>> main()
>>>>>> {
>>>>>> H(P,P);
>>>>>> P(P);
>>>>>> }
>>>>>>
>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>>>>> has been executed first and H has not yet been executed then H is
>>>>>> reporting incorrectly, directly against the verified facts.
>>>>>
>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>>>>>
>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>> *The above specification is incoherent
>>>
>>> So you're saying that it's impossible to create an H that meets this specification?
>> In the same way that it is impossible to correctly answer this question:
>> What time is it (yes or no)?
>
> So just to be clear, you're saying that the following specification:
>
> H(X,Y)==1 if and only if X(Y) halts, and
> H(X,Y)==0 if and only if X(Y) does not halt
>
> Is impossible to satisfy?

On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
> On 8/3/2022 4:18 PM, Dennis Bush wrote:
> > On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
> >> On 8/3/2022 6:46 AM, Dennis Bush wrote:
> >>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
> >>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
> >>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> >>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> >>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion..
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction..
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>>>>>>>> its caller.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>>>>>>>> won't allow it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You know that never said anything like that:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>>>>>>>> saying anything like that.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>>>>>>>
> >>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>>>>>>>> of Hn it is essentially the same as a UTM.
> >>>>>>>>>>>
> >>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>>>>>>>> running.
> >>>>>>>>>>>
> >>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>>>>>>>
> >>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>
> >>>>>>>>>> Yet in the case of H and P that would require a software function to
> >>>>>>>>>> return the result of analyzing a non-input which from a software
> >>>>>>>>>> engineering perspective is pure nonsense.
> >>>>>>>>>
> >>>>>>>>> You don't get to change the question.
> >>>>>>>> When the question is WRONG, I do get to change the question.
> >>>>>>>
> >>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
> >>>>>>>
> >>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>
> >>>>>> main()
> >>>>>> {
> >>>>>> H(P,P);
> >>>>>> P(P);
> >>>>>> }
> >>>>>>
> >>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
> >>>>>> has been executed first and H has not yet been executed then H is
> >>>>>> reporting incorrectly, directly against the verified facts.
> >>>>>
> >>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
> >>>>>
> >>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>> *The above specification is incoherent
> >>>
> >>> So you're saying that it's impossible to create an H that meets this specification?
> >> In the same way that it is impossible to correctly answer this question:
> >> What time is it (yes or no)?
> >
> > So just to be clear, you're saying that the following specification:
> >
> > H(X,Y)==1 if and only if X(Y) halts, and
> > H(X,Y)==0 if and only if X(Y) does not halt
> >
> > Is impossible to satisfy?
> It is incorrect in some cases.

On 8/3/2022 5:53 PM, Dennis Bush wrote:
> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>>>>>
>>>>>>>>>>> You don't get to change the question.
>>>>>>>>>> When the question is WRONG, I do get to change the question.
>>>>>>>>>
>>>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>>>>>>>
>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>
>>>>>>>> main()
>>>>>>>> {
>>>>>>>> H(P,P);
>>>>>>>> P(P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>>>>>>> has been executed first and H has not yet been executed then H is
>>>>>>>> reporting incorrectly, directly against the verified facts.
>>>>>>>
>>>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>>>>>>>
>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>> *The above specification is incoherent
>>>>>
>>>>> So you're saying that it's impossible to create an H that meets this specification?
>>>> In the same way that it is impossible to correctly answer this question:
>>>> What time is it (yes or no)?
>>>
>>> So just to be clear, you're saying that the following specification:
>>>
>>> H(X,Y)==1 if and only if X(Y) halts, and
>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>
>>> Is impossible to satisfy?
>> It is incorrect in some cases.
>
> I didn't ask if it was incorrect. I asked if it's impossible to create an H that satisfies this specification?

On 8/3/22 8:08 AM, olcott wrote:
> On 8/3/2022 6:23 AM, Paul N wrote:
>> On Wednesday, August 3, 2022 at 1:47:42 AM UTC+1, olcott wrote:
>>> main()
>>> {
>>> H(P,P);
>>> P(P);
>>> }
>>>
>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>> has been executed first and H has not yet been executed then H is
>>> reporting incorrectly, directly against the verified facts.
>>
>> I think this also may be key to where you are going wrong. H is
>> supposed to determine whether P(P) halts or not.
>
>    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 [*specified by this
>    description*] will finish running or continue to run forever.
>    https://en.wikipedia.org/wiki/Halting_problem
>
> P(P) is not a "description of an arbitrary computer program and an
> input" it is a running process.
>
> int sum(int x, int y) { return x + y; }
> sum(3,4) must return the sum of 3+4 and
> its not allowed to return the sum of 4+5.
>
> Likewise H must determine the behavior of its input and must not
> determine the behavior of any non-input.

And, as you just said, the input to H(P,P) represents P(P), as a
ACRTUALLY RUNNING PROCESS, NOT its "simulation by H", but what it does
when IT is run.

>
>> You are now saying that the only behaviour of P that you are able to
>> predict is when H is already running.
>
> In other words when H(P,P) has not been run will it not return any result.

yes, H can't give an answer unless you run it, but you are confusing the
decision with the thing being decided.

H needs to answer about what P(P) AS AN INDEPENDENTLY RUN PROCESS will do.

That behavior is INDEPENDENT of whether an H has been run or not, since
an H running outside of P can't affect what P does, only copy of H that
is run as part of P affect what P does.

That means the correct answer for H to give is independent of what has
happened before the call to H or not.

That just comes from the definition of H being a Pure compuation.

If you are saying what has been done before the call to H affect what H
does, then you are just admitting that your H isn't actually a Pure
functions, an thus CAN'T be an actual decider.

>
>> Thus your answer involves itself in the question.
>>
>> To take an analogy - suppose you have a voltmeter. It measures very
>> accurately what the voltage across it is when it is connected.
>> However, that voltage is very different from what the voltage would be
>> across the two points when the voltmeter is not connected, due to the
>> current drawn by the voltmeter itself. Most people would say that this
>> was not a good voltmeter (at least for use in testing), no matter how
>> accurately it did measure what it measured.
>>
>> The same is true for your function H. By your own admission it can
>> only measure what P does when H exists and is running. A halt detector
>> needs to do more than that.
>
> In other words you are saying that H(P,P) must return a result even if
> it does not exist or before it has ever been run?
>
>

So, are you admitting that H doesn't exist?

How else can "it" not exist?

Of course H will "exist" for Main or P to call it, and the program P
obviously exists, as you have the code for it in front of you.

Note, H is NOT being asked about a particular invocation of P, a
particular "process", but what the "algorithm" of P will do with its
input, and since P "exists" as an algorithm, and its input is specified,
that is fully defined.

That ALSO means it CAN'T change based on what happens outside it, as by
definition the things a Halting Decider is asked about are unaffected by
the "outside", but only depend on the algorithm itself, and its defined
input.

On Wednesday, August 3, 2022 at 7:16:33 PM UTC-4, olcott wrote:
> On 8/3/2022 5:53 PM, Dennis Bush wrote:
> > On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
> >> On 8/3/2022 4:18 PM, Dennis Bush wrote:
> >>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
> >>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
> >>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
> >>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
> >>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> >>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>>>>>>>>>> its caller.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>>>>>>>>>> won't allow it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> You know that never said anything like that:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>>>>>>>>>> saying anything like that.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>>>>>>>>>> running.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Yet in the case of H and P that would require a software function to
> >>>>>>>>>>>> return the result of analyzing a non-input which from a software
> >>>>>>>>>>>> engineering perspective is pure nonsense.
> >>>>>>>>>>>
> >>>>>>>>>>> You don't get to change the question.
> >>>>>>>>>> When the question is WRONG, I do get to change the question.
> >>>>>>>>>
> >>>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
> >>>>>>>>>
> >>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>
> >>>>>>>> main()
> >>>>>>>> {
> >>>>>>>> H(P,P);
> >>>>>>>> P(P);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
> >>>>>>>> has been executed first and H has not yet been executed then H is
> >>>>>>>> reporting incorrectly, directly against the verified facts.
> >>>>>>>
> >>>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
> >>>>>>>
> >>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>> *The above specification is incoherent
> >>>>>
> >>>>> So you're saying that it's impossible to create an H that meets this specification?
> >>>> In the same way that it is impossible to correctly answer this question:
> >>>> What time is it (yes or no)?
> >>>
> >>> So just to be clear, you're saying that the following specification:
> >>>
> >>> H(X,Y)==1 if and only if X(Y) halts, and
> >>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>
> >>> Is impossible to satisfy?
> >> It is incorrect in some cases.
> >
> > I didn't ask if it was incorrect. I asked if it's impossible to create an H that satisfies this specification?
> Of course you will ignore that it is incorrect because you are only
> interested in rebuttal and not honest dialogue.

On 8/3/2022 6:50 PM, Dennis Bush wrote:
> On Wednesday, August 3, 2022 at 7:16:33 PM UTC-4, olcott wrote:
>> On 8/3/2022 5:53 PM, Dennis Bush wrote:
>>> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
>>>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
>>>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
>>>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
>>>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>>>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>>>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You don't get to change the question.
>>>>>>>>>>>> When the question is WRONG, I do get to change the question.
>>>>>>>>>>>
>>>>>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>>>>>>>>>
>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>
>>>>>>>>>> main()
>>>>>>>>>> {
>>>>>>>>>> H(P,P);
>>>>>>>>>> P(P);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>>>>>>>>> has been executed first and H has not yet been executed then H is
>>>>>>>>>> reporting incorrectly, directly against the verified facts.
>>>>>>>>>
>>>>>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>>>>>>>>>
>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>> *The above specification is incoherent
>>>>>>>
>>>>>>> So you're saying that it's impossible to create an H that meets this specification?
>>>>>> In the same way that it is impossible to correctly answer this question:
>>>>>> What time is it (yes or no)?
>>>>>
>>>>> So just to be clear, you're saying that the following specification:
>>>>>
>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>
>>>>> Is impossible to satisfy?
>>>> It is incorrect in some cases.
>>>
>>> I didn't ask if it was incorrect. I asked if it's impossible to create an H that satisfies this specification?
>> Of course you will ignore that it is incorrect because you are only
>> interested in rebuttal and not honest dialogue.
>
> Questions are not incorrect. They just are.
>

On Wednesday, August 3, 2022 at 8:08:53 PM UTC-4, olcott wrote:
> On 8/3/2022 6:50 PM, Dennis Bush wrote:
> > On Wednesday, August 3, 2022 at 7:16:33 PM UTC-4, olcott wrote:
> >> On 8/3/2022 5:53 PM, Dennis Bush wrote:
> >>> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
> >>>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
> >>>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
> >>>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
> >>>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
> >>>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
> >>>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation..
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>>>>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question..
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion..
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>>>>>>>>>>>> its caller.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>>>>>>>>>>>> won't allow it.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> You know that never said anything like that:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>>>>>>>>>>>> saying anything like that.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>>>>>>>>>>>> running.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yet in the case of H and P that would require a software function to
> >>>>>>>>>>>>>> return the result of analyzing a non-input which from a software
> >>>>>>>>>>>>>> engineering perspective is pure nonsense.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> You don't get to change the question.
> >>>>>>>>>>>> When the question is WRONG, I do get to change the question.
> >>>>>>>>>>>
> >>>>>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
> >>>>>>>>>>>
> >>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>
> >>>>>>>>>> main()
> >>>>>>>>>> {
> >>>>>>>>>> H(P,P);
> >>>>>>>>>> P(P);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
> >>>>>>>>>> has been executed first and H has not yet been executed then H is
> >>>>>>>>>> reporting incorrectly, directly against the verified facts.
> >>>>>>>>>
> >>>>>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
> >>>>>>>>>
> >>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>> *The above specification is incoherent
> >>>>>>>
> >>>>>>> So you're saying that it's impossible to create an H that meets this specification?
> >>>>>> In the same way that it is impossible to correctly answer this question:
> >>>>>> What time is it (yes or no)?
> >>>>>
> >>>>> So just to be clear, you're saying that the following specification:
> >>>>>
> >>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>
> >>>>> Is impossible to satisfy?
> >>>> It is incorrect in some cases.
> >>>
> >>> I didn't ask if it was incorrect. I asked if it's impossible to create an H that satisfies this specification?
> >> Of course you will ignore that it is incorrect because you are only
> >> interested in rebuttal and not honest dialogue.
> >
> > Questions are not incorrect. They just are.
> >
> OK then what time is it (yes or no)?

On 8/3/22 4:49 PM, olcott wrote:
> On 8/3/2022 2:53 PM, Mr Flibble wrote:
>> On Tue, 2 Aug 2022 21:44:29 -0400
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 8/2/22 2:17 PM, Mr Flibble wrote:
>>>> On Tue, 2 Aug 2022 11:54:34 -0600
>>>> Jeff Barnett <jbb@notatt.com> wrote:
>>>>> On 8/2/2022 10:11 AM, Mr Flibble wrote:
>>>>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>> accept or reject state on the basis of the actual behavior that
>>>>>>>> is actually specified by these inputs.
>>>>>>>
>>>>>>> The halting problem does not require that. It merely says (or
>>>>>>> implies -- each author uses different words but they aways mean
>>>>>>> the same) that
>>>>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>>>>> decider
>>>>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>>>>> halt decider
>>>>>>> - if H(M, I) returns something else then H is not a halt decider
>>>>>>> - if H(M, I) does not return then H is not a halt decider
>>>>>>> - otherwise H is a halt decider
>>>>>>
>>>>>> I can add to that (my key insight):
>>>>>>
>>>>>> - if H(M, I) doesn't signal an exception on pathological
>>>>>>      ("Impossible Program") input then H is not a halt decider.
>>>>> You, like PO, seem to think that a proper H uses some sort of
>>>>> simulation and signals exceptions. That isn't true. Take the
>>>>> impossible program used in the proof that there is no right answer.
>>>>> That result can be derived by simple analysis - everybody still
>>>>> stroking the mega maniac by contributing to these threads has done
>>>>> that  by studying the symbolic code.
>>>>>
>>>>> Once again, the proof shows there is no right answer, but there is
>>>>> one more step to complete the proof: "If there is no right answer
>>>>> for some problems, then an actual decider simply cannot exist."
>>>>> That proof is not the only one however. There are a ton of them
>>>>> (proofs) and many show that desirable deciders about problems of
>>>>> great interest to Software Engineers, Mathematicians, and
>>>>> Logicians don't exist either.
>>>>>
>>>>> The results apply to any claim about Universal Deciders which are
>>>>> really the same class as Deciders.
>>>>>
>>>>> Assume that you have an H(TM,INPUT) that properly returns a value
>>>>> in {halts, pathological, infinite-loop} with the stipulation that H
>>>>> halts for any arguments, i.e., H is the POOP decider that PO has
>>>>> wet dreams about. QUESTION: What happens if you build H' and H^
>>>>> from this H? Run it through the same proof structure that is in
>>>>> Linz and tell us all what happens. Will PO die a fool or find a
>>>>> place in history? The curious want to know!
>>>>
>>>> You are wrong: I am extending the definition of what constitutes a
>>>> halt decider which is my right as both a computer scientist and a
>>>> software engineer.
>>>>
>>>> If the only way to detect pathological input is through the use of a
>>>> simulating halt decider then so be it.
>>>>
>>>> /Flibble
>>>
>>> No, you CAN NOT change the definition of the existing Halting
>>> Function.
>>
>> I can and I have.
>>
>>>
>>> You can create a NEW property, Flibble-Halting, and define what a
>>> Flibble-Halt Decider is, but that is NOT changing the actual
>>> definiton of Halting.
>>>
>>> That is the same mistake that Olcott is doing. He thinks he has the
>>> power to change what is.
>>>
>
> The correct (simulation / x86 emulation) of the (input / arguments) by a
> simulating halt decider is the ultimate basis for its halt status decision.

Nope, just shows you don't know the definition.

The ULTIMATE criteria for the correct decision is does the machine the
input represents Halts. THAT IS THE DEFINITION.

>
> *As Keith Thompson so kindly reminded me* deciders must be pure
> functions of their arguments, thus the computation of the halt status
> must only map its arguments to an accept or reject state on the basis of
> the behavior specified by these arguments.

Right, ENCODED ALGORITHM OF MACHINE + DATA GIVEN TO MACHINE maps to does
the machine when run on that data Halt or not.

>
> If H(P,P) did report on the behavior of P(P) and this behavior was not
> the same as the behavior that H(P,P) simulates then H would not be a
> pure function of its arguments.
>
>

WRONG. For the EXACT set of INPUTS, that of H(P,P), given that H(P,P)
returns 0, there is EXACTLY ONE correct answer that this input maps to,
and that is 1, because P(P) Halts.

How is that NOT a "Pure Function".

Pure function means that a given exact input, leads to a single answer.

Note, that for the input P to be correct, it must include ALL the
algorithm of P, which includes the algorithm of H.

That can be provided either via the x86 assembly code that code, or an
ACCURATE desciption of what the code does, for instance, we can know
that H(P,P) return 0, so bypass the simulation of the x86 code of H and
just return 0 from the call.

We CAN'T use an inaccurate description of what the code does, like
assume that a call to H(P,P) leads to infinite recursion when that is
NOT the actual behavior of the direct call to H, THAT shows UNSOUND
logic and can give incorrect answer.

That is the flaw with your current H, its doesn't actually simulate the
full machine it is given. but replaces calls to H by an description that
doesn't actually match the actual behavior of H.

On 8/3/22 8:21 AM, olcott wrote:
> On 8/2/2022 8:40 PM, Richard Damon wrote:
>>
>> On 8/2/22 8:45 PM, olcott wrote:
>>> On 8/2/2022 1:56 PM, Mikko wrote:
>>>> On 2022-08-02 18:44:24 +0000, Mr Flibble said:
>>>>
>>>>> On Tue, 2 Aug 2022 21:41:54 +0300
>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>
>>>>>> On 2022-08-02 16:11:54 +0000, Mr Flibble said:
>>>>>>
>>>>>>> On Tue, 2 Aug 2022 19:07:33 +0300
>>>>>>> Mikko <mikko.levanto@iki.fi> wrote:
>>>>>>>
>>>>>>>> On 2022-08-01 12:54:04 +0000, olcott said:
>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>> actually specified by these inputs.
>>>>>>>>
>>>>>>>> The halting problem does not require that. It merely says (or
>>>>>>>> implies -- each author uses different words but they aways mean
>>>>>>>> the same) that
>>>>>>>> - if H(M, I) returns false and M(I) halts then H is not a halt
>>>>>>>> decider
>>>>>>>> - if H(M, I) returns true and M(I) doesn't halt then H is not a
>>>>>>>> halt decider
>>>>>>>> - if H(M, I) returns something else then H is not a halt decider
>>>>>>>> - if H(M, I) does not return then H is not a halt decider
>>>>>>>> - otherwise H is a halt decider
>>>>>>>
>>>>>>> I can add to that (my key insight):
>>>>>>>
>>>>>>> - if H(M, I) doesn't signal an exception on pathological
>>>>>>> ("Impossible Program") input then H is not a halt decider.
>>>>>>
>>>>>> No, you can't. The problem definition is what it is and you
>>>>>> can't add anything to it, and it says or at least imlies that
>>>>>> if H(M, I) signals an exception it is not a halt decider.
>>>>>
>>>>> Yes I can and I have. I have extended the definition of a halt
>>>>> decider.
>>>>>
>>>>> /Flibble
>>>>
>>>> If there is two conflicting definitions for the same term the
>>>> definition
>>>> published earlier is the valid one.
>>>>
>>>> Mikko
>>>>
>>>
>>>  >
>>> main()
>>> {
>>>    H(P,P);
>>>    P(P);
>>> }
>>>
>>> If H(P,P) reports on the behavior of a sequence of instructions where
>>> P has been executed first and H has not yet been executed then H is
>>> reporting incorrectly, directly against the verified facts.
>>>
>>>
>>
>> The sequence of instruction that H gets are the same either way. What
>> has happend before the call to H can not affect its behavior if H is a
>> pure function.
> When a "pathological" relationship between H and P has been defined this
> necessitates that the order of execution of H and P makes a difference.
> To ignore this necessity is simply ignorance.

How, if H is a pure function, what happens before the call MUST be
irrelevant. PERIOD.

You ASSUME a lot of stuff that just isn't true, and don't look at actual
facts.

THAT MAKES YOU STUPID.

>
> My pure function version of H always returns the same value for the same
> inputs every time that it is invoked. In this pure function version of H
> (where the infinite recursion is more difficult to see) the simulation
> of P is aborted before H is ever invoked.
>

But it incorrectly presumes that the H(P,P) called by P(P) doesn't give
the same answer, so it is INCORRECT. ONLY A CORRECT simulation followed
by SOUND logic will give the right answer. H assuming the H(P,P) leads
to infinite recursion when it actually doesn't, as proven by the outer
call to H(P,P) returning 0, proves that H is incorrect in its assumption.

THERE IS NO ACTUAL PATHOLOGY IN P, P IS A PERFECTLY LEGAL PROGRAM WITH
FULLY DEFINED BEHAVIOR.

P(P) HALTS if H(P,P) returns 0, so that answer is NOT correct if H
claims to be a Halt Decider. DEFINITION.

ALL you are doing is proving you are lying.

On 8/3/22 7:16 PM, olcott wrote:
> On 8/3/2022 5:53 PM, Dennis Bush wrote:
>> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
>>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
>>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
>>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
>>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the function H
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>> a final state. Which
>>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a
>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is
>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect:
>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from
>>>>>>>>>>>>>>>>>>>>>>>>>>> its inputs to an
>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the
>>>>>>>>>>>>>>>>>>>>>>>>>>> actual behavior that is
>>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is
>>>>>>>>>>>>>>>>>>>>>>>>>> determined by the actual
>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the
>>>>>>>>>>>>>>>>>>>>>>>>> correct simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence
>>>>>>>>>>>>>>>>>>>>>>>>> of instructions that
>>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject
>>>>>>>>>>>>>>>>>>>>>>>>> the concept of UTM
>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will
>>>>>>>>>>>>>>>>>>>>>>>> recreate the behavior of
>>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation
>>>>>>>>>>>>>>>>>>>>>>> correctly matches any
>>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is
>>>>>>>>>>>>>>>>>>>>>>> no need to wait until
>>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop
>>>>>>>>>>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite
>>>>>>>>>>>>>>>>>>>>>> behavior pattern if the
>>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite
>>>>>>>>>>>>>>>>>>>>>> recursion, which it doesn't if
>>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly
>>>>>>>>>>>>>>>>>>>>> determine the halt status of
>>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to
>>>>>>>>>>>>>>>>>>>>> examine its input instead
>>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of
>>>>>>>>>>>>>>>>>>> reviewers reject
>>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even
>>>>>>>>>>>>>>>>>>> looking at it and
>>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding
>>>>>>>>>>>>>>>>>>> fault that they hardly
>>>>>>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing
>>>>>>>>>>>>>>>>>> you again. I know that when you say "H(P,P) does
>>>>>>>>>>>>>>>>>> correctly determine the halt status of its input",
>>>>>>>>>>>>>>>>>> what you really mean is "there is no implementation of
>>>>>>>>>>>>>>>>>> the function H that can simulate the function call
>>>>>>>>>>>>>>>>>> P(P) to a final state". And that is true, and is what
>>>>>>>>>>>>>>>>>> I was agreeing about. That become more clear with what
>>>>>>>>>>>>>>>>>> I said next:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt
>>>>>>>>>>>>>>>>>>>> status of the machine the input represents,
>>>>>>>>>>>>>>>>>>>> specifically Pa(Pa), as per the definition of the
>>>>>>>>>>>>>>>>>>>> function a halt decider is required to compute:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And
>>>>>>>>>>>>>>>>>> everything that follows from here down is bunk because
>>>>>>>>>>>>>>>>>> it depends on the wrong answer being right.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the
>>>>>>>>>>>>>>>>>>> same behavior
>>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because
>>>>>>>>>>>>>>>>>>> the execution
>>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is
>>>>>>>>>>>>>>>>>>> invoked first.
>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first
>>>>>>>>>>>>>>>>>>> call of
>>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its
>>>>>>>>>>>>>>>>>>> input and
>>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all
>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence
>>>>>>>>>>>>>>>>>>> stops.
>>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it
>>>>>>>>>>>>>>>>>>> returns to
>>>>>>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as
>>>>>>>>>>>>>>>>>>> proven by the fact
>>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted)
>>>>>>>>>>>>>>>>>>> therefore H did
>>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of
>>>>>>>>>>>>>>>>>>> a non-input
>>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that
>>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so
>>>>>>>>>>>>>>>>>> absurd, why do you claim that Ha(Pa,Pa) must report
>>>>>>>>>>>>>>>>>> the halt status of Pn(Pn)?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is
>>>>>>>>>>>>>>>> saying:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly
>>>>>>>>>>>>>>>>> emulate ever reach its
>>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped
>>>>>>>>>>>>>>>>> emulating it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It
>>>>>>>>>>>>>>>> is Hn. That also means that Pa is no longer Pa since
>>>>>>>>>>>>>>>> it's now calling Hn. It is now Pn.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you
>>>>>>>>>>>>>>>> change the input. So the above is EXACTLY saying that
>>>>>>>>>>>>>>>> Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input
>>>>>>>>>>>>>> will do if its implementation is Hn, then Ha(Pa,Pa) is
>>>>>>>>>>>>>> predicting the behavior of Pn(Pn). UTM(Pn,Pn) by
>>>>>>>>>>>>>> definition has the same behavior of Pn(Pn), and given the
>>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A simulating halt decider is always correct to abort the
>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>> any input that it correctly predicts would never
>>>>>>>>>>>>>>> otherwise never stop
>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is
>>>>>>>>>>>>>> required to map the halting function:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet in the case of H and P that would require a software
>>>>>>>>>>>>> function to
>>>>>>>>>>>>> return the result of analyzing a non-input which from a
>>>>>>>>>>>>> software
>>>>>>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>>>>>>
>>>>>>>>>>>> You don't get to change the question.
>>>>>>>>>>> When the question is WRONG, I do get to change the question.
>>>>>>>>>>
>>>>>>>>>> Are you saying that it's impossible for a function H to
>>>>>>>>>> implement the following specification?
>>>>>>>>>>
>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>
>>>>>>>>> main()
>>>>>>>>> {
>>>>>>>>> H(P,P);
>>>>>>>>> P(P);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions
>>>>>>>>> where P
>>>>>>>>> has been executed first and H has not yet been executed then H is
>>>>>>>>> reporting incorrectly, directly against the verified facts.
>>>>>>>>
>>>>>>>> That doesn't answer my question. Is it possible for to create an
>>>>>>>> algorithm H that implements the following specification?
>>>>>>>>
>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>> *The above specification is incoherent
>>>>>>
>>>>>> So you're saying that it's impossible to create an H that meets
>>>>>> this specification?
>>>>> In the same way that it is impossible to correctly answer this
>>>>> question:
>>>>> What time is it (yes or no)?
>>>>
>>>> So just to be clear, you're saying that the following specification:
>>>>
>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>
>>>> Is impossible to satisfy?
>>> It is incorrect in some cases.
>>
>> I didn't ask if it was incorrect.  I asked if it's impossible to
>> create an H that satisfies this specification?
>
> Of course you will ignore that it is incorrect because you are only
> interested in rebuttal and not honest dialogue.
>

On 8/3/22 8:08 AM, olcott wrote:
> On 8/3/2022 6:23 AM, Paul N wrote:
>> On Wednesday, August 3, 2022 at 1:47:42 AM UTC+1, olcott wrote:
>>> main()
>>> {
>>> H(P,P);
>>> P(P);
>>> }
>>>
>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>> has been executed first and H has not yet been executed then H is
>>> reporting incorrectly, directly against the verified facts.
>>
>> I think this also may be key to where you are going wrong. H is
>> supposed to determine whether P(P) halts or not.
>
>    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 [*specified by this
>    description*] will finish running or continue to run forever.
>    https://en.wikipedia.org/wiki/Halting_problem
>
> P(P) is not a "description of an arbitrary computer program and an
> input" it is a running process.
>
> int sum(int x, int y) { return x + y; }
> sum(3,4) must return the sum of 3+4 and
> its not allowed to return the sum of 4+5.
>
> Likewise H must determine the behavior of its input and must not
> determine the behavior of any non-input.
>
>> You are now saying that the only behaviour of P that you are able to
>> predict is when H is already running.
>
> In other words when H(P,P) has not been run will it not return any result.
>
>> Thus your answer involves itself in the question.
>>
>> To take an analogy - suppose you have a voltmeter. It measures very
>> accurately what the voltage across it is when it is connected.
>> However, that voltage is very different from what the voltage would be
>> across the two points when the voltmeter is not connected, due to the
>> current drawn by the voltmeter itself. Most people would say that this
>> was not a good voltmeter (at least for use in testing), no matter how
>> accurately it did measure what it measured.
>>
>> The same is true for your function H. By your own admission it can
>> only measure what P does when H exists and is running. A halt detector
>> needs to do more than that.
>
> In other words you are saying that H(P,P) must return a result even if
> it does not exist or before it has ever been run?
>
>

On 8/3/2022 7:12 PM, Dennis Bush wrote:
> On Wednesday, August 3, 2022 at 8:08:53 PM UTC-4, olcott wrote:
>> On 8/3/2022 6:50 PM, Dennis Bush wrote:
>>> On Wednesday, August 3, 2022 at 7:16:33 PM UTC-4, olcott wrote:
>>>> On 8/3/2022 5:53 PM, Dennis Bush wrote:
>>>>> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
>>>>>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
>>>>>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
>>>>>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>>>>>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
>>>>>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
>>>>>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
>>>>>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
>>>>>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
>>>>>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
>>>>>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
>>>>>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
>>>>>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
>>>>>>>>>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
>>>>>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
>>>>>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
>>>>>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
>>>>>>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
>>>>>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
>>>>>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
>>>>>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
>>>>>>>>>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
>>>>>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
>>>>>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
>>>>>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
>>>>>>>>>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
>>>>>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
>>>>>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
>>>>>>>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
>>>>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet in the case of H and P that would require a software function to
>>>>>>>>>>>>>>>> return the result of analyzing a non-input which from a software
>>>>>>>>>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You don't get to change the question.
>>>>>>>>>>>>>> When the question is WRONG, I do get to change the question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
>>>>>>>>>>>>>
>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>
>>>>>>>>>>>> main()
>>>>>>>>>>>> {
>>>>>>>>>>>> H(P,P);
>>>>>>>>>>>> P(P);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
>>>>>>>>>>>> has been executed first and H has not yet been executed then H is
>>>>>>>>>>>> reporting incorrectly, directly against the verified facts.
>>>>>>>>>>>
>>>>>>>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
>>>>>>>>>>>
>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>> *The above specification is incoherent
>>>>>>>>>
>>>>>>>>> So you're saying that it's impossible to create an H that meets this specification?
>>>>>>>> In the same way that it is impossible to correctly answer this question:
>>>>>>>> What time is it (yes or no)?
>>>>>>>
>>>>>>> So just to be clear, you're saying that the following specification:
>>>>>>>
>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>
>>>>>>> Is impossible to satisfy?
>>>>>> It is incorrect in some cases.
>>>>>
>>>>> I didn't ask if it was incorrect. I asked if it's impossible to create an H that satisfies this specification?
>>>> Of course you will ignore that it is incorrect because you are only
>>>> interested in rebuttal and not honest dialogue.
>>>
>>> Questions are not incorrect. They just are.
>>>
>> OK then what time is it (yes or no)?
>
> That question doesn't have a yes or no answer.
Right because it is an incorrect question.

On 8/3/22 9:48 PM, olcott wrote:
> On 8/3/2022 7:12 PM, Dennis Bush wrote:
>> On Wednesday, August 3, 2022 at 8:08:53 PM UTC-4, olcott wrote:
>>> On 8/3/2022 6:50 PM, Dennis Bush wrote:
>>>> On Wednesday, August 3, 2022 at 7:16:33 PM UTC-4, olcott wrote:
>>>>> On 8/3/2022 5:53 PM, Dennis Bush wrote:
>>>>>> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
>>>>>>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
>>>>>>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
>>>>>>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
>>>>>>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
>>>>>>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
>>>>>>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
>>>>>>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
>>>>>>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt decider that correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator, the simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its emulation of its input:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) to do this again.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input with an x86
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simulation. If H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> NOT what happens.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can CORRECTLY determine
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this pattern, because it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly prove the input is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> defined (incorrectly) as
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulation, and H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actual program P(P) to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the question H(P,P) if H is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that H is incorrect to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, since it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that P(P), please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that is different, and is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of the input.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seeing a call to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proved incorrect and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assuming it, and thus falls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conclusion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to H(P,P) that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own "ret" instruction
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> abort its simuation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation this causes the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even after it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sufficiently technically competent
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and complete
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated P that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution steps and reach
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> forced to stop running
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct and COMPLETE
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return instruction.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decider
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that is correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction of this simulated P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation of the function H
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to a final state. Which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of a halt decider.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because Pa(Pa) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is incorrect:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from its inputs to an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the actual behavior that is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determined by the actual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct simulation of an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sequence of instructions that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reject the concept of UTM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will
>>>>>>>>>>>>>>>>>>>>>>>>>>>> recreate the behavior of
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation
>>>>>>>>>>>>>>>>>>>>>>>>>>> correctly matches any
>>>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there
>>>>>>>>>>>>>>>>>>>>>>>>>>> is no need to wait until
>>>>>>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop
>>>>>>>>>>>>>>>>>>>>>>>>>>> never halts.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> behavior pattern if the
>>>>>>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite
>>>>>>>>>>>>>>>>>>>>>>>>>> recursion, which it doesn't if
>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
>>>>>>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly
>>>>>>>>>>>>>>>>>>>>>>>>> determine the halt status of
>>>>>>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to
>>>>>>>>>>>>>>>>>>>>>>>>> examine its input instead
>>>>>>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input
>>>>>>>>>>>>>>>>>>>>>>>>> P(P) ?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its
>>>>>>>>>>>>>>>>>>>>>>>> input".
>>>>>>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of
>>>>>>>>>>>>>>>>>>>>>>> of reviewers reject
>>>>>>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even
>>>>>>>>>>>>>>>>>>>>>>> looking at it and
>>>>>>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding
>>>>>>>>>>>>>>>>>>>>>>> fault that they hardly
>>>>>>>>>>>>>>>>>>>>>>> pay any attention to what I say.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is
>>>>>>>>>>>>>>>>>>>>>> failing you again. I know that when you say
>>>>>>>>>>>>>>>>>>>>>> "H(P,P) does correctly determine the halt status
>>>>>>>>>>>>>>>>>>>>>> of its input", what you really mean is "there is
>>>>>>>>>>>>>>>>>>>>>> no implementation of the function H that can
>>>>>>>>>>>>>>>>>>>>>> simulate the function call P(P) to a final state".
>>>>>>>>>>>>>>>>>>>>>> And that is true, and is what I was agreeing
>>>>>>>>>>>>>>>>>>>>>> about. That become more clear with what I said next:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt
>>>>>>>>>>>>>>>>>>>>>>>> status of the machine the input represents,
>>>>>>>>>>>>>>>>>>>>>>>> specifically Pa(Pa), as per the definition of
>>>>>>>>>>>>>>>>>>>>>>>> the function a halt decider is required to compute:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong
>>>>>>>>>>>>>>>>>>>>>> question.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And
>>>>>>>>>>>>>>>>>>>>>> everything that follows from here down is bunk
>>>>>>>>>>>>>>>>>>>>>> because it depends on the wrong answer being right.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the
>>>>>>>>>>>>>>>>>>>>>>> same behavior
>>>>>>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input
>>>>>>>>>>>>>>>>>>>>>>> because the execution
>>>>>>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>> invoked first.
>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>>>>>>>>>>> return;
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first
>>>>>>>>>>>>>>>>>>>>>>> call of
>>>>>>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its
>>>>>>>>>>>>>>>>>>>>>>> input this
>>>>>>>>>>>>>>>>>>>>>>> is essentially the second call of infinite
>>>>>>>>>>>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its
>>>>>>>>>>>>>>>>>>>>>>> input and
>>>>>>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all
>>>>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole
>>>>>>>>>>>>>>>>>>>>>>> sequence stops.
>>>>>>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it
>>>>>>>>>>>>>>>>>>>>>>> returns to
>>>>>>>>>>>>>>>>>>>>>>> its caller.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as
>>>>>>>>>>>>>>>>>>>>>>> proven by the fact
>>>>>>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted)
>>>>>>>>>>>>>>>>>>>>>>> therefore H did
>>>>>>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status
>>>>>>>>>>>>>>>>>>>>>>> of a non-input
>>>>>>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that
>>>>>>>>>>>>>>>>>>>>>>> software engineering
>>>>>>>>>>>>>>>>>>>>>>> won't allow it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> If determining the halt status of a non-input
>>>>>>>>>>>>>>>>>>>>>> seems so absurd, why do you claim that Ha(Pa,Pa)
>>>>>>>>>>>>>>>>>>>>>> must report the halt status of Pn(Pn)?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You know that never said anything like that:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
>>>>>>>>>>>>>>>>>>>>> saying anything like that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting
>>>>>>>>>>>>>>>>>>>> is saying:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4,
>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly
>>>>>>>>>>>>>>>>>>>>> emulate ever reach its
>>>>>>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped
>>>>>>>>>>>>>>>>>>>>> emulating it?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer
>>>>>>>>>>>>>>>>>>>> Ha. It is Hn. That also means that Pa is no longer
>>>>>>>>>>>>>>>>>>>> Pa since it's now calling Hn. It is now Pn.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So by postulating that Ha has different behavior,
>>>>>>>>>>>>>>>>>>>> you change the input. So the above is EXACTLY saying
>>>>>>>>>>>>>>>>>>>> that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
>>>>>>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and
>>>>>>>>>>>>>>>>>>> Hn(Pn,Pn).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its
>>>>>>>>>>>>>>>>>> input will do if its implementation is Hn, then
>>>>>>>>>>>>>>>>>> Ha(Pa,Pa) is predicting the behavior of Pn(Pn).
>>>>>>>>>>>>>>>>>> UTM(Pn,Pn) by definition has the same behavior of
>>>>>>>>>>>>>>>>>> Pn(Pn), and given the
>>>>>>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> A simulating halt decider is always correct to abort
>>>>>>>>>>>>>>>>>>> the simulation of
>>>>>>>>>>>>>>>>>>> any input that it correctly predicts would never
>>>>>>>>>>>>>>>>>>> otherwise never stop
>>>>>>>>>>>>>>>>>>> running.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is
>>>>>>>>>>>>>>>>>> required to map the halting function:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yet in the case of H and P that would require a
>>>>>>>>>>>>>>>>> software function to
>>>>>>>>>>>>>>>>> return the result of analyzing a non-input which from a
>>>>>>>>>>>>>>>>> software
>>>>>>>>>>>>>>>>> engineering perspective is pure nonsense.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You don't get to change the question.
>>>>>>>>>>>>>>> When the question is WRONG, I do get to change the question.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you saying that it's impossible for a function H to
>>>>>>>>>>>>>> implement the following specification?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>>>>>
>>>>>>>>>>>>> main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H(P,P);
>>>>>>>>>>>>> P(P);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> If H(P,P) reports on the behavior of a sequence of
>>>>>>>>>>>>> instructions where P
>>>>>>>>>>>>> has been executed first and H has not yet been executed
>>>>>>>>>>>>> then H is
>>>>>>>>>>>>> reporting incorrectly, directly against the verified facts.
>>>>>>>>>>>>
>>>>>>>>>>>> That doesn't answer my question. Is it possible for to
>>>>>>>>>>>> create an algorithm H that implements the following
>>>>>>>>>>>> specification?
>>>>>>>>>>>>
>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>>>> *The above specification is incoherent
>>>>>>>>>>
>>>>>>>>>> So you're saying that it's impossible to create an H that
>>>>>>>>>> meets this specification?
>>>>>>>>> In the same way that it is impossible to correctly answer this
>>>>>>>>> question:
>>>>>>>>> What time is it (yes or no)?
>>>>>>>>
>>>>>>>> So just to be clear, you're saying that the following
>>>>>>>> specification:
>>>>>>>>
>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
>>>>>>>>
>>>>>>>> Is impossible to satisfy?
>>>>>>> It is incorrect in some cases.
>>>>>>
>>>>>> I didn't ask if it was incorrect. I asked if it's impossible to
>>>>>> create an H that satisfies this specification?
>>>>> Of course you will ignore that it is incorrect because you are only
>>>>> interested in rebuttal and not honest dialogue.
>>>>
>>>> Questions are not incorrect. They just are.
>>>>
>>> OK then what time is it (yes or no)?
>>
>> That question doesn't have a yes or no answer.
> Right because it is an incorrect question.
>
> I came up with that example of an incorrect question decades ago when
> working on the halting problem.

On Wednesday, August 3, 2022 at 9:48:41 PM UTC-4, olcott wrote:
> On 8/3/2022 7:12 PM, Dennis Bush wrote:
> > On Wednesday, August 3, 2022 at 8:08:53 PM UTC-4, olcott wrote:
> >> On 8/3/2022 6:50 PM, Dennis Bush wrote:
> >>> On Wednesday, August 3, 2022 at 7:16:33 PM UTC-4, olcott wrote:
> >>>> On 8/3/2022 5:53 PM, Dennis Bush wrote:
> >>>>> On Wednesday, August 3, 2022 at 6:50:38 PM UTC-4, olcott wrote:
> >>>>>> On 8/3/2022 4:18 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, August 3, 2022 at 8:41:09 AM UTC-4, olcott wrote:
> >>>>>>>> On 8/3/2022 6:46 AM, Dennis Bush wrote:
> >>>>>>>>> On Wednesday, August 3, 2022 at 1:11:37 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 8/2/2022 7:52 PM, Dennis Bush wrote:
> >>>>>>>>>>> On Tuesday, August 2, 2022 at 8:46:28 PM UTC-4, olcott wrote:
> >>>>>>>>>>>> On 8/1/2022 8:40 PM, Dennis Bush wrote:
> >>>>>>>>>>>>> On Monday, August 1, 2022 at 9:37:49 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>> On 8/1/2022 8:17 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>> On Monday, August 1, 2022 at 9:06:00 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>> On 8/1/2022 7:50 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:42:08 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 8/1/2022 7:36 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 8:27:22 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 8/1/2022 7:16 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 7:54:32 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 8/1/2022 6:06 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Monday, August 1, 2022 at 6:34:37 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 9:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 10:00 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:36 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 9:26 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 8:53 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates its input with an x86 emulator, the simulation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will never
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Executed H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (5) Emulated H(P,P) simulates its input with an x86
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> emulator...
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does abort its simulation, this is NOT what happens.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Good, I agree.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> input is non-halting, will match this pattern, because it
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will NEVER
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in finite time be able to actually correctly prove the input is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stops its
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halt.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return 0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Halting.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> generate a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> different sequence of configurations that P(P), please
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> FIRST configuration in the sequence that is different, and is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually the result of a CORRECT simulation of the input.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "proof"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that its input is non-halting is proved incorrect and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> into the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fallacy of the assumption of the conclusion.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether or not H aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you believe that when H aborts its simulation this causes the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aborted before reaching this instruction?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Unless you reverse your position technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewers will
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that you are not a sufficiently technically competent
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewer.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation, then a correct and complete
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input will reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If H aborts its simulation of P then the simulated P that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no longer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> running will continue several more execution steps and reach
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its "ret"
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instruction even though it has been forced to stop running
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> before ever
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reaching the "ret" instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the input to H(P,P) to reach the return instruction.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is only a simulated P in the following:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> typedef void (*ptr)();
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Output("Input_Halts = ", H(P, P));
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So you agree that the input to H(P,P) that is correctly
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated by H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> or not H aborts its simulation or not?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, I agree that there is no implementation of the function H
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that can simulate the function call P(P) to a final state. Which
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> has nothing to do with the requirements of a halt decider.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you are saying that this is incorrect:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A halt decider must compute the mapping from its inputs to an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> accept or reject state on the basis of the actual behavior that is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actually specified by these inputs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, just that the "Actual Behvior" is determined by the actual
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior of the program the input represents,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> In other words you do not believe that the correct simulation of an
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> input necessarily has the exact same sequence of instructions that
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> are specified by this input, thus you reject the concept of UTM
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> No. a COMPLETE and correct simulation will recreate the behavior of
> >>>>>>>>>>>>>>>>>>>>>>>>>>> the input. The COMPLETE part is important.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Not at all, as long as the partial simulation correctly matches any
> >>>>>>>>>>>>>>>>>>>>>>>>>> correct infinite behavior pattern then there is no need to wait until
> >>>>>>>>>>>>>>>>>>>>>>>>>> the end of time to see that an infinite loop never halts.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> But the pattern is only a CORRECT infinite behavior pattern if the
> >>>>>>>>>>>>>>>>>>>>>>>>> PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
> >>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) aborts its simulation.
> >>>>>>>>>>>>>>>>>>>>>>>> So then you agree the H(P,P) does correctly determine the halt status of
> >>>>>>>>>>>>>>>>>>>>>>>> its input, yet disagree that H is supposed to examine its input instead
> >>>>>>>>>>>>>>>>>>>>>>>> it must examine the behavior of the non-input P(P) ?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Sure, Ha(Pa,Pa) reports the halt status of "its input".
> >>>>>>>>>>>>>>>>>>>>>> I count that as a huge breakthrough when 99% of of reviewers reject
> >>>>>>>>>>>>>>>>>>>>>> everything that I say out-of-hand without even looking at it and
> >>>>>>>>>>>>>>>>>>>>>> the remaining 1% are so laser focused on finding fault that they hardly
> >>>>>>>>>>>>>>>>>>>>>> pay any attention to what I say.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> But is seems you're reading comprehension is failing you again. I know that when you say "H(P,P) does correctly determine the halt status of its input", what you really mean is "there is no implementation of the function H that can simulate the function call P(P) to a final state". And that is true, and is what I was agreeing about. That become more clear with what I said next:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> But that's apparently not the same as the halt status of the machine the input represents, specifically Pa(Pa), as per the definition of the function a halt decider is required to compute:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Where I point out you're answering the wrong question.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. And everything that follows from here down is bunk because it depends on the wrong answer being right.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> The behavior of directly executed P(P) is NOT the same behavior
> >>>>>>>>>>>>>>>>>>>>>> as when H(P,P) correctly simulates its input because the execution
> >>>>>>>>>>>>>>>>>>>>>> order of P(P) first is reversed when H(P,P) is invoked first.
> >>>>>>>>>>>>>>>>>>>>>> void P(ptr x)
> >>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>> int Halt_Status = H(x, x);
> >>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
> >>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>>>>>>>>>>>> return;
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>>>>>> P(P);
> >>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> When P calls H(P,P) this is essentially the first call of
> >>>>>>>>>>>>>>>>>>>>>> infinite recursion. When H(P,P) simulates its input this
> >>>>>>>>>>>>>>>>>>>>>> is essentially the second call of infinite recursion.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> H can see the infinite recursion specified by its input and
> >>>>>>>>>>>>>>>>>>>>>> aborts its simulation on that basis. As with all infinite
> >>>>>>>>>>>>>>>>>>>>>> recursion when any call is aborted the whole sequence stops.
> >>>>>>>>>>>>>>>>>>>>>> In this case when H(P,P) aborts its simulation it returns to
> >>>>>>>>>>>>>>>>>>>>>> its caller.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> The input to H(P,P) is infinitely recursive (as proven by the fact
> >>>>>>>>>>>>>>>>>>>>>> the the simulation never stops unless aborted) therefore H did
> >>>>>>>>>>>>>>>>>>>>>> correctly determine the halt status of this input.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> That is was supposed to determine the halt status of a non-input
> >>>>>>>>>>>>>>>>>>>>>> seems absurd and is rejected on the basis that software engineering
> >>>>>>>>>>>>>>>>>>>>>> won't allow it.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> If determining the halt status of a non-input seems so absurd, why do you claim that Ha(Pa,Pa) must report the halt status of Pn(Pn)?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You know that never said anything like that:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Try and find a date-and-time stamped quote of me
> >>>>>>>>>>>>>>>>>>>> saying anything like that.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> That's precisely what the comment I've been quoting is saying:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Saturday, July 30, 2022 at 4:09:34 PM UTC-4, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> H(P,P) is asking would the input that I correctly emulate ever reach its
> >>>>>>>>>>>>>>>>>>>> "ret" instruction (final state) if I never stopped emulating it?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> If Ha never stops emulating, then it is no longer Ha. It is Hn. That also means that Pa is no longer Pa since it's now calling Hn. It is now Pn.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So by postulating that Ha has different behavior, you change the input. So the above is EXACTLY saying that Ha(Pa,Pa) must report on the behavior of Pn(Pn).
> >>>>>>>>>>>>>>>>>> You did it incorrectly it must be Ha(Pa,Pa) and Hn(Pn,Pn).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> No, it was correct. If Ha(Pa,Pa) predicts what its input will do if its implementation is Hn, then Ha(Pa,Pa) is predicting the behavior of Pn(Pn). UTM(Pn,Pn) by definition has the same behavior of Pn(Pn), and given the
> >>>>>>>>>>>>>>>>> of Hn it is essentially the same as a UTM.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> A simulating halt decider is always correct to abort the simulation of
> >>>>>>>>>>>>>>>>>> any input that it correctly predicts would never otherwise never stop
> >>>>>>>>>>>>>>>>>> running.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> A simulating halt decider, like any halt decider, is required to map the halting function:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Yet in the case of H and P that would require a software function to
> >>>>>>>>>>>>>>>> return the result of analyzing a non-input which from a software
> >>>>>>>>>>>>>>>> engineering perspective is pure nonsense.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> You don't get to change the question.
> >>>>>>>>>>>>>> When the question is WRONG, I do get to change the question.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Are you saying that it's impossible for a function H to implement the following specification?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>>>>>
> >>>>>>>>>>>> main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> H(P,P);
> >>>>>>>>>>>> P(P);
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> If H(P,P) reports on the behavior of a sequence of instructions where P
> >>>>>>>>>>>> has been executed first and H has not yet been executed then H is
> >>>>>>>>>>>> reporting incorrectly, directly against the verified facts.
> >>>>>>>>>>>
> >>>>>>>>>>> That doesn't answer my question. Is it possible for to create an algorithm H that implements the following specification?
> >>>>>>>>>>>
> >>>>>>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>>>> *The above specification is incoherent
> >>>>>>>>>
> >>>>>>>>> So you're saying that it's impossible to create an H that meets this specification?
> >>>>>>>> In the same way that it is impossible to correctly answer this question:
> >>>>>>>> What time is it (yes or no)?
> >>>>>>>
> >>>>>>> So just to be clear, you're saying that the following specification:
> >>>>>>>
> >>>>>>> H(X,Y)==1 if and only if X(Y) halts, and
> >>>>>>> H(X,Y)==0 if and only if X(Y) does not halt
> >>>>>>>
> >>>>>>> Is impossible to satisfy?
> >>>>>> It is incorrect in some cases.
> >>>>>
> >>>>> I didn't ask if it was incorrect. I asked if it's impossible to create an H that satisfies this specification?
> >>>> Of course you will ignore that it is incorrect because you are only
> >>>> interested in rebuttal and not honest dialogue.
> >>>
> >>> Questions are not incorrect. They just are.
> >>>
> >> OK then what time is it (yes or no)?
> >
> > That question doesn't have a yes or no answer.
> Right because it is an incorrect question.