From Newsgroup: comp.theory

It is conventional[1] common knowledge that for every
halt decider their is an input that does the opposite
of whatever this decider reports, thus thwarting this
decider. My HHH(DD)

It is also conventional[1] common knowledge that another
halt decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable
when as Kaz believes DD always specifies the exact same
behavior?




[1] This conventional knowledge is mistaken yet that is
another different point.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am 17.09.2025 um 00:35 schrieb olcott:

It is conventional[1] common knowledge that for every
halt decider their is an input that does the opposite
of whatever this decider reports, thus thwarting this
decider. My HHH(DD)

It is also conventional[1] common knowledge that another
halt decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable
when as Kaz believes DD always specifies the exact same
behavior?

[1] This conventional knowledge is mistaken yet that is
another different point.

The therapist that matches you has yet to be born.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider their
is an input that does the opposite of whatever this decider reports,
thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider
can correctly decide this same input. My HHH1(DD).
How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz
believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-16 22:35:43 +0000, olcott said:

It is conventional[1] common knowledge that for every
halt decider their is an input that does the opposite
of whatever this decider reports, thus thwarting this
decider. My HHH(DD)

Above "every halt decider" is too restrictive: as there is no
halt decider the statement is vacuous. Instead one should sya
that for every decider there is an input that runs forever if
the decider accepts but halts if the deider rejects, proving
that decider is not a halt decider.

It is also conventional[1] common knowledge that another
halt decider can correctly decide this same input. My HHH1(DD).

A decider that decides correctly that input is easy to make.
Either one that always accepts of one that always rejects is
good enough.

How can HHH(DD) be undecidable and HHH1(DD) be decidable
when as Kaz believes DD always specifies the exact same
behavior?

HHH(DD) is not undecidable. Just run HHH(DD) to see what it
says.

[1] This conventional knowledge is mistaken yet that is
another different point.

It is always conventional knowledge that what is soundly
proven is true. This includes that halting is undecidable.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 17.sep.2025 om 00:35 schreef olcott:

It is conventional[1] common knowledge that for every
halt decider their is an input that does the opposite
of whatever this decider reports, thus thwarting this
decider. My HHH(DD)

Yes, for every decider at least one input exists for which the decider
fails and returns an incorrect result. Your HHH(DD) fails for this input.

It is also conventional[1] common knowledge that another
halt decider can correctly decide this same input. My HHH1(DD).

That is not always true. For some inputs we have not (yet?) found a
decider that provides a correct answer. It certainly has not been proven
that for each input there exists a decider that returns the correct result. But, indeed, in this case your HHH1 returns the correct result for this
input.

How can HHH(DD) be undecidable and HHH1(DD) be decidable
when as Kaz believes DD always specifies the exact same
behavior?

HHH(DD) is not undecidable. HHH(DD) just fails to return the correct
result. There is a correct result and HHH1 returns it. There is no
problem to see that some programs fail and others do not.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider their
is an input that does the opposite of whatever this decider reports,
thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider
can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz
believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable
instance I am forced to use that made up term.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 2:34 AM, Mikko wrote:

On 2025-09-16 22:35:43 +0000, olcott said:

It is conventional[1] common knowledge that for every
halt decider their is an input that does the opposite
of whatever this decider reports, thus thwarting this
decider. My HHH(DD)

Above "every halt decider" is too restrictive: as there is no
halt decider the statement is vacuous. Instead one should sya
that for every decider there is an input that runs forever if
the decider accepts but halts if the deider rejects, proving
that decider is not a halt decider.

That is counterfactual as I have proven.
When the simulating termination analyzer bases its
decision on the actual behavior actually specified
by its input then the case you cited never arises.

That you always switch this to some other criteria
is the dishonest use of the strawman error

It is also conventional[1] common knowledge that another
halt decider can correctly decide this same input. My HHH1(DD).

A decider that decides correctly that input is easy to make.
Either one that always accepts of one that always rejects is
good enough.

Yet you jumped ahead bypassing my main point.

How can HHH(DD) be undecidable and HHH1(DD) be decidable
when as Kaz believes DD always specifies the exact same
behavior?

HHH(DD) is not undecidable. Just run HHH(DD) to see what it
says.

Conventional understanding is that it is undecidable.

[1] This conventional knowledge is mistaken yet that is
another different point.

It is always conventional knowledge that what is soundly
proven is true. This includes that halting is undecidable.

You just disagreed with the in the prior statement that
I responded to.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider
their is an input that does the opposite of whatever this decider
reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider
can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz
believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced
to use that made up term.

Every instance is decidable.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider
their is an input that does the opposite of whatever this decider
reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider
can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz
believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced
to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider
has an undecidable input. I have refuted this
yet conventional wisdom currently remains the same.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-17, olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider
their is an input that does the opposite of whatever this decider
reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider >>>>> can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz >>>>> believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced
to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider
has an undecidable input.

No; that is just one man's misconcept or misuse of terminology.

I have refuted this
yet conventional wisdom currently remains the same.

The conventional wisdom is that the set of inputs consisting
of a single case like { DD } is decidable. There is an algorithm
which, for every element of that set, will halt with the correct
answer. There is no algorithm for the global union of all such sets that
exist.

For an input I to have undecidable halting would mean that for the set
{ I }, there is no algorithm that will terminate with the correct answer
for every element of the set. I.e. nothing can decide I.

There is no such thing as "undecidable to a specific function, but
decidable to others". To have such usage, you would have to
change/overload the deeply entrenched meanings of the existing terms "decidable" and "undecidable", which is a terrible idea when those
concepts, and their standard terminology, are at the core of your argumentation.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider
their is an input that does the opposite of whatever this decider
reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider >>>>> can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz >>>>> believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced
to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt
decider".

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

I have refuted this ....

Stop lying.

.... yet conventional wisdom currently remains the same.

The halting theorem has been proven by elegant and simple ways which are
self evidently correct. Only ill-educated fools question it or them.

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

--
Alan Mackenzie (Nuremberg, Germany).

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 17/09/2025 16:43, olcott wrote:

It is conventional wisdom that each halt decider
has an undecidable input. I have refuted this
yet conventional wisdom currently remains the same.

Yeah, we saw. You refuted it by deciding that a wrong decision is
still a decision, dammit.

DD halts.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 1:07 PM, Kaz Kylheku wrote:

On 2025-09-17, olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider >>>>>> their is an input that does the opposite of whatever this decider
reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider >>>>>> can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz >>>>>> believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced >>>> to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider
has an undecidable input.

No; that is just one man's misconcept or misuse of terminology.

I stipulate that term because the theory of computation
has no term for undecidable instance. This has the same
effect as https://en.wikipedia.org/wiki/Doublespeak
hiding lies by making truth inexpressible.

I have refuted this
yet conventional wisdom currently remains the same.

The conventional wisdom is that the set of inputs consisting
of a single case like { DD } is decidable.

Bullshit on that. There is an input for what would otherwise
be a universal halt decider that screws up each deciders
decision.

There is an algorithm
which, for every element of that set, will halt with the correct
answer. There is no algorithm for the global union of all such sets that exist.

That gets too far away from the exact point.

For an input I to have undecidable halting would mean that for the set
{ I }, there is no algorithm that will terminate with the correct answer
for every element of the set. I.e. nothing can decide I.

I am stipulating a new term-of-the art that the HP proof
counter-example input is an [undecidable instance] for its
corresponding HP proof halt decider.

There is no such thing as "undecidable to a specific function, but
decidable to others". To have such usage, you would have to

I WILL NOT BE BLOCKED FROM SAYING WHAT I NEED TO SAY
BY THE DOUBLESPEAK LIMITATION OF CONVENTIONAL TERMS OF THE ART.

change/overload the deeply entrenched meanings of the existing terms "decidable" and "undecidable", which is a terrible idea when those
concepts, and their standard terminology, are at the core of your argumentation.

Until something better comes along this will be
called an undecidable instance.

Its already a crackpot idea to call a TM that simply
ignores its input any kind of DECIDER. It does not
decide jack shit.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider >>>>>> their is an input that does the opposite of whatever this decider
reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider >>>>>> can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz >>>>>> believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced >>>> to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt decider".

That is too cumbersome.
It is a jackass idea that a decider is any more
specific than someone or something that decides.

It is freaking nuts that "decider" in computer
science means all knowing mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt
decider is to report on the actual behavior that
its actual finite string input actually specifies
DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

.... yet conventional wisdom currently remains the same.

The halting theorem has been proven by elegant and simple ways which are
self evidently correct. Only ill-educated fools question it or them.

Unless one bothers to define the job of a halt
decider correctly, thus eliminate the implied
requirement that a halt decider uses its psychic
power to REPORT ON BEHAVIOR THAT IT CANNOT SEE.

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

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider >>>>>>> their is an input that does the opposite of whatever this decider >>>>>>> reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt
decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as >>>>>>> Kaz believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not). >>>>>> Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am
forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt
decider".

That is too cumbersome.
It is a jackass idea that a decider is any more specific than someone or something that decides.

It is freaking nuts that "decider" in computer science means all knowing
mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt decider is to report
on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

You are incorrect to the greatest degree because it is perfectly valid to
pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

/Flibble
--
meet ever shorter deadlines, known as "beat the clock"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider >>>>>>>> their is an input that does the opposite of whatever this decider >>>>>>>> reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt
decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as >>>>>>>> Kaz believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not). >>>>>>> Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am
forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt
decider".

That is too cumbersome.
It is a jackass idea that a decider is any more specific than someone or
something that decides.

It is freaking nuts that "decider" in computer science means all knowing
mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt decider is to report
on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

You are incorrect to the greatest degree because it is perfectly valid to pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

/Flibble

When understanding the meaning of my words
the tiniest slight paraphrase can result in
deception. HHH does freaking not take the
executable process of its caller as its input.

HHH cannot see the behavior of its caller or
which function is calling it.

A halt decider cannot use psychic power to
REPORT ON BEHAVIOR THAT IT CANNOT SEE.

Thus the job of a halt decider is to report
on the actual behavior that its actual finite
string input actually specifies.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Wed, 17 Sep 2025 13:46:22 -0500, olcott wrote:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt
decider their is an input that does the opposite of whatever >>>>>>>>> this decider reports, thus thwarting this decider. My HHH(DD). >>>>>>>>> It is also conventional[1] common knowledge that another halt >>>>>>>>> decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as >>>>>>>>> Kaz believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or
not).
Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am
forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt
decider".

That is too cumbersome.
It is a jackass idea that a decider is any more specific than someone
or something that decides.

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt decider is to report
on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

You are incorrect to the greatest degree because it is perfectly valid
to pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

/Flibble

When understanding the meaning of my words the tiniest slight paraphrase
can result in deception. HHH does freaking not take the executable
process of its caller as its input.

HHH cannot see the behavior of its caller or which function is calling
it.

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.

But it CAN SEE IT because it is given a REPRESENTATION (DESCRIPTION) of it
as an INPUT - the fact that your approach doesn't allow for this is just
an indication that your approach is totally wrong.

/Flibble
--
meet ever shorter deadlines, known as "beat the clock"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 1:50 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:46:22 -0500, olcott wrote:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt >>>>>>>>>> decider their is an input that does the opposite of whatever >>>>>>>>>> this decider reports, thus thwarting this decider. My HHH(DD). >>>>>>>>>> It is also conventional[1] common knowledge that another halt >>>>>>>>>> decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as >>>>>>>>>> Kaz believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or >>>>>>>>> not).
Every single program halts or doesn't. HHH simply gets it wrong. >>>>>

Unless there is a correct term for an undecidable instance I am >>>>>>>> forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt >>>>> decider".

That is too cumbersome.
It is a jackass idea that a decider is any more specific than someone
or something that decides.

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt decider is to report >>>> on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

You are incorrect to the greatest degree because it is perfectly valid
to pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

/Flibble

When understanding the meaning of my words the tiniest slight paraphrase
can result in deception. HHH does freaking not take the executable
process of its caller as its input.

HHH cannot see the behavior of its caller or which function is calling
it.

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.

But it CAN SEE IT because it is given a REPRESENTATION (DESCRIPTION)

That is not 100% exactly the same as the behavior
of main()--->DD().

I have conclusively proven this hundreds of times
over the last three years and people consistently
favor dishonest denigration over truth.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Wed, 17 Sep 2025 13:55:35 -0500, olcott wrote:

On 9/17/2025 1:50 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:46:22 -0500, olcott wrote:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt >>>>>>>>>>> decider their is an input that does the opposite of whatever >>>>>>>>>>> this decider reports, thus thwarting this decider. My HHH(DD). >>>>>>>>>>> It is also conventional[1] common knowledge that another halt >>>>>>>>>>> decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when >>>>>>>>>>> as Kaz believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or >>>>>>>>>> not).
Every single program halts or doesn't. HHH simply gets it
wrong.

Unless there is a correct term for an undecidable instance I am >>>>>>>>> forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_
halt decider".

That is too cumbersome.
It is a jackass idea that a decider is any more specific than
someone or something that decides.

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides >>>>>> wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt decider is to
report on the actual behavior that its actual finite string input
actually specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST
DEGREE.

You are incorrect to the greatest degree because it is perfectly
valid to pass to a halt decider an INPUT that represents a
DESCRIPTION of its CALLER.

/Flibble

When understanding the meaning of my words the tiniest slight
paraphrase can result in deception. HHH does freaking not take the
executable process of its caller as its input.

HHH cannot see the behavior of its caller or which function is calling
it.

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.

But it CAN SEE IT because it is given a REPRESENTATION (DESCRIPTION)

That is not 100% exactly the same as the behavior of main()--->DD().

I have conclusively proven this hundreds of times over the last three
years and people consistently favor dishonest denigration over truth.

The only way your assertion could be correct would be if it is impossible
to prove that the HHH in a description of the caller (as an input) cannot
be gauranteed to be the same HHH that is doing the reporting. Your
approach does gaurantee this however because your HHH takes a machine
address rather than a finite string representation of its caller so you
don't have a leg to stand on.

/Flibble
--
meet ever shorter deadlines, known as "beat the clock"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 2:09 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:55:35 -0500, olcott wrote:

On 9/17/2025 1:50 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:46:22 -0500, olcott wrote:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt >>>>>>>>>>>> decider their is an input that does the opposite of whatever >>>>>>>>>>>> this decider reports, thus thwarting this decider. My HHH(DD). >>>>>>>>>>>> It is also conventional[1] common knowledge that another halt >>>>>>>>>>>> decider can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when >>>>>>>>>>>> as Kaz believes DD always specifies the exact same behavior? >>>>>>>

For the umpteenth time: *Sets* of programs are decidable (or >>>>>>>>>>> not).
Every single program halts or doesn't. HHH simply gets it >>>>>>>>>>> wrong.

Unless there is a correct term for an undecidable instance I am >>>>>>>>>> forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_
halt decider".

That is too cumbersome.
It is a jackass idea that a decider is any more specific than
someone or something that decides.

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides >>>>>>> wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt decider is to
report on the actual behavior that its actual finite string input
actually specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST
DEGREE.

You are incorrect to the greatest degree because it is perfectly
valid to pass to a halt decider an INPUT that represents a
DESCRIPTION of its CALLER.

/Flibble

When understanding the meaning of my words the tiniest slight
paraphrase can result in deception. HHH does freaking not take the
executable process of its caller as its input.

HHH cannot see the behavior of its caller or which function is calling >>>> it.

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.

But it CAN SEE IT because it is given a REPRESENTATION (DESCRIPTION)

That is not 100% exactly the same as the behavior of main()--->DD().

I have conclusively proven this hundreds of times over the last three
years and people consistently favor dishonest denigration over truth.

The only way your assertion could be correct would be

If we don't stupidly expect a halt decider to report
on something that it cannot possibly see.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-17, olcott <polcott333@gmail.com> wrote:

I stipulate that term because the theory of computation
has no term for undecidable instance.

Yes it does. An undecidable instance is some specific problem
for which there is no algorithm.

This has the same
effect as https://en.wikipedia.org/wiki/Doublespeak
hiding lies by making truth inexpressible.

Doublespeak is what you are perpetrating by talking about
undecidability, while co-opting that same word for a different meaning,
in the same discussion and context.

I have refuted this
yet conventional wisdom currently remains the same.

The conventional wisdom is that the set of inputs consisting
of a single case like { DD } is decidable.

Bullshit on that. There is an input for what would otherwise
be a universal halt decider that screws up each deciders
decision.

No; there is a separate, distinct such input crafted for each
decider. Not one undecidable input.

See: you still don't understand it, yet want to dictate terminology.

For an input I to have undecidable halting would mean that for the set
{ I }, there is no algorithm that will terminate with the correct answer
for every element of the set. I.e. nothing can decide I.

I am stipulating a new term-of-the art that the HP proof
counter-example input is an [undecidable instance] for its
corresponding HP proof halt decider.

You don't get to stipulate terms of art until you make some kind
of dent in the world.

There is no such thing as "undecidable to a specific function, but
decidable to others". To have such usage, you would have to

I WILL NOT BE BLOCKED FROM SAYING WHAT I NEED TO SAY
BY THE DOUBLESPEAK LIMITATION OF CONVENTIONAL TERMS OF THE ART.

You are going to stay in this newsgroup and not amount to anything, for
the rest of your days.

change/overload the deeply entrenched meanings of the existing terms
"decidable" and "undecidable", which is a terrible idea when those
concepts, and their standard terminology, are at the core of your
argumentation.

Until something better comes along this will be
called an undecidable instance.

Its already a crackpot idea to call a TM that simply
ignores its input any kind of DECIDER. It does not
decide jack shit.

A decider that ignores its input and just returns 0 correctly decides
all calculations that do not terminate.

It is isn't a universal decider because it wrongly decides all other
programs, claiming that they also do not terminate.

Such a "stub" decider is useful in certain argumentation. It can be
used as the simplest illustration of a decider falling victim to a
diagonal case.

Whenever someone points out that your HHH is nowhere near a functioning
decider that could handle a large and useful set of programs, you start
crying about how you are not trying to solve universal halting, but only
to disprove a certain proof.

So in other words, you believe that your simplified machinery is
good enough for your purposes.

Yet you chide someone else for using a "return 0" decider that is
good enough for /their/ discussion purpose.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 17 Sep 2025 13:46:22 -0500 schrieb olcott:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

Unless there is a correct term for an undecidable instance I am
forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt
decider".

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

It means a terminating, total algorithm.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

That you do not understand that the job of a halt decider is to report
on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

Its job is to report on the direct execution of its input.

You are incorrect to the greatest degree because it is perfectly valid
to pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

When understanding the meaning of my words the tiniest slight paraphrase
can result in deception. HHH does freaking not take the executable
process of its caller as its input.

Like you just did. Flibble explicitly said "description".

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.
Thus the job of a halt decider is to report on the actual behavior that
its actual finite string input actually specifies.

Except HHH does not see correctly.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-17, olcott <polcott333@gmail.com> wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

On 9/17/2025 2:29 AM, joes wrote:

Am Tue, 16 Sep 2025 17:35:43 -0500 schrieb olcott:

It is conventional[1] common knowledge that for every halt decider >>>>>>> their is an input that does the opposite of whatever this decider >>>>>>> reports, thus thwarting this decider. My HHH(DD).
It is also conventional[1] common knowledge that another halt decider >>>>>>> can correctly decide this same input. My HHH1(DD).

How can HHH(DD) be undecidable and HHH1(DD) be decidable when as Kaz >>>>>>> believes DD always specifies the exact same behavior?

For the umpteenth time: *Sets* of programs are decidable (or not). >>>>>> Every single program halts or doesn't. HHH simply gets it wrong.

Unless there is a correct term for an undecidable instance I am forced >>>>> to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt
decider".

That is too cumbersome.
It is a jackass idea that a decider is any more
specific than someone or something that decides.

It is freaking nuts that "decider" in computer
science means all knowing mind of God.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

Too cumbersome.

I have refuted this ....

Stop lying.

That you do not understand that the job of a halt
decider is to report on the actual behavior that
its actual finite string input actually specifies
DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

.... yet conventional wisdom currently remains the same.

The halting theorem has been proven by elegant and simple ways which are
self evidently correct. Only ill-educated fools question it or them.

Unless one bothers to define the job of a halt
decider correctly, thus eliminate the implied
requirement that a halt decider uses its psychic
power to REPORT ON BEHAVIOR THAT IT CANNOT SEE.

The requirement is for an algorithm (a Turing computation) which
can decide whether any Turing computation halts.

Yes, that requirement does necessarily call for reporting on behavior
that the decider cannot see.

That's (one reason) why the problem is undecidable: the existence of
cases which run the decider on themselves and then do something that is
then beyond the power of the decider to do anything about: contradict
that answer.

This is in the nature of computation.

You cannot define an alternative halting problem which those
cases are ruled out.

Let's say that we drop the requirement for deciders to correctly answer
their diagonal cases, because we feel that they are unfair.

Let's call that the Relaxed Halting Problem: RHP.

Is RHP an easier problem than HP? Is it decidable?

The problem is that deciders under RPH are required to accuratrely
partition their input space. Given a test case P, they have to decide
whether it is an impossible-to-answer diagonal test case crafted against
them or whether it is not such a test case. If it is such a test case,
then they can give any answer without being judged incorrect.
If it is not such a test case, they are required to give the correct
answer.

The problem is that the decision whether the input P is diagonal
or not ... is an undecidable problem!!!

For a given decider H, the diagonal program D can be written in an
infinite number of ways. And the H which that program uses can itself
be written in an infinite number of ways, not just the D part.

You cannot tell those infinite number of cases apart from the
remaining infinity which are not those programs.

So your idea that the diagonal cases are pathological and wrong
does not help with decidability of halting, even if we accept it.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 17 Sep 2025 13:32:07 -0500 schrieb olcott:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

.... yet conventional wisdom currently remains the same.

The halting theorem has been proven by elegant and simple ways which
are self evidently correct. Only ill-educated fools question it or
them.

Unless one bothers to define the job of a halt decider correctly, thus eliminate the implied requirement that a halt decider uses its psychic
power to REPORT ON BEHAVIOR THAT IT CANNOT SEE.

But it could see it! Only then it is not a decider. HHH fails in the
other way, by closing its eyes. All the information about DD is right
there (except HHH hypothesizes about a different DD' that calls a
different non-aborting simulator). A hardware processor doesn't get
any different input.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-17, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

That you do not understand that the job of a halt decider is to report
on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

You are incorrect to the greatest degree because it is perfectly valid to pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

That caller is main:

int main() { if (HHH(DD)) { print this } else { print that }}

Yes; HHH is not required to report on its caller; it's required
to report on DD.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 17 Sep 2025 13:20:16 -0500 schrieb olcott:

On 9/17/2025 1:07 PM, Kaz Kylheku wrote:

On 2025-09-17, olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Every instance is decidable.

It is conventional wisdom that each halt decider has an undecidable
input.

No; that is just one man's misconcept or misuse of terminology.

I stipulate that term because the theory of computation has no term for undecidable instance.

See above: there are no undecidable instances, only "deciders" that
get them wrong.

The conventional wisdom is that the set of inputs consisting of a
single case like { DD } is decidable.

Bullshit on that. There is an input for what would otherwise be a
universal halt decider that screws up each deciders decision.

Weird way to say that every "decider" gets at least one input wrong.

There is an algorithm which, for every element of that set, will halt
with the correct answer. There is no algorithm for the global union of
all such sets that exist.

That gets too far away from the exact point.

No, that is exactly the point of the HP. You just want to distract.

For an input I to have undecidable halting would mean that for the set
{ I }, there is no algorithm that will terminate with the correct
answer for every element of the set. I.e. nothing can decide I.

I am stipulating a new term-of-the art that the HP proof counter-example input is an [undecidable instance] for its corresponding HP proof halt decider.

The existing term of the art is "wrong".

There is no such thing as "undecidable to a specific function, but
decidable to others". To have such usage, you would have to

I WILL NOT BE BLOCKED FROM SAYING WHAT I NEED TO SAY BY THE DOUBLESPEAK LIMITATION OF CONVENTIONAL TERMS OF THE ART.

lol. There is no input such that every TM returns the wrong value.
If you are already convinced that DD doesn't halt, you can shorten
HHH to {return 0;} and be done with it.

change/overload the deeply entrenched meanings of the existing terms
"decidable" and "undecidable", which is a terrible idea when those
concepts, and their standard terminology, are at the core of your
argumentation.

Its already a crackpot idea to call a TM that simply ignores its input
any kind of DECIDER. It does not decide jack shit.

We are not concerned with a TM that immediately halts.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 2:41 PM, joes wrote:

Am Wed, 17 Sep 2025 13:46:22 -0500 schrieb olcott:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

Unless there is a correct term for an undecidable instance I am >>>>>>>> forced to use that made up term.

Every instance is decidable.

It is conventional wisdom that each halt decider ....

There are no halt deciders. I think you mean "each _purported_ halt >>>>> decider".

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

It means a terminating, total algorithm.

It means always getting the correct answer AKA mind
of God omniscience. That is too far away from the
conventional meaning of one that makes a decision.

.... has an undecidable input.

No. For each purported halt decider there is a program it decides
wrongly on.

That you do not understand that the job of a halt decider is to report >>>> on the actual behavior that its actual finite string input actually
specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST DEGREE.

Its job is to report on the direct execution of its input.

That requires psychic ability.
No TM can ever report on anything that it cannot see.
It is nuts to require otherwise.

You are incorrect to the greatest degree because it is perfectly valid
to pass to a halt decider an INPUT that represents a DESCRIPTION of its
CALLER.

When understanding the meaning of my words the tiniest slight paraphrase
can result in deception. HHH does freaking not take the executable
process of its caller as its input.

Like you just did. Flibble explicitly said "description".

Flibble has repeatedly spammed many times with "DD halts"
as his reply.

The input to HHH(DD) specifies different behavior than
DD() executed from main(). I have conclusively proved
this many dozens of times in the last three years by
providing the execution trace that proves this.

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.
Thus the job of a halt decider is to report on the actual behavior that
its actual finite string input actually specifies.

Except HHH does not see correctly.

That is merely your own lack of technical competence
with the x86 language.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 17 Sep 2025 15:32:31 -0500 schrieb olcott:

On 9/17/2025 2:41 PM, joes wrote:

Am Wed, 17 Sep 2025 13:46:22 -0500 schrieb olcott:

On 9/17/2025 1:40 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:32:07 -0500, olcott wrote:

On 9/17/2025 1:08 PM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 9/17/2025 10:26 AM, joes wrote:

Am Wed, 17 Sep 2025 08:29:31 -0500 schrieb olcott:

It is freaking nuts that "decider" in computer science means all
knowing mind of God.

It means a terminating, total algorithm.

It means always getting the correct answer AKA mind of God omniscience.
That is too far away from the conventional meaning of one that makes a decision.

We would like the decisions to be correct.

That you do not understand that the job of a halt decider is to
report on the actual behavior that its actual finite string input
actually specifies DOES NOT MAKE ME INCORRECT IN THE SLIGHTEST
DEGREE.

Its job is to report on the direct execution of its input.

That requires psychic ability.
No TM can ever report on anything that it cannot see.
It is nuts to require otherwise.

It only requires complete simulation or a correct analysis.
Or even a {return 1;}. HHH should look at the continuation.

You are incorrect to the greatest degree because it is perfectly
valid to pass to a halt decider an INPUT that represents a
DESCRIPTION of its CALLER.

When understanding the meaning of my words the tiniest slight
paraphrase can result in deception. HHH does freaking not take the
executable process of its caller as its input.

Like you just did. Flibble explicitly said "description".

Flibble has repeatedly spammed many times with "DD halts"
as his reply.

You are one to complain...

The input to HHH(DD) specifies different behavior than DD() executed
from main(). I have conclusively proved this many dozens of times in the
last three years by providing the execution trace that proves this.

Yes, you proved that HHH is wrong.

Still nobody is passing HHH a process in execution.

A halt decider cannot use psychic power to REPORT ON BEHAVIOR THAT IT
CANNOT SEE.
Thus the job of a halt decider is to report on the actual behavior
that its actual finite string input actually specifies.

Except HHH does not see correctly.

That is merely your own lack of technical competence with the x86
language.

x86 does not specify aborting.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 17/09/2025 20:16, olcott wrote:

On 9/17/2025 2:09 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:55:35 -0500, olcott wrote:

On 9/17/2025 1:50 PM, Mr Flibble wrote:

On Wed, 17 Sep 2025 13:46:22 -0500, olcott wrote:

<snip>

HHH cannot see the behavior of its caller or which function
is calling
it.

A halt decider cannot use psychic power to REPORT ON
BEHAVIOR THAT IT
CANNOT SEE.

But it CAN SEE IT because it is given a REPRESENTATION
(DESCRIPTION)

That is not 100% exactly the same as the behavior of main()---

DD().

I have conclusively proven this hundreds of times over the
last three
years and people consistently favor dishonest denigration over
truth.

The only way your assertion could be correct would be

If we don't stupidly expect a halt decider to report
on something that it cannot possibly see.

HHH("dd.exe");
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Richard Heathfield <rjh@cpax.org.uk> writes:

... You refuted it by deciding that a wrong decision is still a
decision, dammit.

Is there a missing word? A wrong decision most certainly is still a
decision. PO came up with the daft idea that a wrong decision is the
right one:

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

PO:
Yes that is the correct answer even though P(P) halts.
--
Ben.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On Wed, 2025-09-17 at 23:18 +0100, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

... You refuted it by deciding that a wrong decision is still a
decision, dammit.

Is there a missing word?  A wrong decision most certainly is still a decision.  PO came up with the daft idea that a wrong decision is the
right one:

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

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

A correct halt decider can only correctly compute its input halts or not. Therefore, "HHH(DD)==0, DD() halts" can be correct (hope will not be too different from what olcott would say).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 5:18 PM, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

... You refuted it by deciding that a wrong decision is still a
decision, dammit.

Is there a missing word? A wrong decision most certainly is still a decision. PO came up with the daft idea that a wrong decision is the
right one:

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

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

DD simulated by HHH according to the semantics
of the x86 language specifies a sequence of moves
that cannot possibly reach their own final halt state.

All TM deciders can only report on the semantic or
syntactic property THAT THEIR ACTUAL INPUT ACTUAL SPECIFIES. main-->DD-->HHH(DD) *IS NOT AN INPUT TO HHH*
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 17/09/2025 23:18, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

... You refuted it by deciding that a wrong decision is still a
decision, dammit.

Is there a missing word? A wrong decision most certainly is still a decision. PO came up with the daft idea that a wrong decision is the
right one:

Oh, he knows he's wrong. Really, truly, he /must/ do. /Nobody/
can be that stupid. But I think he just woke up one morning on an
academic mountain ledge, and he's been up there ever since
because he simply has no idea how to climb down.

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

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

*Nobody* can be that dense.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/17/2025 7:04 PM, Richard Heathfield wrote:

On 17/09/2025 23:18, Ben Bacarisse wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

... You refuted it by deciding that a wrong decision is still a
decision, dammit.

Is there a missing word?  A wrong decision most certainly is still a
decision.  PO came up with the daft idea that a wrong decision is the
right one:

Oh, he knows he's wrong. Really, truly, he /must/ do. /Nobody/ can be
that stupid. But I think he just woke up one morning on an academic
mountain ledge, and he's been up there ever since because he simply has
no idea how to climb down.

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

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

*Nobody* can be that dense.

It is not that I am dense. It is that the depth of
complete understanding of everyone is learned-by-rote.
When we carefully analyze why these are the way they
are and don't simply take everything as coming from
the mind of God then we can actually see inconsistencies.

Rice's theorem almost gets there. Rice talks about the
semantic properties of programs. It is not actually the
semantic properties of executing Turing machines it is
the semantic properties of the finite string machine
description inputs.

No one single person could ever say that they believe
that I am wrong by showing even the slightest error in
my reasoning. It is always a matter that my view does
not exactly parrot the conventional view.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

It is already common knowledge that DD specifies
different behavior to HHH than it does to HHH1

otherwise how the Hell can the diagonal argument
be formed on one decider/input pair and yet another
decider can decide this same input?
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 18/09/2025 01:52, olcott wrote:

It is already common knowledge that DD specifies
different behavior to HHH than it does to HHH1

Rubbish. DD's behaviour is fixed.

otherwise how the Hell can the diagonal argument
be formed on one decider/input pair and yet another
decider can decide this same input?

Buggy code.

How do I know it's buggy? Because it gets the answer wrong,
that's how.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2