How do we know that the input to H(P,P) really never halts?

[olcott]

When we examine pages 4 and 5 and hypothesize
that H is merely a pure simulator we can see
that when P calls H at its machine address 0xc41
that this **is** infinitely nested simulation
such that P never reaches its final state.

The only other possibility is that H is a halt
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation


--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

[wij]

P exists only after the existence of H. No H, no P.
Your H is specific for some 'P' already existent before H.
Your understanding and implement are not what you think.

GUR dictates that:
...
No function f can decide the property of another function g that g can defy.
GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
...

[Richard Damon]

On 10/30/21 10:44 PM, olcott wrote:
> When we examine pages 4 and 5 and hypothesize
> that H is merely a pure simulator we can see
> that when P calls H at its machine address 0xc41
> that this **is** infinitely nested simulation
> such that P never reaches its final state.
>
> The only other possibility is that H is a halt
> decider that aborts its simulation of P at the
> machine address 0xc41 of P. In this case P also
> never reaches is final state at machine address
> 0xc50. Thus in every possibility P never reaches
> its final state and thus never halts.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

Yes, if H IS a 'pure simulator', then H^/P will be non-halting. But H
doesn't get this case right, as H never answers.

This fact ONLY applies if H is actually a Pure Simulator, and in no
other case.

In your second case, yes, the partial simulation by H of P does not
reach a halting state, but that does NOT show that P is non-halting, to
claim it does is a logical failicy.

We do see that if H aborts its simulation of a copy of P and returns
non-halting, then another copy of P that uses a copy of this H will get
that non-halting answer and then Halt, showing us that P(P) is actually
a Halting Computation.

You mistaken claim that a partial simulation shows non-halting or that
you can use different Hs when running P by itself vs what the halt
decider is.

Note, your claim that you can replace the simulation of a machine with
the direct execution of that machine ONLY applies if the simulation is
truely 'pure' or never aborted, so using that model implies that H can
only be that real pure simulator that we have shown never answers H(P,P)
and thus fails to meet the basic requirements of a halt decider.

The transform does NOT apply to a 'pure simulator until...' machine.

[olcott]

I show all of the details of how we can know that when H(P,P) does not
abort its simulation of its input then its input never reaches its final
state. We can also see that its input never reaches its final state even
if H(P,P) aborts its input therefore we can know that under all possible
conditions the input to H(P,P) does not halt.

You have to exactly look at pages 4 and 5 to see this:

[olcott]

On 10/31/2021 6:00 AM, Richard Damon wrote:
>
> On 10/30/21 10:44 PM, olcott wrote:
>> When we examine pages 4 and 5 and hypothesize
>> that H is merely a pure simulator we can see
>> that when P calls H at its machine address 0xc41
>> that this **is** infinitely nested simulation
>> such that P never reaches its final state.
>>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>
> Yes, if H IS a 'pure simulator', then H^/P will be non-halting. But H
> doesn't get this case right, as H never answers.
>
> This fact ONLY applies if H is actually a Pure Simulator, and in no
> other case.
>

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}

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

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36 // push P
[00000c5e](05) 68360c0000 push 00000c36 // push P
[00000c63](05) e8fefcffff call 00000966 // call H(P,P)
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The input to H(P,P) never reaches its final state at its machine address
0xc50 whether or not H(P,P) aborts the simulation of this input
therefore we can definitely conclude that the input to H(P,P) never halts.

> In your second case, yes, the partial simulation by H of P does not
> reach a halting state, but that does NOT show that P is non-halting, to
> claim it does is a logical failicy.
>

If we examine every possible case and find that the input to H(P,P)
never reaches its final state in any of them then it is necessarily true
that the input to H(P,P) never halts.

> We do see that if H aborts its simulation of a copy of P and returns
> non-halting, then another copy of P that uses a copy of this H will get
> that non-halting answer and then Halt,

Not in the above case.

[00000c68][0010172a][00000000] 83c408 add esp,+08
[00000c6b][00101726][00000000] 50 push eax
[00000c6c][00101722][00000357] 6857030000 push 00000357
[00000c71][00101722][00000357] e810f7ffff call 00000386
Input_Halts = 0
[00000c76][0010172a][00000000] 83c408 add esp,+08
[00000c79][0010172a][00000000] 33c0 xor eax,eax
[00000c7b][0010172e][00100000] 5d pop ebp
[00000c7c][00101732][00000068] c3 ret
Number_of_User_Instructions(27)

H(P,P) is simulating its input. P invokes another instance of H to
simulate itself. When this second P is about to invoke another instance
of H, the outermost H aborts its outermost P thus terminating the entire
simulation hierarchy.

So the question comes down to this:
(a) If H(P,P) never aborts the simulation of its input then its input

never reaches its final state.

(b) If H(P,P) aborts the simulation of its input then its input never
reaches its final state.

If H aborts the simulation of its input then the whole simulation
hierarchy has been aborted because the whole simulation hierarchy
depends on the execution of the outermost P.

> showing us that P(P) is actually
> a Halting Computation.
>
> You mistaken claim that a partial simulation shows non-halting or that
> you can use different Hs when running P by itself vs what the halt
> decider is.
>

I have shown that the input to H(P,P) never reaches its final state in
every possible case therefore it is necessarily correct that the input
to H(P,P) never halts.

> Note, your claim that you can replace the simulation of a machine with
> the direct execution of that machine ONLY applies if the simulation is
> truely 'pure' or never aborted, so using that model implies that H can
> only be that real pure simulator that we have shown never answers H(P,P)
> and thus fails to meet the basic requirements of a halt decider.
>
> The transform does NOT apply to a 'pure simulator until...' machine.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> The only other possibility is that H is a halt
> decider that aborts its simulation of P at the
> machine address 0xc41 of P. In this case P also
> never reaches is final state at machine address
> 0xc50. Thus in every possibility P never reaches
> its final state and thus never halts.

So having lost the argument in relation to Turing machines, you have
returned to your hidden code that gets the wrong answer? Or do you now
accept that H(P,P) == false is wrong if P(P) halts? To get any traction
you really do have to admit that defining the wrong answer to be the
right one simply did not cut it!

By playing tricks (which will remain as hidden as your code) you can
arrange for H(P,P) == true when P(P) halts which would be a welcome
change of heart.

--
Ben.

[wij]

On page 4:
The word 'partial' in the title "Simulating partial halt decider H correctly decides that P(P) never halts (V1)" bugged me.

On page 5:
1. Your H does not actually take any 'given input'.
2. What language (or model) C, x86 assembly, or TM are you using?
None of these three languages are easy to take 'machine description' as input.
You chose a hard(impossible, by GUR) way to tackle the problem.

If I understand correctly, you seem to emphasize the fact that H can correctly
decide whether its P will halt or not. I have no doubt of your case.
But, for the conventional HP, P does not exist before H is created. Hard coding
P into H is simply wrong. It is not a decider of any given real program.

[olcott]

On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>
> So having lost the argument in relation to Turing machines, you have
> returned to your hidden code that gets the wrong answer?

(1) I haven't lost the argument on Turing Machines.

(2) I conclusively prove that the input to H(P,P) never halts in
Message-ID: <hIednR1p-IK1NuP8...@giganews.com>
Giganews posted this message to other groups and skipped itself.

> Or do you now
> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
> you really do have to admit that defining the wrong answer to be the
> right one simply did not cut it!
>
> By playing tricks (which will remain as hidden as your code) you can
> arrange for H(P,P) == true when P(P) halts which would be a welcome
> change of heart.
>

The above is from pages 4 and 5 of this paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

There are no tricks. There are only two possible cases:
(1) H(P,P) aborts its simulation and P never reaches its final state at
0xc50

(2) H(P,P) does not abort its simulation and P never reaches its final
state at 0xc50

Therefore when H(P,P) decides that its input never halts H is
necessarily correct.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> I show all of the details of how we can know that when H(P,P) does not
> abort its simulation of its input then its input never reaches its
> final state.

That's a teeny, tiny fib, isn't it, because you don't show /all/ the
details. The most important details -- in the code for H -- are going
to remain hidden forever.

--
Ben.

[olcott]

The "partial" halt decider takes every COFF object file that has
been generated by the Microsoft C compiler. There are a limited
number of non-halting behavior patterns that H can recognize.

As soon as it recognizes one of these patterns in its simulated input
it aborts the simulation of this input and reports non-halting. H
merely waits for its input to halt in all other cases. Some of these
cases are inputs that never halt where it does not recognize the
non-halting behavior pattern.

> On page 5:
> 1. Your H does not actually take any 'given input'.
> 2. What language (or model) C, x86 assembly, or TM are you using?
> None of these three languages are easy to take 'machine description' as input.
> You chose a hard(impossible, by GUR) way to tackle the problem.
>
> If I understand correctly, you seem to emphasize the fact that H can correctly
> decide whether its P will halt or not. I have no doubt of your case.
> But, for the conventional HP, P does not exist before H is created. Hard coding
> P into H is simply wrong. It is not a decider of any given real program.
>

H correctly decides the halt status of:
(a) Simple Infinitely nested simulation
(b) Simple Infinite recursion
(c) Simple Infinite loops

H(P,P) can see that its input never reaches its final state whether or
not H aborts the simulation of this input (thus all possible cases)
therefore H is necessarily correct when it aborts the simulation of this
input and reports non-halting.

[olcott]

If H is a pure simulator of its input then the function call to H at the
machine address 0xc41 of P specifies infinitely nested simulation
preventing P from ever reaching its final state of machine address 0xc50.

If H aborts its simulation of P at the machine address of P of 0xc41
then P never reaches its final state of machine address 0xc50.

Therefore in all possible cases:
(a) H(P,P) aborts its simulation of its input
(b) H(P,P) does not abort its simulation of its input
P never reaches its final state at machine address 0xc50.

Details shown below:

[Mike Terry]

On 31/10/2021 15:51, olcott wrote:
> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>>
>> So having lost the argument in relation to Turing machines, you have
>> returned to your hidden code that gets the wrong answer?
>
> (1) I haven't lost the argument on Turing Machines.
>
> (2) I conclusively prove that the input to H(P,P) never halts in
> Message-ID: <hIednR1p-IK1NuP8...@giganews.com>
> Giganews posted this message to other groups and skipped itself.
>

Ignoring the blatent false claim that you have proved anything, you have
fallen foul of the Giganews "delayed publishing" feature/bug. (That's
my name for it.)

This isn't a rare event, I'd say anything from 5%-40% of articles hit
this problem. What happens is that Giganews receives an article and
assigns article numbers for it, in its normal sequence for the groups.
Then Giganews decides "hey, I'm not going to "publish" that article for
a few hours!" So the article id is skipped in NNTP responses that list
article ids and doesn't appear in news readers. Most often I notice
this when I see responses to articles that haven't appeared.

A few hours later, Giganews decides "hey, I think I've pissed off my
paying customers enough now, so I'll finally "publish" that old article
I received". At this point it starts listing the article id in group
listings so that news reader clients pick it up. (Except that by now
many clients may have just decided the article id is simply invalid, and
may never retrieve it, and even if they do retrieve it, there may well
have been "mysterious" responses to it retrieved out of order.)

I've not seen any of the free news servers behaving like this, so what
does that say about Giganews?

Anyway I predict your post will mysteriously appear in a few hours time.
We'll see. (On my Giganews server your article appears to have been
allocated id 107792 but hasn't been "published" as such yet. Grr.)

Mike.

[olcott]

On 10/31/2021 11:48 AM, Mike Terry wrote:
> On 31/10/2021 15:51, olcott wrote:
>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>
>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8...@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>>
>
> Ignoring the blatent false claim that you have proved anything,

That you simply ignore my proof does not actually count as any rebuttal
at all. Because of my poor communication skills I can see immediately
when I have proved my claim, yet it takes many many iterations of review
until I can finally find clear enough words so that others can also see
that I proved my claim.

I have just now proved that the input to H(P,P) never halts using clear
enough words that are backed up my code. I am not going to repeat that
proof here.

you have
> fallen foul of the Giganews "delayed publishing" feature/bug.  (That's
> my name for it.)
>
> This isn't a rare event, I'd say anything from 5%-40% of articles hit
> this problem.  What happens is that Giganews receives an article and
> assigns article numbers for it, in its normal sequence for the groups.
> Then Giganews decides "hey, I'm not going to "publish" that article for
> a few hours!"  So the article id is skipped in NNTP responses that list
> article ids and doesn't appear in news readers.  Most often I notice
> this when I see responses to articles that haven't appeared.
>
> A few hours later, Giganews decides "hey, I think I've pissed off my
> paying customers enough now, so I'll finally "publish" that old article
> I received".  At this point it starts listing the article id in group
> listings so that news reader clients pick it up.  (Except that by now
> many clients may have just decided the article id is simply invalid, and
> may never retrieve it, and even if they do retrieve it, there may well
> have been "mysterious" responses to it retrieved out of order.)
>
> I've not seen any of the free news servers behaving like this, so what
> does that say about Giganews?
>
> Anyway I predict your post will mysteriously appear in a few hours time.
>  We'll see.  (On my Giganews server your article appears to have been
> allocated id 107792 but hasn't been "published" as such yet. Grr.)
>
> Mike.

The weird (and good) aspect of this is that they show up right away in
other groups when posted to Giganews. I contacted them about this issue.

[Richard Damon]

Irrelevant.

If H does abort its simulation and return the non-halting answer then
this partial simulation is NOT proof of non-halting, and if we give this
exact same input to a real UTM we we see that the UTM's simulation does
reach a halting state.

If H doesn't abort its simulation, then H never returns an answer to the
question of H(P,P) so this H also fails to be the proper decider.

Since the defintion of the computaiton P depend on the definiton of H,
you can't mix these two cases and have sound logic.

The proper answer is NOT what the simulation in H does, but what a
simulation by a REAL UTM does. You have even said that a few times.

>
>> In your second case, yes, the partial simulation by H of P does not
>> reach a halting state, but that does NOT show that P is non-halting,
>> to claim it does is a logical failicy.
>>
>
> If we examine every possible case and find that the input to H(P,P)
> never reaches its final state in any of them then it is necessarily true
> that the input to H(P,P) never halts.

Nope. UNSOUND LOGIC.

The simulation by H is NOT the definition of the right answer, but the
simulation of that exact same input by a REAL UTM, i.e. an Unconditional
Simulator.

All that you have proved is that no H of your form can ever prove that H
is Halting, not that H is not Halting.

>
>> We do see that if H aborts its simulation of a copy of P and returns
>> non-halting, then another copy of P that uses a copy of this H will
>> get that non-halting answer and then Halt,
>
> Not in the above case.
>
> [00000c68][0010172a][00000000] 83c408      add esp,+08
> [00000c6b][00101726][00000000] 50          push eax
> [00000c6c][00101722][00000357] 6857030000  push 00000357
> [00000c71][00101722][00000357] e810f7ffff  call 00000386
> Input_Halts = 0
> [00000c76][0010172a][00000000] 83c408      add esp,+08
> [00000c79][0010172a][00000000] 33c0        xor eax,eax
> [00000c7b][0010172e][00100000] 5d          pop ebp
> [00000c7c][00101732][00000068] c3          ret
> Number_of_User_Instructions(27)
>
> H(P,P) is simulating its input. P invokes another instance of H to
> simulate itself. When this second P is about to invoke another instance
> of H, the outermost H aborts its outermost P thus terminating the entire
> simulation hierarchy.
>
> So the question comes down to this:
> (a) If H(P,P) never aborts the simulation of its input then its input
> never reaches its final state.

Bad Logic, if H is defined to actually abort the simulation at this
point, asking about what happens if it did something different is
irrelevent.

> (b) If H(P,P) aborts the simulation of its input then its input never
> reaches its final state.

And there is nothing wrong with an aborted simulation never getting to a
fianl halting state. That does NOT show that an unaborted simulation by
a real UTM of this exact same input would not halt.

Your (a) case is NOT that, because you change the global defintion of H
which changed the machine being decided.

All you have shown is that Ha, the H that aborts its simulation, can
correctly decide that Pn(Pn) based on the Hn that doesn't abort its
simulation doesn't halt

THis says NOTHING about the Pa that it needs to get right to counter Linz.

>
> If H aborts the simulation of its input then the whole simulation
> hierarchy has been aborted because the whole simulation hierarchy
> depends on the execution of the outermost P.

An H that abort can only abort the simulations that it is doing, is can
NOT abort any machine that it is part of. To do that means it fails to
be a computation that answers the question it was given.

Thus, the P (P) that calls H(P,P) can be correctly proved to Halt if we
can show that H(P,P) returns non-halting, and because of that, we can
show that H geve the WRONG answer.

>
>> showing us that P(P) is actually a Halting Computation.
>>
>> You mistaken claim that a partial simulation shows non-halting or that
>> you can use different Hs when running P by itself vs what the halt
>> decider is.
>>
>
> I have shown that the input to H(P,P) never reaches its final state in
> every possible case therefore it is necessarily correct that the input
> to H(P,P) never halts.
>

Nope. All you have shown is that No H can every prove Halting, by seeing
its simulation reach a halting state.

The fact that a PARTIAL simulation didn't reach a halting state does NOT
prove non-halting, especially when we can show with simple logic that a
UTM simulating that exact same input WILL reach that halting state when
it simulates that exact same input.

We can show that no matter how many iterations deep H simulates, because
of the way that P depends on H, that the simulation by the UTM of P goes
1 more layer deep, and then halts.

Thus, all you have shown is that there does not exsit an X such that
X > X+1

[Richard Damon]

On 10/31/21 11:51 AM, olcott wrote:
> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>>
>> So having lost the argument in relation to Turing machines, you have
>> returned to your hidden code that gets the wrong answer?
>
> (1) I haven't lost the argument on Turing Machines.

Only because you haven't actually made a real arguemnt on Turing Machines.

>
> (2) I conclusively prove that the input to H(P,P) never halts in
> Message-ID: <hIednR1p-IK1NuP8...@giganews.com>
> Giganews posted this message to other groups and skipped itself.

Except that is a meaningless statement.

'Inputs' don't halt. Machines Halt.

When the input <H^><H^> is given to a UTM, that computation Halts, which
is one of the ways to look at the definition of the Halting Problem.

Yes, H's aborted simulation of <H^><H^> never reached a final halting
state, but aborted simulation NEVER, in themselves, prove non-halting
(or Halting). So you are arguing about meaningless behavior trying to
claim that it actually means something by using bad terminology.

You are just arguing POOP.

The fact that H doesn't reach the halting state is irrelevent to the
halting problem.

The fact that if Main calls P(P) it will halt shows that H is wrong. PERIOD.

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>> So having lost the argument in relation to Turing machines, you have
>> returned to your hidden code that gets the wrong answer?
>
> (1) I haven't lost the argument on Turing Machines.
>
> (2) I conclusively prove that the input to H(P,P) never halts in
> Message-ID: <hIednR1p-IK1NuP8...@giganews.com>
> Giganews posted this message to other groups and skipped itself.

The input to H represents the computation P(P). At least up until
recently you asserted that P(P) halts and you spent a lot of time trying
to hand-wave away the wrong answer from H.

>> Or do you now
>> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
>> you really do have to admit that defining the wrong answer to be the
>> right one simply did not cut it!
>> By playing tricks (which will remain as hidden as your code) you can
>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>> change of heart.

> There are no tricks.

Good. That means you can't have H(P,P) == true iff P(P) halts.

> There are only two possible cases:
> (1) H(P,P) aborts its simulation and P never reaches its final state
> at 0xc50
>
> (2) H(P,P) does not abort its simulation and P never reaches its final
> state at 0xc50
>
> Therefore when H(P,P) decides that its input never halts H is
> necessarily correct.

I can see you don't want to answer. I was asking if you have changed
your mind, and I know that's very hard for someone in your position to
admit. Here's the key question: do you still assert that H(P,P) ==
false is the "correct" answer even though P(P) halts? If you won't say,
nothing you do say about what is "correct" (necessarily or otherwise) is
pointless.

Of course, it's likely you have no changed you mind and you are still
searching for words to make the wrong answer seems less obviously
wrong. Not answering my question is a key part of that strategy so I
don't expect an answer.

--
Ben.

[olcott]

I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.

H either aborts the simulation of its input or does not abort the
simulation of its input.

(1) H(P,P) aborts its simulation and 0xc50

P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50

(2) H(P,P) does not abort its simulation and
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50

Therefore when H(P,P) decides that its input never halts H is
necessarily correct.

[Richard Damon]

Which makes the following FALSE statement:

> We do not see any of the x86 instructions of H in the above execution trace because we know that H is only acting as a pure simulator of its inputs until after it has made its halt status decision. This means that H cannot possibly have any effect on the behavior of its input during the above (execution trace / halt status analysis), thus H can safely ignore its own instructions in this halt status analysis.If

Since is H is only 'acting as a pure simulator of its input until
after..." then H is NOT actually a pure simualtor, since a pure
simulator, by definition, NEVER stops its simulation until it simulation
actually gets to a Halting state.

Since H is thus NOT a pure simulator, it is NOT true that it can ignore
the copy of itself inside the machine it is simulating.

Now, a lot of the words in the second part of this statement are just
badly stating things.

First, 'Inputs' don't have 'Behavior'. Inputs are static strings. The
input might represent a Computation, and that Computation has behavior.

It is a basic fact that NOTHING working off an input that is a
representation of something can have ANY affect on the behavior of the
Computation that the input is a representation, unless that thing
started of as part of the computation, then its behavior in that
computation of course affects the computation it is part of by what it
returns (but not by what it does to its own input).

Ultimately, we have that H(P,P) does some stuff that doesn't matter and
returns a non-halting results to its caller.

If that caller was P, then this makes P(P) a Halting Computation, thus
showing that H(P,P) was wrong.

The interesting point is that it is wrong because of that false logic
you used, and BECAUSE it is wrong, it returns the answer that allows
P(P) to be halting.

If H refused to make the wrong decision, then H will never aborts its
simulation, and thus P(P) will be non-halting, but H can't predict that
because it can never get to the point it could prove that, because if
ever it thinks it can prove it and return non-halting, by the structure
of P, H will ALWAYS be wrong, as P will Halt.


That is part of the genius of this proof, if there was some way for H to
appear to prove that it knows what its input will do, this particular
input will ALWAYS make it wrong. The only way that H can't give the
wrong answer is to not answer, but that makes it definitionally wrong
also, as it fails to meet the requirement to answer.

[Richard Damon]

Correction: The 'Simulation of P by H' never reaches its final state

P when run by itself WILL.

FAIL

> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
>
> (2) H(P,P) does not abort its simulation and
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50

If H(P,P) does not abort its simulation then H(P,P) never answers so it
fails to be a decider.


Note, case (1) and (2) have different Ps as well as different Hs so we
can't make the argueent that because the P is (2) never halts that this
says anything about the P in (1).

>
> Therefore when H(P,P) decides that its input never halts H is
> necessarily correct.
>
>

Except that P DOES reach that halting state when P is run as an actual
machine (Assuming H(P,P) answers non-halting). PERIOD.

What doesn't reach that point is H's simulation of P, but that is
irrelevent.

You claim is that H's simulation of P never reaches its final state.

That is clearly what you mean by 'its input never halts' which is a
non-sense statement. Again, Input don't halt.

The PROPER test is looking at what a UTM simulation of that input does,
or what that Compuation that input represents does.

In both cases, that will halt if H(P,P) says non-halting.

Thus H (and YOU) is WRONG.

[olcott]

I have answered, perhaps you are not smart enough to understand the answer?

> I was asking if you have changed
> your mind,

If in both possible cases where H(P,P) aborts the simulation of its
input or H(P,P) fails to abort the simulation of its input P never
reaches its final state at its own machine address of 0xc50 then we know
that P never reaches this final state.

Smart people that understand the x86 language know that when H is a pure
simulator that P does specify infinitely nested simulation at its
machine address 0xc41. Even Richard understands this part.

Smart people that understand the x86 language know that when H aborts
its simulation of P at the machine address of 0xc41 of P that the input
to H(P,P) never reaches its final state of 0xc50.

This means that the following code provides proof that the input to
H(P,P) never reaches its final state of 0xc50 in any possible case, thus
the input to H(P,P) never halts.

The following is taken from pages 4 and 5 of this paper:
Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> and I know that's very hard for someone in your position to
> admit. Here's the key question: do you still assert that H(P,P) ==
> false is the "correct" answer even though P(P) halts?

Yes that is the correct answer even though P(P) halts.
The fact that in all possible cases the input to H(P,P) never halts
conclusively proves that H(P,P)==0 is correct no matter what.

H1(P,P)==1 is consistent with the behavior of P(P).

The difference between H(P,P) and H1(P,P) is that the former has
pathological self-reference and the latter does not. This makes these
two computations distinct from each other and thus not equivalent.

> If you won't say,
> nothing you do say about what is "correct" (necessarily or otherwise) is
> pointless.
>
> Of course, it's likely you have no changed you mind and you are still
> searching for words to make the wrong answer seems less obviously
> wrong. Not answering my question is a key part of that strategy so I
> don't expect an answer.
>

Pathological self-reference has been my life's work. For other people
where this is not the case it would be much more difficult to
understand. The fact that H reports a halt status that is consistent
with the behavior of its input conclusively proves that H is correct.

The input to H1(P,P) has behavior that is computationally equivalent to
P(P).

The input to H(P,P) does not have behavior that is computationally
equivalent to P(P).

The difference in behavior is caused by pathological self-reference.

[olcott]

H1(P,P) is computationally equivalent to P(P)
H(P,P) is NOT computationally equivalent to P(P)

[Richard Damon]

Excpet it isn't that 'P never reaches it final state', that isn't what
you have shown.

You have shown that the simulation of H of P never simulated the machine
to its final state.

If H doesn't abort its simulation, then yes, this H has proved that P is
non-halting, but this H can't give the answer to the question, so it has
failed tis job.

But, if H does abort its simulation, then the fact that it hadn't
reached a halting state doesn't prove it to be right, and to perform
that test we need to give this exact same input to a UTM to see what
happens.

That UTM should get the exact same trace of P up to the point of the
abort, then the UTM will continue and see one last run of P calling an
H, then the top level H in this simulatin aborting its simulation and
returning the non-halting response to the outer most P and then P Halting.

This shows that P(P) is, and always was, a Halting Computation, and H
was just plain WRONG to decide it was non-halting.

>
> Smart people that understand the x86 language know that when H is a pure
> simulator that P does specify infinitely nested simulation at its
> machine address 0xc41. Even Richard understands this part.

Yes, if H IS a Pure Simulator, P is non-halting, and H fails to answer.

>
> Smart people that understand the x86 language know that when H aborts
> its simulation of P at the machine address of 0xc41 of P that the input

> to H(P,P) never reaches its final state of 0xc50.\

Your bad words again.

H aborting says that H's simulation of its input never reached a Halting
State, which seems to be what you mean by the 'non-sense' of 'the input
to H(P,P) never reaches its final state'. The problem is inputs don't do
anything.

The actual definition says the Computation represented by the Input, or
equivalently what happens if this input is give to a REAL UTM.

In either of these cases, the RIGHT test of this input shows that it halts.

>
> This means that the following code provides proof that the input to
> H(P,P) never reaches its final state of 0xc50 in any possible case, thus
> the input to H(P,P) never halts.

Yes, H(P,P) never reaches the halting state in its simulation.

it is still a fact that Inputs don't halt.

it is still a fact that the Computaton represented by the input (or its
simulation by a real UTM) DOES halt in every case where H returns a
non-halting response to this input, so H is WRONG.

So, you are saying with a straight face that Non-Halting is the correct
answer to the question "Does P(P) Halt?" wheh P(P) Halts.

Note, Does P(P) Halt is EXACTLY the question asked by

H(P,P) as the halting question in the halting problem is EXACTLY does
the Computation represented as the input to the Halt Decider Halt, or
equivalently, does the machine represented by the first input to the
halt decider when applied to the second input to the halt decider halt
when it is run.

In ALL cases.

> The fact that in all possible cases the input to H(P,P) never halts
> conclusively proves that H(P,P)==0 is correct no matter what.
>

BUZZ, bad term again. 'the input to H(P,P) never halts' is not a proper
statement. Input NEVER have, by themselves, a Halting status.

Computations have Halting Status.

You either need to look at the Computation the input is a representation
of, or you need to look at the behavior of that input applied to a REAL
UTM (not just H).

> H1(P,P)==1 is consistent with the behavior of P(P).

But H1 isn't the machine that needs to get the right answer, H is.

>
> The difference between H(P,P) and H1(P,P) is that the former has
> pathological self-reference and the latter does not. This makes these

> two computations distinct from each other and thus not equivalent.\

And Pathological Self Reference isn't a valid defense for giving the
wrong answer.

And since H1 is a different computation from H, is means it answer is
not relevent.

>
>> If you won't say,
>> nothing you do say about what is "correct" (necessarily or otherwise) is
>> pointless.
>>
>> Of course, it's likely you have no changed you mind and you are still
>> searching for words to make the wrong answer seems less obviously
>> wrong.  Not answering my question is a key part of that strategy so I
>> don't expect an answer.
>>
>
> Pathological self-reference has been my life's work. For other people
> where this is not the case it would be much more difficult to
> understand. The fact that H reports a halt status that is consistent
> with the behavior of its input conclusively proves that H is correct.

Again, input don't have behavior.

Machines do.

The only machine that matters for this input is what a UTM does with it,
or the machine that the input is a representation of.

>
> The input to H1(P,P) has behavior that is computationally equivalent to
> P(P).
>
> The input to H(P,P) does not have behavior that is computationally
> equivalent to P(P).

Again, inputs don't have behavior.

But, if your arguement is that the input to H doesn't properly represent
the Computation P(P), then that just PROVES that your proof is wrong, as
that is the requirement for the proof.

YOU were the one providing a proper representation of P (aka H^). The
likely problem is that your H is just not defined right so you CAN'T
give it a proper representation, maybe because H isn't actually a proper
computaiton of the right form.

>
> The difference in behavior is caused by pathological self-reference.
>
>

Which is allowed (at least in the form that is actually in the original
proof, which really isn't pathological self-reference).

[Richard Damon]

??????

H and P/H^ are very distinct computations.

The ANSWER that H gives is supposed to correspond to the BEHAVIOR of
P/H^ (They are not 'computationally equivalent')

The fact that some other computation H1, gives the right answer is
irrelent, as Linz only needs that H can't give the right for H^(<H^>)

H1 will similarly fail for H1^(<H1^>)

H1 is TOTALLY meaningless as far as H failing to give the right answer.

You end up stuck in that you want H1 to be 'just like' H so you can use
it to redeam H, but if you try to claim it is close enough to do that,
then all you have done is proved that neither H or H1 is actually the
needed Computation.

[olcott]

Whether or not the input to H(P,P) is aborted at machine address 0xc41
of P the simulation of P never reaches machine address 0xc50 of P.

Can you understand that a computation that is aborted at machine address
0xc41 never gets past machine address 0xc41?

[Richard Damon]

But, what you don't seem to be able to keep in your head is that it
doesn't matter what the simulation done by H does, but what the actual
machine does, or equivalently, a simulation by a REAL UTM.

If H does abort the simulation of P, and thus returns the non-halting
answer, then ths simulation of that exact same input but a UTM does.

Note, that when H abort its simulation, that only affects that
simulation within H, and does NOT affect any outer copy of that machine.

Thus when we run the actual computation P(P) then P(P) will call H(P,P)
and H does its simulation and aborts it at some address, say 0xC41, then
H will need to return that answer to the P that called it, and that P
will run past that address and return, showing that it halts.

PREEMPTIVE: If you want to claim that the H doing the simulation doesn't
return to the actual running P that called it, then H either isn't a
'Compuation' in the mathematical sense, or H doesn't meet the
requirements of 'answering' in the mathematical sense.

Also, if the H called by P acts differently the the H called just by
main, then we also have the fact that H has just proved itself not to be
a Computation in the Mathematical sense.

[olcott]

I did show that the input to H(P,P) never halts and

If the input to H(P,P) never halts then no matter what else H it is
necessary correct when H decides its input never halts.

When you keep trying to argue that a "black cat" is not a "cat" don't
you comprehend that you must be wrong?

H1(P,P) is computationally equivalent to P(P)
H(P,P) is NOT computationally equivalent to P(P)

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> I show all of the details of how we can know that when H(P,P) does not
>>> abort its simulation of its input then its input never reaches its
>>> final state.
>>
>> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
>> details. The most important details -- in the code for H -- are going
>> to remain hidden forever.
>

> If H is...

Will you do what you (not entirely correctly) say you already have and
show all the details? I.e. will you post the code you are keeping
hidden away?

--
Ben.

[Ben Bacarisse]

Ah, that old crank line! I certainly hadn't sees an answer before now,
but you do answer it later on in this post.

>> Here's the key question: do you still assert that H(P,P) == false is
>> the "correct" answer even though P(P) halts?
>
> Yes that is the correct answer even though P(P) halts.

Thank you. The trouble is you don't get to say what the correct answer
is for instances of the halting problem. But the good news is you /do/
get to say what the correct answer is for instances of PO's Other
Halting problem. Unfortunately, no one but you cares about your POOH
problem.

--
Ben.

[André G. Isaak]

On 2021-10-31 15:35, olcott wrote:

> H1(P,P) is computationally equivalent to P(P)
> H(P,P) is NOT computationally equivalent to P(P)

What exactly is it that you are trying to claim here?

H and H1 are supposedly halt deciders. P is not. So Neither H1(P,P) nor
H(P,P) are computationally equivalent to P(P).

Both H1(P,P) and H(P,P) are supposedly answering a question *about*
P(P), i.e. they are both being asked a question about the same
computation, but neither are equivalent to that computation.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

[André G. Isaak]

On 2021-10-31 12:23, olcott wrote:

> Yes that is the correct answer even though P(P) halts.

So the correct question to 'does P(P) halts' is 'no' despite the fact
that P(P) does halt.

That's definitely in the realm of 'alternative logic'.

> The fact that in all possible cases the input to H(P,P) never halts
> conclusively proves that H(P,P)==0 is correct no matter what.

No. The fact that P(P) halts and H(P,P) claims it doesn't conclusively
proves that whatever it is that your H(P, P) is doing it is *not*
answering the question which it is supposed to.

> H1(P,P)==1 is consistent with the behavior of P(P).

So what? You need H(P, P) to be consistent with the behaviour of P(P) if
you want to claim that it is answering correctly.

[olcott]

On 10/31/2021 4:55 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> I show all of the details of how we can know that when H(P,P) does not
>>>> abort its simulation of its input then its input never reaches its
>>>> final state.
>>>
>>> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
>>> details. The most important details -- in the code for H -- are going
>>> to remain hidden forever.
>>
>> If H is...
>
> Will you do what you (not entirely correctly) say you already have and
> show all the details? I.e. will you post the code you are keeping
> hidden away?
>

We don't need to know anything about the internal workings of H besides
two possible cases of its behavior:
(a) H(P,P) never aborts its input
(b) H(P,P) aborts its input at 0xc41

Since in both cases its input never halts we can know for sure that its
input never halts.

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============

[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[Richard Damon]

No, you didn't, because that would be like showing that black is a Cat.

Do you understand that an 'Input' is a string of symbols, and as such
doesn't have 'behvaior' like halting.

Halting is the property of a Computation.

An input can be a representation of a Computation, or when used as an
input to a machine creates a Computaitiopn, but the input isn't a
Computaiton itself.

For the Halting Problem, the input given to H is the representation of a
Computation, so the 'Halting' it is asking about is that actual
computaiton that has been given via the representaiton.

Thus when we apply H to <M> I we are asking if M(I) will halt or not.

By the definitions, and alternative meaning is also will a UTM applied
to <M> I (the input to H) Halt or not.

You have perverted the meaning of this to rather than looking at a UTM
simulating the input to H simulating it, even when H is only a partial
simulator, which is incorrect.

>
> If the input to H(P,P) never halts then no matter what else H it is
> necessary correct when H decides its input never halts.

NO input Halts, or Doesn't Halt. Error of Kind.

You seem to mean that the simulation within H(P,P) never reaches a
halting state, which while true isn't the question of the Halting Problem.

The ACTUAL question that H is SUPPOSED to be answering is would UTM(P,P)
halt or not. When H(P,P) answers non-halting, then we KNOW that UTM(P,P)
will halt. YOU agree to this, as you agree that P(P) does halt. You just
keep trying to argue that the definitional right answer isn't the right
answer because you use the wrong definitions, because you mind seems to
be stuck in POOP.

>
> When you keep trying to argue that a "black cat" is not a "cat" don't
> you comprehend that you must be wrong?

No, you keep on saying that Black is a Cat.

Please ahow me what is the analogy of a 'Black Cat' and a 'Cat' in the
statements.

>
> H1(P,P) is computationally equivalent to P(P)
> H(P,P) is NOT computationally equivalent to P(P)
>
>

You aren't even using Computationally Equivalent in the right manner.

MACHINES or Computation Structures can have Computation Equivalence, not
specific Computations.

Computation Structures, Like Turing Machines and RASP Machines are
called Computationally Equivalent if all Computations that can be
expressed on one struture can be also expressed on the other. This is
the general property you are using to try to claim that by showing x86
code to do halt deciding you can claim that you have shown that you
could do it with a Turing Machine.

Computational Equivalence also can be used on machines, to mean that for
these two machines, for every input that can exist, both machines will
generate the exact same output.

Thus, BY DEFINITION, you can't apply this to machine/input combinations.

Such cases aren't call Computation Equivalent, maybe you could say they
give the 'same answer', but thats about it.

Now, you could try to make the claim that H1(p, p) is the computational
Equivalent of P(p) (where lower case p means ANY program represation
input), but that is obviously incorrect as if H1 is given a simple input
that represents a machine that just halts, it should just halt in state
qy, while P if given a simple input that represents a machine that just
halts, it will go into an infinite loop. Thus a claim that they are
somehow 'equivalent' is provably false.

[Richard Damon]

On 10/31/21 6:26 PM, olcott wrote:
> On 10/31/2021 4:55 PM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> I show all of the details of how we can know that when H(P,P) does not
>>>>> abort its simulation of its input then its input never reaches its
>>>>> final state.
>>>>
>>>> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
>>>> details.  The most important details -- in the code for H -- are going
>>>> to remain hidden forever.
>>>
>>> If H is...
>>
>> Will you do what you (not entirely correctly) say you already have and
>> show all the details?  I.e. will you post the code you are keeping
>> hidden away?
>>
>
> We don't need to know anything about the internal workings of H besides
> two possible cases of its behavior:
> (a) H(P,P) never aborts its input
> (b) H(P,P) aborts its input at 0xc41

Which have to be two DIFFERENT definition of H, which will have
DIFFERENT Ps associated with them, so completely different problems.

>
> Since in both cases its input never halts we can know for sure that its
> input never halts.

WRONG TERMINOLOGY. INPUT DON'T have a halting property of themselves.

The Halting Problem can be looked at as what does this input do when
applied to the same input as the Halt Decider is given.

And UTM(P,P) will HALT for every input that H(P,P) says in non-halting,
so H(P,P) saying Non-Halting is always wrong.

[wij]

Thus, H is no longer a partial decider as previously claimed.
Drawing general conclusion from specific cases is invalid deduction.

> therefore H is necessarily correct when it aborts the simulation of this
> input and reports non-halting.

Invalid deduction

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 10/31/2021 4:55 PM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> I show all of the details of how we can know that when H(P,P) does not
>>>>> abort its simulation of its input then its input never reaches its
>>>>> final state.
>>>>
>>>> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
>>>> details. The most important details -- in the code for H -- are going
>>>> to remain hidden forever.
>>>
>>> If H is...
>> Will you do what you (not entirely correctly) say you already have and
>> show all the details? I.e. will you post the code you are keeping
>> hidden away?
>
> We don't need to know anything about the internal workings of H

Since H gets the wrong answer for the key instance, I agree -- no one
needs to know any more that that. My point was just that you were
fibbing about showing "all of the details".

--
Ben.

[olcott]

On 11/1/2021 5:51 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 10/31/2021 4:55 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> I show all of the details of how we can know that when H(P,P) does not
>>>>>> abort its simulation of its input then its input never reaches its
>>>>>> final state.
>>>>>
>>>>> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
>>>>> details. The most important details -- in the code for H -- are going
>>>>> to remain hidden forever.
>>>>
>>>> If H is...
>>> Will you do what you (not entirely correctly) say you already have and
>>> show all the details? I.e. will you post the code you are keeping
>>> hidden away?
>>
>> We don't need to know anything about the internal workings of H
>
> Since H gets the wrong answer for the key instance, I agree -- no one
> needs to know any more that that. My point was just that you were
> fibbing about showing "all of the details".
>

No matter what the code is for H every possible H must abort its
simulation of (P,P) otherwise this input never halts.

I was about to show all the details then:
(1) I ran into an unexpected complexity with my pure function H
(2) Realized that these details do not matter. My claim applies equally
to every possible encoding of H.

[olcott]

A machine is a partial halt decider if it gets as many as one single
input correctly. In the case of H(P,P)==0 H gets this case correctly.

>> therefore H is necessarily correct when it aborts the simulation of this
>> input and reports non-halting.
>
> Invalid deduction
>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

[olcott]

On 10/31/2021 11:48 AM, Mike Terry wrote:

> On 31/10/2021 15:51, olcott wrote:

>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>

>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>

>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8...@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>>
>

> Ignoring the blatent false claim that you have proved anything, you have

> fallen foul of the Giganews "delayed publishing" feature/bug.  (That's
> my name for it.)
>
> This isn't a rare event, I'd say anything from 5%-40% of articles hit
> this problem.  What happens is that Giganews receives an article and
> assigns article numbers for it, in its normal sequence for the groups.
> Then Giganews decides "hey, I'm not going to "publish" that article for
> a few hours!"  So the article id is skipped in NNTP responses that list
> article ids and doesn't appear in news readers.  Most often I notice
> this when I see responses to articles that haven't appeared.
>
> A few hours later, Giganews decides "hey, I think I've pissed off my
> paying customers enough now, so I'll finally "publish" that old article
> I received".  At this point it starts listing the article id in group
> listings so that news reader clients pick it up.  (Except that by now
> many clients may have just decided the article id is simply invalid, and
> may never retrieve it, and even if they do retrieve it, there may well
> have been "mysterious" responses to it retrieved out of order.)
>
> I've not seen any of the free news servers behaving like this, so what
> does that say about Giganews?
>
> Anyway I predict your post will mysteriously appear in a few hours time.
>  We'll see.  (On my Giganews server your article appears to have been
> allocated id 107792 but hasn't been "published" as such yet. Grr.)
>
> Mike.

The post never appeared on my Giganews feed in Thunderbird.
It did appear on my other USENET provider Thunderbird feed.

I reported it to Giganews and they are unconvinced that it is on their
end. Did you have this problem using Thunderbird or some other client?

[Mike Terry]

The problem is definitely on their server, assuming it is "the usual"
problem which I see dozens of times a day (some days). I'm tempted to
say they /must/ be aware of it, as it's been going on for ages (years?),
although it does seem to have got MUCH worse lately (last couple of
months). Perhaps everyone is like me and just assumes someone else has
reported it! (For me, reporting would be hampered because I have no
relationship with Giganews - I'd have to go through my ISP, and from
their perspective Usenet is bundled in and I'm not explicitly paying for
it. So I just know it would be an uphill battle!

Anyway, my description of the problem is based on network traces etc.
rather than any particular client I'm using. It is definitely their
server that is not "publishing" (my word) the article ids.

Look, here is a list of recent article ids for comp.theory on my
Giganews server (news.plus.net, alias for europe.isp.giganews.com, IP:
216.166.105.145)

--107780 Sat, 30 Oct 2021 10:48:35 -0700 (PDT)
--107781 Sat, 30 Oct 2021 11:29:33 -0700 (PDT)
--107782 Sat, 30 Oct 2021 11:30:27 -0700 (PDT)
--107783 Sat, 30 Oct 2021 14:19:40 -0700 (PDT)
--107784 Sat, 30 Oct 2021 14:25:12 -0700 (PDT)
--107785 Sat, 30 Oct 2021 21:44:54 -0500
--107786 Sat, 30 Oct 2021 21:01:10 -0700 (PDT)
--107787 Sun, 31 Oct 2021 07:00:36 -0400
--107788 Sun, 31 Oct 2021 09:13:57 -0500
###
###
--107791 Sun, 31 Oct 2021 08:47:12 -0700 (PDT)
###
--107793 Sun, 31 Oct 2021 16:25:20 +0000
--107794 Sun, 31 Oct 2021 11:34:40 -0500
--107795 Sun, 31 Oct 2021 11:46:32 -0500
--107796 Sun, 31 Oct 2021 16:48:07 +0000
###
--107798 Sun, 31 Oct 2021 13:28:45 -0400
--107799 Sun, 31 Oct 2021 13:36:51 -0400
###
--107801 Sun, 31 Oct 2021 12:54:32 -0500
--107802 Sun, 31 Oct 2021 14:12:12 -0400
--107803 Sun, 31 Oct 2021 14:20:25 -0400
###
###
--107806 Sun, 31 Oct 2021 14:56:55 -0400
###
###
--107809 Sun, 31 Oct 2021 16:18:07 -0400
###
--107811 Sun, 31 Oct 2021 21:55:14 +0000
###
--107813 Sun, 31 Oct 2021 16:20:42 -0600
###
--107815 Sun, 31 Oct 2021 17:26:12 -0500
###
--107817 Sun, 31 Oct 2021 18:53:59 -0400
###
--107819 Sun, 31 Oct 2021 22:28:43 -0500
--107820 Sun, 31 Oct 2021 22:45:40 -0500
###
###
--107823 Mon, 01 Nov 2021 10:51:11 +0000
--107824 Mon, 1 Nov 2021 06:59:01 -0400
--107825 Mon, 1 Nov 2021 07:02:09 -0400
###
--107827 Mon, 01 Nov 2021 14:28:40 +0000
--107828 Mon, 1 Nov 2021 09:48:03 -0500
--107829 Mon, 1 Nov 2021 09:54:20 -0500
###
###
--107832 Mon, 1 Nov 2021 10:18:48 -0500
--107833 Mon, 1 Nov 2021 10:31:07 -0600

(I guess you would have a different US Giganews server, so I don't know
if you'd get exactly the same results, or even similar results!)

Your "lost" post is retrievable from the server via its message id
<hIednR1p-IK1NuP8...@giganews.com>, but not via its article
number, which (based on the time you posted it) is where the missing
article 107792 should be in the list above.

Normally what happens is that after a few hours (can be several hours!)
the "missing" articles appear in exactly the expected missing article
number positions. That tells me that Giganews HAS received the articles
at the normal time in its sequence of article numbers, and I would say
the article number has been "tentatively" assigned to the article, hence
the observed gap. HOWEVER, the xover database is not updated, and
requests that are based on article id (rather than message-id) do not
show the articles.

(Note, retrieval via message-id is "server-wide" and not associated with
any newsgroup, whereas article-ids are specific to each newsgroup like
comp.theory, and also specific to each server. Message-ids are the same
on all servers...)

Also, if I retrieve the article via its messageid, I notice that it is
missing the Xref header which includes the list of newsgroups+articleids
that are linked to the article. When Giganews finally "publish" the
article, it appears with the expected articleid numbers in the expected
newsgroups, and also the XREF header magically appears on the article.

I imagine someone at Giganews must instantly recognise these symptoms
and is probably quite familiar with the problem and its causes! (But it
seems not the person you're dealing with!)

You see from the listing above that your article is just one of 19
recent problem instances!

If I had to make a guess, I would wonder whether the "hidden" articles
have been diverted into some kind of "manual approval" queue, a bit like
as for moderated newsgroups, but none of the newsgroups are moderated -
still, maybe Giganews have some kind of "manual" handling for certain
articles?????? Just a total guess...

Mike.
ps. my day-to-day newsreader is SeaMonkey. Also, if Giganews want to
talk directly to me about the problem I'd be ok with that...

[Ben Bacarisse]

olcott <No...@NoWhere.com> writes:

> On 11/1/2021 5:51 AM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 10/31/2021 4:55 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> I show all of the details of how we can know that when H(P,P) does not
>>>>>>> abort its simulation of its input then its input never reaches its
>>>>>>> final state.
>>>>>>
>>>>>> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
>>>>>> details. The most important details -- in the code for H -- are going
>>>>>> to remain hidden forever.
>>>>>
>>>>> If H is...
>>>> Will you do what you (not entirely correctly) say you already have and
>>>> show all the details? I.e. will you post the code you are keeping
>>>> hidden away?
>>>
>>> We don't need to know anything about the internal workings of H
>>
>> Since H gets the wrong answer for the key instance, I agree -- no one
>> needs to know any more that that. My point was just that you were
>> fibbing about showing "all of the details".
>
> No matter what the code is for H every possible H must abort its
> simulation of (P,P) otherwise this input never halts.

P(P) halts (according to you). H(P,P) == 0 (according to you). This is
wrong (according to everyone /except/ you).

> I was about to show all the details then:
> (1) I ran into an unexpected complexity with my pure function H

Then publish the H you had fully encoded three years ago. That one is
not complicated. It fits on a scrap of paper (I seem to recall), and is
"easily verifiably correct". Or was that remark also a li^H^H^H^H
poetic license as well?

> (2) Realized that these details do not matter.

To you, maybe, but I'd like to see the yards of code you've written
simply to get the wrong answer.

--
Ben.

[Richard Damon]

No, it doesn't, since P(P) Halts.

The DEFINITION of the Halting Problem is that decider is supposed to
tell us what the ACTUAL COMPUTATION, that the input is repesentation of
does.

Only in your POOP, does it matter what the partial simulation of tne
input by the decider does.

FAIL.

[Richard Damon]

Yes, it doesn't matter if H meets the requirements of a 'pure function'
or not.

What DOES matter is H must meet the requirements of being a
COMUPUTATION, and a computation whose sole input it the representation
of the computation it is deciding on, that being the representation of
the Turing Machine and a copy of the input to that machine.

If H actually IS a computation, then EVERY copy of H will ALWAYS produce
the exact same result for the same input under EVERY condition.

THe key point here is that means that if when we run H(P,P) as an
independent operation and it answer 'Non-Halting', then when we run P(P)
as an independent top level computation, when it uses its copy of H with
the input P,P, then that too must say 'Non-Halting' in finite time, and
that also says that if H is doing an accurate simulation of this input,
that this simulation will ALSO see in its simulation of H that H WILL in
a finite time also return that exact same answer.

The fact that when H simulates this input, it 'sees' that P(P) goes into
an infinite recursion says that one of two things must be true (or both):

1) Either H is NOT being an accurate simulation, and it is seeing
something different in its trace that isn't actually there in the actual
running of P(P), or

2) H itself is not actually a Computation of the right inputs.


How else can you explain that H 'sees' a different result in its
simulation of P(P) then what happens when we actually run P(P).

Note, your claim of 'Pathological Self-Reference' is NOT a excuse for H
to act incorrectly, though it may be a reason why it does. The problem
is that this form of interaction in the design of H^ is FULLY LEGAL in
the universe of Turing Machines, and a Universal Halt Decider, to be
one, needs to handle this case, and to claim you even handle this case,
you need to do it by the actual rules, and don't have the 'authority' to
change the definitions in the problem to something else. That just means
you are working on something other than the Halting Problem, and your
results just don't apply to it.

[Mike Terry]

OK, I was right (mostly)! Your missing post, along with all the other
missing posts shown as ### above, have appeared some time in the last 14
hours!

(I guessed the article number incorrectly - it was number 107789 all
along, but Giganews didn't want to tell us that...)

Here is the same article-id listing as above, but brought up to date:

--107780 Sat, 30 Oct 2021 10:48:35 -0700 (PDT)
--107781 Sat, 30 Oct 2021 11:29:33 -0700 (PDT)
--107782 Sat, 30 Oct 2021 11:30:27 -0700 (PDT)
--107783 Sat, 30 Oct 2021 14:19:40 -0700 (PDT)
--107784 Sat, 30 Oct 2021 14:25:12 -0700 (PDT)
--107785 Sat, 30 Oct 2021 21:44:54 -0500
--107786 Sat, 30 Oct 2021 21:01:10 -0700 (PDT)
--107787 Sun, 31 Oct 2021 07:00:36 -0400
--107788 Sun, 31 Oct 2021 09:13:57 -0500

--107789 Sun, 31 Oct 2021 09:41:41 -0500 <=== your article!
--107790 Sun, 31 Oct 2021 15:11:39 +0000

--107791 Sun, 31 Oct 2021 08:47:12 -0700 (PDT)

--107792 Sun, 31 Oct 2021 10:51:48 -0500

--107793 Sun, 31 Oct 2021 16:25:20 +0000
--107794 Sun, 31 Oct 2021 11:34:40 -0500
--107795 Sun, 31 Oct 2021 11:46:32 -0500
--107796 Sun, 31 Oct 2021 16:48:07 +0000

--107797 Sun, 31 Oct 2021 12:14:24 -0500

--107798 Sun, 31 Oct 2021 13:28:45 -0400
--107799 Sun, 31 Oct 2021 13:36:51 -0400

--107800 Sun, 31 Oct 2021 17:46:24 +0000

--107801 Sun, 31 Oct 2021 12:54:32 -0500
--107802 Sun, 31 Oct 2021 14:12:12 -0400
--107803 Sun, 31 Oct 2021 14:20:25 -0400

--107804 Sun, 31 Oct 2021 13:23:29 -0500
--107805 Sun, 31 Oct 2021 13:47:35 -0500

--107806 Sun, 31 Oct 2021 14:56:55 -0400

--107807 Sun, 31 Oct 2021 15:03:51 -0400
--107808 Sun, 31 Oct 2021 14:26:56 -0500

--107809 Sun, 31 Oct 2021 16:18:07 -0400

--107810 Sun, 31 Oct 2021 16:35:59 -0500

--107811 Sun, 31 Oct 2021 21:55:14 +0000

--107812 Sun, 31 Oct 2021 22:09:49 +0000

--107813 Sun, 31 Oct 2021 16:20:42 -0600

--107814 Sun, 31 Oct 2021 16:25:11 -0600

--107815 Sun, 31 Oct 2021 17:26:12 -0500

--107816 Sun, 31 Oct 2021 18:36:44 -0400

--107817 Sun, 31 Oct 2021 18:53:59 -0400

--107819 Sun, 31 Oct 2021 22:28:43 -0500
--107820 Sun, 31 Oct 2021 22:45:40 -0500

--107823 Mon, 01 Nov 2021 10:51:11 +0000
--107824 Mon, 1 Nov 2021 06:59:01 -0400
--107825 Mon, 1 Nov 2021 07:02:09 -0400

--107827 Mon, 01 Nov 2021 14:28:40 +0000
--107828 Mon, 1 Nov 2021 09:48:03 -0500
--107829 Mon, 1 Nov 2021 09:54:20 -0500

--107832 Mon, 1 Nov 2021 10:18:48 -0500
--107833 Mon, 1 Nov 2021 10:31:07 -0600

For my newsreader, it's way too late for it to pick up those articles,
as it's already decided the article-ids are invalid. Grrr. Thank you
Giganews - a great payed-for (by my ISP, not by me) service!

All those articles were available straight away on e.g. the AIOE (FREE)
news server, so well done to Giganews for the subtracted-value it is
offering its subscribers!


Mike.

[olcott]

This message is still not showing up in my Giganews in Thunderbird
even when I unsubscribe, delete the local files and subscribe again.

On 10/31/2021 9:41 AM, olcott wrote:
<hIednR1p-IK1NuP8...@giganews.com>

Most of the messages that I posted today did not show up
in my Giganews in Thunderbird. So far they seem to always
show up on USENET, just not on USENET through Giganews in
Thunderbird.

This is a good free backup:
https://www.eternal-september.org/

I am trying to get this to work: https://www.aioe.org/

[Mike Terry]

On 02/11/2021 18:57, olcott wrote:
> On 11/2/2021 1:08 PM, Mike Terry wrote:

<..snip..>

>>
>> OK, I was right (mostly)!  Your missing post, along with all the other
>> missing posts shown as ### above, have appeared some time in the last
>> 14 hours!
>>
>
> This message is still not showing up in my Giganews in Thunderbird
> even when I unsubscribe, delete the local files and subscribe again.

You would be using a US Giganews server, and maybe the servers are not
totally synchronised. It's hard to say, since I don't have access to
your Giganews server. So maybe the problem with your
<hIednR1p-IK1NuP8...@giganews.com> post will resolve itself
in time.

Another possibility is that your Thunderbird client is obscuring the
situation, although unsubscribing, deleting local files and
resubscribing ought to pick up your missing post if its really on your
server - at least if it's been done properly...

To avoid that sort of issue I submit commands manually directly to the
server. Then it's easy to see the problem, with no possibility of
client software obscuring things. I have my own console-mode program
that submits commands from stdin, but generally available alternatives
would be telnet, or (better) netcat. The NNTP protocol is simple text
based, a bit like SMTP for emails. Some useful commands:

article <hIednR1p-IK1NuP8...@giganews.com>
group comp.theory
article 12345
xhdr date 12345-12400
quit

The first command retrieves your post by message-id. (If the headers
have an Xref: header, that will tell you the message-id for each
newsgroup. If it doesn't have an Xref header, that's a good indicator
of the problem!) The group command selects an active group for the 3rd
and 4th commands, and the response also contains the max item number for
the group, which can provide numbers to go into article and xhdr
commands. The third command retrieves an article by its number within
the selected group, and the xhdr command is a good way of seeing which
article numbers are actually assigned within the group. E.g. my output
in previous posts was from "xhdr date 107780-107833", but maybe your
server has different message ids (depending on whether/how different
Giganews servers synchronise, which I have no idea about).

Anyway, you could maybe use this way to check out what's actually on
your server, independent of what your client is doing... (Remember, you
want the NNTP port which should be 119. If you resort to Telnet, it
will be a bit painful, as the whole "terminal emulation" part of it is
unwanted - you just want to send lines of text followed by <CR><LF> with
no terminal control characters. Still, it works as long as you can type
correctly and don't try to backspace to correct typos etc.)

>
> On 10/31/2021 9:41 AM, olcott wrote:
> <hIednR1p-IK1NuP8...@giganews.com>
>
> Most of the messages that I posted today did not show up
> in my Giganews in Thunderbird. So far they seem to always
> show up on USENET, just not on USENET through Giganews in
> Thunderbird.

Yes, the Giganews problem seems to be just with assigning posts to their
newsgroups, not actually accepting posts in the first place. The
missing posts are spread across all originating servers as far as I can
see. So you can post via e.g. AIOE and it's just as likely Giganews
will mess up your post and hide/delay it, but at least if you're reading
via AIOE as well, you should see it straight away...

>
> This is a good free backup:
> https://www.eternal-september.org/
>
> I am trying to get this to work: https://www.aioe.org/

Those are the two I'm most familiar with. The first requires
registration, and the second is no registration required. (But
registration is hardly a big deal if you plan to use it long term.)
Both are free... I don't really know which is "best"!

Mike.

[olcott]

I would like to determine the actual problem and get Giganews to fix it.
The big advantage of Giganews is that they have every post that I have
ever written.

I could not get past authentication with telnet.

The post in question has never showed up on Giganews but a reply to that
post has showed up. I have never had a case where I post to
Eternal September that has not showed up in Giganews in less than one
minute.

[Mike Terry]

I would expect they still have all your old posts, and also the new ones
- it's just that some newer ones are not yet visible. (If your problem
is the one I've described...)

>
> I could not get past authentication with telnet.

Hmm, that doesn't happen with my Giganews server, but I suspect that's
because they can authenticate me implicitly by IP address. (My ISP has
the contract with them, and my ISP has a known block of allocated IP
addresses it uses.)

This does complicate things! Presumably you have been given a Giganews
userid/password?

One option is try authenticating via the AUTHINFO command, if that is
what your server supports. The downside for this is that it would send
the userid/pwd in clear text to the server. (I don't know how bad you
would consider that - maybe you could do your tests then change the
password after or something...)

When the server says authentication is required, you would send

AUTHINFO USER username

and then if that is accepted:

AUTHINFO PASS password

and then if that's accepted carry on as before. I've never needed to do
this, so I've never actually tested this!

An alternative is to use an NNTP over SSL port - Giganews use the
default 443, I think. Then the above commands would not expose your
credentials, but now the problem would be your connection - telnet
wouldn't work unless it has an "over SSL" option?? I believe this is
just the sort of thing netcat excels at, but I can't advise you on how
to use that. (I know there is a version to work on Windows but you'd
have to install it and work out the command line options yourself. I
think it's generally available on UNIX based system(?))

If you have a specific post you'd like me to check on my (European)
Giganews server, let me know the message-id or (UTC) date/time and I'll
have a look...

Mike.

>
> The post in question has never showed up on Giganews but a reply to that
> post has showed up. I have never had a case where I post to
> Eternal September that has not showed up in Giganews in less than one
> minute.

I don't know - maybe you've just been lucky, or maybe there are more
details for the problem to occur that we don't know about and that make
ES server avoid the problem? (It's definitely not just GN that has the
problem I see, so I'd guess you've just been lucky!)

[olcott]

The problem only occurs when I post using Giganews and try to retrieve
the same post using Giganews. This problem is only periodic, yet
seemed to have happened several times today.