André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
take the position against this tautology:

They all take the position that the fact that the input to H(P,P) is
non-halting is not an entirely sufficient reason for H to report that
its input is non-halting.

Halting problem undecidability and infinitely nested simulation (V5)

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

--
Copyright 2022 Pete Olcott

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

On 4/15/22 5:16 PM, olcott wrote:
> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
> take the position against this tautology:
>
> They all take the position that the fact that the input to H(P,P) is
> non-halting is not an entirely sufficient reason for H to report that
> its input is non-halting.
>
>

No, we take the position that you haven't actually established that the
input to H(P,P) is non-halting if H does report that fact.

When H(P,P) returns non-halting, that makes the CORRECT simulation of
the input to H halting, because the CORRECT simulation of that input
doesn't abort itself just because it reaches the point where H gave up
on it, but continues to see the H it is simulationg decider that its
input is non-halting and return the non-halting answer to the P that we
are correctly simulating and then that P halts.

You confuse the aborted, and thus only partial and thus by definition
incorrect simulation by H for the actual correct simulation of that input.

Since you haven't established the premise to you statement, even if the
statement is true, it doesn't establish that the conclusion is true.

IF you have a black cat, you have a cat, is a tautology.

But, if rather than actually having a black cat, you have a white dog,
you can't use that tautology to call your dog a cat, to show that cats bark.

Since you haven't established that the input to H actually never reaches
its final state, particualarly when H aborts its processing and returns
non-halting, you haven't established the needed condition to prove it
was correct.

You have only invoked unsound logic by assuming that the H in the input
will never abort its simulation, when in fact it will if the H you are
looking at does.

FAIL.

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

On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
> take the position against this tautology:
>
> They all take the position that the fact that the input to H(P,P) is
> non-halting is not an entirely sufficient reason for H to report that
> its input is non-halting.
>
>
>
>
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

It is a sufficient reason to say that H is non-halting, but how would H, the algorithm itself, report that?

-Philip

On 4/15/2022 4:49 PM, B.H. wrote:
> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
>> take the position against this tautology:
>>
>> They all take the position that the fact that the input to H(P,P) is
>> non-halting is not an entirely sufficient reason for H to report that
>> its input is non-halting.
>>
>>
>>
>>
>>
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>
>>
>>
>>
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
>
> It is a sufficient reason to say that H is non-halting, but how would H, the algorithm itself, report that?
>
> -Philip

Reporting it is trivial simply return 0 from H.

My problem is that all but one of my reviewers have turned into damn
liars on this one key point:

They say that even if the input to H(P,P) is non-halting the fact that
this input is non-halting is not a sufficient reason to know that it is
non-halting.

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

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

--
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 4/15/22 5:59 PM, olcott wrote:
> On 4/15/2022 4:49 PM, B.H. wrote:
>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
>>> take the position against this tautology:
>>>
>>> They all take the position that the fact that the input to H(P,P) is
>>> non-halting is not an entirely sufficient reason for H to report that
>>> its input is non-halting.
>>>
>>>
>>>
>>>
>>>
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>>
>>
>> It is a sufficient reason to say that H is non-halting, but how would
>> H, the algorithm itself, report that?
>>
>> -Philip
>
> Reporting it is trivial simply return 0 from H.
>
> My problem is that all but one of my reviewers have turned into damn
> liars on this one key point:
>
> They say that even if the input to H(P,P) is non-halting the fact that
> this input is non-halting is not a sufficient reason to know that it is
> non-halting.
>
>

No, we are saying you are LYING that the input to H(P,P) is non-halting,
because you never actually LOOKED at the right input, but only to the
input based on/to a different H that doesn't actually aborts its simulation.

Since the input contains a copy of the decider that it is supposed to
work on, using the wrong input doesn't actually prove anything.

FAIL

>
> void P(u32 x)
> {
>   if (H(x, x)) //
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
>

And the CORRECT simulatlon of that input was posted by you in the past,
showing it HALTS.

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

"B.H." <xlt.pjw@gmail.com> writes:

> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:

> It is a sufficient reason to say that H is non-halting, but how would
> H, the algorithm itself, report that?

By returning false. The key case PO obsesses about is H(P,P) with P
defined as, very roughly

void P(ptr x) { if (H(x, x)) while (1); }

PO tells us, contrary to the facts, that H(P,P) == false is correct even
though P(P) obviously "halts" (i.e. returns in this C formulation).

--
Ben.

On 4/15/2022 5:31 PM, Ben wrote:
> "B.H." <xlt.pjw@gmail.com> writes:
>
>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>
>> It is a sufficient reason to say that H is non-halting, but how would
>> H, the algorithm itself, report that?
>
> By returning false. The key case PO obsesses about is H(P,P) with P
> defined as, very roughly
>
> void P(ptr x) { if (H(x, x)) while (1); }
>
> PO tells us, contrary to the facts, that H(P,P) == false is correct even
> though P(P) obviously "halts" (i.e. returns in this C formulation).
>

The fact that the input to H(P,P) is non-halting is complete proof that
H(P,P)===false is correct by logical necessity.

When you contradict verifiable facts you are a liar even if you are
unable to verify these facts for yourself.

--
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 4/15/22 6:34 PM, olcott wrote:
> On 4/15/2022 5:31 PM, Ben wrote:
>> "B.H." <xlt.pjw@gmail.com> writes:
>>
>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>
>>> It is a sufficient reason to say that H is non-halting, but how would
>>> H, the algorithm itself, report that?
>>
>> By returning false.  The key case PO obsesses about is H(P,P) with P
>> defined as, very roughly
>>
>>    void P(ptr x) { if (H(x, x)) while (1); }
>>
>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>
>
> The fact that the input to H(P,P) is non-halting is complete proof that
> H(P,P)===false is correct by logical necessity.

The fact that the input to H(P,P) actually Halts when the H(P,P) that it
uses says its input is non-halting proves that your logic is unsound.

>
> When you contradict verifiable facts you are a liar even if you are
> unable to verify these facts for yourself.
>
>

YOU are the one that contradict the verifiable facts.

You have only showed the input to H(P,P) is non-halting in the
uninteresting case that H(P,P) fails to answer, and so is wrong
regardless of the behavior of the input.

FAIL.

On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
> "B.H." <xlt...@gmail.com> writes:
>
> > On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>
> > It is a sufficient reason to say that H is non-halting, but how would
> > H, the algorithm itself, report that?
> By returning false. The key case PO obsesses about is H(P,P) with P
> defined as, very roughly
>
> void P(ptr x) { if (H(x, x)) while (1); }
>
> PO tells us, contrary to the facts, that H(P,P) == false is correct even
> though P(P) obviously "halts" (i.e. returns in this C formulation).
>
> --
> Ben.

Although I am not familiar with the idea of inputting functions to functions in C, and have never seen "ptr" as the syntax for pointers (I don't like pointers and haven't used them in a while, but usually I used * in school), but you would appear to have said something incorrect...it looks like P(P) would not halt because H, presumably a direct simulator of P on P until P halts on its input, would never halt, thus P would never return at all...it would never halt.

Ahh, the thrill of victory...it's like playing Pendulum Castle [1], but easier, from Super Mario once again.

-Philip White (philipjwhite@yahoo.com)

[1] For the Philip White analysis freaks (/scholars) out there: Actually, Pendulum Castle is very hard...it's in the secret world, and not to excite you too much with more fun facts about the secrets of my personal life, but I actually played it over 100 times before I beat it, years ago. The truth is, I think I only beat it once. Now that's what I call tenacity.

On Friday, April 15, 2022 at 5:59:10 PM UTC-4, olcott wrote:
> On 4/15/2022 4:49 PM, B.H. wrote:
> > On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
> >> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
> >> take the position against this tautology:
> >>
> >> They all take the position that the fact that the input to H(P,P) is
> >> non-halting is not an entirely sufficient reason for H to report that
> >> its input is non-halting.
> >>
> >>
> >>
> >>
> >>
> >>
> >> Halting problem undecidability and infinitely nested simulation (V5)
> >>
> >> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> >>
> >>
> >>
> >>
> >> --
> >> Copyright 2022 Pete Olcott
> >>
> >> "Talent hits a target no one else can hit;
> >> Genius hits a target no one else can see."
> >> Arthur Schopenhauer
> >
> >
> > It is a sufficient reason to say that H is non-halting, but how would H, the algorithm itself, report that?
> >
> > -Philip
> Reporting it is trivial simply return 0 from H.
>
> My problem is that all but one of my reviewers have turned into damn
> liars on this one key point:
>
> They say that even if the input to H(P,P) is non-halting the fact that
> this input is non-halting is not a sufficient reason to know that it is
> non-halting.
>
>
>
> void P(u32 x)
> {
> if (H(x, x)) //
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
>
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

It depends what you mean by "know." It's like P = EXPTIME...technically it's false, because no algorithm can let you be right all the time. At the same time, I believe that there are algorithms that would be correct on an extremely high percentage of inputs. I can't code that right now, and I don't have a proof...but there are techniques that I hold to be a secret that can at least solve EXPTIME complete problems efficiently, so I think that would allow for "pretty good" solutions to the halting problem to...you would just increase the size of the number of cycles to simulate for to some huge number, and eventually, satisfy yourself that the number is "probably too high" so it couldn't possibly halt.

-Philip White (philipjwhite@yahoo.com)

On 4/15/2022 6:23 PM, B.H. wrote:
> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>> "B.H." <xlt...@gmail.com> writes:
>>
>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>
>>> It is a sufficient reason to say that H is non-halting, but how would
>>> H, the algorithm itself, report that?
>> By returning false. The key case PO obsesses about is H(P,P) with P
>> defined as, very roughly
>>
>> void P(ptr x) { if (H(x, x)) while (1); }
>>
>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>
>> --
>> Ben.
>
> Although I am not familiar with the idea of inputting functions to functions in C, and have never seen "ptr" as the syntax for pointers (I don't like pointers and haven't used them in a while, but usually I used * in school), but you would appear to have said something incorrect...it looks like P(P) would not halt because H, presumably a direct simulator of P on P until P halts on its input, would never halt, thus P would never return at all...it would never halt.

You caught on very quickly. H watches its x86 emulation of P and sees
that it would never halt, aborts its simulation and returns false.

>
> Ahh, the thrill of victory...it's like playing Pendulum Castle [1], but easier, from Super Mario once again.
>
> -Philip White (philipjwhite@yahoo.com)
>
> [1] For the Philip White analysis freaks (/scholars) out there: Actually, Pendulum Castle is very hard...it's in the secret world, and not to excite you too much with more fun facts about the secrets of my personal life, but I actually played it over 100 times before I beat it, years ago. The truth is, I think I only beat it once. Now that's what I call tenacity.

--
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 Friday, April 15, 2022 at 7:26:33 PM UTC-4, B.H. wrote:
> On Friday, April 15, 2022 at 5:59:10 PM UTC-4, olcott wrote:
> > On 4/15/2022 4:49 PM, B.H. wrote:
> > > On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
> > >> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
> > >> take the position against this tautology:
> > >>
> > >> They all take the position that the fact that the input to H(P,P) is
> > >> non-halting is not an entirely sufficient reason for H to report that
> > >> its input is non-halting.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Halting problem undecidability and infinitely nested simulation (V5)
> > >>
> > >> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Copyright 2022 Pete Olcott
> > >>
> > >> "Talent hits a target no one else can hit;
> > >> Genius hits a target no one else can see."
> > >> Arthur Schopenhauer
> > >
> > >
> > > It is a sufficient reason to say that H is non-halting, but how would H, the algorithm itself, report that?
> > >
> > > -Philip
> > Reporting it is trivial simply return 0 from H.
> >
> > My problem is that all but one of my reviewers have turned into damn
> > liars on this one key point:
> >
> > They say that even if the input to H(P,P) is non-halting the fact that
> > this input is non-halting is not a sufficient reason to know that it is
> > non-halting.
> >
> >
> >
> > void P(u32 x)
> > {
> > if (H(x, x)) //
> > HERE: goto HERE;
> > }
> >
> > int main()
> > {
> > Output("Input_Halts = ", H((u32)P, (u32)P));
> > }
> >
> >
> > --
> > Copyright 2022 Pete Olcott
> >
> > "Talent hits a target no one else can hit;
> > Genius hits a target no one else can see."
> > Arthur Schopenhauer
> It depends what you mean by "know." It's like P = EXPTIME...technically it's false, because no algorithm can let you be right all the time. At the same time, I believe that there are algorithms that would be correct on an extremely high percentage of inputs. I can't code that right now, and I don't have a proof...but there are techniques that I hold to be a secret that can at least solve EXPTIME complete problems efficiently, so I think that would allow for "pretty good" solutions to the halting problem to...you would just increase the size of the number of cycles to simulate for to some huge number, and eventually, satisfy yourself that the number is "probably too high" so it couldn't possibly halt.
>
> -Philip White (philip...@yahoo.com)

Revision:

"...that I hold to be a secret that *I THINK* can at least solve EXPTIME complete problems..."

On 4/15/22 7:27 PM, olcott wrote:
> On 4/15/2022 6:23 PM, B.H. wrote:
>> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>>> "B.H." <xlt...@gmail.com> writes:
>>>
>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>
>>>> It is a sufficient reason to say that H is non-halting, but how would
>>>> H, the algorithm itself, report that?
>>> By returning false. The key case PO obsesses about is H(P,P) with P
>>> defined as, very roughly
>>>
>>> void P(ptr x) { if (H(x, x)) while (1); }
>>>
>>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>>
>>> --
>>> Ben.
>>
>> Although I am not familiar with the idea of inputting functions to
>> functions in C, and have never seen "ptr" as the syntax for pointers
>> (I don't like pointers and haven't used them in a while, but usually I
>> used * in school), but you would appear to have said something
>> incorrect...it looks like P(P) would not halt because H, presumably a
>> direct simulator of P on P until P halts on its input, would never
>> halt, thus P would never return at all...it would never halt.
>
> You caught on very quickly. H watches its x86 emulation of P and sees
> that it would never halt, aborts its simulation and returns false.

Except that is it wrong (or you have lied about setting up the
equivalent to the Halting Problem), because if H does abort that that
point, then the copy of H in P would also abort its processing, and thus
that P will Halt, so H is incorrect that a correct simulation of its
input would never halt.

>
>>
>> Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
>> but easier, from Super Mario once again.
>>
>> -Philip White (philipjwhite@yahoo.com)
>>
>> [1]  For the Philip White analysis freaks (/scholars) out there:
>> Actually, Pendulum Castle is very hard...it's in the secret world, and
>> not to excite you too much with more fun facts about the secrets of my
>> personal life, but I actually played it over 100 times before I beat
>> it, years ago.  The truth is, I think I only beat it once.  Now that's
>> what I call tenacity.
>
>

On 4/15/2022 6:28 PM, B.H. wrote:
> On Friday, April 15, 2022 at 7:26:33 PM UTC-4, B.H. wrote:
>> On Friday, April 15, 2022 at 5:59:10 PM UTC-4, olcott wrote:
>>> On 4/15/2022 4:49 PM, B.H. wrote:
>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>>> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
>>>>> take the position against this tautology:
>>>>>
>>>>> They all take the position that the fact that the input to H(P,P) is
>>>>> non-halting is not an entirely sufficient reason for H to report that
>>>>> its input is non-halting.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Copyright 2022 Pete Olcott
>>>>>
>>>>> "Talent hits a target no one else can hit;
>>>>> Genius hits a target no one else can see."
>>>>> Arthur Schopenhauer
>>>>
>>>>
>>>> It is a sufficient reason to say that H is non-halting, but how would H, the algorithm itself, report that?
>>>>
>>>> -Philip
>>> Reporting it is trivial simply return 0 from H.
>>>
>>> My problem is that all but one of my reviewers have turned into damn
>>> liars on this one key point:
>>>
>>> They say that even if the input to H(P,P) is non-halting the fact that
>>> this input is non-halting is not a sufficient reason to know that it is
>>> non-halting.
>>>
>>>
>>>
>>> void P(u32 x)
>>> {
>>> if (H(x, x)) //
>>> HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>>
>>> --
>>> Copyright 2022 Pete Olcott
>>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>> Arthur Schopenhauer
>> It depends what you mean by "know." It's like P = EXPTIME...technically it's false, because no algorithm can let you be right all the time. At the same time, I believe that there are algorithms that would be correct on an extremely high percentage of inputs. I can't code that right now, and I don't have a proof...but there are techniques that I hold to be a secret that can at least solve EXPTIME complete problems efficiently, so I think that would allow for "pretty good" solutions to the halting problem to...you would just increase the size of the number of cycles to simulate for to some huge number, and eventually, satisfy yourself that the number is "probably too high" so it couldn't possibly halt.
>>
>> -Philip White (philip...@yahoo.com)
>
> Revision:
>
> "...that I hold to be a secret that *I THINK* can at least solve EXPTIME complete problems..."
>

When it is known fact that {an X is a Y} anyone or anything disagreeing
that {an X is a Y} is necessarily correct.

André, Ben, Mike, Dennis, Richard don't seem to be able to get this.

--
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 4/15/22 7:33 PM, olcott wrote:
> On 4/15/2022 6:28 PM, B.H. wrote:
>> On Friday, April 15, 2022 at 7:26:33 PM UTC-4, B.H. wrote:
>>> On Friday, April 15, 2022 at 5:59:10 PM UTC-4, olcott wrote:
>>>> On 4/15/2022 4:49 PM, B.H. wrote:
>>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>>>> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon
>>>>>> all
>>>>>> take the position against this tautology:
>>>>>>
>>>>>> They all take the position that the fact that the input to H(P,P) is
>>>>>> non-halting is not an entirely sufficient reason for H to report that
>>>>>> its input is non-halting.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Copyright 2022 Pete Olcott
>>>>>>
>>>>>> "Talent hits a target no one else can hit;
>>>>>> Genius hits a target no one else can see."
>>>>>> Arthur Schopenhauer
>>>>>
>>>>>
>>>>> It is a sufficient reason to say that H is non-halting, but how
>>>>> would H, the algorithm itself, report that?
>>>>>
>>>>> -Philip
>>>> Reporting it is trivial simply return 0 from H.
>>>>
>>>> My problem is that all but one of my reviewers have turned into damn
>>>> liars on this one key point:
>>>>
>>>> They say that even if the input to H(P,P) is non-halting the fact that
>>>> this input is non-halting is not a sufficient reason to know that it is
>>>> non-halting.
>>>>
>>>>
>>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x)) //
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>>
>>>> --
>>>> Copyright 2022 Pete Olcott
>>>>
>>>> "Talent hits a target no one else can hit;
>>>> Genius hits a target no one else can see."
>>>> Arthur Schopenhauer
>>> It depends what you mean by "know." It's like P =
>>> EXPTIME...technically it's false, because no algorithm can let you be
>>> right all the time. At the same time, I believe that there are
>>> algorithms that would be correct on an extremely high percentage of
>>> inputs. I can't code that right now, and I don't have a proof...but
>>> there are techniques that I hold to be a secret that can at least
>>> solve EXPTIME complete problems efficiently, so I think that would
>>> allow for "pretty good" solutions to the halting problem to...you
>>> would just increase the size of the number of cycles to simulate for
>>> to some huge number, and eventually, satisfy yourself that the number
>>> is "probably too high" so it couldn't possibly halt.
>>>
>>> -Philip White (philip...@yahoo.com)
>>
>> Revision:
>>
>> "...that I hold to be a secret that *I THINK* can at least solve
>> EXPTIME complete problems..."
>>
>
> When it is known fact that {an X is a Y} anyone or anything disagreeing
> that {an X is a Y} is necessarily correct.
>
> André, Ben, Mike, Dennis, Richard don't seem to be able to get this.
>

Which is a vacuous statement since you never say WHAT you consider to be
the X and the Y.

You SEEM to be implying that the input to H must be non-halting, but
that is in fact NOT established for the case when H aborts its
simulation (and in fact it has been proved that in that case the input
is in fact HALTING). What you HAVE shown is that the input to H is
non-halting when H and the input are defined to be the non-aborting H,
but that case isn't interesting as that H never gives an answer to
H(P,P), so fails to be correct no matter what the input does.

You just seem to like to LIE about what you have shown, likely because
you really don't understand how stupid you are, and how bad you are
making yourself look.

You seem to know enough that you are missing something, as you are smart
enough not to just write it up to publish, but don't seem to understand
the review process that you seem to be embarking on, as you just
stubbornly refuse to actually learn anything by it. Self imposed
stupidity it the absolure worse kind of dumb.

FAIL.

On 4/15/2022 5:23 PM, B.H. wrote:
> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>> "B.H." <xlt...@gmail.com> writes:
>>
>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>
>>> It is a sufficient reason to say that H is non-halting, but how would
>>> H, the algorithm itself, report that?
>> By returning false. The key case PO obsesses about is H(P,P) with P
>> defined as, very roughly
>>
>> void P(ptr x) { if (H(x, x)) while (1); }
>>
>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>
>> --
>> Ben.
>
> Although I am not familiar with the idea of inputting functions to functions in C, and have never seen "ptr" as the syntax for pointers (I don't like pointers and haven't used them in a while, but usually I used * in school), but you would appear to have said something incorrect...it looks like P(P) would not halt because H, presumably a direct simulator of P on P until P halts on its input, would never halt, thus P would never return at all...it would never halt.

No, you have it wrong - maybe the CIA effected your brain. However, 1) H
is my assumption (hypothesis) a halt decider and 2) by definition a
decider is halting function/computation that returns a decision for any
arguments. In other words, it MUST halt by the very definition of
things. No waffle, no wiggle, no PO poop or bull shit. The fact that the
idiot is trying to use a simulator as a decider is an error and,
depending on how you say it or define terms, the only categorical error
in this discussion.

> Ahh, the thrill of victory...it's like playing Pendulum Castle [1], but easier, from Super Mario once again.
>
> -Philip White (philipjwhite@yahoo.com)
>
> [1] For the Philip White analysis freaks (/scholars) out there: Actually, Pendulum Castle is very hard...it's in the secret world, and not to excite you too much with more fun facts about the secrets of my personal life, but I actually played it over 100 times before I beat it, years ago. The truth is, I think I only beat it once. Now that's what I call tenacity.
--
Jeff Barnett

"B.H." <xlt.pjw@gmail.com> writes:

> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>> "B.H." <xlt...@gmail.com> writes:
>>
>> > On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>
>> > It is a sufficient reason to say that H is non-halting, but how would
>> > H, the algorithm itself, report that?
>> By returning false. The key case PO obsesses about is H(P,P) with P
>> defined as, very roughly
>>
>> void P(ptr x) { if (H(x, x)) while (1); }
>>
>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>
> Although I am not familiar with the idea of inputting functions to
> functions in C, and have never seen "ptr" as the syntax for pointers

It's a typedef name. There was another post where I included the
definition, but since PO uses an integer, the type is not agreed upon.
Hence the "very roughly".

> (I don't like pointers and haven't used them in a while, but usually I
> used * in school), but you would appear to have said something
> incorrect...it looks like P(P) would not halt because H, presumably a
> direct simulator of P on P until P halts on its input, would never
> halt, thus P would never return at all...it would never halt.

H is supposed to be a halt decider (if only for this one case) so it
must return. The one thing it can't do is act like a pure simulator.

PO does sometimes flip to claiming that the call to H in P won't return
(while saying that a top-level call will) but that's really just a case
of PO saying what's needed to get out of a bind. H must return the same
result, for the same arguments values, no matter where it is called from.

> Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
> but easier, from Super Mario once again.

What victory?

--
Ben.

On 4/15/22 9:21 PM, Ben wrote:
> "B.H." <xlt.pjw@gmail.com> writes:
>
>> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>>> "B.H." <xlt...@gmail.com> writes:
>>>
>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>
>>>> It is a sufficient reason to say that H is non-halting, but how would
>>>> H, the algorithm itself, report that?
>>> By returning false. The key case PO obsesses about is H(P,P) with P
>>> defined as, very roughly
>>>
>>> void P(ptr x) { if (H(x, x)) while (1); }
>>>
>>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>
>> Although I am not familiar with the idea of inputting functions to
>> functions in C, and have never seen "ptr" as the syntax for pointers
>
> It's a typedef name. There was another post where I included the
> definition, but since PO uses an integer, the type is not agreed upon.
> Hence the "very roughly".
>
>> (I don't like pointers and haven't used them in a while, but usually I
>> used * in school), but you would appear to have said something
>> incorrect...it looks like P(P) would not halt because H, presumably a
>> direct simulator of P on P until P halts on its input, would never
>> halt, thus P would never return at all...it would never halt.
>
> H is supposed to be a halt decider (if only for this one case) so it
> must return. The one thing it can't do is act like a pure simulator.
>
> PO does sometimes flip to claiming that the call to H in P won't return
> (while saying that a top-level call will) but that's really just a case
> of PO saying what's needed to get out of a bind. H must return the same
> result, for the same arguments values, no matter where it is called from.

He does sometimes try to argue that point, and claim that the behavior
of a computation might depend on the 'context' it is called in.

I wondwer a bit if his switch back to x86 vs Turing Machines was that he
was boxed in to need to explain how that happens in a Turing Machine.

At least in x86 code, it is possible to write an H that isn't actually a
computation, and thus the code for H could possibly behave differently
in different contexts, just proving it isn't actaully a computation and
thus there isn't actually a Turing Machine 'equivalent' to it.

>
>> Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
>> but easier, from Super Mario once again.
>
> What victory?
>

On 4/15/2022 8:21 PM, Ben wrote:
> "B.H." <xlt.pjw@gmail.com> writes:
>
>> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>>> "B.H." <xlt...@gmail.com> writes:
>>>
>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>
>>>> It is a sufficient reason to say that H is non-halting, but how would
>>>> H, the algorithm itself, report that?
>>> By returning false. The key case PO obsesses about is H(P,P) with P
>>> defined as, very roughly
>>>
>>> void P(ptr x) { if (H(x, x)) while (1); }
>>>
>>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>
>> Although I am not familiar with the idea of inputting functions to
>> functions in C, and have never seen "ptr" as the syntax for pointers
>
> It's a typedef name. There was another post where I included the
> definition, but since PO uses an integer, the type is not agreed upon.
> Hence the "very roughly".
>

I did like your update to this and thought it was an improvement it
makes the code cleaner.

>> (I don't like pointers and haven't used them in a while, but usually I
>> used * in school), but you would appear to have said something
>> incorrect...it looks like P(P) would not halt because H, presumably a
>> direct simulator of P on P until P halts on its input, would never
>> halt, thus P would never return at all...it would never halt.
>
> H is supposed to be a halt decider (if only for this one case) so it
> must return. The one thing it can't do is act like a pure simulator.
>

USENET comp.theory: On 4/11/2022 3:19 PM, Malcolm McLean wrote:
> PO's idea is to have a simulator with an infinite cycle detector.
> You would achieve this by modifying a UTM, so describing it as
> a "modified UTM", or "acts like a UTM until it detects an infinite
> cycle", is reasonable. And such a machine is a fairly powerful
> halt decider. Even if the infinite cycle detector isn't very
> sophisticated, it will still catch a large subset of non-halting
> machines.

> PO does sometimes flip to claiming that the call to H in P won't return
> (while saying that a top-level call will) but that's really just a case
> of PO saying what's needed to get out of a bind. H must return the same
> result, for the same arguments values, no matter where it is called from.
>

But this is flat out not true.
If the first call of infinite recursion is aborted then the whole thing
stops. If the second call of infinite recursion is aborted then the
first call returns.

P(P) does specify infinite recursion that is terminated on its second
call in the simulated input to H(P,P).

>> Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
>> but easier, from Super Mario once again.
>
> What victory?
>

--
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 4/15/22 9:31 PM, olcott wrote:
> On 4/15/2022 8:21 PM, Ben wrote:
>> "B.H." <xlt.pjw@gmail.com> writes:
>>
>>> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>>>> "B.H." <xlt...@gmail.com> writes:
>>>>
>>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>>
>>>>> It is a sufficient reason to say that H is non-halting, but how would
>>>>> H, the algorithm itself, report that?
>>>> By returning false. The key case PO obsesses about is H(P,P) with P
>>>> defined as, very roughly
>>>>
>>>> void P(ptr x) { if (H(x, x)) while (1); }
>>>>
>>>> PO tells us, contrary to the facts, that H(P,P) == false is correct
>>>> even
>>>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>>
>>> Although I am not familiar with the idea of inputting functions to
>>> functions in C, and have never seen "ptr" as the syntax for pointers
>>
>> It's a typedef name.  There was another post where I included the
>> definition, but since PO uses an integer, the type is not agreed upon.
>> Hence the "very roughly".
>>
>
> I did like your update to this and thought it was an improvement it
> makes the code cleaner.
>
>>> (I don't like pointers and haven't used them in a while, but usually I
>>> used * in school), but you would appear to have said something
>>> incorrect...it looks like P(P) would not halt because H, presumably a
>>> direct simulator of P on P until P halts on its input, would never
>>> halt, thus P would never return at all...it would never halt.
>>
>> H is supposed to be a halt decider (if only for this one case) so it
>> must return.  The one thing it can't do is act like a pure simulator.
>>
>
> USENET comp.theory: On 4/11/2022 3:19 PM, Malcolm McLean wrote:
> > PO's idea is to have a simulator with an infinite cycle detector.
> > You would achieve this by modifying a UTM, so describing it as
> > a "modified UTM", or "acts like a UTM until it detects an infinite
> > cycle", is reasonable. And such a machine is a fairly powerful
> > halt decider. Even if the infinite cycle detector isn't very
> > sophisticated, it will still catch a large subset of non-halting
> > machines.
>
>> PO does sometimes flip to claiming that the call to H in P won't return
>> (while saying that a top-level call will) but that's really just a case
>> of PO saying what's needed to get out of a bind.  H must return the same
>> result, for the same arguments values, no matter where it is called from.
>>
>
> But this is flat out not true.
> If the first call of infinite recursion is aborted then the whole thing
> stops. If the second call of infinite recursion is aborted then the
> first call returns.

The problem with this is that if a simulation aborts, then that
simulation doesn't show if the machine it is simulating will halt or
not. To do that, you need to put that input into a REAL simulator that
doesn't abort.

Since one H(P,P) aborts its simulation, then ALL copies, if allowed to
run to completion, will do the same, then ALL copies of P(P) will Halt,
thus ALL copies of H were proved wrong to abort, because their input was
non-halting.

>
> P(P) does specify infinite recursion that is terminated on its second
> call in the simulated input to H(P,P).

Then it doesn't specify infinite recursion. If the H within P will abort
its simulation at the second call in its simulation of the input, then
the P that called it will halt, showing that P (P) does NOT specify
infinite recursion.

>
>>> Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
>>> but easier, from Super Mario once again.
>>
>> What victory?
>>
>
>

On 4/15/2022 4:16 PM, olcott wrote:
> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
> take the position against this tautology:
>
> They all take the position that the fact that the input to H(P,P) is
> non-halting is not an entirely sufficient reason for H to report that
> its input is non-halting.
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Richard is clueless about these things. He either is not smart enough to
ever understand the key facts or he is dishonest. I no longer care which.

The key fact that André, Mike, and Dennis can understand is that the
simulated input to H(P,P) would never reach its own final state.

This may simply be over Richard and Ben's heads.

--
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 Friday, April 15, 2022 at 9:21:53 PM UTC-4, Ben wrote:
> "B.H." <xlt...@gmail.com> writes:
>
> > On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
> >> "B.H." <xlt...@gmail.com> writes:
> >>
> >> > On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
> >>
> >> > It is a sufficient reason to say that H is non-halting, but how would
> >> > H, the algorithm itself, report that?
> >> By returning false. The key case PO obsesses about is H(P,P) with P
> >> defined as, very roughly
> >>
> >> void P(ptr x) { if (H(x, x)) while (1); }
> >>
> >> PO tells us, contrary to the facts, that H(P,P) == false is correct even
> >> though P(P) obviously "halts" (i.e. returns in this C formulation).
> >
> > Although I am not familiar with the idea of inputting functions to
> > functions in C, and have never seen "ptr" as the syntax for pointers
> It's a typedef name. There was another post where I included the
> definition, but since PO uses an integer, the type is not agreed upon.
> Hence the "very roughly".
> > (I don't like pointers and haven't used them in a while, but usually I
> > used * in school), but you would appear to have said something
> > incorrect...it looks like P(P) would not halt because H, presumably a
> > direct simulator of P on P until P halts on its input, would never
> > halt, thus P would never return at all...it would never halt.
> H is supposed to be a halt decider (if only for this one case) so it
> must return. The one thing it can't do is act like a pure simulator.
>
> PO does sometimes flip to claiming that the call to H in P won't return
> (while saying that a top-level call will) but that's really just a case
> of PO saying what's needed to get out of a bind. H must return the same
> result, for the same arguments values, no matter where it is called from.
> > Ahh, the thrill of victory...it's like playing Pendulum Castle [1],
> > but easier, from Super Mario once again.
> What victory?
>

The victory of accuracy. I won, the concession is implicit; it's a proof by inspection. You might want to concede to avoid getting pegged as "an Obama-oid."

-Philip

> --
> Ben.

On Friday, April 15, 2022 at 8:15:03 PM UTC-4, Jeff Barnett wrote:
> On 4/15/2022 5:23 PM, B.H. wrote:
> > On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
> >> "B.H." <xlt...@gmail.com> writes:
> >>
> >>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
> >>
> >>> It is a sufficient reason to say that H is non-halting, but how would
> >>> H, the algorithm itself, report that?
> >> By returning false. The key case PO obsesses about is H(P,P) with P
> >> defined as, very roughly
> >>
> >> void P(ptr x) { if (H(x, x)) while (1); }
> >>
> >> PO tells us, contrary to the facts, that H(P,P) == false is correct even
> >> though P(P) obviously "halts" (i.e. returns in this C formulation).
> >>
> >> --
> >> Ben.
> >
> > Although I am not familiar with the idea of inputting functions to functions in C, and have never seen "ptr" as the syntax for pointers (I don't like pointers and haven't used them in a while, but usually I used * in school), but you would appear to have said something incorrect...it looks like P(P) would not halt because H, presumably a direct simulator of P on P until P halts on its input, would never halt, thus P would never return at all....it would never halt.
> No, you have it wrong - maybe the CIA effected your brain. However, 1) H
> is my assumption (hypothesis) a halt decider and 2) by definition a
> decider is halting function/computation that returns a decision for any
> arguments. In other words, it MUST halt by the very definition of
> things. No waffle, no wiggle, no PO poop or bull shit. The fact that the
> idiot is trying to use a simulator as a decider is an error and,
> depending on how you say it or define terms, the only categorical error
> in this discussion.

You are acting like an angry jerk who is angry for no reason who knows nothing about CS but would like to claim that you know something.

I won't get too involved in an insult battle here--you post less obnoxious stuff than "wij"--but your comments make it sound like you don't know what you're talking about and want to insult me. You'll be thrilled to note I'm less sensitive about insult and "betrayals," not that you were on my side last time I checked the boolean friendliness flags.

Since you talk to Peter Olcott a lot and he said he is dying, why not be nicer to him? I've said that before, haven't I? If you want something in life beyond entertainment on the internet, which you probably do, you could probably say things that sound witty/funny enough without trying to trample others emotionally. In particular, you are more likely to "look like a decent respectable person worth knowing" if you joke around without insulting someone who has claimed to be near death. An at-least partly sincere friendly "goodbye message" would be a nice touch if you want to look better in your community. You might say your brand is "irreverent jerk who likes math," but that is game-theoretically dominated by "irreverent humorous person who shows a little respect for people in trouble and doesn't damage other people emotionally or otherwise and likes math." Not all brands, personal, professional, or corporate, are created equal.

I mostly forgot my previous conversations with you, so at least they aren't bothering/haunting me these days. You don't always know what strangers on the internet are dealing with in their personal lives, so it's "better safe than sorry" as a general rule about starting fights with people and agitating them.

-Philip White

> > Ahh, the thrill of victory...it's like playing Pendulum Castle [1], but easier, from Super Mario once again.
> >
> > -Philip White (philip...@yahoo.com)
> >
> > [1] For the Philip White analysis freaks (/scholars) out there: Actually, Pendulum Castle is very hard...it's in the secret world, and not to excite you too much with more fun facts about the secrets of my personal life, but I actually played it over 100 times before I beat it, years ago. The truth is, I think I only beat it once. Now that's what I call tenacity.
> --
> Jeff Barnett

On 4/15/2022 9:14 PM, B.H. wrote:
> On Friday, April 15, 2022 at 8:15:03 PM UTC-4, Jeff Barnett wrote:
>> On 4/15/2022 5:23 PM, B.H. wrote:
>>> On Friday, April 15, 2022 at 6:31:21 PM UTC-4, Ben wrote:
>>>> "B.H." <xlt...@gmail.com> writes:
>>>>
>>>>> On Friday, April 15, 2022 at 5:17:08 PM UTC-4, olcott wrote:
>>>>
>>>>> It is a sufficient reason to say that H is non-halting, but how would
>>>>> H, the algorithm itself, report that?
>>>> By returning false. The key case PO obsesses about is H(P,P) with P
>>>> defined as, very roughly
>>>>
>>>> void P(ptr x) { if (H(x, x)) while (1); }
>>>>
>>>> PO tells us, contrary to the facts, that H(P,P) == false is correct even
>>>> though P(P) obviously "halts" (i.e. returns in this C formulation).
>>>>
>>>> --
>>>> Ben.
>>>
>>> Although I am not familiar with the idea of inputting functions to functions in C, and have never seen "ptr" as the syntax for pointers (I don't like pointers and haven't used them in a while, but usually I used * in school), but you would appear to have said something incorrect...it looks like P(P) would not halt because H, presumably a direct simulator of P on P until P halts on its input, would never halt, thus P would never return at all...it would never halt.
>> No, you have it wrong - maybe the CIA effected your brain. However, 1) H
>> is my assumption (hypothesis) a halt decider and 2) by definition a
>> decider is halting function/computation that returns a decision for any
>> arguments. In other words, it MUST halt by the very definition of
>> things. No waffle, no wiggle, no PO poop or bull shit. The fact that the
>> idiot is trying to use a simulator as a decider is an error and,
>> depending on how you say it or define terms, the only categorical error
>> in this discussion.
>
> You are acting like an angry jerk

You got Jeff's number, yes angry jerk.

> who is angry for no reason who knows nothing about CS but would like to claim that you know something.
>
> I won't get too involved in an insult battle here--you post less obnoxious stuff than "wij"--but your comments make it sound like you don't know what you're talking about and want to insult me. You'll be thrilled to note I'm less sensitive about insult and "betrayals," not that you were on my side last time I checked the boolean friendliness flags.
>
> Since you talk to Peter Olcott a lot and he said he is dying, why not be nicer to him? I've said that before, haven't I? If you want something in life beyond entertainment on the internet, which you probably do, you could probably say things that sound witty/funny enough without trying to trample others emotionally. In particular, you are more likely to "look like a decent respectable person worth knowing" if you joke around without insulting someone who has claimed to be near death. An at-least partly sincere friendly "goodbye message" would be a nice touch if you want to look better in your community. You might say your brand is "irreverent jerk who likes math," but that is game-theoretically dominated by "irreverent humorous person who shows a little respect for people in trouble and doesn't damage other people emotionally or otherwise and likes math." Not all brands, personal, professional, or corporate, are created equal.
>
> I mostly forgot my previous conversations with you, so at least they aren't bothering/haunting me these days. You don't always know what strangers on the internet are dealing with in their personal lives, so it's "better safe than sorry" as a general rule about starting fights with people and agitating them.
>
> -Philip White
>
>
>>> Ahh, the thrill of victory...it's like playing Pendulum Castle [1], but easier, from Super Mario once again.
>>>
>>> -Philip White (philip...@yahoo.com)
>>>
>>> [1] For the Philip White analysis freaks (/scholars) out there: Actually, Pendulum Castle is very hard...it's in the secret world, and not to excite you too much with more fun facts about the secrets of my personal life, but I actually played it over 100 times before I beat it, years ago. The truth is, I think I only beat it once. Now that's what I call tenacity.
>> --
>> Jeff Barnett

--
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 4/15/22 9:49 PM, olcott wrote:
> On 4/15/2022 4:16 PM, olcott wrote:
>> André Isaak, Ben Bacarisse, Mike Terry, Dennis Bush, Richard Damon all
>> take the position against this tautology:
>>
>> They all take the position that the fact that the input to H(P,P) is
>> non-halting is not an entirely sufficient reason for H to report that
>> its input is non-halting.
>>
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
> Richard is clueless about these things. He either is not smart enough to
> ever understand the key facts or he is dishonest. I no longer care which.

No, YOU are cluesless because you just don't care about the right
answer, you just want to try to justify your own wrong answer.

>
> The key fact that André, Mike, and Dennis can understand is that the
> simulated input to H(P,P) would never reach its own final state.

No, you only 'prove' that the input is non-halting based on the
assumption that H will never abort its simulation.

Since H does, your conclusion is based on a false premise and thus is
unsound.

What you also prove that H's simuation (which isn't a 'correct'
simulation if it aborts to answer) will never reach a final state, so by
your criteria, H can never actually prove the input to be halting, so it
will never answer Qy for this input.

>
> This may simply be over Richard and Ben's heads.
>

Nope. you just are lying through your teeth and maybe confusing a few
people.

When you come to the final test, you will be found to be a cheater and a
liar and suffer the consequences.

You also seem to have switched back to the x86 version, my guess is so
that you can start back up your false claim that different copies of H
can give different answers, which only proves that they are not the
equivavlent of a Turing Machine, and thus you are lying about that part
of the problem.