Architectural design of a halting problem solution

[olcott]

Intuitively, a decider should be a Turing machine that given an input,
halts and either accepts or rejects, relaying its answer in one of many
equivalent ways, such as halting at an ACCEPT or REJECT state, or
leaving its answer on the output tape.Yuval Filmus
https://cs.stackexchange.com/questions/84433/what-is-decider

Yuval Filmus top 0.04% overall Assistant Professor in the Department of
Computer Science at the Technion.

It is common knowledge that a halt decider with the following
architectural design can be thwarted by an input program that does the
opposite of whatever the halt decider decides:

The halt decider divides all of its inputs into:
(a) HALTS
(b) DOES_NOT_HALT

This brand new architectural design cannot be thwarted by the
conventional self-referential halting problem trick. With this design
there is no input that can be shown to be undecidable:

The halt decider that divides all of its inputs into:
(a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED
(b) INPUT_PROGRAM_HAS_TERMINATED

The redefined halt decider UTM executes its subordinate UTM one state
transition at a time until it detects non-halting behavior or its
subordinate UTM has terminated normally.

If the halt decider UTM detects non-halting behavior of its subordinate
UTM it simply stops executing the subordinate and transitions to its own
final state of ABORTED_NON_TERMINATING_BEHAVIOR.

If the subordinate UTM terminates normally the halt decider UTM
transitions to its own final state of SUBORDINATE_HAS_TERMINATED.

--
Copyright 2020 Pete Olcott

[André G. Isaak]

On 2020-10-27 13:30, olcott wrote:
> Intuitively, a decider should be a Turing machine that given an input,
> halts and either accepts or rejects, relaying its answer in one of many
> equivalent ways, such as halting at an ACCEPT or REJECT state, or
> leaving its answer on the output tape.Yuval Filmus
> https://cs.stackexchange.com/questions/84433/what-is-decider
>
> Yuval Filmus top 0.04% overall Assistant Professor in the Department of
> Computer Science at the Technion.
>
> It is common knowledge that a halt decider with the following
> architectural design can be thwarted by an input program that does the
> opposite of whatever the halt decider decides:
>
> The halt decider divides all of its inputs into:
> (a) HALTS
> (b) DOES_NOT_HALT

That isn't an 'architectural design'. That's simply a definition of what
a halt decider does. Anything which does not do the above is not a halt
decider. The above says nothing whatsoever about 'architectural design'.

André

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

[olcott]

On 10/27/2020 2:46 PM, André G. Isaak wrote:
> On 2020-10-27 13:30, olcott wrote:
>> Intuitively, a decider should be a Turing machine that given an input,
>> halts and either accepts or rejects, relaying its answer in one of
>> many equivalent ways, such as halting at an ACCEPT or REJECT state, or
>> leaving its answer on the output tape.Yuval Filmus
>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>
>> Yuval Filmus top 0.04% overall Assistant Professor in the Department
>> of Computer Science at the Technion.
>>
>> It is common knowledge that a halt decider with the following
>> architectural design can be thwarted by an input program that does the
>> opposite of whatever the halt decider decides:
>>
>> The halt decider divides all of its inputs into:
>> (a) HALTS
>> (b) DOES_NOT_HALT
>
> That isn't an 'architectural design'. That's simply a definition of what
> a halt decider does.

Then my solution can be called a redefinition:

The halt decider that divides all of its inputs into:
(a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED
(b) INPUT_PROGRAM_HAS_TERMINATED

> Anything which does not do the above is not a halt
> decider. The above says nothing whatsoever about 'architectural design'.
>
> André

Then we can call it the definition of a NON_HALTING_DECIDER. None of its
inputs would halt unless it aborts their execution and all of the rest
of its inputs would halt.

[olcott]

On 10/27/2020 3:03 PM, Mike Terry wrote:

> On 27/10/2020 19:30, olcott wrote:
>> Intuitively, a decider should be a Turing machine that given an input,
>> halts and either accepts or rejects, relaying its answer in one of many
>> equivalent ways, such as halting at an ACCEPT or REJECT state, or
>> leaving its answer on the output tape.Yuval Filmus
>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>
>> Yuval Filmus top 0.04% overall Assistant Professor in the Department of
>> Computer Science at the Technion.
>>
>> It is common knowledge that a halt decider with the following
>> architectural design can be thwarted by an input program that does the
>> opposite of whatever the halt decider decides:
>>
>> The halt decider divides all of its inputs into:
>> (a) HALTS
>> (b) DOES_NOT_HALT
>

> That's not an "architecural design" - it's part of the definition of a
> halt decider.  It's good though, that you seem to be finally admitting
> that the HP proof is correct.  The end of an era!!
>
> You may not get the fame and credibility you longed for, but at least
> you can get on with the rest of your life.

>
>>
>> This brand new architectural design cannot be thwarted by the
>> conventional self-referential halting problem trick. With this design
>> there is no input that can be shown to be undecidable:
>>
>> The halt decider that divides all of its inputs into:
>> (a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED
>> (b) INPUT_PROGRAM_HAS_TERMINATED
>>
>

> Aha, some kind of "aborted because non-halting behaviour detected"
> decider!  Unfortunately there are plenty of decision problems that /are/
> decidable, including many whose domain is the same as that halting
> problem's.  Possibly if you made the definition of the your decision
> well defined, it could be one of those...
>
I have redefined the impossible halt decider into a NON_HALTING_DECIDER

that divides all of its inputs into:
(a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED
(b) INPUT_PROGRAM_HAS_TERMINATED

As you can see from (b) the NON_HALTING_DECIDER is still a halt decider.

[André G. Isaak]

If your (a) and (b) are simply new names for 'doesn't halt' and 'halts',
then this is just as subject to Linz's proof as any other purported halt
decider.

If they are not, and there are cases where 'aborted' and 'halted' don't
mean exactly the same thing, then what you have isn't a halt decider at all.

A halt decider determines if a particular TM, T, will halt for input I.

IOW, it tells us something about the behaviour of T when confronted with
input I.

Part (b) of your 'redefinition' presupposes that we have actually
already run T(I). That still tells us that T(I) halts, but we could have
just run T(I) ourselves to make this determination, so your
'redefinition' doesn't provide us with any useful information in this case.

Part (a) of your redefinition is where things really get mucked up since
it presupposes that we have already attempted to run T(I); moreover, we
have done it in some sort of specialized environment E in which it is
possible to force things to abort. Therefore, your 'revision' is asking
how T behaves when confronted with input I IN ENVIRONMENT E.

Whereas the actual definition of a halt decider tells us about T, in
your 'revised' version we have no way of knowing whether it is telling
us about T or about E in cases where the input is forced to terminate.

What you have isn't analogous to a halt decider. It is a
How-does-this-TM-behave-in-environment-E decider.

Unless you can provide some reason why I should care about how things
behave in environment E (or environment E at all, for that matter), this
isn't something that is of interest.

[olcott]

I dared anyone to show this and they absolutely could not because it is
impossible.

> If they are not, and there are cases where 'aborted' and 'halted' don't
> mean exactly the same thing, then what you have isn't a halt decider at
> all.

The above two sets are the exact same sets that a correct halt decider
would decide.

> A halt decider determines if a particular TM, T, will halt for input I.

Apparently it is much easier to decide the cases that would not halt
unless aborted and leave the halting cases as those that are left over.

> IOW, it tells us something about the behaviour of T when confronted with
> input I.
>

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I)
Try and find a (T, I) pair that the above function cannot correctly decide.

By correctly decide what I mean is the totally obvious:
The above function returns true and this sentence is true:
"T was aborted because non halting behavior was detected."

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I) would
be incorrect when it returns true and:
(a) The input program was not aborted.
(b) Non-halting behavior was not detected.
(c) Non-halting behavior was erronesously reported.
(d) The input program was aborted and the halt decider correctly
detected non-halting behavior of the input program, yet the input
program was aborted for some other reason besides the fact that
non-halting behavior was detected.

> Part (b) of your 'redefinition' presupposes that we have actually
> already run T(I). That still tells us that T(I) halts, but we could have
> just run T(I) ourselves to make this determination, so your
> 'redefinition' doesn't provide us with any useful information in this case.

You must not have through that one through very well. The
NON_HALTING_DECIDER screens out all of the infinite executions.

> Part (a) of your redefinition is where things really get mucked up since
> it presupposes that we have already attempted to run T(I); moreover, we
> have done it in some sort of specialized environment E in which it is
> possible to force things to abort. Therefore, your 'revision' is asking
> how T behaves when confronted with input I IN ENVIRONMENT E.

No, not really, not at all.
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I)
only aborts the execution of programs that would not otherwise halt.

If H_Hat(H_Hat) did not have any of its otherwise infinitely recursive
invocations terminated it would never stop running.


void H_Hat(u32 M)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_1 // Execution of M(M) has been aborted
else
{
MOV_EAX_0 // M(M) has halted
HERE: goto HERE;
}
HALT
}


int main()
{
u32 M = (u32)H_Hat;
H_Hat(M);
HALT

}


> Whereas the actual definition of a halt decider tells us about T, in
> your 'revised' version we have no way of knowing whether it is telling
> us about T or about E in cases where the input is forced to terminate.
>
> What you have isn't analogous to a halt decider. It is a
> How-does-this-TM-behave-in-environment-E decider.

No, not at all, not in the least.
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 T, u32 I)
only aborts the execution of programs that would not otherwise halt.

> Unless you can provide some reason why I should care about how things
> behave in environment E (or environment E at all, for that matter), this
> isn't something that is of interest.
>
> André
>

The following definition shows that it is not any specialied environment
it is merely the conventional notion of a UTM.

The redefined halt decider UTM executes its subordinate UTM one state
transition at a time until it detects non-halting behavior or its
subordinate UTM has terminated normally.

If the halt decider UTM detects non-halting behavior of its subordinate
UTM it simply stops executing the subordinate and transitions to its own
final state of ABORTED_NON_TERMINATING_BEHAVIOR.

If the subordinate UTM terminates normally the halt decider UTM
transitions to its own final state of SUBORDINATE_HAS_TERMINATED.

[olcott]

On 10/27/2020 4:11 PM, Mike Terry wrote:

> Exactly, and in another thread PO has confirmed that 'aborted' includes
> cases where the calculation in question halts.

That is flat out not true. In every single case where this halt decider
decides that its input must be aborted its input would not otherwise
halt: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)

Also in every single case where the above function returns false its
input has already halted.

> (Of course, I mean is in
> the HP defined HALTING class.)  And obviously cases in his 'terminated'
> class are also in the HALTING class...
>
> Mike.

[olcott]

On 10/27/2020 4:44 PM, Malcolm McLean wrote:

> So write a stub for bool Aborted_Because_Non_Halting_Behavior_Detected
> that just works on the input H_Hat, H_Hat.
>

That would be no better than telling people that I must be correct
because I really know that I am right, the same petitio principii
logical fallacy that they are using in their utterly vacuous rebuttals.

I simply have to finish writing the actual halt deciding code for
bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat).
I already totally explained (2018-12-13 solution) exactly how this works.

[olcott]

On 10/27/2020 4:33 PM, Mike Terry wrote:

> I explained in the other thread why that's just your confused thinking -
> a confusion with the ".. *would* not otherwise halt ..", muddling up two
> totally different programs.
>
> I won't be repeating everything again in a new thread :)
> Mike.
>

It is totally your confusion not mine.

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)

always decides its inputs correctly.

Your incorrect attempt at a counter-example was not an input to

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)

[olcott]

On 10/27/2020 5:07 PM, Malcolm McLean wrote:

> On Tuesday, 27 October 2020 at 21:54:11 UTC, olcott wrote:
>> On 10/27/2020 4:44 PM, Malcolm McLean wrote:
>>> On Tuesday, 27 October 2020 at 21:27:42 UTC, olcott wrote:
>>>> On 10/27/2020 4:11 PM, Mike Terry wrote:
>>>>> Exactly, and in another thread PO has confirmed that 'aborted' includes
>>>>> cases where the calculation in question halts.
>>>>
>>>> That is flat out not true. In every single case where this halt decider
>>>> decides that its input must be aborted its input would not otherwise
>>>> halt: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)
>>>>
>>>> Also in every single case where the above function returns false its
>>>> input has already halted.
>>>>
>>> So write a stub for bool Aborted_Because_Non_Halting_Behavior_Detected
>>> that just works on the input H_Hat, H_Hat.
>>>
>> That would be no better than telling people that I must be correct
>> because I really know that I am right, the same petitio principii
>> logical fallacy that they are using in their utterly vacuous rebuttals.
>>

> The "stub" cannot be
>
> bool Aborted_Because_Non_Halting_Behaviour_Detected(U32 *M, U32 *N)
> {
> return true;
> }
>
> because that is no different from a halt decider, which can be inverted. It
> can't be "return false" for the same reason.
> So it must be something else. But only you can provide that. That will
> clarify everything.

>>
>> I simply have to finish writing the actual halt deciding code for
>> bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat).
>> I already totally explained (2018-12-13 solution) exactly how this works.
>>

> But it's a very long way round. If you were writing a real fully-fledged
> function, you would of course have to do this. But all you are doing is trying
> to refute Linz. So you only need to handle one case.

Not really. The hard part that took about 2000 hours was writing the
x86utm operating system. I could finish the halt deciding code in 40 to
80 hours.

I am definitely going to finish this code very soon. More importantly
the impossibility of creating an input that
bool Aborted_Because_Non_Halting_Behaviour_Detected(u32 P, u32 I)
cannot correctly decide meaning that:

"It only reports true in those cases where its input would not halt
unless it was aborted and its input was aborted"
and in all the others case is reports false.

I can't begin to understand why Mike Terry had such an awfully difficult
time with something as self-evident as this meaning.

People don't seem to be able to stay focused on this single crucially
important point:

Find an input where
bool Aborted_Because_Non_Halting_Behaviour_Detected(u32 P, u32 I)
gets the wrong answer or admit that there is no such input.

[Richard Damon]

On 10/27/20 5:27 PM, olcott wrote:
>
> That is flat out not true. In every single case where this halt decider
> decides that its input must be aborted its input would not otherwise
> halt: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)
>
> Also in every single case where the above function returns false its
> input has already halted.

Except that it DOES get the wrong answer for H_Hat, because H_Hat DOES
halt, at least if H give the answer that it aborted and H meets the
requirements of a decider to be always finite in execution.

The actual machine H_Hat was not aborted, just the simulation of the
model of H_Hat run inside H, and that simulation MUST by definition be
finite in execution whatever the program is that it is analyzing. You
can't 'blame' H_Hat for needing to be aborted, when the actual fault was
in you simulator.

Note, that your detrmination of 'Halting' is spurious, because it is a
function of what H did, and just shows a limitation of your chosen
method, By similar argument a poorly designed alternate H might just
decide that ALL machines had infinite behavior because H did in
analysing it so it aborts all machines. This makes 'Aborted' a
meaningless term.

Also, I suspect that you are going to have a problem handling a large
class of interesting programs which go towards or to infinite execution
but never have a repeated state. One example would be a program of the form:

define f(i)
while true:
if p(i) then Halt(i)
else i := i+1

where p(i) is some finite executing test on i to determine if it meets
some property, and we want to find the first such number at least as
large as the input to the machine.

p could be a prime test, it could be an impossible test (one that will
never be true so it needs to be aborted) or it could be a test that just
won't be meet until i gets very big, like is i equal to the factorial of
a googleplex.

This machine NEVER repeats state, so your design can't determine
infinite execution by looking for repeated state. Determining between
the last two cases likely exceeds your machines capability, or your
patience. This is why 'debug stepping' is NOT really a viable method of
determining halting.

[olcott]

On 10/27/2020 8:45 PM, Richard Damon wrote:
> On 10/27/20 5:27 PM, olcott wrote:
>>
>> That is flat out not true. In every single case where this halt decider
>> decides that its input must be aborted its input would not otherwise
>> halt: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)
>>
>> Also in every single case where the above function returns false its
>> input has already halted.
>
> Except that it DOES get the wrong answer for H_Hat, because H_Hat DOES
> halt, at least if H give the answer that it aborted and H meets the
> requirements of a decider to be always finite in execution.

void H_Hat(u32 M)
{
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
MOV_EAX_1 // Execution of M(M) has been aborted
else
{
MOV_EAX_0 // M(M) has halted
HERE: goto HERE;
}
HALT
}

01 int main()
02 {
03 u32 M = (u32)H_Hat;
04 H_Hat(M);
05 HALT
06 }

This line of H_Hat:
if (Aborted_Because_Non_Halting_Behavior_Detected(M, M))
invokes this function call
Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat).

The above function call returns true because its first H_Hat parameter
must be aborted on its input (the second H_Hat parameter).

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)
can never ever be shown to decide its input incorrectly.

Line 04 of main: H_Hat(M);
IS NOT INPUT TO
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)

[olcott]

On 10/27/2020 9:48 PM, Richard Damon wrote:

> H_Hat, the machine running, did NOT have infinite execution, therefore
> if H properly followed it through, it would have seen that it stopped.

No that is not true. I thought that might be true too the first time
that I analyzed this months ago. It turns out that unless H_Hat is
aborted it really never does stop running. If we simply wait and see
what H_Hat does it never ever stops running.

> You could say that was in infinite execution inside it, but that is
> within the implementation of H, which MUST NOT have infinite execution.
> That infinite execution only comes about due to a flawed choice of
> implementation of your halt detector, it is NOT inevitable and in fact
> your design can't handle a lot of machines that are interesting, because
> they may execute infinitely without every repeating a state.

There is not any input that can be shown to cause:

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)

to decide its input incorrectly.

I have already thought these things all the way through.

[André G. Isaak]

In that case, can you answer the following two extremely simple
questions which I asked in a previous post but which you did not answer

When we consider H(H_Hat, H_HAT) what are you claiming is the output of:

(1) Your ABNHBD contained in H?
(2) Your ABNHBD contained in the outermost instance of H_Hat?

[olcott]

bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat)
always returns true in the outermost instance of its recursive invocation.

It does that because that is the only correct return value for its
input. It always decides its input correctly and there is no input that
can be shown that it decides incorrectly.

Can you see how this completely answers your question?

[André G. Isaak]

So the answer to (2) is that it returns ABORTED.

That doesn't answer my question (1). What does your ABNHBD in H return?

André

> It does that because that is the only correct return value for its
> input. It always decides its input correctly and there is no input that
> can be shown that it decides incorrectly.
>
> Can you see how this completely answers your question?
>
>


--

[olcott]

Do you think that always means once in a while?

>
> André
>
>> It does that because that is the only correct return value for its
>> input. It always decides its input correctly and there is no input
>> that can be shown that it decides incorrectly.
>>
>> Can you see how this completely answers your question?
>>
>>
>
>


--

Copyright 2020 Pete Olcott

[André G. Isaak]

If the ABNHBD invoked in the outermost H_Hat returns ABORTED, that means
the outmost H_Hat does indeed halt, so if the ABNHBD invoked in H
returns ABORTED then it is getting the wrong answer!

André

[Richard Damon]

On 10/27/20 10:55 PM, olcott wrote:
>
> No that is not true. I thought that might be true too the first time
> that I analyzed this months ago. It turns out that unless H_Hat is
> aborted it really never does stop running. If we simply wait and see
> what H_Hat does it never ever stops running.

And that is the problem with your H, not with H_Hat.

H, by definition, must have finite execution. If we can supply H with
some input which it can't determine the right answer with finite
execution, then H is NOT a proper halting determinater. Your 'abort'
result is really, at least sometimes, an 'I don't know' answer, you
haven't proven that the supplied program will never halt (because you
haven't seen repeated state) or seen that it halted (which makes the
answer easy) so it punts and just aborts and makes a bold statement,
that can be wrong.

It is theroretically possible, within the definition of H, that all H is
is a finite regex on the input machine, or some magic hash. None of
these can possibly have this infinite recursion issue, so H can't
'blame' the recursion on H_Hat, so can't claim that H_Hat 'was aborted'.

Again part of the issue is you want to change the question, but if you
do, you can't apply your results to the original question. The ONLY
question of a Halt Decider is that H(M,N) will indicate in finite time,
what will happen if we run M(N). It doesn't matter if H(M,N) releases
the 7 plagues, if running M(N) doesn't, then that is not part of the answer.

It is clear, that from the answer you say H(H_Hat, H_Hat) will produce,
that is 'Will Not Halt' (that you call 'Aborted') that when you apply
that to the run of H_Hat(H_Hat), and that machine terminates in finite
time, the H(H_Hat, H_Hat) got the answer wrong.

The question is NOT about what happened to the emulated M(N), because
the problem doesn't assume emulation (in fact it can be shown that
emulation can't be a universal solution), but what would happen to a
REAL M(N) run.

It is like disproving that you can't trisect an arbitrary angle with
compass and straight edge, by saying you can if the angle happens to be
a right angle. Different Question, different results.

The original, classical, halting problem statement has useful
implication in the theory of Mathematics and Logic. Your modified
question, I don't know of a use.

Yes, you can disproof Linz, if you change to domain that you are
applying Linz to. It has LONG been know that if you don't need to be a
UNIVERSAL halt determinater, that there are a number of classes a Turing
machines that you can determine if they will halt or not. The key here
is that they can't handle any arbitrary Turing Machine. In particular,
the easiest case is for machines that stay bounded over there full
execution of the problem. It is the unboundedness that causes the
problems, and is where you seem to have the issues, and where other
aspects you have problems with, like incompleteness, come in.

[Mostowski Collapse]

In what parallel universum does your nonsense
have anything to do with Prolog? You fucking
moron spammer Richard Damon?

No need to post responses on comp.lang.prolog.

Richard Damon schrieb:
> bla bla not a bit of Prolog bla bla

[Mostowski Collapse]

[David Brown]

Even better - would all the sane people in these pointless "olcott"
threads /please/ remove the language groups from the replies? They are
not remotely relevant or on-topic for C, C++ or Prolog. I don't think
they are of much interest for theoretical computation either, but as I
don't follow comp.theory, I can't be sure.

We all know that this "Olcott" person is a manic poster and can't be
stopped. But Richard Damon, and some of the others in these threads, is
a reasonable person. If you folks want to discuss Olcott's ideas, make
sure you remove all non-relevant newsgroups from the posts and
follow-ups. And if he insists on putting them back in, then please
boycott him altogether.

[olcott]

bool Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat);
Never decides its input incorrectly. No dishonest dodge will show this.

[olcott]

On 10/28/2020 4:38 AM, Alan Mackenzie wrote:

> In comp.theory olcott <No...@nowhere.com> wrote:
>> On 10/27/2020 4:11 PM, Mike Terry wrote:
>>> On 27/10/2020 20:34, André G. Isaak wrote:
>>>> On 2020-10-27 14:13, olcott wrote:
>

> [ .... ]

>
>>>>> I have redefined the impossible halt decider into a
>>>>> NON_HALTING_DECIDER that divides all of its inputs into:
>>>>> (a) INPUT_PROGRAM_ABORTED_BECAUSE_NON_HALTING_BEHAVIOR_DETECTED
>>>>> (b) INPUT_PROGRAM_HAS_TERMINATED
>
>>>>> As you can see from (b) the NON_HALTING_DECIDER is still a halt
>>>>> decider.
>
>>>> If your (a) and (b) are simply new names for 'doesn't halt' and
>>>> 'halts', then this is just as subject to Linz's proof as any other
>>>> purported halt decider.
>
>>>> If they are not, and there are cases where 'aborted' and 'halted'
>>>> don't mean exactly the same thing, then what you have isn't a halt
>>>> decider at all.
>
>>> Exactly, and in another thread PO has confirmed that 'aborted'
>>> includes cases where the calculation in question halts.
>
>> That is flat out not true. In every single case where this halt decider
>> decides that its input must be aborted its input would not otherwise
>> halt: bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)
>
>> Also in every single case where the above function returns false its
>> input has already halted.
>

> That leaves, of course, the cases where the function never returns,
> neither halting nor detecting "non-halting behaviour".

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)

It cannot be shown that it ever decides its input incorrectly.

Furthermore although very complex examples can be provided, none of
these examples can be shown to be undecidable.

[olcott]

On 10/28/2020 8:04 AM, Richard Damon wrote:
> On 10/27/20 10:55 PM, olcott wrote:
>>
>> No that is not true. I thought that might be true too the first time
>> that I analyzed this months ago. It turns out that unless H_Hat is
>> aborted it really never does stop running. If we simply wait and see
>> what H_Hat does it never ever stops running.
>
> And that is the problem with your H, not with H_Hat.
>
> H, by definition, must have finite execution. If we can supply H with
> some input which it can't determine the right answer with finite
> execution, then H is NOT a proper halting determinater. Your 'abort'
> result is really, at least sometimes, an 'I don't know' answer, you
> haven't proven that the supplied program will never halt (because you
> haven't seen repeated state) or seen that it halted (which makes the
> answer easy) so it punts and just aborts and makes a bold statement,
> that can be wrong.

I did not answer these posts this morning so that I could work on
providing the example program.

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 M, u32 M).
There is no input that can be proved to be undecidable for the above
function.

> It is theroretically possible, within the definition of H, that all H is
> is a finite regex on the input machine, or some magic hash. None of
> these can possibly have this infinite recursion issue, so H can't
> 'blame' the recursion on H_Hat, so can't claim that H_Hat 'was aborted'.

I have defined a Non_Halting decider that has no input that can be shown
to be undecidable. It is possible to define this differently so that it
is no longer a decider for all of its input. This of course would form
no rebuttal of my definition at all.

> Again part of the issue is you want to change the question, but if you
> do, you can't apply your results to the original question. The ONLY
> question of a Halt Decider is that H(M,N) will indicate in finite time,
> what will happen if we run M(N). It doesn't matter if H(M,N) releases
> the 7 plagues, if running M(N) doesn't, then that is not part of the answer.

I think that the only way that I changed the question is that the halt
decider became a non-halting decider. It Accepts non-halting programs
and Rejects halting programs.

> It is clear, that from the answer you say H(H_Hat, H_Hat) will produce,
> that is 'Will Not Halt' (that you call 'Aborted') that when you apply
> that to the run of H_Hat(H_Hat), and that machine terminates in finite
> time, the H(H_Hat, H_Hat) got the answer wrong.

You may not be able to understand that my analysis is correct until I
have fully operational code. I worked on this all day.

> The question is NOT about what happened to the emulated M(N), because
> the problem doesn't assume emulation (in fact it can be shown that
> emulation can't be a universal solution), but what would happen to a
> REAL M(N) run.

You may not be able to understand that my analysis is correct until I
have fully operational code. I worked on this all day.

This function can not be shown to have any undecidable inputs:

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)

int main()
{
H_Hat(H_Hat);
}

Would never terminate unless this function aborts it input:
Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat)

> It is like disproving that you can't trisect an arbitrary angle with
> compass and straight edge, by saying you can if the angle happens to be
> a right angle. Different Question, different results.
>
> The original, classical, halting problem statement has useful
> implication in the theory of Mathematics and Logic. Your modified
> question, I don't know of a use.

I defined a NON_HALT decider that always Accepts its input if its input
would not halt and Rejects its input if its input would halt.

> Yes, you can disproof Linz, if you change to domain that you are
> applying Linz to. It has LONG been know that if you don't need to be a
> UNIVERSAL halt determinater, that there are a number of classes a Turing
> machines that you can determine if they will halt or not. The key here
> is that they can't handle any arbitrary Turing Machine. In particular,
> the easiest case is for machines that stay bounded over there full
> execution of the problem. It is the unboundedness that causes the
> problems, and is where you seem to have the issues, and where other
> aspects you have problems with, like incompleteness, come in.
>

I defined a NON_HALTING decider that always Accepts NON_HALTING input
and Rejects HALTING input.

[olcott]

This function can not be shown to have any undecidable inputs:
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)

int main()
{
H_Hat(H_Hat);
}

Can you tell that the outer H_Hat(H_Hat) in main() is not an input to:
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I) ???

When H_Hat(H_Hat) invokes:
Aborted_Because_Non_Halting_Behavior_Detected(H_Hat, H_Hat)
it would never terminate unless the H_Hat input to H_Hat was aborted.

So this statement is literally true:

This function can not be shown to have any undecidable inputs:
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I)

because the outer H_Hat in main() IS NOT AN INPUT !!!

[olcott]

On 10/29/2020 1:45 AM, André G. Isaak wrote:

> But this discussion is about Linz's H. When you remove H from the
> picture as you do above, you are no longer discussing Linz's proof.
>
> When H_Hat is an input to H, the ABNHBD invoked in *H* gets the wrong
> answer.
>
> André
>
> [groups trimmed]
>

On the top of page 320 H_Hat is applied to itself:
http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf

[olcott]

On 10/29/2020 1:59 AM, Alan Mackenzie wrote:
> In comp.theory olcott <No...@nowhere.com> wrote:
>> On 10/28/2020 4:38 AM, Alan Mackenzie wrote:
>>> In comp.theory olcott <No...@nowhere.com> wrote:
>>>> On 10/27/2020 4:11 PM, Mike Terry wrote:
>

> [ .... ]

>
>>>>> Exactly, and in another thread PO has confirmed that 'aborted'
>>>>> includes cases where the calculation in question halts.
>
>>>> That is flat out not true. In every single case where this halt
>>>> decider decides that its input must be aborted its input would not
>>>> otherwise halt: bool
>>>> Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)
>
>>>> Also in every single case where the above function returns false its
>>>> input has already halted.
>
>>> That leaves, of course, the cases where the function never returns,
>>> neither halting nor detecting "non-halting behaviour".
>
>> bool Aborted_Because_Non_Halting_Behavior_Detected(u32 N, u32 M)
>> It cannot be shown that it ever decides its input incorrectly.
>

> You're like a loop of tape. You're all output with no input. Why don't
> you actually consider the points people are making?

All but one of the points that people are making have been shown to be
incorrect and people simply ignored that they have been proved wrong.
I am showing that the remaining unaddressed point is incorrect too (see
below).

> Let me put the point to you again. Even assuming A_B_N_H_B_D never
> returns a wrong answer, there are cases in which it will return _no_
> answer at all; it will carry on executing without ever stopping or
> displaying "non-halting behaviour" (whatever that means).

This cannot be proven. If a machine is proven to never repeat the same
state and this machine is also proven to never terminate a very smart
halt decider could replicate the proof of non-termination, stop
executing its input and report non-halting.

Alternatively it cannot be proven that there is any program that meets
those specs thus it cannot be proven that a counter-example exists.

>> Furthermore although very complex examples can be provided, none of
>> these examples can be shown to be undecidable.
>

> Well, the burden of proof is on your side. You must show that there are
> no such examples, complex or not. This will necessarily involve you
> getting to know some mathematics. Hint: this has been shown not to be
> possible.

My categorical has already been provided. I just addressed the last
unaddressed point.

[olcott]

If it can be proved that such a counter-example exists then it is not a
counter-example, otherwise it cannot be proved that such a counter
example exists.

Any program that can be proved does not halt can be decided on the basis
of this proof.

Every counter-example must be provably undecidable.

>
>>> Furthermore although very complex examples can be provided, none of
>>> these examples can be shown to be undecidable.
>>
>> Well, the burden of proof is on your side.  You must show that there are
>> no such examples, complex or not.  This will necessarily involve you
>> getting to know some mathematics.  Hint: this has been shown not to be
>> possible.
>
> My categorical has already been provided. I just addressed the last
> unaddressed point.

My categorical PROOF has already been provided. I just addressed the

[Mostowski Collapse]

For gods sacke stop cross posting on 4 newsgroups.

Especially comp.lang.prolog doesn't make much sense.

RAM/RASP is probably best housed on comp.theory.

olcott schrieb:
> I am a complete imbecial spammer

[Joe Pfeiffer]

Mostowski Collapse <janb...@fastmail.fm> writes:

> For gods sacke stop cross posting on 4 newsgroups.
>
> Especially comp.lang.prolog doesn't make much sense.
>
> RAM/RASP is probably best housed on comp.theory.

Many people have asked this, and have made no impact on him. The best
you can do is not interact with him on newsgroups where his crackpottery
is off-topic (sadly, to the best of my knoweldge there is no
alt.crackpot newsgroup, as that is the only one where he would really be
on-topic).

[Mike Terry]

There IS an alt.crackpot newsgroup! :) Of course PO will not post there.

Anyway, the obvious solution to all this is that if someone doesn't want
to be bothered by PO crackpottery in a particular newsgroup, they should
just filter PO's posts from those groups. I find that "ignore
subthread" works best, as it also ignores any replies to PO.

Mike.

[olcott]

On 10/29/2020 9:41 AM, Andy Walker wrote:

> On 29/10/2020 12:18, olcott wrote:
>> On the top of page 320 H_Hat is applied to itself:
>

>     No, it isn't.  It's [putatively] applied to a description
> of itself.  As you have been told several times.  Thus, there is
> /no/ recursion, actual or implicit, finite or infinite, involved.
> If you would, as I have suggested, distinguish executables from
> sources, you would not make this /repeated/ mistake.

If we simulate the debug trace based on source code or have a
description language that is executable machine code there is infinite
recursion in either case, yet former case is much more clumsy.

The description language of the x86utm system is x86 machine language
that is disassembled into human readable form on the fly only for the
benefit of humans.

It turns out to be the case that analyzing the control flow of a program
is much easier in machine language because all of the control flow is
already in the form of a directed graph with integer labeled nodes.

>     You will also perhaps note that Linz gives a quite different
> proof on that /same page/.
>

x86 language ≡ von Neumann architecture ≡ UTM ≡ RASP Machine

The RASP is a random-access machine (RAM) model that, unlike the RAM,
has its program in its "registers" together with its input. The
registers are unbounded (infinite in capacity); whether the number of
registers is finite is model-specific. Thus the RASP is to the RAM as
the Universal Turing machine is to the Turing machine. The RASP is an
example of the von Neumann architecture whereas the RAM is an example of
the Harvard architecture.

https://en.wikipedia.org/wiki/Random-access_stored-program_machine

[olcott]

On 10/29/2020 8:30 AM, André G. Isaak wrote:

> Which has absolutely nothing to do with the point I am making. The basis
> of the Linz proof is H applied to (H_Hat, H_Hat). Your 'solution'
> doesn't resolve the contradiction. Your H gets your H_Hat case wrong.
>
> André
>

The one case that you point to when I claim that:
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I);
never decides any of its inputs incorrectly

is not a case of
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I);
deciding its inputs. This is why I called this case a dishonest dodge.

It is like I say that cats do not bark and you respond with of course
cats bark because dogs bark all the time.

[olcott]

Sure these kind of ad homimen attacks are the first resort of clueless
wonders and the last resort of people like yourself that diligently try
to find a legitimate rebuttal.

Failing at that these people resort to ad hominem attacks because their
only interest was in forming one kind of rebuttal or another and they
never had any interest in forming mutual understanding.

[André G. Isaak]

You refuse to give clear answers. I've asked you numerous times

If you apply your H to (H_hat, H_hat),

(1) What does the ABNHBD function called from with H return?
(2) What does the ABNHBD function called from within the outermost H_hat
return?

The only clear and direct answers to either of the above questions is
either ABORTED or TERMINATED NORMALLY (or Not Aborted or whatever you
call it).

You've refused to answer both of these questions directly when asked.
You have on occasion given a very indirect, wishy-washy response which
hints at the answer to one or the other, but never both at the same time.

If you want to claim that your ABNHBD never decides any of its inputs
incorrectly, then can you please provide a DIRECT answer to the above to
two questions. Then I can explain why your claim is wrong.

> is not a case of
> bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P, u32 I);
> deciding its inputs. This is why I called this case a dishonest dodge.

How exacly would either of the above not be a cases of ABNHBD deciding
its inputs? Both your H and your H_hat contain a copy of ABNHBD. Both
take an input. Both need to decide that input.

[olcott]

I know that you are not too stupid to understand this:
This function always provides the correct return value for its input
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P u32 I)

I know that you are not too stupid to understand this:
This function always provides the correct return value for its input
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P u32 I)

I know that you are not too stupid to understand this:
This function always provides the correct return value for its input
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P u32 I)

I know that you are not too stupid to understand this:
This function always provides the correct return value for its input
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P u32 I)

I know that you are not too stupid to understand this:
This function always provides the correct return value for its input
bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P u32 I)

--
Copyright 2020 Pete Olcott

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

[Chris Vine]

On Thu, 29 Oct 2020 11:13:13 -0500
olcott <No...@NoWhere.com> wrote:
[snip]

> Failing at that these people resort to ad hominem attacks because their
> only interest was in forming one kind of rebuttal or another and they
> never had any interest in forming mutual understanding.

People resort to mostly polite requests for you to stop your
unacceptable posting activities because (i) your posts are irrelevant
to the comp.lang groups, and (ii) people in general have no interest in
the halting problem. To that extent you are probably right that people
have no interest in forming a mutual understanding with you, but why
should they? To keep provoking people until they share your off-topic
obsessions seems counter productive. They don't.

The truth is that your weird posting practices and unwillingness to
behave reasonably towards others shows that are mentally disturbed, with
an obsessive and probably (given your total disregard of everyone else)
narcissistic disorder. Why you want to display yourself in this way is
anyone's guess: probably you just cannot stop yourself.

However there is hope. You said in an earlier posting that you would
stop your posting if people agree with you. On that basis I am happy
to say I agree with you. How many other people have to say to same to
get you to stop? I would be happy to try and put together the
necessary collection. Would, say, 4 people who say they agree with you
be enough?

[Manfred]

The problem is that some repliers use poor newsreaders that break thread
ID consistency, and their replies manage to get through the "ignore
subthread" killfile directive.
So, the advise still holds that those repliers should better remove the
language groups from their replies, unless they aim at landing into the
killfile themselves.

[olcott]

On 10/29/2020 12:58 PM, André G. Isaak wrote:

> And yet you refuse to actually answer the two above questions...
>
> André
>

If every single time this function decides its input correctly

bool Aborted_Because_Non_Halting_Behavior_Detected(u32 P u32 I)

then

(a) Called from H() it decides its input correctly.
(b) Called from H_Hat() it decides its input correctly.
(c) Called from Late_To_Dinner() it decides it input correctly.

I am sure that you understood this and are merely trying to get away
with playing head games.

Introducing Homey D. Clown: Homie Don't Play Dat
https://www.youtube.com/watch?v=_QhuBIkPXn0

[Nikolaj Lazic]

Dana Thu, 29 Oct 2020 08:48:15 -0600, Joe Pfeiffer <pfei...@cs.nmsu.edu> napis'o:

Is this the same PO?
https://groups.google.com/g/comp.theory/c/0i86aQ3WPaA
https://www.bailbondshq.com/nebraska/sarpy-inmate-OLCOTTJr/20150325001

[olcott]

On 10/29/2020 1:20 PM, Chris Vine wrote:
> On Thu, 29 Oct 2020 11:13:13 -0500
> olcott <No...@NoWhere.com> wrote:
> [snip]
>> Failing at that these people resort to ad hominem attacks because their
>> only interest was in forming one kind of rebuttal or another and they
>> never had any interest in forming mutual understanding.
>
> People resort to mostly polite requests for you to stop your
> unacceptable posting activities because (i) your posts are irrelevant
> to the comp.lang groups, and (ii) people in general have no interest in
> the halting problem. To that extent you are probably right that people
> have no interest in forming a mutual understanding with you, but why
> should they? To keep provoking people until they share your off-topic
> obsessions seems counter productive. They don't.
>
> The truth is that your weird posting practices and unwillingness to
> behave reasonably towards others shows that are mentally disturbed, with
> an obsessive and probably (given your total disregard of everyone else)
> narcissistic disorder. Why you want to display yourself in this way is
> anyone's guess: probably you just cannot stop yourself.

This is the culmination of my life's work and I currently have have no
other reasonable alternatives than cross-posting to less relevant
groups. This is the first phase of review. As soon as this phase
completes I will be seeking reviews outside of USENET.

If I had a PhD in computer science and had extensive experience
publishing to academic journals I would not have to be concerned that my
work would be rejected out-of-hand without review entirely on the basis
of style versus substance issues.

> However there is hope. You said in an earlier posting that you would
> stop your posting if people agree with you. On that basis I am happy
> to say I agree with you.
> How many other people have to say to same to
> get you to stop? I would be happy to try and put together the
> necessary collection. Would, say, 4 people who say they agree with you
> be enough?

Any proof that I am correct that would be accepted as correct by an
academic journal will be sufficient.

--
Copyright 2020 Pete Olcott

[Mostowski Collapse]

For gods sacke stop cross posting on 4 newsgroups.

Especially comp.lang.prolog doesn't make much sense.

RAM/RASP is probably best housed on comp.theory.

olcott schrieb:
> I am a brainless mud turtle

[Chris Vine]

On Thu, 29 Oct 2020 13:38:52 -0500
olcott <No...@NoWhere.com> wrote:
[snip]

> Any proof that I am correct that would be accepted as correct by an
> academic journal will be sufficient.

So you want others to provide the proof of the correctness of your
ideas because you are unable to provide it yourself? And until then
you intend to annoy them into doing this task for you by unacceptable
posting practices?

Surely not: you must inadvertently be being dishonest. Given your
interest in logic you must surely understand how ridiculous that is.

Please ponder your absurdness and reconsider my offer of agreement.

[Mike Terry]

Interesting - I'm not familiar with that problem. Perhaps you give me a
couple of recent examples of such responses, and the newsgroup where
you're seeing them? (msgid values would be enough)

On the sci.math newsgroup I use ignore subthread fairly extensively and
it pretty much eliminates posts by the well-known trolls/crackpots.
Sometimes I think "why am I seeing this post about TrollPoster who's in
my filter?". But when I look closer I see it's not down to poor
newsreaders - typically it is either that the post is merely /about/
TrollPoster and not actually a reply to her, or it is a reply to a
TrollPoster post from such a long time ago that it's not recorded in my
local newsreader. (Neither of these is down to posters using poor
newsreaders.)

Mike.

[olcott]

The prior respondent had indicated that they specifically intended to be
dishonest. My reply was on that basis.

[Chris Vine]

On Thu, 29 Oct 2020 14:16:44 -0500
olcott <No...@NoWhere.com> wrote:
> On 10/29/2020 1:46 PM, Chris Vine wrote:
> > On Thu, 29 Oct 2020 13:38:52 -0500
> > olcott <No...@NoWhere.com> wrote:
> > [snip]
> >> Any proof that I am correct that would be accepted as correct by an
> >> academic journal will be sufficient.
> >
> > So you want others to provide the proof of the correctness of your
> > ideas because you are unable to provide it yourself? And until then
> > you intend to annoy them into doing this task for you by unacceptable
> > posting practices?
> >
> > Surely not: you must inadvertently be being dishonest. Given your
> > interest in logic you must surely understand how ridiculous that is.
> >
> > Please ponder your absurdness and reconsider my offer of agreement.
> >
>
> The prior respondent had indicated that they specifically intended to be
> dishonest. My reply was on that basis.

Please stop avoiding the question in such a manipulative way.

Would four people saying they agree with you be enough to stop you
posting to comp.lang.c++, given that you now seem agree that it is
unacceptable to expect others to provide the proofs that you are unable
to provide yourself? (Were others to do the work, you would be robbed
of the recognition that you think you so richly deserve: you would
not even be an asterisk.)

[Mike Terry]

Both are PO.
Mike.

[David Brown]

The cause of this is not a problem with newsreaders - it is a problem
with Olcott. Roughly speaking (assuming I understand it myself), it
goes like this.

First, he makes a cross-posting to several off-topic groups. Then
someone tries to be helpful by replying to him with these extra groups
removed, leaving only comp.theory (this is normally the correct way to
handle bad cross-posting). But when Olcott replies again, he adds the
off-topic groups once more. As far as anyone (or any newsreader)
viewing these other groups is concerned, that reply from Olcott has come
from nowwhere - it is not a reply to anything in the group, and it
therefore counts as a new thread.

[Ben Bacarisse]

David Brown <david...@hesbynett.no> writes:

> On 29/10/2020 19:55, Mike Terry wrote:
>> On 29/10/2020 18:20, Manfred wrote:
>>> On 10/29/2020 4:17 PM, Mike Terry wrote:

<cut>
>>>> ... I find that "ignore

>>>> subthread" works best, as it also ignores any replies to PO.
>>>

>>> The problem is that some repliers use poor newsreaders that break thread
>>> ID consistency, and their replies manage to get through the "ignore
>>> subthread" killfile directive.

<cut>

>> Interesting - I'm not familiar with that problem.  Perhaps you give me a
>> couple of recent examples of such responses, and the newsgroup where
>> you're seeing them?  (msgid values would be enough)

<cut>

> The cause of this is not a problem with newsreaders - it is a problem
> with Olcott. Roughly speaking (assuming I understand it myself), it
> goes like this.
>
> First, he makes a cross-posting to several off-topic groups. Then
> someone tries to be helpful by replying to him with these extra groups
> removed, leaving only comp.theory (this is normally the correct way to
> handle bad cross-posting). But when Olcott replies again, he adds the
> off-topic groups once more. As far as anyone (or any newsreader)
> viewing these other groups is concerned, that reply from Olcott has come
> from nowwhere - it is not a reply to anything in the group, and it
> therefore counts as a new thread.

That is a problem with newsreaders. They should be able to see that
these "replies from nowhere" are indeed all in one thread -- a thread
that simply has some missing posts. This was normal in the old days
with slow and sometimes unreliable feeds, and old newsreaders can
usually fill in a thread as posts arrive, and happily work with threads
that are sparse. They should be able to do this even in when the
subject header gets edited. Maybe some newer ones can't?

--
Ben.

[Ralf Goertz]

Am Fri, 30 Oct 2020 11:02:08 +0100
schrieb David Brown <david...@hesbynett.no>:

> The cause of this is not a problem with newsreaders - it is a problem
> with Olcott. Roughly speaking (assuming I understand it myself), it
> goes like this.
>
> First, he makes a cross-posting to several off-topic groups. Then
> someone tries to be helpful by replying to him with these extra groups
> removed, leaving only comp.theory (this is normally the correct way to
> handle bad cross-posting). But when Olcott replies again, he adds the
> off-topic groups once more. As far as anyone (or any newsreader)
> viewing these other groups is concerned, that reply from Olcott has
> come from nowwhere - it is not a reply to anything in the group, and
> it therefore counts as a new thread.

But usually there are many references in the header of a deep thread
message. In yours for instance they are:

References: <4o2dnVXM88fR6AXC...@giganews.com>
<rneee3$d0j$2...@solani.org> <1bd011c...@pfeifferfamily.net>
<3c6dndQ5KJWQQAfC...@brightview.co.uk>
<rnf161$m68$1...@gioia.aioe.org>
<x_idnannRP6KjQbC...@brightview.co.uk>

The last of these is the one you replied to and is also mentioned in the
<In-Reply-To:> field. Maybe it's just that some newsreaders only care
about this field and therefore are unable to put the message in context
when it is absent in that group.

[Jorgen Grahn]

On Fri, 2020-10-30, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
...

> As far as anyone (or any newsreader)
>> viewing these other groups is concerned, that reply from Olcott has come
>> from nowwhere - it is not a reply to anything in the group, and it
>> therefore counts as a new thread.
>
> That is a problem with newsreaders. They should be able to see that
> these "replies from nowhere" are indeed all in one thread -- a thread
> that simply has some missing posts. This was normal in the old days
> with slow and sometimes unreliable feeds, and old newsreaders can
> usually fill in a thread as posts arrive, and happily work with threads
> that are sparse. They should be able to do this even in when the
> subject header gets edited.

Yes. It's simple: the References: header has[1] an incomplete list of
postings on the path back to the original. Given a set of postings
(with Message-Id and References headers) you can build a set of trees,
with gaps if necessary.

The hardest part may be protecting yourself from malicious postings
which try to form a non-tree DAG, or introduce cycles, or something.

> Maybe some newer ones can't?

/Jorgen

[1] From memory. The RFC would tell.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .