Simulating halt decider applied to a simpler input

[olcott]

void E(void (*x)())
{
H(x, x);
}

(Ignoring stack overflow) If H correctly simulates E would the simulated
E ever stop running without being aborted?

Because no E would ever stop running unless H aborts its simulation of E
this proves that the aborted E specifies a non-halting sequence of
configurations.

Simulating Halt Decider Applied to the Halting Theorem
https://www.researchgate.net/publication/364657019_Simulating_Halt_Decider_Applied_to_the_Halting_Theorem

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

[olcott]

On 11/11/2022 5:48 PM, Richard Damon wrote:
> On 11/11/22 6:39 PM, olcott wrote:
>> On 11/11/2022 5:20 PM, Richard Damon wrote:
>>> On 11/11/22 5:37 PM, olcott wrote:
>>>> On 11/11/2022 3:44 PM, Richard Damon wrote:
>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>
>>>>>>>>>>>> It is my understanding that Olcott has blocked you and I
>>>>>>>>>>>> would have
>>>>>>>>>>>> thought given your intelligence you would also understand that.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I don't think he has actually blocked me, just mostly ignores
>>>>>>>>>>> me.
>>>>>>>>>>>
>>>>>>>>>>> I say this because at times he seems to respond to what I
>>>>>>>>>>> say, even if not in a direct reply,
>>>>>>>>>>>
>>>>>>>>>>> Also, when someone like you replies, even if he has blocked
>>>>>>>>>>> me, he will still see me.
>>>>>>>>>>>
>>>>>>>>>>> More importantly, If anyone naive wanders into the archives,
>>>>>>>>>>> I want enough evidence to be around to point out his errors.
>>>>>>>>>>>
>>>>>>>>>>> Note also, my longer replies shows what I know and provide
>>>>>>>>>>> reasoning behind the claims, showing the Truth.
>>>>>>>>>>>
>>>>>>>>>>> His short claims, and guff replies just show that he doesn't
>>>>>>>>>>> actually know what he is talking about, and reveals his
>>>>>>>>>>> ignorance. If he tries to put his explanation into explicit
>>>>>>>>>>> words, his errors become very apparent, I think even to him,
>>>>>>>>>>> so he just refuses.
>>>>>>>>>>
>>>>>>>>>> You always use the strawman deception as your only basis.
>>>>>>>>>> Naive readers will never notice this, yet naive readers are
>>>>>>>>>> not in my target audience.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, because *I* use the actual definition of a Halting Decider.
>>>>>>>>>
>>>>>>>> Anyone that accepts the definition of a universal Turing machine
>>>>>>>> (UTM) knows that the behavior of D correctly simulated by H
>>>>>>>> provides H with a correct basis for its halt status decision.
>>>>>>>>
>>>>>>>
>>>>>>> But only if H DOES correctly simulate its input.

>>>>>>>
>>>>>>
>>>>>> void E(void (*x)())
>>>>>> {
>>>>>>    H(x, x);
>>>>>> }
>>>>>>

>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>> execution of E is correct to report non-halting. No shell game can
>>>>>> correctly deny this.
>>>>>>
>>>>>
>>>>> Any H that does aborts its simulation is INCORRECT because the
>>>>> CORRECT simulation, as will the diret exectuion, will halt.
>>>> If no H ever aborts its simulation of E then no E ever stops running
>>>> this conclusively proves that H is correct to abort its simulation
>>>> and report non-halting.
>>>>
>>>
>>> if THE H doesn't abort, it doesn't answer.
>>>
>>
>> H only need to correctly predict that its input would never reach its
>> own final state and terminate normally in 1 to ∞ of correct simulation.
>
> Right, and it does when CORRECTLY (and completely) simulated or directly
> executed.
>
> H just aborts its simulation too soon.

*This is the part where you are either incompetent or a liar*

Any expert in C knows that the correctly simulated E never reaches its
own final state even if an infinite number of steps are correctly
simulated. Thus H is correct to predict that its input never halts.

void E(void (*x)())
{
H(x, x);
}

int main() { H(E,E); }

[olcott]

On 11/12/2022 8:02 AM, Richard Damon wrote:
> On 11/11/22 11:00 PM, olcott wrote:
>> On 11/11/2022 8:56 PM, Richard Damon wrote:
>>> On 11/11/22 9:48 PM, olcott wrote:
>>>> On 11/11/2022 8:45 PM, Richard Damon wrote:
>>>>> On 11/11/22 9:35 PM, olcott wrote:
>>>
>>>> Yes and when embedded_H can predict this in a finite number of steps
>>>> then it is a halt decider for ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>
>>> Except that it can't do that since it is shown that H^ <H^> Will halt
>>> in this case, so it is impossible to correctly predict that a correct
>>> simulation of the input <H^> <H^> will not halt.
>> A simulating halt decider must correctly predict (in a finite number
>> of steps whether or not its simulated input would ever stop running if
>> it never aborted its simulation of its input.
>>
>>
>
> Right, it must, but it can't. Again, your Egish is lacking because you
> are too stupid.
>
> If you claim it can, what pattern did it use to detect this, that ALWAYS
> shows the program is non-halting?
>
> I will note that E(E) calling H(E,E) is NOT such a pattern, as E(E) will
> halt if H(E,E) is defined to abort that simulation and return 0.
void Infinite_Loop()
{
HERE: goto HERE;
}

It is an easily verified fact that Infinite_Loop correctly simulated by
H would never reach its own last instruction and terminate normally
after 1 to ∞ steps of correct simulation.

void E(void (*x)())
{
H(x, x);
}

It is an easily verified fact that E correctly simulated by H would
never reach its own last instruction and terminate normally after 1 to ∞
steps of correct simulation.

[olcott]

On 11/12/2022 9:03 AM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 09:52:12 -0500
> Richard Damon <Ric...@Damon-Family.org> wrote:
>
>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>> Richard Damon <Ric...@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>> Richard Damon <Ric...@Damon-Family.org> wrote:
>>>>>
>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>> Richard Damon <Ric...@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:

>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>   H(x, x);
>>>>>>>>>>> }
>>>>>>>>>>>

>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will

>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>
>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>> INVALID INPUT.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, no self reference.
>>>>>>>>
>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>> directly express a reference.
>>>>>>>
>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>> different way.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>> actually a decider.
>>>>>>
>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>> program is simple to make from it, and is given one copy of the
>>>>>> description of itself, which is also simple to make.
>>>>>>
>>>>>> When run it makes a second copy of its description, and then
>>>>>> calls the decider.
>>>>>>
>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>> infinite loop, the decider is just wrong.
>>>>>>
>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>> the requirements.
>>>>>>
>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>> copy of something that just happens to be its own description.
>>>>>>
>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>> out be be impossible, so no such program exists.
>>>>>
>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>> not due to self reference or infinite copies but because the input
>>>>> tries to do the opposite of what the decider decides; the category
>>>>> error that I have identified is different: it is an error of self
>>>>> reference and/or infinite copies; it is an error related to the
>>>>> fact that the input references a decider rather than being related
>>>>> to what the input does with the decision result of a decider.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> But the infinite copies is a error in the Decider, not in
>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>> ANY input and answer in finite time, If an input causes it to make
>>>> infinite copies, then the decided just doesn't meet its
>>>> requirements.
>>>>
>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>> if H is actualy a Turing Machine.
>>>>
>>>> All your declaration of a "Category Error" here is doing is
>>>> admitting that your H can't actually be a Turing Machine, but must
>>>> be of a HIGHER order logic system, which means H fails the
>>>> requirement to be the needed decider.
>>>
>>> In which case we get infinite turning machines all the way down: yet
>>> another manifestation of the category error I have identified.
>>>
>>> /Flibble
>>>
>>
>> Where are infinite machines? There is ONE machine being run, either H
>> or D, and it SIMULATING others, and if we get an infinite sequence of
>> simulations we have just shown that H was defective because it failed
>> to answer in finite time.
>>
>> This isn't a category error, but a design error in H.
>>
>> Note, when we start H, there is exactly two machines present in
>> representation on the tape, and two is much smaller than infinity.
>
> Nope, if,
>
> a) H is a copy, and
> b) H is a Turing Machine, and
> c) D is an input into H, and
> d) D references H, and
> e) H references D,
>
> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
> all the way down: a manifestation of the category error I have
> identified.
>
> /Flibble

>

void E(void (*x)())
{
H(x, x);
}

The point is
that D correctly simulated by H would never reach its own last

instruction and terminate normally after 1 to ∞ steps of correct simulation.

When H returns 0 to main() it is indicating

that D correctly simulated by H would never reach its own last

instruction and terminate normally after 1 to ∞ steps of correct simulation.