On recursion and infinite recursion (reprise)

Mr Flibble

unread,

May 2, 2022, 11:47:35 AM5/2/22

to

Not all infinitely recursive definitions are invalid however infinitely
recursive definitions that arise out of a category error (as is the
case with the halting problem) are invalid.

The halting problem (as currently defined) is invalid due to the
invalid "impossible program" [Strachey, 1965] that is actually
impossible due to the category error present in its definition and
*not* because of any function call-like recursion; confusion between
these two types of recursion are why Olcott is having difficulty
communicating his ideas with the rest of you shower.

The categories involved in the category error are the decider and that
which is being decided. Currently extant attempts to conflate the
decider with that which is being decided are infinitely
recursive and thus invalid.

/Flibble

olcott

unread,

May 2, 2022, 12:18:40 PM5/2/22

to

On 5/2/2022 10:47 AM, Mr Flibble wrote:
> Not all infinitely recursive definitions are invalid however infinitely
> recursive definitions that arise out of a category error (as is the
> case with the halting problem) are invalid.
>

It seems to me that all infinitely recursive definitions are invalid and
I am having an excellent dialogue with some Prolog folks about this in
comp.lang.prolog.

> The halting problem (as currently defined) is invalid due to the
> invalid "impossible program" [Strachey, 1965] that is actually
> impossible due to the category error present in its definition and
> *not* because of any function call-like recursion; confusion between
> these two types of recursion are why Olcott is having difficulty
> communicating his ideas with the rest of you shower.
>

I created the x86 operating system taking at least a man-year so that I
could encode the HP counter-example P in C/x86 and then create a halt
decider H in C that examines the behavior of its correct simulation of P.

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

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

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
...[000009d6][00211368][0021136c] 55 push ebp // enter P
...[000009d7][00211368][0021136c] 8bec mov ebp,esp
...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
...[000009dc][00211364][000009d6] 50 push eax // Push P
...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][00211360][000009d6] 51 push ecx // Push P
...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
...[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
...[000009dc][0025bd8c][000009d6] 50 push eax // Push P
...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
...[000009e0][0025bd88][000009d6] 51 push ecx // Push P
...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

It is clear that the input to H(P,P) specifies infinitely nested
simulation to H.

> The categories involved in the category error are the decider and that
> which is being decided. Currently extant attempts to conflate the
> decider with that which is being decided are infinitely
> recursive and thus invalid.
>
> /Flibble
>

I already applied your idea of category error to Gödel's Incompleteness
and Tarski Undefinability. In both of these cases the Gödel H and the
Tarski p are incorrectly placed in the category of truth bearer / logic
sentence. They cannot be correctly evaluated because they are
semantically incorrect.

Now in comp.lang.prolog we are getting Prolog to agree that they are
semantically ill-formed.

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

Ben

unread,

May 2, 2022, 12:39:13 PM5/2/22

to

olcott <polc...@gmail.com> writes:

> It is clear that the input to H(P,P) specifies infinitely nested
> simulation to H.

What two pointers must be passed to H for H to tell up about the halting
of P(P)? If H can't report on the halting of the computation P(P) it is
not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.

You have nowhere to go with H, hence your switching topics to being
wrong about Gödel again.

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

olcott

unread,

May 2, 2022, 4:28:12 PM5/2/22

to

On 5/2/2022 11:39 AM, Ben wrote:
> olcott <polc...@gmail.com> writes:
>
>> It is clear that the input to H(P,P) specifies infinitely nested
>> simulation to H.
>
> What two pointers must be passed to H for H to tell up about the halting
> of P(P)? If H can't report on the halting of the computation P(P) it is
> not a halt decider, and you have already told use that H(P,P) == false
> and that P(P) halts.

If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final
states.

>
> You have nowhere to go with H, hence your switching topics to being
> wrong about Gödel again.
>

That you expect a halt decider to compute the mapping from non-inputs is
a little nuts when you know that deciders can't possibly do this.

It turns out that I can create a whole TM interpreter from scratch
quicker than I can learn the extraneous complexity of the TM Interpreter
http://www.lns.mit.edu/~dsw/turing/turing.html

It will have the same eight-bit quintuples of the TM, The Turing Machine
Interpreter. These will be at the beginning of the file, followed by
BEGIN_TAPE on a line by itself. Followed by the initial tape as
contiguous ASCII characters.

It will output a full execution trace. The only parameter to the command
line system with be filename.tm. This system is easily extended to
16-bits or 32-bits. These larger systems will use 4-8 hex digits for
state / character representation.

Richard Damon

unread,

May 2, 2022, 6:32:16 PM5/2/22

to

Except that the "impossible program" isn't part of the definition of the
Halting Problem.

By your definition, I suspect much of Mathematics becomes a category error.

If you are willing to say that this is a natural result of your logic
system, fine, but just remember that consequence, which actually says
your logic doesn't refute Gobel, as the Theorm specifically requires
working in a field that supports some minimums that your logic doesn't
handle.

Mr Flibble

unread,

May 2, 2022, 6:38:14 PM5/2/22

to

On Mon, 2 May 2022 18:32:16 -0400
Richard Damon <Ric...@Damon-Family.org> wrote:

> On 5/2/22 11:47 AM, Mr Flibble wrote:
> > Not all infinitely recursive definitions are invalid however
> > infinitely recursive definitions that arise out of a category error
> > (as is the case with the halting problem) are invalid.
> >
> > The halting problem (as currently defined) is invalid due to the
> > invalid "impossible program" [Strachey, 1965] that is actually
> > impossible due to the category error present in its definition and
> > *not* because of any function call-like recursion; confusion between
> > these two types of recursion are why Olcott is having difficulty
> > communicating his ideas with the rest of you shower.
> >
> > The categories involved in the category error are the decider and
> > that which is being decided. Currently extant attempts to conflate
> > the decider with that which is being decided are infinitely
> > recursive and thus invalid.
> >
> > /Flibble
> >
>
> Except that the "impossible program" isn't part of the definition of
> the Halting Problem.

It is according to [Wikipedia, 2022].

/Flibble

Richard Damon

unread,

May 2, 2022, 6:46:01 PM5/2/22

to

Nope, you comprehend worse that PO.

Note, and Encyclopedic entery, like Wikipedia, is NOT just a definition
but a full article explaining the subject.

Maybe if you look for a FORMAL source, that states what is the ACTUAL
definition, you would learn something.

Mr Flibble

unread,

May 2, 2022, 6:47:15 PM5/2/22

to

On Mon, 2 May 2022 18:46:00 -0400

If Wikipedia is wrong then correct it and have your corrections
reviewed; until then please shut the fuck up.

/Flibble

Ben

unread,

May 2, 2022, 7:10:49 PM5/2/22

to

olcott <polc...@gmail.com> writes:

> On 5/2/2022 11:39 AM, Ben wrote:
>> olcott <polc...@gmail.com> writes:
>>
>>> It is clear that the input to H(P,P) specifies infinitely nested
>>> simulation to H.
>> What two pointers must be passed to H for H to tell up about the halting
>> of P(P)? If H can't report on the halting of the computation P(P) it is
>> not a halt decider, and you have already told use that H(P,P) == false
>> and that P(P) halts.
>
> If H can report on the halting of non-input P(P) then it is not a
> decider because deciders only compute the mapping from inputs to final
> states.

TM deciders compute mappings from inputs to final states /according to
some property of the inputs/ -- whether the input represents, for
example, an even number, a prime number or a halting computation.

According to you there is no "input" (in reality a pair of pointers)
that represents the halting computation P(P). Why should anyone care
about this H if it does not decide what we want -- the halting of the
function call represented by the two arguments to H? Whatever H is
actually deciding is not interesting.

Also, I wonder why you wasted so much time justifying the fact that
H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
even supposed to be deciding the halting P(P). Well, we know, of
course. You realised you were in a hole so you started to dig sideways.
You used to know that H(X,Y) had to decide the halting of X(Y). You're
now pretending it never did!

> That you expect a halt decider to compute the mapping from non-inputs
> is a little nuts when you know that deciders can't possibly do this.

Don't be silly. They decide properties of inputs -- parity, halting and
so on. You'd know this if you'd done even the warm-up exercises I set.
How are they coming along? It looks like you have found an excuse to
bail out again:

> It turns out that I can create a whole TM interpreter from scratch
> quicker than I can learn the extraneous complexity of the TM
> Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html

I doubt it. But I suppose you think that's a reasonable excuse. Of
course, some of us remember you saying writing such a thing would take
about a week three years ago. I remember wondering how such a simple
program could take you a week to write.

Of course you don't need an interpreter to write E or specify P, but you
must find some excuse for bailing out.

Richard Damon

unread,

May 2, 2022, 7:16:05 PM5/2/22

to

It isn't that the article is "Wrong", it is a fairly good Encyclpedic
article. It just is that the first two paragraphs aren't all a
definition, and it doesn't say they are.

Mr Flibble

unread,

May 2, 2022, 7:30:46 PM5/2/22

to

On Mon, 2 May 2022 19:16:03 -0400

The first two paragraphs define the halting problem as that is what the
currently extant halting problem "proofs" are predicated on (and why
they are invalid).

/Flibble

olcott

unread,

May 2, 2022, 8:35:42 PM5/2/22

to

I think that the problem is that Richard has disagreeably as his highest
priority, thus doesn't really give a rat's ass for the truth. An

An impossible program C. Strachey
The Computer Journal, Volume 7, Issue 4, January 1965, Page 313,
Published: 01 January 1965
https://academic.oup.com/comjnl/article/7/4/313/354243

It is very common knowledge that the Wikipedia description is true and
this is affirmed in Sipser.

For any program f that might determine if programs halt, a
"pathological" program g, called with some input, can pass its own
source and its input to f and then specifically do the opposite of what
f predicts g will do. https://en.wikipedia.org/wiki/Halting_problem

Now we construct a new Turing machine D with H as a subroutine. This new
TM calls H to determine what M does when the input to M is its own
description ⟨M⟩. Once D has determined this information, it does the
opposite. https://www.liarparadox.org/Sipser_165_167.pdf

Richard Damon

unread,

May 2, 2022, 8:40:16 PM5/2/22

to

No, lets actually look at what is says, and parse it:

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run
forever. Alan Turing proved in 1936 that a general algorithm to solve
the halting problem for all possible program-input pairs cannot exist.

For any program f that might determine if programs halt, a
"pathological" program g, called with some input, can pass its own
source and its input to f and then specifically do the opposite of what

f predicts g will do. No f can exist that handles this case. A key part
of the proof is a mathematical definition of a computer and program,
which is known as a Turing machine; the halting problem is undecidable
over Turing machines. It is one of the first cases of decision problems
proven to be unsolvable. This proof is significant to practical
computing efforts, defining a class of applications which no programming
invention can possibly perform perfectly.

Jack Copeland attributes the introduction of the term halting problem to
the work of Martin Davis in the 1950s.[1]

The FIRST SENTENCE is the definition of the Problem.

The Second Sentence is the Theorem about it that says that no solution
exists.

That ends the first paragraph.

The Second Paragraph, is a continuation of the idea of the Second
Sentence, giving a summary of the proof that no solution exist.

It is a category error to confuse the Statement of the Problem with the
Proof of the Theorem that not answer to the Problem exists.

A Proof is NOT a Problem.

Richard Damon

unread,

May 2, 2022, 8:48:57 PM5/2/22

to

Thus you have shown you don't even know what a "Definition" is, so it is
impossible for you to reason by the meaning of the words.

You have just proved yourself to be an IDIOT.

Mikko

unread,

May 3, 2022, 5:31:47 AM5/3/22

to

On 2022-05-02 15:47:32 +0000, Mr Flibble said:

> Not all infinitely recursive definitions are invalid however infinitely
> recursive definitions that arise out of a category error (as is the
> case with the halting problem) are invalid.

An infinite recursion cannot arise out of a category error as the recursion
stops at the category error.

Mikko

Mikko

unread,

May 3, 2022, 5:36:48 AM5/3/22

to

On 2022-05-02 16:18:36 +0000, olcott said:

> It seems to me that all infinitely recursive definitions are invalid
> and I am having an excellent dialogue with some Prolog folks about this
> in comp.lang.prolog.

One of the rules that define Prolog language is

arguments ::= argument | argument "," arguments

which is infinitely recursive. Is it invalid? Is Prolog invalid because
of this and other infinitely recursive rules?

Mikko

Malcolm McLean

unread,

May 3, 2022, 7:08:12 AM5/3/22

to

Kind of.
A Prolog program is a physical object, not a mathematical object, so
the recursion has to terminate somewhere.
But it might lead you into strange territory if you tried to define the result
of passing an ininite argument list to some Prolog.

wij wij

unread,

May 3, 2022, 8:12:15 AM5/3/22

to

richar...@gmail.com 在 2022年5月3日星期二上午8:48:57 [UTC+8] 的信中寫道：

PO is incapable of logic reasoning (PO had shown he cannot even get the truth
table of logical implication/AND right). All he said is delusion including when
words from him happen to be correct to others (no real meaning).

IIRC, PO's revision that H(P,P) has no relation with P(P) is deliberately
fabricated this recent year after PO ran out his reasons to explain why HP is
wrong and he is correct. PO has no trouble to 'lie' to his bible (he can read
it his way), the HP thing is just piece of cake.

olcott

unread,

May 3, 2022, 10:31:21 AM5/3/22

to

It is an easily verified fact that P(P) and the correct simulation of
the input to H(P,P) specify different sequences of configurations, thus
have different halting behavior. That several people here deny easily
verified facts is a little psychotic on their part.

olcott

unread,

May 3, 2022, 10:33:45 AM5/3/22

to

Even infinitely recursive math expressions are semantically incorrect in
that they can never be evaluated.

olcott

unread,

May 3, 2022, 10:39:02 AM5/3/22

to

If would have to be invalid because it can never be resolved.

olcott

unread,

May 3, 2022, 10:42:37 AM5/3/22

to

The category error is that an expression of language X is construed as a
logic sentence / truth bearer that is true or false. It is because of
the infinitely recursive definition that X is neither of these.

https://en.wikipedia.org/wiki/Sentence_(mathematical_logic)#:~:text=In%20mathematical%20logic%2C%20a%20sentence,must%20be%20true%20or%20false.

Dennis Bush

unread,

May 3, 2022, 10:47:32 AM5/3/22

to

On Tuesday, May 3, 2022 at 10:31:21 AM UTC-4, olcott wrote:
> On 5/3/2022 7:12 AM, wij wij wrote:

> > Richard Damon 在 2022年5月3日星期二上午8:48:57 [UTC+8] 的信中寫道：

The easily verified fact is that the correct simulation to H(P,P) is performed by Hb(P,P) (which simulates for k more steps than H) which remains in UTM mode while simulating the same input to a final state.

Because H and Hb and both simulating halt deciders and are given the same input, they are deciding on the same sequence of configurations (namely starting with the first instruction of P). Because one answers false and one answers true, one must be wrong.

Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(P,P) == true is correct and that H(P,P) == false is incorrect, and that H(P,P) does *not* in fact perform a correct simulation of its input because it aborts too soon.

You've been asked several times what input must be given to H to determine if P(P) halts. It turns out that the input (P,P) can be given to Hb to determine exactly that, so the fact that H can't give the same result for the same input just shows that it is wrong and that the halting problem is unsolvable as the existing proofs show.

> That several people here deny easily
> verified facts is a little psychotic on their part.

You're projecting. Again. In fact you're *so* good a projecting that if you opened a movie theater I'll bet the picture quality would be second to none.

olcott

unread,

May 3, 2022, 11:19:33 AM5/3/22

to

I have no idea what you mean.

> Because H and Hb and both simulating halt deciders and are given the same input, they are deciding on the same sequence of configurations (namely starting with the first instruction of P). Because one answers false and one answers true, one must be wrong.
>

It is ridiculously stupid to assume that an input having pathological
self-reference to its decider would have the same behavior as an input
NOT having pathological to its decider.

> Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(P,P) == true is correct and that H(P,P) == false is incorrect, and that H(P,P) does *not* in fact perform a correct simulation of its input because it aborts too soon.
>

It is very easy to verify the fact that the simulated input to H(P,P)
would never stop unless aborted. It is pretty psychotic that many of my
reviewers deny easily verified facts.

> You've been asked several times what input must be given to H to determine if P(P) halts. It turns out that the input (P,P) can be given to Hb to determine exactly that, so the fact that H can't give the same result for the same input just shows that it is wrong and that the halting problem is unsolvable as the existing proofs show.
>

It is ridiculously stupid to assume that an input having pathological
self-reference to its decider would have the same behavior as an input
NOT having pathological to its decider.

It is an easily verified fact that H does correctly reject its input and
that deciders only compute the mapping from their inputs.

>> That several people here deny easily
>> verified facts is a little psychotic on their part.
>
> You're projecting. Again. In fact you're *so* good a projecting that if you opened a movie theater I'll bet the picture quality would be second to none.

Anyone that denies easily verified facts has (by definition) a break
from reality.

Dennis Bush

unread,

May 3, 2022, 11:36:07 AM5/3/22

to

In other words you don't want to admit that this proves you are wrong.

> > Because H and Hb and both simulating halt deciders and are given the same input, they are deciding on the same sequence of configurations (namely starting with the first instruction of P). Because one answers false and one answers true, one must be wrong.
> >
> It is ridiculously stupid to assume that an input having pathological
> self-reference to its decider would have the same behavior as an input
> NOT having pathological to its decider.

Which is another way of saying that H can't give a correct answer for (P,P).

> > Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(P,P) == true is correct and that H(P,P) == false is incorrect, and that H(P,P) does *not* in fact perform a correct simulation of its input because it aborts too soon.
> >
> It is very easy to verify the fact that the simulated input to H(P,P)
> would never stop unless aborted. It is pretty psychotic that many of my
> reviewers deny easily verified facts.

There is no "unless". The fixed algorithm of H, which will henceforth be referred to as Ha and similarly P will be referred to as Pa, *does* abort. Because of this, Hb(Pa,Pa) explicitly shows that the simulated input to Ha(Pa,Pa) *does* stop. The fact that Pn(Pn) does not halt and that Hn(Pn,Pn) does not halt is irrelevant.

> > You've been asked several times what input must be given to H to determine if P(P) halts. It turns out that the input (P,P) can be given to Hb to determine exactly that, so the fact that H can't give the same result for the same input just shows that it is wrong and that the halting problem is unsolvable as the existing proofs show.
> >
> It is ridiculously stupid to assume that an input having pathological
> self-reference to its decider would have the same behavior as an input
> NOT having pathological to its decider.

Which is another way of saying that Ha can't give a correct answer for (Pa,Pa).

>
> It is an easily verified fact that H does correctly reject its input

Ha does not correctly reject its input as easily verified by Hb.

> and that deciders only compute the mapping from their inputs.

And all halt deciders must compute the same mapping from the same input. Ha(Pa,Pa) and Hb(Pa,Pa) do not perform the same mapping from the same input so one must be wrong.

Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(Pa,Pa) == true is correct and that Ha(Pa,Pa) == false is incorrect

> >> That several people here deny easily
> >> verified facts is a little psychotic on their part.
> >
> > You're projecting. Again. In fact you're *so* good a projecting that if you opened a movie theater I'll bet the picture quality would be second to none.
> Anyone that denies easily verified facts has (by definition) a break
> from reality.

I can't *wait* to see your movie theater. Such a expert at projection must have a great picture.

olcott

unread,

May 3, 2022, 12:39:49 PM5/3/22

to

No I can't understand what you mean.
I think that I see it now, I had forgotten the notation.

An input having a pathological self-reference relationship to its
decider H would necessarily derive a different halt status than an input
not having a pathological self-reference relationship to its decider Hb.

The P having a pathological self-reference relationship to H is not the
same as the Px NOT having a pathological self-reference relationship to
Hb. Because P.H calls itself and Px.Hb does not call itself P is not the
same input as Px.

>
>>> Because H and Hb and both simulating halt deciders and are given the same input, they are deciding on the same sequence of configurations (namely starting with the first instruction of P). Because one answers false and one answers true, one must be wrong.
>>>
>> It is ridiculously stupid to assume that an input having pathological
>> self-reference to its decider would have the same behavior as an input
>> NOT having pathological to its decider.
>
> Which is another way of saying that H can't give a correct answer for (P,P).
>

Different computations must give different answers.
That you don't fully understand all of the nuances of how this applies
to H/P and Hb/Px is OK, it is difficult to understand.

>>> Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(P,P) == true is correct and that H(P,P) == false is incorrect, and that H(P,P) does *not* in fact perform a correct simulation of its input because it aborts too soon.
>>>
>> It is very easy to verify the fact that the simulated input to H(P,P)
>> would never stop unless aborted. It is pretty psychotic that many of my
>> reviewers deny easily verified facts.
>
> There is no "unless". The fixed algorithm of H, which will henceforth be referred to as Ha and similarly P will be referred to as Pa, *does* abort.

Which is *NOT* halting. A halting input must reach its own final state.

> Because of this, Hb(Pa,Pa) explicitly shows that the simulated input to Ha(Pa,Pa) *does* stop. The fact that Pn(Pn) does not halt and that Hn(Pn,Pn) does not halt is irrelevant.

It it not Hb(Pa,Pa) it is Hb(Px,Px). That P calls H makes it an entirely
different input than Px that does not call Hb.

>>> You've been asked several times what input must be given to H to determine if P(P) halts. It turns out that the input (P,P) can be given to Hb to determine exactly that, so the fact that H can't give the same result for the same input just shows that it is wrong and that the halting problem is unsolvable as the existing proofs show.
>>>
>> It is ridiculously stupid to assume that an input having pathological
>> self-reference to its decider would have the same behavior as an input
>> NOT having pathological to its decider.
>
> Which is another way of saying that Ha can't give a correct answer for (Pa,Pa).
>
>>
>> It is an easily verified fact that H does correctly reject its input
>
> Ha does not correctly reject its input as easily verified by Hb.

That P calls H makes it an entirely different input than Px that does
not call Hb.

>
>> and that deciders only compute the mapping from their inputs.
>
> And all halt deciders must compute the same mapping from the same input. Ha(Pa,Pa) and Hb(Pa,Pa) do not perform the same mapping from the same input so one must be wrong.
>

That P calls H makes it an entirely different input than Px that does
not call Hb.

> Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(Pa,Pa) == true is correct and that Ha(Pa,Pa) == false is incorrect

That P calls H makes it an entirely different input than Px that does
not call Hb.

>
>>>> That several people here deny easily
>>>> verified facts is a little psychotic on their part.
>>>
>>> You're projecting. Again. In fact you're *so* good a projecting that if you opened a movie theater I'll bet the picture quality would be second to none.
>> Anyone that denies easily verified facts has (by definition) a break
>> from reality.
>
> I can't *wait* to see your movie theater. Such a expert at projection must have a great picture.

Malcolm McLean

unread,

May 3, 2022, 3:17:24 PM5/3/22

to

We have very close views on this. Infinite recursion is definitely the
key issue with the HP counter-examples and makes Gödel's G and Tarski's
p semantically incorrect.

Dennis Bush

unread,

May 3, 2022, 5:49:47 PM5/3/22

to

The P we're talking about is a *specific* P, namely Pa which is built from Ha, and Ha is a *specific* H. So Pa and Px are the *same*.

So just because Pa contains an embedded copy of Ha but not an embedded copy of Hb doesn't means that it's not the same.

Ha(Pa,Pa) and Hb(Pa,Pa) have the *exact* same input.

Just because it appears from a glance that Ha is starting its simulation of Pa "in the middle" doesn't mean that's what's actually happening. That's just how the incorrect simulation is manifesting itself. It's kind of like undefined behavior in a C program.

> >
> >>> Because H and Hb and both simulating halt deciders and are given the same input, they are deciding on the same sequence of configurations (namely starting with the first instruction of P). Because one answers false and one answers true, one must be wrong.
> >>>
> >> It is ridiculously stupid to assume that an input having pathological
> >> self-reference to its decider would have the same behavior as an input
> >> NOT having pathological to its decider.
> >
> > Which is another way of saying that H can't give a correct answer for (P,P).
> >
> Different computations must give different answers.
> That you don't fully understand all of the nuances of how this applies
> to H/P and Hb/Px is OK, it is difficult to understand.

Just because Pa contains an embedded copy of Ha but not an embedded copy of Hb doesn't means that it's not the same.

> >>> Since a simulating halt decider that simulates its input to a final state while remaining in UTM mode is necessarily correct, this proves that Hb(P,P) == true is correct and that H(P,P) == false is incorrect, and that H(P,P) does *not* in fact perform a correct simulation of its input because it aborts too soon.
> >>>
> >> It is very easy to verify the fact that the simulated input to H(P,P)
> >> would never stop unless aborted. It is pretty psychotic that many of my
> >> reviewers deny easily verified facts.
> >
> > There is no "unless". The fixed algorithm of H, which will henceforth be referred to as Ha and similarly P will be referred to as Pa, *does* abort.
> Which is *NOT* halting. A halting input must reach its own final state.
> > Because of this, Hb(Pa,Pa) explicitly shows that the simulated input to Ha(Pa,Pa) *does* stop. The fact that Pn(Pn) does not halt and that Hn(Pn,Pn) does not halt is irrelevant.
> It it not Hb(Pa,Pa) it is Hb(Px,Px). That P calls H makes it an entirely
> different input than Px that does not call Hb.

No it is *exactly* Hb(Pa,Pa). The same encoding passed to Ha is passed to Hb.

unread,

May 3, 2022, 6:11:52 PM5/3/22

to

It is not at all about physical representations it is about ideas that
directly contradict the verified facts, the square root of a negative
number and parallel lines that meet are both known to be non-existent on
the basis of definitions.

> All these concepts have historically caused great difficulty. Which is why it
> is almost impossible to make progress in mathematics or related disciplines
> without having a deep understanding of what has gone before. Otherwise you
> are doomed to retread old debates.

olcott

unread,

May 3, 2022, 6:15:36 PM5/3/22

to

Ad Hominem attacks are the first resort of clueless wonders.
You have proven that you are not totally clueless about all of these
things, there are some of these things that you do correctly understand.

Python

unread,

May 3, 2022, 6:21:31 PM5/3/22

to

Peter Olcott wrote:
> On 5/3/2022 1:59 PM, Mr Flibble wrote:
>> On Tue, 3 May 2022 11:57:39 -0500
>> olcott <polc...@gmail.com> wrote:

...

>>> I don't buy into the whole imaginary numbers game.
>>> We could imagine that 2 + 3 = 17 and call that an imaginary sum.

...

>
> Nice to know, thanks. Thus your rebuttal seems complete it is not an
> infinite anything. Imagining the square root of a negative number or
> that parallel lines meet seems a little nuts to me.

Before jumping to such outrageously uninformed conclusions you may want
to learn how complex numbers are actually defined nowadays.

It is true that, at first, it was used without any proper definition
better than "let's assume we can deal with sqrt(-1) as usual". The
surprising point at that time is it works pretty well.

*Then*, in the XIXth Century, Gallois showed how to define complex
numbers rigorously.

You've never heard of that, Peter, really?

[for the record: C is the set of equivalence classes of polynomials
on R by the relation p ~ q iff p - q = 0 [mod x^2+1], compatibility
of + and * on R and C can be proven easily, R is naturally injected
into C as a set of constant polynomials, i is the equivalence class of
the polynomial x]

Dennis Bush

unread,

May 3, 2022, 6:21:45 PM5/3/22

to

Hb(Pa,Pa) proves that Ha(Pa,Pa) does NOT perform a correct simulation. Both perform the same mapping so both must answer the same.

Both start simulation at the beginning. At the point that Ha aborts, Hb does not but continues to simulate the same input and sees that it reaches a final state.

There is no infinitely nested simulation in Pa *because* Ha aborts. It *thinks* it sees infinitely nested simulation but it doesn't. While Ha(Pn,Pn) does in fact correctly detect infinitely nested simulation, that's not the case we're interested in.

Hn(Pn,Pn) is infinitely nested simulation, but this has nothing to do with Ha or Pa.

>
> How much longer are you going to continue the verified facts?
> This does make you look quite foolish or dishonest.

So when are you going to open up that movie theater? The picture would just be beautiful from such a master at projection.

Python

unread,

May 3, 2022, 6:23:29 PM5/3/22

to

You cranks are really unsufferable idiots...

olcott

unread,

May 3, 2022, 6:32:52 PM5/3/22

to

By looking at the actual execution trace of the simulation of Hb(Pa,Pa)
and Ha(Pa,Pa) it is easy to determine that the simulations are correct
on the basis of the x86 source code of Pa.

I will see if I can create the execution of Hb(Pa,Pa) to derive this
execution trace. We have had the one for Ha(Pa,Pa) for many months now.

It is self evident that Hb will not see itself being called in
infinitely nested simulation and the executuion trace of Ha(Pa,Pa) does
see itself called in infinitely nested simulation. This difference would
very obviously make the results of Ha and Hb differ.

olcott

unread,

May 3, 2022, 6:41:01 PM5/3/22

to

On 5/3/2022 5:21 PM, Python wrote:
> Peter Olcott wrote:
>> On 5/3/2022 1:59 PM, Mr Flibble wrote:
>>> On Tue, 3 May 2022 11:57:39 -0500
>>> olcott <polc...@gmail.com> wrote:
> ...
>>>> I don't buy into the whole imaginary numbers game.
>>>> We could imagine that 2 + 3 = 17 and call that an imaginary sum.
> ...
>>
>> Nice to know, thanks. Thus your rebuttal seems complete it is not an
>> infinite anything. Imagining the square root of a negative number or
>> that parallel lines meet seems a little nuts to me.
>
> Before jumping to such outrageously uninformed conclusions you may want
> to learn how complex numbers are actually defined nowadays.
>

They are defined to directly contradict the verified facts.
I really hate anything that directly contradicts the verified facts
because this can result in:
(a) Climate change making humans extinct quite soon,

(b) Nazi "big lie" propaganda about election fraud is making very
significant inroads to transforming Democracy ion the USA to Fascism.

(c) It directly resulted in many covid-19 deaths

> It is true that, at first, it was used without any proper definition
> better than "let's assume we can deal with sqrt(-1) as usual". The
> surprising point at that time is it works pretty well.
>

We can see what happens when we hypothesize (against the facts) that
square roots of negative numbers and parallel lines that meet exist
simply to see where this leads. I am sure that this is the intent.

> *Then*, in the XIXth Century, Gallois showed how to define complex
> numbers rigorously.
>
> You've never heard of that, Peter, really?
>
> [for the record: C is the set of equivalence classes of polynomials
> on R by the relation p ~ q iff p - q = 0 [mod x^2+1], compatibility
> of + and * on R and C can be proven easily, R is naturally injected
> into C as a set of constant polynomials, i is the equivalence class of
> the polynomial x]
>
>

Python

unread,

May 3, 2022, 6:46:05 PM5/3/22

to

Peter Olcott wrote:
> On 5/3/2022 5:21 PM, Python wrote:
>> Peter Olcott wrote:
>>> On 5/3/2022 1:59 PM, Mr Flibble wrote:
>>>> On Tue, 3 May 2022 11:57:39 -0500
>>>> olcott <polc...@gmail.com> wrote:
>> ...
>>>>> I don't buy into the whole imaginary numbers game.
>>>>> We could imagine that 2 + 3 = 17 and call that an imaginary sum.
>> ...
>>>
>>> Nice to know, thanks. Thus your rebuttal seems complete it is not an
>>> infinite anything. Imagining the square root of a negative number or
>>> that parallel lines meet seems a little nuts to me.
>>
>> Before jumping to such outrageously uninformed conclusions you may want
>> to learn how complex numbers are actually defined nowadays.
>>
>
> They are defined to directly contradict the verified facts.
> I really hate anything that directly contradicts the verified facts
> because this can result in:
> (a) Climate change making humans extinct quite soon,
>
> (b) Nazi "big lie" propaganda about election fraud is making very
> significant inroads to transforming Democracy ion the USA to Fascism.
>
> (c) It directly resulted in many covid-19 deaths

You should definitely call a doctor and ask for help, your mental
state is utterly ill. What the f* are complex numbers related to
your rants on politics?

>> It is true that, at first, it was used without any proper definition
>> better than "let's assume we can deal with sqrt(-1) as usual". The
>> surprising point at that time is it works pretty well.
>>
>
> We can see what happens when we hypothesize (against the facts) that
> square roots of negative numbers and parallel lines that meet exist
> simply to see where this leads. I am sure that this is the intent.

Not quite you're wrong. The intent was to find *real* roots of degree 3
polynomials even if square root of negative quantities appears at
intermediary steps.

You know *nothing* about history of Science, Peter. Guessing is quite
absurd when it comes to History.

>> *Then*, in the XIXth Century, Gallois showed how to define complex
>> numbers rigorously.
>>
>> You've never heard of that, Peter, really?
>>
>> [for the record: C is the set of equivalence classes of polynomials
>> on R by the relation p ~ q iff p - q = 0 [mod x^2+1], compatibility
>> of + and * on R and C can be proven easily, R is naturally injected
>> into C as a set of constant polynomials, i is the equivalence class of
>> the polynomial x]

No reaction? Well... Not a big surprise, your eyes cancel out any
sensible arguments proving you wrong, as usual.

Die in Hell, idiotic annoying crank. You deserve it.

olcott

unread,

May 3, 2022, 6:49:43 PM5/3/22

to

None-the-less as I just said this whole think relies on accepting a
known false premise.

> You know *nothing* about history of Science, Peter. Guessing is quite
> absurd when it comes to History.
>
>>> *Then*, in the XIXth Century, Gallois showed how to define complex
>>> numbers rigorously.
>>>
>>> You've never heard of that, Peter, really?
>>>
>>> [for the record: C is the set of equivalence classes of polynomials
>>> on R by the relation p ~ q iff p - q = 0 [mod x^2+1], compatibility
>>> of + and * on R and C can be proven easily, R is naturally injected
>>> into C as a set of constant polynomials, i is the equivalence class of
>>> the polynomial x]
>
> No reaction? Well... Not a big surprise, your eyes cancel out any
> sensible arguments proving you wrong, as usual.
>
> Die in Hell, idiotic annoying crank. You deserve it.
>
>
>
>

Python

unread,

May 3, 2022, 7:05:24 PM5/3/22

to

Let me guess, you are some kind of "information engineer" and consider
yourself also as "one of the greatest logicians Humanity ever had",
right? There is a demented guy of this kind on sci.physics.relativity,
his name is Maciej Wozniak. You guys should definitely mate (NOT).

>> You know *nothing* about history of Science, Peter. Guessing is quite
>> absurd when it comes to History.
>>
>>>> *Then*, in the XIXth Century, Gallois showed how to define complex
>>>> numbers rigorously.
>>>>
>>>> You've never heard of that, Peter, really?
>>>>
>>>> [for the record: C is the set of equivalence classes of polynomials
>>>> on R by the relation p ~ q iff p - q = 0 [mod x^2+1], compatibility
>>>> of + and * on R and C can be proven easily, R is naturally injected
>>>> into C as a set of constant polynomials, i is the equivalence class of
>>>> the polynomial x]
>>
>> No reaction? Well... Not a big surprise, your eyes cancel out any
>> sensible arguments proving you wrong, as usual.
>>
>> Die in Hell, idiotic annoying crank. You deserve it.

(bis)

olcott

unread,

May 3, 2022, 7:48:07 PM5/3/22

to

I consider myself to have made significant unique advancements on the
single subject on the philosophical foundation of the notion of logical
truth.

One of my key breakthroughs is redefining the analytic / synthetic
distinction such that analytic means (the same as it did) any expression
of formal or natural language that can be verified as true entirely on
the basis of its meaning. "Dogs are animals"

The somewhat vaguely defined synthetic is renamed as empirical and it is
the same sort of thing as analytic that additionally requires sense data
from the sense organs as an aspect of the truth verification process.
"There is a dog in my living room right now."

This is the most important paper on the subject
Two Dogmas of Empiricism by Willard Van Orman Quine
(Harvard University Press, 1953; second, revised, edition 1961)
https://www.theologie.uzh.ch/dam/jcr:ffffffff-fbd6-1538-0000-000070cf64bc/Quine51.pdf

Quine didn't seem to understand that bachelors are necessarily unmarried.

Meaning Postulates by RUDOLF CARNAP
https://liarparadox.org/Meaning_Postulates_Rudolf_Carnap_1952.pdf
conclusively proved the complete basis of how we know that bachelors are
necessarily unmarried. Quine didn't want to hear this because it
contradicted his paper.

>>> You know *nothing* about history of Science, Peter. Guessing is quite
>>> absurd when it comes to History.
>>>
>>>>> *Then*, in the XIXth Century, Gallois showed how to define complex
>>>>> numbers rigorously.
>>>>>
>>>>> You've never heard of that, Peter, really?
>>>>>
>>>>> [for the record: C is the set of equivalence classes of polynomials
>>>>> on R by the relation p ~ q iff p - q = 0 [mod x^2+1], compatibility
>>>>> of + and * on R and C can be proven easily, R is naturally injected
>>>>> into C as a set of constant polynomials, i is the equivalence class of
>>>>> the polynomial x]
>>>
>>> No reaction? Well... Not a big surprise, your eyes cancel out any
>>> sensible arguments proving you wrong, as usual.
>>>
>>> Die in Hell, idiotic annoying crank. You deserve it.
>
> (bis)
>
>

Richard Damon

unread,

May 3, 2022, 9:38:04 PM5/3/22

to

On 5/3/22 2:13 PM, olcott wrote:
> On 5/3/2022 12:27 PM, Mikko wrote:
>> On 2022-05-03 14:42:32 +0000, olcott said:
>>
>>> On 5/3/2022 4:31 AM, Mikko wrote:
>>>> On 2022-05-02 15:47:32 +0000, Mr Flibble said:
>>>>
>>>>> Not all infinitely recursive definitions are invalid however
>>>>> infinitely
>>>>> recursive definitions that arise out of a category error (as is the
>>>>> case with the halting problem) are invalid.
>>>>
>>>> An infinite recursion cannot arise out of a category error as the
>>>> recursion
>>>> stops at the category error.
>>>>
>>>> Mikko
>>>>
>>>
>>> The category error is that an expression of language X is construed
>>> as a logic sentence / truth bearer that is true or false. It is
>>> because of the infinitely recursive definition that X is neither of
>>> these.
>>
>> Only if the recursive expression is used as if it were a truth bearer.
>> Definitions usually don't use expression that way.
>>
>> Mikko
>>
>
> Expressions of language can only be correctly construed as true:
> (a) if they are defined to be true
> (b) have no contradictory elements in (a)
> (c) are derived by applying true preserving operations to (a) or (c)
>

So, you don't believe the Bible verse you like to Quote is actually true?

Then why do you quote it?

There is no "Definiton" that it must be true, or how do you decide WHICH
writings get that status.

And you certainly can't derive it from things actually defined to be true.

This seems to say you have a contradiction in your logic system, so I
guess that mean your logic system isn't correct.

Richard Damon

unread,

May 3, 2022, 9:41:49 PM5/3/22

to

On 5/3/22 10:42 AM, olcott wrote:
> On 5/3/2022 4:31 AM, Mikko wrote:
>> On 2022-05-02 15:47:32 +0000, Mr Flibble said:
>>
>>> Not all infinitely recursive definitions are invalid however infinitely
>>> recursive definitions that arise out of a category error (as is the
>>> case with the halting problem) are invalid.
>>
>> An infinite recursion cannot arise out of a category error as the
>> recursion
>> stops at the category error.
>>
>> Mikko
>>
>
> The category error is that an expression of language X is construed as a
> logic sentence / truth bearer that is true or false. It is because of
> the infinitely recursive definition that X is neither of these.
>

> https://en.wikipedia.org/wiki/Sentence_(mathematical_logic)#:~:text=In%20mathematical%20logic%2C%20a%20sentence,must%20be%20true%20or%20false.
>
>

Except that neither G (in F) or the Halting Problem as properly defined
has a recursive definition, so you have no grounds to call it infinitely
recursive.

Yes, G may become recursive in F', but it isn't in F.

Richard Damon

unread,

May 3, 2022, 9:47:13 PM5/3/22

to

Nope. You are looking at a WRONG simulation.

Note, your "second" layer is incorrect as we really need to see the
simulation of Ha simulating Pa,Pa, not another execution of Pa

Note, there is a valid transform of UNCONDITIONAL simulation to
execution, but Pa does NOT unconditionally simulate its input, so that
transform is not valid.

And the concept of being "unconditional until", is just an oxymoron, and
your arguments about that just prove you are a regular one.

>
> I will see if I can create the execution of Hb(Pa,Pa) to derive this
> execution trace. We have had the one for Ha(Pa,Pa) for many months now.

No, you have an INCORRECT one that uses a false transform.

We need to see the trace of Ha actually simulating, not that part skipped.

>
> It is self evident that Hb will not see itself being called in
> infinitely nested simulation and the executuion trace of Ha(Pa,Pa) does
> see itself called in infinitely nested simulation. This difference would
> very obviously make the results of Ha and Hb differ.
>

Which just helps prove that Ha was WRONG.

Richard Damon

unread,

May 3, 2022, 9:54:44 PM5/3/22

to

So the second sentence of the first paragraph is part of the definition,
so BY DEFINITON, no answer exists to the Halting Problem?

You can't say that paragraph 2 is part of the definiton and exclude the
end of paragraph 1.

The only reasonable parsing is:

Sentence 1: the Defintion of the Problem
Sentence 2: The Theorem about the Problem
Paragraph 2: A sketch of the proof of the Theorem
Paragraph 3: History of how it got its common name.

You confuse the "Halting Problem" with the Theorem about the Halting
Problem that states that no machine can exist to compute the answer to
the problem (and its proof).

Richard Damon

unread,

May 3, 2022, 9:58:01 PM5/3/22

to

On 5/3/22 2:13 PM, olcott wrote:
> On 5/3/2022 12:17 PM, Mikko wrote:
>> On 2022-05-03 14:38:57 +0000, olcott said:

>>
>>> On 5/3/2022 4:36 AM, Mikko wrote:
>>>> On 2022-05-02 16:18:36 +0000, olcott said:
>>>>
>>>>> It seems to me that all infinitely recursive definitions are
>>>>> invalid and I am having an excellent dialogue with some Prolog
>>>>> folks about this in comp.lang.prolog.
>>>>
>>>> One of the rules that define Prolog language is
>>>>
>>>> arguments ::= argument | argument "," arguments
>>>>
>>>> which is infinitely recursive. Is it invalid? Is Prolog invalid because
>>>> of this and other infinitely recursive rules?
>>>>

>>>> Mikko
>>>>
>>>
>>> If would have to be invalid because it can never be resolved.
>>
>> What would be invalid? Prolog? Definition of Prolog?
>> Why "would be" and not "is"?
>>
>> Mikko
>>
>
> Failing a unify_with_occurs_check which would otherwise derive this:
>
> [trace] ?- LP = \+(LP).
> LP = (\+LP).
>
> [trace] ?- LP.
> % ... 1,000,000 ............ 10,000,000 years later
> %
> % >> 42 << (last release gives the question)
> [trace] ?-
>

So, it just says that the question is beyond Prolog ability to process.

Doesn't mean it is an invalid logical sentence.

Prolog has a VERY limited form of logic, and can't express a LOT of true
propositions.

olcott

unread,

May 3, 2022, 10:07:57 PM5/3/22

to

On 5/2/2022 6:10 PM, Ben wrote:
> olcott <polc...@gmail.com> writes:
>
>> On 5/2/2022 11:39 AM, Ben wrote:
>>> olcott <polc...@gmail.com> writes:
>>>
>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>> simulation to H.
>>> What two pointers must be passed to H for H to tell up about the halting
>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>> not a halt decider, and you have already told use that H(P,P) == false
>>> and that P(P) halts.
>>
>> If H can report on the halting of non-input P(P) then it is not a
>> decider because deciders only compute the mapping from inputs to final
>> states.
>
> TM deciders compute mappings from inputs to final states /according to
> some property of the inputs/

That par is exactly correct.

> -- whether the input represents, for

That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
The correct simulation of the input to H(P,P) specifies non-halting
behavior.

Clueless wonders that don't know the first thing about the x86 language
assume that this simulation is incorrect even though is is nearly
trivial to determine that the simulation is correct as a verified fact.

That they contradict verified facts entirely one the basis that they are
incompetent to verify that it is a fact is the worst hubris.

> example, an even number, a prime number or a halting computation.
>
> According to you there is no "input" (in reality a pair of pointers)
> that represents the halting computation P(P). Why should anyone care
> about this H if it does not decide what we want -- the halting of the
> function call represented by the two arguments to H? Whatever H is
> actually deciding is not interesting.

(a) H does correctly decide its input
(b) H is only required to decide its input.
(c) Therefore H(P,P) is entirely correct on the "impossible" input.

> Also, I wonder why you wasted so much time justifying the fact that
> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
> even supposed to be deciding the halting P(P). Well, we know, of
> course. You realised you were in a hole so you started to dig sideways.
> You used to know that H(X,Y) had to decide the halting of X(Y). You're
> now pretending it never did!
>

>> That you expect a halt decider to compute the mapping from non-inputs
>> is a little nuts when you know that deciders can't possibly do this.
>
> Don't be silly. They decide properties of inputs -- parity, halting and
> so on. You'd know this if you'd done even the warm-up exercises I set.

The problem here is that you expect that the property of an input not be
the actual property of the actual input but the property of a non-input.

The halting property of the input to H(P,P) is the actual behavior of
the correct simulation of this input and thus not at all what you simply
imagine this property should be.

> How are they coming along? It looks like you have found an excuse to
> bail out again:
>

It is coming along great and it is wonderful fun.
I think that it is a great idea to move in this direction.
I may eventually convert C copy of the TM into a RASP machine.
I probably won't begin to do that until after we finish our exercises.

>> It turns out that I can create a whole TM interpreter from scratch
>> quicker than I can learn the extraneous complexity of the TM
>> Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html
>
> I doubt it. But I suppose you think that's a reasonable excuse. Of
> course, some of us remember you saying writing such a thing would take
> about a week three years ago. I remember wondering how such a simple
> program could take you a week to write.

As soon as I complete the detailed design I should have an accurate
estimate of the total time. It currently looks like < 4 hours. I have
spent 15 minutes on the detailed design and it looks like it will take
45 more minutes.

One thing that is great is that I have fully recovered from what could
have been a life threatening infection. I was in the hospital getting IV
antibiotics for nearly two days. Chemotherapy patients have a few days
after chemotherapy where their immune system is very close to zero.

>
> Of course you don't need an interpreter to write E or specify P, but you
> must find some excuse for bailing out.
>

It is much better (and more fun) if I make this totally concrete.
One can not effectively debug code by desk checking.

Mikko

unread,

May 4, 2022, 3:19:49 AM5/4/22

to

On 2022-05-03 18:06:24 +0000, olcott said:

> On 5/3/2022 12:17 PM, Mikko wrote:
>> On 2022-05-03 14:38:57 +0000, olcott said:
>>
>>> On 5/3/2022 4:36 AM, Mikko wrote:
>>>> On 2022-05-02 16:18:36 +0000, olcott said:
>>>>
>>>>> It seems to me that all infinitely recursive definitions are invalid
>>>>> and I am having an excellent dialogue with some Prolog folks about this
>>>>> in comp.lang.prolog.
>>>>
>>>> One of the rules that define Prolog language is
>>>>
>>>> arguments ::= argument | argument "," arguments
>>>>
>>>> which is infinitely recursive. Is it invalid? Is Prolog invalid because
>>>> of this and other infinitely recursive rules?
>>>>
>>>> Mikko
>>>>
>>>
>>> If would have to be invalid because it can never be resolved.
>>
>> What would be invalid? Prolog? Definition of Prolog?
>> Why "would be" and not "is"?
>>
>> Mikko
>>
>

> Expressions that cannot be resolved in Prolog that fail the
> unify_with_occurs_check test proves that these expressions are
> semantically incorrect.

No, it does not mean anything like that. It only means that no well founded
data structure matches both arguments.

For example, unify_with_occurs_check(1, 2) fails but there is nothing
sematically incorrect in 1, 2.

> It is generally the case that every expression of any natural of formal
> language that cannot be derived by applying truth preserving operations
> (such as Prolog rules) to expressions known to be true (such as Prolog
> facts) cannot possibly be correctly construed as true.
>
> Dogs are animals (purely analytic)
> There is a small dog in my living room right now (Empirical).
>
> This is true for the entire body of analytic knowledge which only
> excludes expressions of language that rely on sense data from the sense
> organs to verify truth.
>
> The proof that this is correct is that no counter-examples exist.
> When G is considered true and unprovable there is some way the "true"
> is derived, it is not merely a wild guess.
>
> Just like Prolog databases True is limited to a specific formal system,
> one formal system is the entire body of analytic knowledge: EBAK. This
> is an entirely different formal system than PA.
>
> unprovable in PA and true in EBAC is not the same thing as true and
> unprovable. unprovable in PA means not true in PA, and true in EBAC
> means provable in EBAC.

Nothing in this response is relevant to the responded message.
In particular, none of the simple questions were answered.

Mikko

Mikko

unread,

May 4, 2022, 3:31:28 AM5/4/22

to

On 2022-05-03 18:26:21 +0000, Mr Flibble said:

> On Tue, 3 May 2022 12:31:44 +0300
> Mikko <mikko....@iki.fi> wrote:
>
>> On 2022-05-02 15:47:32 +0000, Mr Flibble said:
>>

>>> Not all infinitely recursive definitions are invalid however
>>> infinitely recursive definitions that arise out of a category error
>>> (as is the case with the halting problem) are invalid.
>>

>> An infinite recursion cannot arise out of a category error as the
>> recursion stops at the category error.
>

> Which is kind of my point: the category error is what makes the
> infinite recursion invalid thus rendering the halting problem
> definition itself invalid and any proofs predicated on it.

Category error does not make the infinite recursion invalid, just
irrelevant. The sentence containing the category error wourld be
invalid even whithout the infinite recursion.

There is no category error in the Halting problem. Neither Mr Flibble
nor anyone else has identified a word of wrong category in the problem.

Mikko

Ben

unread,

May 4, 2022, 7:04:59 AM5/4/22

to

Malcolm McLean <malcolm.ar...@gmail.com> writes:

> Zero doesn't have a physical representation. So Roman numbers didn't have
> the concept.

I think this is a common myth. The concept of zero is quite different
from the numeral. The Romans used abacuses for calculations so there
was a very natural physical representation both for zero (an empty
counting board) and for zero counters in one or other column.

--
Ben.

Ben

unread,

May 4, 2022, 7:15:21 AM5/4/22

to

olcott <polc...@gmail.com> writes:

> Even infinitely recursive math expressions are semantically incorrect
> in that they can never be evaluated.

Someone with no education in mathematics makes a bold claim about
mathematical concepts without defining any of then, and for some reason
a discussion ensues on Usenet. Let me get snacks...

--
Ben.
"le génie humain a des limites, quand la bêtise humaine n’en a pas"
Alexandre Dumas (fils)

Ben

unread,

May 4, 2022, 7:24:15 AM5/4/22

to

Python <pyt...@example.invalid> writes:

> You cranks are really unsufferable idiots...

To make it more fun, play crank bingo. All cards include "category
error", "ad hominem" and "straw man" along with "I've answered that a
thousand times". The maths crank bingo card includes "isomorphic",
"0.999... =/= 1" and "Cantor". What else?

--
Ben.

Andy Walker

unread,

May 4, 2022, 9:04:29 AM5/4/22

to

Partly agreed. But there are other myths and confusions which are
quite near the surface in the above. Zero as a placeholder in a column of
an abacus is quite different from zero as a number. If you ask a farmer
how many sheep he has, he might say "four" or "216"; he is unlikely to
say "zero" [rather, "I don't have any sheep"], and [FWIW] very unlikely to
say "minus three". Even if 0 and -3 exist for some purposes, they were not
thought to be /numbers/ until relatively recently, whereas the answer to
"How many ...?" is expected to be a number. So 0 and -3 were as "nutty"
to most people, however useful in mathematics, as "i" is to PO and others
today. Luckily, I doubt whether PO has yet discovered "j" and "k" as
further square roots of -1, or his "nuttiness" would know no bounds; yet
quaternions are a natural route into [very practical!] relativity.

One of the problems with 0 as a number is that inventories and
other lists become ill-specified. It's one thing to say that this farm
has 216 sheep, 42 cows and three horses, but once you start adding in
that there are zero pigs, zero giraffes, zero unicorns, ..., where do
you stop?

Separately, there is a persistent myth that Roman numerals are
unsuitable for use in arithmetic. Not so. As long as your numbers don't
exceed a few thousand, they are as easy to use as Arabic numerals; and
for large/tiny numbers, you can do what everyone did until recently and
invent new units [such as acres rather than square yards].

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Mozart,L

Ben

unread,

May 4, 2022, 9:48:43 AM5/4/22

to

Andy Walker <a...@cuboid.co.uk> writes:

> On 04/05/2022 12:04, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>> Zero doesn't have a physical representation. So Roman numbers didn't have
>>> the concept.
>> I think this is a common myth. The concept of zero is quite different
>> from the numeral. The Romans used abacuses for calculations so there
>> was a very natural physical representation both for zero (an empty
>> counting board) and for zero counters in one or other column.
>
> Partly agreed. But there are other myths and confusions which are
> quite near the surface in the above. Zero as a placeholder in a column of
> an abacus is quite different from zero as a number.

I hope you don't think I implied they were the same. My point was that
the concept of zero things is very natural, even if it expressed without
that word.

> If you ask a farmer
> how many sheep he has, he might say "four" or "216"; he is unlikely to
> say "zero" [rather, "I don't have any sheep"], and [FWIW] very unlikely to
> say "minus three". Even if 0 and -3 exist for some purposes, they were not
> thought to be /numbers/ until relatively recently, whereas the answer to
> "How many ...?" is expected to be a number.

I think that some quite old Chinese, Indian and Mayan text would suggest
otherwise. Of course it's hard to cross the cultural chasm and work out
who had the concept of zero "as a number", but even if you don't rate my
interpretation of the textual evidence, every culture will have had an
answer to "how many sheep do you have now that they've all starved?".
Is that "none as a number"? I don't think that's an easy question to
answer.

> So 0 and -3 were as "nutty"
> to most people, however useful in mathematics, as "i" is to PO and others
> today. Luckily, I doubt whether PO has yet discovered "j" and "k" as
> further square roots of -1, or his "nuttiness" would know no bounds; yet
> quaternions are a natural route into [very practical!] relativity.
>
> One of the problems with 0 as a number is that inventories and
> other lists become ill-specified. It's one thing to say that this farm
> has 216 sheep, 42 cows and three horses, but once you start adding in
> that there are zero pigs, zero giraffes, zero unicorns, ..., where do
> you stop?
>
> Separately, there is a persistent myth that Roman numerals are
> unsuitable for use in arithmetic. Not so. As long as your numbers don't
> exceed a few thousand, they are as easy to use as Arabic numerals; and
> for large/tiny numbers, you can do what everyone did until recently and
> invent new units [such as acres rather than square yards].

Yes, and the calculations where often done with a place-holder abacus.
The subtractive notation for numbers like IX and IV was a relatively
late contraction and, I believe, not universally used even when it
became common for ceremonial use (for dates and names and the like).

--
Ben.

Ben

unread,

May 4, 2022, 10:17:10 AM5/4/22

to

olcott <polc...@gmail.com> writes:

> On 5/2/2022 6:10 PM, Ben wrote:
>> olcott <polc...@gmail.com> writes:
>>
>>> On 5/2/2022 11:39 AM, Ben wrote:
>>>> olcott <polc...@gmail.com> writes:
>>>>
>>>>> It is clear that the input to H(P,P) specifies infinitely nested
>>>>> simulation to H.
>>>> What two pointers must be passed to H for H to tell up about the halting
>>>> of P(P)? If H can't report on the halting of the computation P(P) it is
>>>> not a halt decider, and you have already told use that H(P,P) == false
>>>> and that P(P) halts.
>>>
>>> If H can report on the halting of non-input P(P) then it is not a
>>> decider because deciders only compute the mapping from inputs to final
>>> states.
>> TM deciders compute mappings from inputs to final states /according to
>> some property of the inputs/
>
> That par is exactly correct.
>
>> -- whether the input represents, for
>
> That part has been the key error of everyone in that they all believe
> that is can represent something other than what it actually specifies.

So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function
calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two
arguments /would/ specify it.

A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the
honest way to move things on. If you were clear about this, maybe
someone will talk to you about whether it is that your H is deciding.

>> example, an even number, a prime number or a halting computation.
>> According to you there is no "input" (in reality a pair of pointers)
>> that represents the halting computation P(P). Why should anyone care
>> about this H if it does not decide what we want -- the halting of the
>> function call represented by the two arguments to H? Whatever H is
>> actually deciding is not interesting.
>
> (a) H does correctly decide its input

But no one cares about that as it's not what we want a decider for.

> (b) H is only required to decide its input.

And it seems that you agree that no D such that D(X,Y) == true if and
only if X(Y) halts and false otherwise is possible. That's the D that
the world cares about.

> (c) Therefore H(P,P) is entirely correct on the "impossible" input.

It decides some property of the pair of pointers P and P, but not the
one people care about: the halting or otherwise of the function call
P(P).

>> Also, I wonder why you wasted so much time justifying the fact that
>> H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
>> even supposed to be deciding the halting P(P). Well, we know, of
>> course. You realised you were in a hole so you started to dig sideways.
>> You used to know that H(X,Y) had to decide the halting of X(Y). You're
>> now pretending it never did!

Why /did/ you waste so much time trying to convince us that H(P,P) ==
false was correct even though P(P) halted if you never intended H(P,P)
to report on the halting of P(P)?

>> You'd know this if you'd done even the warm-up exercises I set.

>> How are they coming along? It looks like you have found an excuse to
>> bail out again:
>
> It is coming along great and it is wonderful fun.

It's good that it's fun, but it seems to be taking a long time. I'd
expect students to be able to write E and specify P "live" in a tutorial
-- i.e. it would take a couple of minutes and we could the discuss more
interesting examples.

The specification of TM's is your stumbling block, so you could be doing
that in parallel.

> I think that it is a great idea to move in this direction.
> I may eventually convert C copy of the TM into a RASP machine.

Do ever read what you write? What is a "C copy of the TM"? I think you
mean the TM interpreter that you've decided to write so as to delay
actually writing even a trivial TM.

olcott

unread,

May 4, 2022, 12:24:49 PM5/4/22

to

On 5/4/2022 6:15 AM, Ben wrote:
> olcott <polc...@gmail.com> writes:
>
>> Even infinitely recursive math expressions are semantically incorrect
>> in that they can never be evaluated.
>
> Someone with no education in mathematics makes a bold claim about
> mathematical concepts without defining any of then, and for some reason
> a discussion ensues on Usenet. Let me get snacks...
>

I have spent thousands of hours on this point.
When the evaluation directed graph of an expression has an infinite
cycle. See page 4.

https://www.researchgate.net/publication/350789898_Prolog_detects_and_rejects_pathological_self_reference_in_the_Godel_sentence

Mr Flibble

unread,

May 4, 2022, 12:40:39 PM5/4/22

to

On Tue, 3 May 2022 21:54:42 -0400

Sentence 2 merely states that Turing provided a proof: a proof is not a
theory, a proof proves a theory.

I see you wish to continue to play word games; I can play word games
too, and win.

If I accept your assertion as true (which is reasonable) then the facts
on the ground haven't actually changed: I merely have to make minor
modifications to my original assertion. See my "reprise #2" post which I
will post shortly.

/Flibble

olcott

unread,

May 4, 2022, 1:46:20 PM5/4/22

to

I made this same mistake for many years.
Now I refer to the conventional HP proof counter-examples.

olcott

unread,

May 4, 2022, 1:57:37 PM5/4/22

to

BEGIN:(Clocksin & Mellish 2003:254)
Finally, a note about how Prolog matching sometimes differs from the
unification used in Resolution. Most Prolog systems will allow you to
satisfy goals like:

equal(X, X).
?- equal(foo(Y), Y).

that is, they will allow you to match a term against an uninstantiated
subterm of itself. In this example, foo(Y) is matched against Y, which
appears within it. As a result, Y will stand for foo(Y), which is
foo(foo(Y)) (because of what Y stands for), which is foo(foo(foo(Y))),
and so on. So Y ends up standing for some kind of infinite structure.

<inserted for clarity>
foo(foo(foo(foo(foo(foo(foo(foo(foo(foo(foo(foo(...))))))))))))
</inserted for clarity>

Note that, whereas they may allow you to construct something like this,
most Prolog systems will not be able to write it out at the end.
According to the formal definition of Unification, this kind of
“infinite term” should never come to exist. Thus Prolog systems that
allow a term to match an uninstantiated subterm of itself do not act
correctly as Resolution theorem provers. In order to make them do so, we
would have to add a check that a variable cannot be instantiated to
something containing itself. Such a check, an occurs check, would be
straightforward to implement, but would slow down the execution of
Prolog programs considerably. Since it would only affect very few
programs, most implementors have simply left it out 1.

1 The Prolog standard states that the result is undefined if a Prolog
system attempts to match a term against an uninstantiated subterm of
itself, which means that programs which cause this to happen will not
be portable. A portable program should ensure that wherever an occurs
check might be applicable the built-in predicate
unify_with_occurs_check/2 is used explicitly instead of the normal
unification operation of the Prolog implementation. As its name
suggests, this predicate acts like =/2 except that it fails if an occurs
check detects an illegal attempt to instantiate a variable.
END:(Clocksin & Mellish 2003:254)

Clocksin, W.F. and Mellish, C.S. 2003. Programming in Prolog Using the
ISO Standard Fifth Edition, 254. Berlin Heidelberg: Springer-Verlag.

>> It is generally the case that every expression of any natural of
>> formal language that cannot be derived by applying truth preserving
>> operations (such as Prolog rules) to expressions known to be true
>> (such as Prolog facts) cannot possibly be correctly construed as true.
>>
>> Dogs are animals (purely analytic)
>> There is a small dog in my living room right now (Empirical).
>>
>> This is true for the entire body of analytic knowledge which only
>> excludes expressions of language that rely on sense data from the
>> sense organs to verify truth.
>>
>> The proof that this is correct is that no counter-examples exist.
>> When G is considered true and unprovable there is some way the "true"
>> is derived, it is not merely a wild guess.
>>
>> Just like Prolog databases True is limited to a specific formal
>> system, one formal system is the entire body of analytic knowledge:
>> EBAK. This is an entirely different formal system than PA.
>>
>> unprovable in PA and true in EBAC is not the same thing as true and
>> unprovable. unprovable in PA means not true in PA, and true in EBAC
>> means provable in EBAC.
>
> Nothing in this response is relevant to the responded message.
> In particular, none of the simple questions were answered.
>
> Mikko
>

olcott

unread,

May 4, 2022, 2:09:49 PM5/4/22

to

On 5/4/2022 2:31 AM, Mikko wrote:
> On 2022-05-03 18:26:21 +0000, Mr Flibble said:
>
>> On Tue, 3 May 2022 12:31:44 +0300
>> Mikko <mikko....@iki.fi> wrote:
>>
>>> On 2022-05-02 15:47:32 +0000, Mr Flibble said:
>>>
>>>> Not all infinitely recursive definitions are invalid however
>>>> infinitely recursive definitions that arise out of a category error
>>>> (as is the case with the halting problem) are invalid.
>>>
>>> An infinite recursion cannot arise out of a category error as the
>>> recursion stops at the category error.
>>
>> Which is kind of my point: the category error is what makes the
>> infinite recursion invalid thus rendering the halting problem
>> definition itself invalid and any proofs predicated on it.
>
> Category error does not make the infinite recursion invalid, just
> irrelevant. The sentence containing the category error wourld be
> invalid even whithout the infinite recursion.
>

Infinite recursion prevents an expression of language from being a logic
sentence.

https://en.wikipedia.org/wiki/Sentence_(mathematical_logic)#:~:text=In%20mathematical%20logic%2C%20a%20sentence,must%20be%20true%20or%20false.

When we try to evaluate an expression of language that is not a logic
sentence / truth bearer for its truth value that is just like asking:
Is this banana true?

> There is no category error in the Halting problem. Neither Mr Flibble
> nor anyone else has identified a word of wrong category in the problem.
>
> Mikko
>

Flibble was very helpful with his use of the term Category Error here is
one very great way to apply it:

There is certainly a category error in:
(a) The formalized Liar Paradox
(b) Gödel 1931 Incompleteness
(c) 1936 Tarski undefinability

In each of these cases the respective LP, G, and P are assumed to belong
in the category of logic sentence, and they do not actually belong in
this category.

In English only declarative sentences have a truth value. Trying to
determine the truth value of an interrogatory sentence is a category
error. Likewise the same error occurs when trying to determine the truth
value of an expression of formal language that is not a logic sentence.

olcott

unread,

May 4, 2022, 3:27:43 PM5/4/22

to

I adapted my system so that I could empirically test this:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct

Both deciders correctly report on the actual behavior of their actual
input. This can be verified by carefully studying their execution trace.

I have had some serious health issues that could have killed me last week.

>
> The specification of TM's is your stumbling block, so you could be doing
> that in parallel.

I like to go through all of the best steps in order. Having a machine to
execute TM's is the first step.

(a) Deciding to get around to start this project took weeks when dealing
with my other issues.

(b) No setting up the tedious syntax of reading a file of text lines
took much longer than usual, I usually cut-and-paste.

(c) I studied enough of the
http://www.lns.mit.edu/~dsw/turing/turing.html
To realize it was a superb architecture yet an overly complex
implementation.

Other people can read much faster than me, yet they lose a lot of
meaning when they read this fast. I usually read something over and over
until I have 100% complete understanding.

When I was reading the specs for how VISA changed their system so that I
could adapt the bank's system to meet these changed specs I had to read
the VISA material 17 times. I only had to read the Discover card changes
three times.

>
>> I think that it is a great idea to move in this direction.
>> I may eventually convert C copy of the TM into a RASP machine.
>
> Do ever read what you write? What is a "C copy of the TM"? I think you
> mean the TM interpreter that you've decided to write so as to delay
> actually writing even a trivial TM.
>

I am going to write a TM interpreter in C++. Sometime after I get done
with this I may adapt it to becoming an RASP machine. I will keep the
original TM interpreter and not simply overwrite it with the RASP
machine. This requires that the changes must be to a copy of the TM
interpreter.

Richard Damon

unread,

May 4, 2022, 6:51:45 PM5/4/22

to

On 5/4/22 12:24 PM, olcott wrote:
> On 5/4/2022 6:15 AM, Ben wrote:
>> olcott <polc...@gmail.com> writes:
>>
>>> Even infinitely recursive math expressions are semantically incorrect
>>> in that they can never be evaluated.
>>
>> Someone with no education in mathematics makes a bold claim about
>> mathematical concepts without defining any of then, and for some reason
>> a discussion ensues on Usenet. Let me get snacks...
>>
>
> I have spent thousands of hours on this point.
> When the evaluation directed graph of an expression has an infinite
> cycle. See page 4.
>
> https://www.researchgate.net/publication/350789898_Prolog_detects_and_rejects_pathological_self_reference_in_the_Godel_sentence
>
>

Which shows that Prolog's limited logic capability can't handle (with
that method) this form of logic.

I don't think Prolog can handle the properties of mathematics, so I
suspect that you are just showing that you logic syste is to primative
to handle the complexity needed to handle the incompleteness proof
(which states the minimum capability of the logic system to apply) or
Computation theory.

So, baseing your rejection on the limitations of Prolog just show your
lack of understand of what you are claiming.

Richard Damon

unread,

May 4, 2022, 6:53:48 PM5/4/22

to

And Prolog implements a logic system simpler than needed to handle the
proof you are talking about.

Prolog can't handle the needed logic to express the needed properties of
mathematics, so you "proof" just fails.

Richard Damon

unread,

May 4, 2022, 7:23:13 PM5/4/22

to

It seems that you are making the eror of confusing the Halting Problem,
with the Halting Problem Theorem, with the proof of the Theorem.

THe Halting problem, is simply the challange to try to create a
"Program" (i.e a Turing Macnine) that can answer the question (by giving
it an appropriate repesentation) if a given Computation (or Program
given an specific input) will Halt in finite time or run forever. That
is ALL there is to the problem, besides the details of the ground rules
of what the programs can be (which is where making everything Turing
Machines makes things simpler, as the ground rules become simpler to
state). This is what the First Sentence Describes.

The Halting Problem Theorem, is that there does not exist a program that
fully meets the requirements of the problem for all possible inputs.
This is what the second Sentence talks about. This is in the article
about the Halting Problem, because it is ABOUT the Halting Problem, even
if it isn't the problem itself.

Then the second paragraph is a summary of the proof of the Halting
Problme Theorem. Again, it isn't the Halting Problem itself, (Just as a
discussion of the History of the Halting Problem isn't part of the
defintion of the problem).

Ben

unread,

May 4, 2022, 8:59:17 PM5/4/22

to

>> someone will talk to you about [whatever] it is that your H is
>> deciding.

So you won't admit that no algorithm can do what D is specified to do?
You are just going to pretend that no one cares about actual halting.

I hope you see that by ignoring this point you are confirming that you
know D can't exist. If you thought such a D was possible, you'd be
shouting that from the roof tops since it's what everyone else says is
impossible.

> I adapted my system so that I could empirically test this:
> H1(P,P)==true is empirically proven to be correct
> H(P,P)==false is empirically proven to be correct

But neither can tell us squat about the halting of P(P) -- the thing
that H was originally supposed to decide.

> Both deciders correctly report on the actual behavior of their actual
> input. This can be verified by carefully studying their execution
> trace.

But neither can tell us what we want. Your H does not meet D's
specification, but you are not brave enough to admit that you now know
that D can't exist because denying that is what got you started down
this rabbit hole 18 years ago.

You have been able to write dozens of posts, so why not the few words
needed to specify P, or the few states needed for E? And even now
you've taken on a task that seems too much for you rather than get down
to writing and specifying a TM. It looks like avoidance.

>> The specification of TM's is your stumbling block, so you could be doing
>> that in parallel.
>
> I like to go through all of the best steps in order. Having a machine
> to execute TM's is the first step.

The firsts step is to be able to specify a TM. You can't have anything
to execute of you can't specify it. It's just avoidance.

> (a) Deciding to get around to start this project took weeks when
> dealing with my other issues.

You decided to start weeks ago. Then you gave up.

> (b) No setting up the tedious syntax of reading a file of text lines
> took much longer than usual, I usually cut-and-paste.

What? I thought you knew C++ and could write code.

> (c) I studied enough of the
> http://www.lns.mit.edu/~dsw/turing/turing.html
> To realize it was a superb architecture yet an overly complex
> implementation.

I hate it, but you chose it /five years ago/. Five years ago I
suggested a simple exercise and you bailed them. I'd forgotten that. I
should learn, shouldn't I?

olcott

unread,

May 4, 2022, 9:19:34 PM5/4/22

to

Are you simply wired to ignore my words so that you can disagree with
everything that I say?

H1(P,P)==true reports on the behavior of P(P).

>> Both deciders correctly report on the actual behavior of their actual
>> input. This can be verified by carefully studying their execution
>> trace.
>
> But neither can tell us what we want.

H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).
H1(P,P)==true reports on the behavior of P(P).

I am a concrete thinker, abstractions are always far too vague.

>> (a) Deciding to get around to start this project took weeks when
>> dealing with my other issues.
>
> You decided to start weeks ago. Then you gave up.

I am dead set on finishing it now.

>
>> (b) No setting up the tedious syntax of reading a file of text lines
>> took much longer than usual, I usually cut-and-paste.
>
> What? I thought you knew C++ and could write code.
>

On this tedious syntax details I always cut-and-paste from working code.
I hate tedious syntax details. Engineering algorithms is what I enjoy.

>> (c) I studied enough of the
>> http://www.lns.mit.edu/~dsw/turing/turing.html
>> To realize it was a superb architecture yet an overly complex
>> implementation.
>
> I hate it, but you chose it /five years ago/. Five years ago I
> suggested a simple exercise and you bailed them. I'd forgotten that. I
> should learn, shouldn't I?
>

I don't hate it, it does have a superb architecture that I will quickly
implement. I don't want to have to always enter the tape initialization
manually and want this in the machine description file.

Ben

unread,

May 4, 2022, 10:29:37 PM5/4/22

to

I try to ignore that bits that are irrelevant. These two deciders
decide all halting instances between them:

bool H1(X, Y) { return true; }
bool H2(X, Y) { return false; }

Neither is interesting. For H1, the key case is H1(H1_hat, H1_hat) or
maybe you call it H1(P1,P1) now since P is what you used to call H_hat.

>>> Both deciders correctly report on the actual behavior of their actual
>>> input. This can be verified by carefully studying their execution
>>> trace.
>> But neither can tell us what we want.
>
> H1(P,P)==true reports on the behavior of P(P).

So what? That some functions gets the right answer for P is irrelevant.
H1 is just as wrong about it's "P" as H is. You know all this. We went
through it years ago.

Your H does not tell us about H_hat(H_hat), and your new mantra about
what it does tell us about is just an admission that fails to do what
the world correctly claims is impossible.

>> Your H does not meet D's
>> specification, but you are not brave enough to admit that you now know
>> that D can't exist because denying that is what got you started down
>> this rabbit hole 18 years ago.

Still nothing about this. You need to come clean and admit that your
mantra has nothing to do with what other people care about: a D such
that D(X,Y) == true if and only if X(Y) halts and false otherwise.

This is why you are wrong. You have nothing to say anymore about the
function the rest of the world is talking about.

>>> (a) Deciding to get around to start this project took weeks when
>>> dealing with my other issues.
>>
>> You decided to start weeks ago. Then you gave up.
>
> I am dead set on finishing it now.

But not yet. First, pointlessly re-implement an TM interpreter by
cutting and pasting code:

>>> (b) No setting up the tedious syntax of reading a file of text lines
>>> took much longer than usual, I usually cut-and-paste.
>>
>> What? I thought you knew C++ and could write code.
>
> On this tedious syntax details I always cut-and-paste from working
> code. I hate tedious syntax details. Engineering algorithms is what I
> enjoy.

olcott

unread,

May 4, 2022, 10:55:07 PM5/4/22

to

Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines that
its input halts and the other correctly determines that its input does
not halt. ALL THESE THINGS ARE VERIFIED FACTS !

I know that you can't verify that these are facts yet imagine they are
the facts. In that case I have totally proved that I am correct.

Other people can look at in this in my paper:

Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

There is enough material in my first paper to verify that everything in
the first paragraph is a fact for people having sufficient expertise in
the x86 language and good familiarity with the halting problem.

Dennis Bush

unread,

May 4, 2022, 10:59:01 PM5/4/22

to

If that is so then H and H1 don't perform the same mapping. This means that one (or both) do not compute the halting function.

So which one doesn't compute the halting function?

olcott

unread,

May 4, 2022, 11:09:35 PM5/4/22

to

*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*

André G. Isaak

unread,

May 4, 2022, 11:17:45 PM5/4/22

to

On 2022-05-04 21:09, olcott wrote:
> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:

>>> H1(P,P)==true is empirically proven to be correct
>>> H(P,P)==false is empirically proven to be correct
>>
>> If that is so then H and H1 don't perform the same mapping. This
>> means that one (or both) do not compute the halting function.
>>
>> So which one doesn't compute the halting function?

You didn't actually answer this question.

> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> Both take the machine code of P as input parameters and are provably
> correct simulations of this same input yet one correctly determines that
> its input halts and the other correctly determines that its input does
> not halt.

Please define your use of the term "correct simulation".

André

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

Dennis Bush

unread,

May 4, 2022, 11:20:35 PM5/4/22

to

Which means at least one is not computing the halting function. So which one is it?

olcott

unread,

May 4, 2022, 11:35:33 PM5/4/22

to

Good question.
The behavior of the simulated input exactly matches the correct
execution trace of the behavior in a real hardware machine.

olcott

unread,

May 4, 2022, 11:38:54 PM5/4/22

to

The above paragraph means that it makes no mistakes in computing the
halting function. This is a verifiable fact, not any mere opinion. The
reason that I did the HP in C/x86 was so that every detail can be shown
thus gaps in reasoning revealed.

André G. Isaak

unread,

May 4, 2022, 11:38:58 PM5/4/22

to

On 2022-05-04 21:35, olcott wrote:
> On 5/4/2022 10:17 PM, André G. Isaak wrote:
>> On 2022-05-04 21:09, olcott wrote:
>>> On 5/4/2022 9:59 PM, Dennis Bush wrote:
>>>> On Wednesday, May 4, 2022 at 10:55:07 PM UTC-4, olcott wrote:
>>
>>>>> H1(P,P)==true is empirically proven to be correct
>>>>> H(P,P)==false is empirically proven to be correct
>>>>
>>>> If that is so then H and H1 don't perform the same mapping. This
>>>> means that one (or both) do not compute the halting function.
>>>>
>>>> So which one doesn't compute the halting function?
>>
>> You didn't actually answer this question.
>>
>>> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
>>> Both take the machine code of P as input parameters and are provably
>>> correct simulations of this same input yet one correctly determines
>>> that its input halts and the other correctly determines that its
>>> input does not halt.
>>
>> Please define your use of the term "correct simulation".
>>
>> André
>>
>>
>
> Good question.
> The behavior of the simulated input exactly matches the correct
> execution trace of the behavior in a real hardware machine.

So if P(P), when executed directly, halts, how can a 'correct
simulation' possibly not halt?

olcott

unread,

May 4, 2022, 11:42:53 PM5/4/22

to

As soon as you very carefully study every single detail of the above
paragraph you will realize that it proves that I am correct as soon as
the paragraph itself is proved to be factually correct.

Dennis Bush

unread,

May 4, 2022, 11:44:00 PM5/4/22

to

Any decider that maps the halting function performs the *same* mapping of inputs to outputs. Since H and H1 perform different mappings they can't possibly both map the halting function.

So which one doesn't?

Dennis Bush

unread,

May 4, 2022, 11:50:12 PM5/4/22

to

Would you then also agree that Ha3(N,5) == false and Ha7(N,5) == true are both correct because both perform a provably correct simulation their input, so that Ha3 correctly determines that its input does not halt while Ha7 correctly determines that its input halts?

If not, then clarify your correctness criteria so that it can apply to *any* input and *any* decider such that it shows that Ha3(N,5) does not perform a correct simulation but H(P,P) does.

olcott

unread,

May 4, 2022, 11:54:14 PM5/4/22

to

That is now proven to be factually incorrect.

If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly. The above paragraph can
be proven to be a fact.

> Since H and H1 perform different mappings they can't possibly both map the halting function.
>
> So which one doesn't?

olcott

unread,

May 4, 2022, 11:58:50 PM5/4/22

to

I am not going to go through any of your extraneous nonsense.

*ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
Both take the machine code of P as input parameters and are provably
correct simulations of this same input yet one correctly determines
that its input halts and the other correctly determines that its
input does not halt.

If the above paragraph is proven to be a fact then this proves that both
H and H1 compute the halting function correctly.

Try to point to any gaps in this reasoning.

Dennis Bush

unread,

May 5, 2022, 12:07:48 AM5/5/22

to

If you can't explain why Ha3(N,5) == false is incorrect then you can't explain why H(P,P) == false is correct.

> *ALL THESE THINGS ARE EASILY VERIFIABLE FACTS*
> Both take the machine code of P as input parameters and are provably
> correct simulations of this same input yet one correctly determines
> that its input halts and the other correctly determines that its
> input does not halt.
> If the above paragraph is proven to be a fact then this proves that both
> H and H1 compute the halting function correctly.
> Try to point to any gaps in this reasoning.

You defined "correct simulation" as:

The behavior of the simulated input exactly matches the correct
execution trace of the behavior in a real hardware machine

The correct execution trace of the behavior of P(P) in a real hardware machine is halting. The behavior of the simulated input H(P,P) is non-halting.

Therefore your claim that H(P,P) performs a "provably correct simulation" is FALSE.

Dennis Bush

unread,

May 5, 2022, 12:12:32 AM5/5/22

to

Just because a simulating halt decider aborts doesn't necessarily mean it was correct to do so. On the other hand, a simulating halt decider that simulates to a final state is always correct and proves that any mapping of the same input to non-halting is necessarily incorrect.

> >
> > Any decider that maps the halting function performs the *same* mapping of inputs to outputs.
> That is now proven to be factually incorrect.

FALSE. The mapping of the halting function is DEFINED (i.e. is immutable and fixed) as:

M w maps to true if and only if M(w) halts, and
M w maps to false if and only if M(w) does not halt

So any halt decider that does not compute this *exact* mapping is not computing the halting function.

olcott

unread,

May 5, 2022, 12:48:29 AM5/5/22

to

Both H(P,P) and H1(P,P) are provably correct.

> The behavior of the simulated input H(P,P) is non-halting.
>
> Therefore your claim that H(P,P) performs a "provably correct simulation" is FALSE.
>

olcott

unread,

May 5, 2022, 12:49:27 AM5/5/22

to

Both H(P,P) and H1(P,P) are provably correct.

>>

Mikko

unread,

May 5, 2022, 5:19:50 AM5/5/22

to

On 2022-05-02 15:47:32 +0000, Mr Flibble said:

> Not all infinitely recursive definitions are invalid however infinitely
> recursive definitions that arise out of a category error (as is the
> case with the halting problem) are invalid.
>
> The halting problem (as currently defined) is invalid due to the
> invalid "impossible program" [Strachey, 1965] that is actually
> impossible due to the category error present in its definition and
> *not* because of any function call-like recursion; confusion between
> these two types of recursion are why Olcott is having difficulty
> communicating his ideas with the rest of you shower.
>
> The categories involved in the category error are the decider and that
> which is being decided. Currently extant attempts to conflate the
> decider with that which is being decided are infinitely
> recursive and thus invalid.

There is no category error in the theorem. An infinitely recursive
computation is still in the category of computations. Its behaviour
is well defined and it either halts in finite time (in which case
it isn't actually infinitely recursive) or it does not (either because
it is infinitely recursive or because of some other cause). Therefore
the claim that there is a category error in the theorem is invalid.

Mikko

Mikko

unread,

May 5, 2022, 5:37:14 AM5/5/22

to

Nice that you now agree and retract your earlier statement.

Mikko