From Newsgroup: comp.lang.c

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.
--
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.lang.c

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.

It's not necessarily a *proof* per se, because it relies on Olcott's code
which isn't correct. It has shared, mutated states which render HHH
impure.

But the experiment does establish that we can continue "aborted"
simulations (which Olcott has denied, calling them "totally killed),
and that those simulations in the same apparatus produce a result which contradicts what was claimed (that DD does not halt; and moreover, this
is specifically because the simulated HHH never returns to DD).

In short, Olcott used a certain contraption to try to prove his claims
(which we know is impossible and wrong since they claims go against an air-tight proof, deeply entrenched at the core of computer science). In connection with those claims, he claimed that the contraption's
behaviors have certain properties which substantiate the claims. Code experiments refute those claims; the contraption's behavior does not
have those claimed properties, like the simulated DD not returning out
of the HHH(DD) call.

We don't need these experiments to know that the whole thing is wrong,
but it may of benefit of Olcott to have a better understanding of his
own contraption and an additional tool to explore its behavior.
--
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.lang.c

On 10/28/2025 12:04 PM, Kaz Kylheku wrote:

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.

It's not necessarily a *proof* per se, because it relies on Olcott's code which isn't correct. It has shared, mutated states which render HHH
impure.

But the experiment does establish that we can continue "aborted"
simulations (which Olcott has denied, calling them "totally killed),
and that those simulations in the same apparatus produce a result which contradicts what was claimed (that DD does not halt; and moreover, this
is specifically because the simulated HHH never returns to DD).

In short, Olcott used a certain contraption to try to prove his claims
(which we know is impossible and wrong since they claims go against an air-tight proof, deeply entrenched at the core of computer science). In connection with those claims, he claimed that the contraption's
behaviors have certain properties which substantiate the claims. Code experiments refute those claims; the contraption's behavior does not
have those claimed properties, like the simulated DD not returning out
of the HHH(DD) call.

We don't need these experiments to know that the whole thing is wrong,
but it may of benefit of Olcott to have a better understanding of his
own contraption and an additional tool to explore its behavior.

Agreed.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/28/2025 3:04 PM, Kaz Kylheku wrote:

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.

It's not necessarily a *proof* per se, because it relies on Olcott's code which isn't correct. It has shared, mutated states which render HHH
impure.

But the experiment does establish that we can continue "aborted"
simulations (which Olcott has denied, calling them "totally killed),
and that those simulations in the same apparatus produce a result which contradicts what was claimed (that DD does not halt; and moreover, this
is specifically because the simulated HHH never returns to DD).

In short, Olcott used a certain contraption to try to prove his claims
(which we know is impossible and wrong since they claims go against an air-tight proof, deeply entrenched at the core of computer science). In connection with those claims, he claimed that the contraption's
behaviors have certain properties which substantiate the claims. Code experiments refute those claims; the contraption's behavior does not
have those claimed properties, like the simulated DD not returning out
of the HHH(DD) call.

We don't need these experiments to know that the whole thing is wrong,
but it may of benefit of Olcott to have a better understanding of his
own contraption and an additional tool to explore its behavior.

The funny part about all this is that he was using his code as a way of "concretely specifying all details" to avoid any ambiguity. But given
that there's code that shows the opposite, now all of a sudden it's all
about the abstract and actual code doesn't matter.

Hypocrisy at its finest.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/28/2025 2:04 PM, Kaz Kylheku wrote:

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
  int Halt_Status = H(D);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.

It's not necessarily a *proof* per se, because it relies on Olcott's code which isn't correct. It has shared, mutated states which render HHH
impure.

But the experiment does establish that we can continue "aborted"
simulations (which Olcott has denied, calling them "totally killed),
and that those simulations in the same apparatus produce a result which contradicts what was claimed (that DD does not halt; and moreover, this
is specifically because the simulated HHH never returns to DD).

In short, Olcott used a certain contraption to try to prove his claims
(which we know is impossible and wrong since they claims go against an air-tight proof, deeply entrenched at the core of computer science). In connection with those claims, he claimed that the contraption's
behaviors have certain properties which substantiate the claims. Code experiments refute those claims; the contraption's behavior does not
have those claimed properties, like the simulated DD not returning out
of the HHH(DD) call.

We don't need these experiments to know that the whole thing is wrong,
but it may of benefit of Olcott to have a better understanding of his
own contraption and an additional tool to explore its behavior.

int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.
--
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.lang.c

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

DO I HAVE TO REPEAT THAT 10,000
TIME BEFORE YOU NOTICE THAT I EVER SAID IT ONCE?

int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.
--
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.lang.c

Am Tue, 28 Oct 2025 15:57:29 -0500 schrieb olcott:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object of a
Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE THE NON-INPUT IS OUT-OF-SCOPE

What non-input? H gets passed (a pointer to) the code of D including
the version of H that aborts. If you pass that to a UTM or H1, it 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.lang.c

On 10/28/2025 4:06 PM, joes wrote:

Am Tue, 28 Oct 2025 15:53:52 -0500 schrieb olcott:

On 10/28/2025 2:28 PM, joes wrote:

Am Tue, 28 Oct 2025 13:46:23 -0500 schrieb olcott:

On 10/28/2025 1:32 PM, joes wrote:

Nobody has claimed otherwise. Every input is decidable!

I have proven that the counter-example input is decidable thus refuting
by the same halt decider that this input is rigged against thus refuting
the proof.

Of course DD is decidable. You just decided (pun not intended) to redefine halting.

int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

Not at all. I discovered that the halting problem
itself is a category error because it sometimes
requires a halt decider to report on something
other than exactly what its finite string input
specifies.

That the semantic properties of finite string inputs differ from the >>>>>> semantic properties of non-inputs seems to be the crux of my
innovation.

Which string is not an input?

Every one that is not an argument to H.

How does the description of D differ when you execute or simulate it?

I have only told you this 10,000 times.

No, I mean the description. What is the difference between the code of
D and the input to H?

The input to H(D) specifies non-halting even though
the directly executed D() halts. Deciders only report
on what their input specifies requiring more than this
is a category error. For all of these years since
1936 the halting problem has only been a category error.

Flibble was the first to use this term in this forum
on this matter. I always thought that was brilliant.
--
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.lang.c

On 10/28/2025 4:09 PM, joes wrote:

Am Tue, 28 Oct 2025 15:57:29 -0500 schrieb olcott:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object of a
Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE THE NON-INPUT IS OUT-OF-SCOPE

What non-input?

The input to H(D) is its argument.
The non-input to H is the D() executed from main().

Apparently this single little detail overturns
a foundational element of computer science.

int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

H gets passed (a pointer to) the code of D including
the version of H that aborts. If you pass that to a UTM or H1, it halts.

--
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.lang.c

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

DO I HAVE TO REPEAT THAT 10,000
TIME BEFORE YOU NOTICE THAT I EVER SAID IT ONCE?

You have not said anything substantial about this even once.

To substantiate the idea that the input is actually two different
things: a solvable input, and an out-of-scope non-input, you need to
show an algorithm which separates inputs from non-inputs.

// Returns true if P is a non-input which is out of scope of H.
bool IsNonInput(Ptr H, Ptr P)
{
// fill me in with the deets, plz!
}

A few test cases:

IsNonInput(HHH, DD) -> true
IsNonInput(HHH1, DD) -> false
IsNonInput(HHH, Infinite_Loop) -> false

The first two show how DD is both an input and a non-input.
--
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.lang.c

On 10/28/2025 4:43 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

DO I HAVE TO REPEAT THAT 10,000
TIME BEFORE YOU NOTICE THAT I EVER SAID IT ONCE?

You have not said anything substantial about this even once.

Do you understand that deciders only report on their inputs?
--
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.lang.c

On 10/28/2025 4:51 PM, olcott wrote:

On 10/28/2025 2:04 PM, Kaz Kylheku wrote:

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
    int Halt_Status = H(D);
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.

It's not necessarily a *proof* per se, because it relies on Olcott's code
which isn't correct. It has shared, mutated states which render HHH
impure.

But the experiment does establish that we can continue "aborted"
simulations  (which Olcott has denied, calling them "totally killed),
and that those simulations in the same apparatus produce a result which
contradicts what was claimed (that DD does not halt; and moreover, this
is specifically because the simulated HHH never returns to DD).

In short, Olcott used a certain contraption to try to prove his claims
(which we know is impossible and wrong since they claims go against an
air-tight proof, deeply entrenched at the core of computer science).  In
connection with those claims, he claimed that the contraption's
behaviors have certain properties which substantiate the claims.  Code
experiments refute those claims; the contraption's behavior does not
have those claimed properties, like the simulated DD not returning out
of the HHH(DD) call.

We don't need these experiments to know that the whole thing is wrong,
but it may of benefit of Olcott to have a better understanding of his
own contraption and an additional tool to explore its behavior.

<repeat of previously refuted point>

So again you admit that Kaz's code proves that D is halting.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/28/2025 4:57 PM, olcott wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

Then why do you claim that H(D) must decide on this non input?


int D()
{
int Halt_Status = UTM(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 4:43 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

DO I HAVE TO REPEAT THAT 10,000
TIME BEFORE YOU NOTICE THAT I EVER SAID IT ONCE?

You have not said anything substantial about this even once.

Do you understand that deciders only report on their inputs?

I understand that there only exist inputs.

Do you understand that we can design a description language for
Turing Machines in which any sequence of 1's and 0's is
valid?

Then all possible bit strings are valid inputs, making it
redundant to emphasize that deciders only operate on inputs.
--
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.lang.c

On 10/28/2025 5:03 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 4:43 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

DO I HAVE TO REPEAT THAT 10,000
TIME BEFORE YOU NOTICE THAT I EVER SAID IT ONCE?

You have not said anything substantial about this even once.

Do you understand that deciders only report on their inputs?

I understand that there only exist inputs.

That's a crazy thing to say. I own a car and it is not an input.

Do you understand that we can design a description language for
Turing Machines in which any sequence of 1's and 0's is
valid?

Then all possible bit strings are valid inputs, making it
redundant to emphasize that deciders only operate on inputs.

None-the-less I do have an important discovery in
computer science if you could only bother to pay
complete attention. That you tried to say that my
car does not exist shows a woeful lack of precision
in your choice of words.
--
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.lang.c

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 4:57 PM, olcott wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

Then why do you claim that H(D) must decide on this non input?

Because he claims that D is two things; it has two properties:
D.input and D.noninput.

H(D) is solving D.input (as machines are required) and (believe
him when he says) that D.input is nonterminating.

What is terminating is D.noninput (he acknowledges).

If some H_other decider is tested on H_other(D), then the "Olcott
reality distortion wave function" (ORDF) collapses, and D.input
becomes the same as D.noninput.

When observed by H, D.input and D.noninput have different quantum
states: D is effectively split, identifiable as two particles. When
observed by non-H, no difference in any quantum properties (charge, spin
...) is observed, and so D.input and D.noninput must be one and the
same; they are indistinguishable particles: https://en.wikipedia.org/wiki/Indistinguishable_particles

Olcott is a top quantum computer scientist, on the level of Dirac or
Feynman.
--
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.lang.c

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 5:03 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 4:43 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible >>>>>>>> for some halting algorithms.

Not just impossible outside of the scope of every Turing machine. >>>>>>> Its the same kind of thing as requiring the purely mental object >>>>>>> of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

DO I HAVE TO REPEAT THAT 10,000
TIME BEFORE YOU NOTICE THAT I EVER SAID IT ONCE?

You have not said anything substantial about this even once.

Do you understand that deciders only report on their inputs?

I understand that there only exist inputs.

That's a crazy thing to say. I own a car and it is not an input.

Note that a car is not an input to some halting deciders, but a
non-input to others.

If X is an input to any halting decider, it is an input to all.

So for practical purposes, we need no think about non-inputs like cars;
they are not interesting and we can confine our thinking strictly to the universe of inputs.

There are no non-inputs (that are relevant and worth discussing).

Do you understand that we can design a description language for
Turing Machines in which any sequence of 1's and 0's is
valid?

Then all possible bit strings are valid inputs, making it
redundant to emphasize that deciders only operate on inputs.

None-the-less I do have an important discovery in

"None the less" means "In spite of what you say being correct ...".

computer science if you could only bother to pay
complete attention. That you tried to say that my
car does not exist shows a woeful lack of precision
in your choice of words.

--
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.lang.c

On 10/28/2025 1:01 PM, dbush wrote:

On 10/28/2025 3:04 PM, Kaz Kylheku wrote:

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 12:49 PM, olcott wrote:

On 10/28/2025 11:33 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

The above point

If H rejects D as non-halting, it makes D halting.

I have demonstrated that with actual code.

Is refuted above

int D()
{
    int Halt_Status = H(D);
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}

H simulates D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
that calls H(D) to simulate D
until H sees this repeating pattern.

When simulating halt decider H is reporting on the
behavior that its input specifies then H is correct
to reject D as non-halting.

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

And repeated above.

Repeating a previously refuted point is less that no rebuttal and is
your admission that the refutation, i.e. that Kaz's code proves that D
is halting, is *CORRECT*.

It's not necessarily a *proof* per se, because it relies on Olcott's code
which isn't correct. It has shared, mutated states which render HHH
impure.

But the experiment does establish that we can continue "aborted"
simulations  (which Olcott has denied, calling them "totally killed),
and that those simulations in the same apparatus produce a result which
contradicts what was claimed (that DD does not halt; and moreover, this
is specifically because the simulated HHH never returns to DD).

In short, Olcott used a certain contraption to try to prove his claims
(which we know is impossible and wrong since they claims go against an
air-tight proof, deeply entrenched at the core of computer science).  In
connection with those claims, he claimed that the contraption's
behaviors have certain properties which substantiate the claims.  Code
experiments refute those claims; the contraption's behavior does not
have those claimed properties, like the simulated DD not returning out
of the HHH(DD) call.

We don't need these experiments to know that the whole thing is wrong,
but it may of benefit of Olcott to have a better understanding of his
own contraption and an additional tool to explore its behavior.

The funny part about all this is that he was using his code as a way of "concretely specifying all details" to avoid any ambiguity.  But given
that there's code that shows the opposite, now all of a sudden it's all about the abstract and actual code doesn't matter.

Hypocrisy at its finest.

Oh shit. Follow the yellow brick road to the charlatan behind the scenes
that is a carny just smart enough to swindle the lesser than's, lol. I
feel sorry for the LLM's his mind got a hold of. Wow! Call the cops man!
;^o sigh.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 28/10/2025 21:58, dbush wrote:

On 10/28/2025 4:51 PM, olcott wrote:

<snip>

<repeat of previously refuted point>

So again you admit that Kaz's code proves that D is halting.

Credit where credit is due. By returning 0*, /olcott's/ code
proves that D is halting.

*i.e. non-halting.
--
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.lang.c

On 10/28/2025 3:14 PM, Kaz Kylheku wrote:

On 2025-10-28, dbush <dbush.mobile@gmail.com> wrote:

On 10/28/2025 4:57 PM, olcott wrote:

On 10/28/2025 2:37 PM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

On 10/28/2025 11:35 AM, Kaz Kylheku wrote:

On 2025-10-28, olcott <polcott333@gmail.com> wrote:

Deciders only compute a mapping from their actual
inputs. Computing the mapping from non-inputs is
outside of the scope of Turing machines.

Calculating the halting of certain inputs is indeed impossible
for some halting algorithms.

Not just impossible outside of the scope of every Turing machine.
Its the same kind of thing as requiring the purely mental object
of a Turing machine to bake a birthday cake.

It simply isn't. Inputs that are not correctly solvable by some
deciders are decided by some others.

THIS INPUT IS SOLVABLE
THE NON-INPUT IS OUT-OF-SCOPE

Then why do you claim that H(D) must decide on this non input?

Because he claims that D is two things; it has two properties:
D.input and D.noninput.

H(D) is solving D.input (as machines are required) and (believe
him when he says) that D.input is nonterminating.

What is terminating is D.noninput (he acknowledges).

If some H_other decider is tested on H_other(D), then the "Olcott
reality distortion wave function" (ORDF) collapses, and D.input
becomes the same as D.noninput.

When observed by H, D.input and D.noninput have different quantum
states: D is effectively split, identifiable as two particles. When
observed by non-H, no difference in any quantum properties (charge, spin
...) is observed, and so D.input and D.noninput must be one and the
same; they are indistinguishable particles: https://en.wikipedia.org/wiki/Indistinguishable_particles

Olcott is a top quantum computer scientist, on the level of Dirac or
Feynman.

Olcott should show his resume to the Q# team:

https://learn.microsoft.com/en-us/azure/quantum/qsharp-overview

:^)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/28/2025 2:14 PM, olcott wrote:
[...]

DD can halt, or not depending on what HHH(DD) returns. Therefore my
BASIC program is better than any HHH your can crap out for any test program:


1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Right?
--- Synchronet 3.21a-Linux NewsLink 1.2