On 7/13/22 9:34 PM, olcott wrote:
> On 7/13/2022 8:20 PM, Richard Damon wrote:
>>
>> On 7/13/22 8:06 PM, olcott wrote:
>>> On 7/13/2022 6:51 PM, Richard Damon wrote:
>>>> On 7/13/22 8:19 AM, olcott wrote:
>>>>> On 7/13/2022 6:51 AM, Richard Damon wrote:
>>>>>> On 7/12/22 10:52 PM, olcott wrote:
>>>>>>> On 7/12/2022 9:39 PM, Richard Damon wrote:
>>>>>>>> On 7/12/22 10:29 PM, olcott wrote:
>>>>>>>>> On 7/12/2022 9:26 PM, Richard Damon wrote:
>>>>>>>>>> On 7/12/22 9:49 PM, olcott wrote:
>>>>>>>>>>> On 7/12/2022 9:14 AM, Freethinker wrote:
>>>>>>>>>>>> On 12.07.22 01:14, olcott wrote:
>>>>>>>>>>>>> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>>>>>>>>>>>>>> On 11/07/2022 11:28, Mark Bluemel wrote:
>>>>>>>>>>>>>>> As you'd remember if you actually read this newsgroup, we
>>>>>>>>>>>>>>> discussed this nearly 4 months ago when the article came
>>>>>>>>>>>>>>> out.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I doubt we need to cover the ground again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why don't you tell the same thing to that idiot called
>>>>>>>>>>>>>> Olcott? He keeps
>>>>>>>>>>>>>> posting the same thing every two weeks and there are two
>>>>>>>>>>>>>> guys here who
>>>>>>>>>>>>>> keep responding to him, instead of kill-filing him.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Olcott comes here because he is getting a response; Olcott
>>>>>>>>>>>>>> won't go
>>>>>>>>>>>>>> anywhere unless people stop responding to him completely.
>>>>>>>>>>>>>> Just ignore him;
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I won't go anywhere until my work is validated whether or
>>>>>>>>>>>>> not anyone responds. I just had a very extensive review (23
>>>>>>>>>>>>> emails) by a leading computer scientist.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because of this review I was able to simplify my
>>>>>>>>>>>>> presentation so that everyone here can easily verify that I
>>>>>>>>>>>>> have correctly refuted the halting theorem on this pure
>>>>>>>>>>>>> software engineering basis:
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> OK, so now that we have easily verified that, would you
>>>>>>>>>>>> please stop posting this same thing millions of times?
>>>>>>>>>>>
>>>>>>>>>>> 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 is not verified until it is understood that P and H
>>>>>>>>>>> implement the classical halting problem "impossible input"
>>>>>>>>>>> template (as shown above) and refutes this template in that
>>>>>>>>>>> H(P,P) correctly determines that its input never terminates
>>>>>>>>>>> normally.
>>>>>>>>>>>
>>>>>>>>>>> *This is the key software engineering that I need validated*
>>>>>>>>>>> Most anyone here can easily verify that the simulated input
>>>>>>>>>>> to H(P,P) cannot possibly terminate normally.
>>>>>>>>>>>
>>>>>>>>>>> The next level of pure software engineering is that H(P,P)
>>>>>>>>>>> correctly predicts that its simulated input cannot possibly
>>>>>>>>>>> terminate normally. It may be the case that only the top 5%
>>>>>>>>>>> of software engineers can validate this point.
>>>>>>>>>>>
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int H(ptr p, ptr i);
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>    if (H(x, x))
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Simulating halt decider H detects that its simulated input is
>>>>>>>>>>> essentially calling H in infinite recursion. H aborts its
>>>>>>>>>>> simulation on this basis and rejects this input as non-halting.
>>>>>>>>>>>
>>>>>>>>>>> The execution trace of function P() simulated by function H()
>>>>>>>>>>> shows:
>>>>>>>>>>> (1) Function H() is called from P().
>>>>>>>>>>> (2) With the same parameters to H().
>>>>>>>>>>> (3) With no instructions in P() that could possibly escape
>>>>>>>>>>> this infinitely recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> *That was all of the software engineering that I need validated*
>>>>>>>>>>>
>>>>>>>>>>> Halting problem proofs refuted on the basis of software
>>>>>>>>>>> engineering
>>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And your property (3) is incorrect the way you use it. The
>>>>>>>>>> CORRECT version of (3) looks ALL the way through the loop,
>>>>>>>>>> which includes in H, and will find the condtional there.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> H(P,P) correctly predicts that its input cannot possibly
>>>>>>>>> terminate normally. (I have better words now).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except that the program represented by the input, P(P) DOES
>>>>>>>> terminate normally if H(P,P) returns 0.
>>>>>>>
>>>>>>> *CHANGING THE SUBJECT IS NEVER A REBUTTAL*
>>>>>>> Simulating halt decider H(P,P) correctly predicts that its
>>>>>>> correctly simulated input cannot possibly terminate normally.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> WHAT Change of subject?
>>>>>>
>>>>>
>>>>> IT IS A VERIFIED FACT THAT
>>>>> Simulating halt decider H(P,P) correctly predicts that its correctly
>>>>> simulated input cannot possibly terminate normally.
>>>>>
>>>>> The only possible correct rebuttal must show all the steps of
>>>>> exactly how the input to simulating halt decider H(P,P) does
>>>>> terminate normally when H correctly simulates this input.
>>>>>
>>>>> Since I already proved that this is false entirely on the basis of
>>>>> verified fact this is impossible.
>>>>>
>>>>> This requires that a function called in essentially infinite
>>>>> recursion to return a value to its caller this is impossible.
>>>>>
>>>>> Most everyone here knows that every function called in infinite
>>>>> recursion never returns any value to its caller. There is no
>>>>> gibberish that you can say that would convince them otherwise.
>>>>>
>>>> That can't be a verified fact because the opposite is a verified
>>>> fact, that the CORRECT simulation of the input to H(P,P), which is
>>>> the correct simulation of P(P) will actually Halt if H(P,P) returns
>>>> 0, as you claim it does.
>>>
>>> I already gave Paul N a great explanation of that on comp.theory.
>>> I won't be able to see your reply there because I have you blocked
>>> there.
>>>
>>> My explanation to wjj even sums it up better:
>>>
>>> On 7/13/2022 3:51 PM, olcott wrote:
>>>  > On 7/13/2022 3:47 PM, wij wrote:
>>>  >> The property that an arbitrary program P will finish
>>>  >> running or not is  determined by running P as an
>>>  >> independent program
>>>
>>> Because that would require that a halt decider must sometimes make its
>>> halt status decision on a basis other than the actual behavior of its
>>> actual input that long standing misconception has been refuted.
>>>
>>
>> No, because all the behavior of that program exists will be encoded in
>> the representation of the program given to the decider.
>>
>
> The reason that I stop talking to you is that you make false assumptions
> that are utterly impervious to all reasoning.
>
> It is a verified fact that the input that is correctly simulated by
> H(P,P) cannot possibly terminate normally. It is also a verified fact
> that the direct execution of P(P) does terminate normally.
>
> It is also common knowledge that the correct simulation of a program is
> a correct measure of the behavior of this program.
>
> This conclusively proves that H(P,P) is correct to reject its input as
> non-halting and the behavior of a non-input cannot possibly contradict
> this.
>
>

YOU SAY THAT, but it is a FACT that you H doesn't correctly simulate the
input (since it aborts it to return 0) so it doesn't MATTER that if it
was a different program it wouldn't be able to simulate to a final state.

You are just showing you don't understand the nature of what an
algorithm IS>

P calls H, and YOUR H simulates for a while, INCORRECTLY decides it
doesn't halt, and returns 0, thus making P(P) a Halting Program.

It doesn't matter that some other H that might exist that doesn't abort
results in a P(P) that doesn't halt, that isn't the H that we are
looking at the you claim correctly return 0, as THAT H never returns
from H(P,P)/

The fact that you see these two DIFFERENT H's as the same thing just
proves that YOU don't have a firm grip of what is true.

Unless you can actually provide a H that with the EXACT SAME CODE, and
as a PURE FUNCTION of its ihput does both of these, you are just caught
in the lie you have been working on for decades. This code is of course
impossible, which is why you have refused to show any version of this
code that you have claimed to have had (with "small" errors) for years.

The "Small errors" are fundamental design bugs that you may be trying to
fix, and if you actually publish your code, it will become obvious that
you have been lying about what you program does.

You keep on saying that P(P) is a non-input, but then you are shown to
LIE that your P meets the requirements of the "impossible program", as
that asks H about the behavior of itself with its input, that is P(P),
and you have coded that as H(P,P), so if the behavior of the input to
H(P,P) is not the behabior of P(P) your P is not correct, and you proof
is INVALID.

You need to change P to call H in the way that DOES ask about P(P), and
if you can't do that, you H is automattically proven wrong as you have
shown an machine and input that it can not decide.

Or perhaps more simply, you haven't shown that it gives the right answer
for the impossible program, because you never asked it about it.

You are showing your total lack of understanding of the basics of
computation theory, or even basic logic. Your "proof" is a model for how
not to try to prove something.