From Newsgroup: comp.theory

On 8/26/25 11:46 AM, olcott wrote:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if
H does.

That is incorrect.

How does it differ?

Or are you admitting that they aren't the exact same algorithm with the
exact same data?

If it cannot possibly see the repeating state of its
input then we do know more about the halting problem
proof than we ever knew before, that the counter-example
input would be correctly decided as non-halting. We can
see that it is non-halting even if -n.embedded_H cannot.

If -n.embedded_H cannot see what we see then H can't either.
This means, assuming that what we can see acturally is there,
that H is not a halt decder, Q.E.D.

H is not the issue it does not have a pathological
relationship to its input.

Sure it does, its input (H^) (H^) is built to do the opposite of what it
will say.

Or, are you admitting that you proof is based on lying about following
the Linz proof.

However, there are possible inputs that heither halt nor repeat
any configuration.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if
H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

If it cannot possibly see the repeating state of its
input then we do know more about the halting problem
proof than we ever knew before, that the counter-example
input would be correctly decided as non-halting. We can
see that it is non-halting even if -n.embedded_H cannot.

If -n.embedded_H cannot see what we see then H can't either.
This means, assuming that what we can see acturally is there,
that H is not a halt decder, Q.E.D.

H is not the issue it does not have a pathological
relationship to its input.

H is the topic of Linz proof, which is the topic of this discussion.

However, there are possible inputs that heither halt nor repeat
any configuration.

--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if
H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

This is the same as my HHH and HHH1 pair that
have identical source code.

The outermost instance of HHH meets its abort
criteria first.

If it cannot possibly see the repeating state of its
input then we do know more about the halting problem
proof than we ever knew before, that the counter-example
input would be correctly decided as non-halting. We can
see that it is non-halting even if -n.embedded_H cannot.

If -n.embedded_H cannot see what we see then H can't either.
This means, assuming that what we can see acturally is there,
that H is not a halt decder, Q.E.D.

H is not the issue it does not have a pathological
relationship to its input.

H is the topic of Linz proof, which is the topic of this discussion.

H that is embedded in -n and H that is not embedded in -n
are not the same ONLY because -n calls embedded_H in
recursive simulation and does not call H in recursive
simulation.

However, there are possible inputs that heither halt nor repeat
any configuration.

--
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 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD.

<snip>
--
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 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD.

<snip>

All disingenuous replies will be ignored.
--
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 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD.

<snip>

All disingenuous replies will be ignored.

You ignore most of my replies, because you have no answer for
most of my replies. When you do reply it's often incoherent, so I
suppose I should be grateful for small mercies.

You rightly say that your simulations get stuck because you abort
them. What you fail to realise is that /by/ aborting the run the
way you do you fail to complete the analysis of DD's behaviour.

By declaring that DD never halts, you force it to halt (as your
simulation might well see if it only looked past the recursive
call to see what would happen next after your "never-halts" report.
--
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 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD.

<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.
--
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 8/27/2025 11:41 AM, olcott wrote:

On 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD.

<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.

Translation:

"I ignore replies that clearly prove me wrong for which I have no rebuttal". --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/27/25 10:49 AM, olcott wrote:

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if >>>> H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

You mean your lie that says that you can look at a different program
than the one that is at the input?

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

But that lies about their being just one "DD", which since DD needs to
be a program, and thus includes all its code, each DD built on a
different HHH is a diferent DD.

Thus, you can prove that the DD built on an HHH that does a correct
simulation would be non-halting, but that doesn't apply to the DD built
on an HHH that doesn't do a correct simulation but aborts it to return 0.

THat is like saying cats bark, because your dog does, and both are pets.

This is the same as my HHH and HHH1 pair that
have identical source code.

And the fact that they give different results just proves that they are
not pure functions, and thus not actual deciders.>

The outermost instance of HHH meets its abort
criteria first.

But the criteria isn't correct.

If it cannot possibly see the repeating state of its
input then we do know more about the halting problem
proof than we ever knew before, that the counter-example
input would be correctly decided as non-halting. We can
see that it is non-halting even if -n.embedded_H cannot.

If -n.embedded_H cannot see what we see then H can't either.
This means, assuming that what we can see acturally is there,
that H is not a halt decder, Q.E.D.

H is not the issue it does not have a pathological
relationship to its input.

H is the topic of Linz proof, which is the topic of this discussion.

H that is embedded in -n and H that is not embedded in -n
are not the same ONLY because -n calls embedded_H in
recursive simulation and does not call H in recursive
simulation.

In other words you admit that you didn't build H^ right, and that your H
isn't a pure function, as pure functions don't care about how they are
called.

It seems you logic just doesn't understand that basic meaning of correct.

However, there are possible inputs that heither halt nor repeat
any configuration.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-08-27 14:49:44 +0000, olcott said:

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if >>>> H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

Even then. The proof does not mention any simulation but covers
all Turing machines, including simulating ones.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-08-27 16:24:04 +0000, dbush said:

On 8/27/2025 11:41 AM, olcott wrote:

On 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD.

<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.

Translation:

"I ignore replies that clearly prove me wrong for which I have no rebuttal".

Olcott never posts anything that could be reasonably called a "rebuttal".
His usual style is to talk about something else and to pretend that it
is an answer but apparently he has found that that does not work.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/28/2025 2:06 AM, Mikko wrote:

On 2025-08-27 14:49:44 +0000, olcott said:

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if >>>>> H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

Even then. The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.
My 2016 idea of a simulating halt decider
changes everything.

(a) The "do the opposite" code is unreachable
(b) The behavior becomes non-halting

Those two things advance enormously beyond
both yes and no are the wrong return value
"undecidability".
--
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 8/28/2025 2:13 AM, Mikko wrote:

On 2025-08-27 16:24:04 +0000, dbush said:

On 8/27/2025 11:41 AM, olcott wrote:

On 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD. >>>>>>
<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.

Translation:

"I ignore replies that clearly prove me wrong for which I have no
rebuttal".

Olcott never posts anything that could be reasonably called a "rebuttal".
His usual style is to talk about something else and to pretend that it
is an answer but apparently he has found that that does not work.

Counter-factual
--
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 8/28/2025 10:23 AM, olcott wrote:

On 8/28/2025 2:06 AM, Mikko wrote:

On 2025-08-27 14:49:44 +0000, olcott said:

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if >>>>>> H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

Even then. The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.

False. The proof assumes a total halt decider exists and then chooses
one such decider to test. The only thing known about this total halt
decider is what it returns, so *any* potential implementation is
included, including simulation.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/28/2025 10:24 AM, olcott wrote:

On 8/28/2025 2:13 AM, Mikko wrote:

On 2025-08-27 16:24:04 +0000, dbush said:

On 8/27/2025 11:41 AM, olcott wrote:

On 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD. >>>>>>>
<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.

Translation:

"I ignore replies that clearly prove me wrong for which I have no
rebuttal".

Olcott never posts anything that could be reasonably called a "rebuttal".
His usual style is to talk about something else and to pretend that it
is an answer but apparently he has found that that does not work.

Counter-factual

On 10/12/2024 8:35 PM, olcott wrote:

That your rebuttals are pure bluster utterly bereft of any
supporting reasoning is clear to all having sufficient
technical understanding.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 28/08/2025 15:23, olcott wrote:

On 8/28/2025 2:06 AM, Mikko wrote:

<snip>

[...]The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.
My 2016 idea of a simulating halt decider
changes everything.

No, it changes nothing.

(a) The "do the opposite" code is unreachable

No, it isn't, unless you wrote a shit simulator. Oh, wait.

(b) The behavior becomes non-halting

Except that it doesn't. What your simulation thinks doesn't halt
is the /simulation/. And then HHH can't be arsed to do a proper
job of simulating what happens next, so it halts the simulation -
which means the simulation *does* halt, but you then wrongly
claim that this means it doesn't halt. You get it wrong twice in
every run. Impressive!

Those two things advance enormously beyond
both yes and no are the wrong return value
"undecidability".

No, it's just a shit simulator.

The trick you're missing is, at some arbitrary depth, to replace
a recursive call to HHH with the 0 you insist it returns, and
then keep on simulating from there, rendering the "unreachable"
code reachable.
--
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 8/28/2025 9:54 AM, Richard Heathfield wrote:

On 28/08/2025 15:23, olcott wrote:

On 8/28/2025 2:06 AM, Mikko wrote:

<snip>

[...]The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.
My 2016 idea of a simulating halt decider
changes everything.

No, it changes nothing.

(a) The "do the opposite" code is unreachable

No, it isn't, unless you wrote a shit simulator. Oh, wait.

If you are just going to lie about these things
I will start only responding to your posts with: Liar!
At least (unlike others) you are not a stupid liar.
No sense even talking to stupid liars.
--
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 28/08/2025 16:21, olcott wrote:

<snip>

If you are just going to lie about these things
I will start only responding to your posts with: Liar!

Let me know when you grow up.
--
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 2025-08-28 14:24:18 +0000, olcott said:

On 8/28/2025 2:13 AM, Mikko wrote:

On 2025-08-27 16:24:04 +0000, dbush said:

On 8/27/2025 11:41 AM, olcott wrote:

On 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD. >>>>>>>
<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.

Translation:

"I ignore replies that clearly prove me wrong for which I have no rebuttal".

Olcott never posts anything that could be reasonably called a "rebuttal".
His usual style is to talk about something else and to pretend that it
is an answer but apparently he has found that that does not work.

Counter-factual

So you say but can't show.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-08-28 14:23:16 +0000, olcott said:

On 8/28/2025 2:06 AM, Mikko wrote:

On 2025-08-27 14:49:44 +0000, olcott said:

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if >>>>>> H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

Even then. The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.

False. It does not mention simulation because that detail is irrelevant
to the proof. The proof covers every method, including those that are
already known to be wrong, for example a decider that always accepts.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-08-28 15:21:31 +0000, olcott said:

On 8/28/2025 9:54 AM, Richard Heathfield wrote:

On 28/08/2025 15:23, olcott wrote:

On 8/28/2025 2:06 AM, Mikko wrote:

<snip>

[...]The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.
My 2016 idea of a simulating halt decider
changes everything.

No, it changes nothing.

(a) The "do the opposite" code is unreachable

No, it isn't, unless you wrote a shit simulator. Oh, wait.

If you are just going to lie about these things
I will start only responding to your posts with: Liar!

It is a sin to lie about other people.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 28.aug.2025 om 16:23 schreef olcott:

On 8/28/2025 2:06 AM, Mikko wrote:

On 2025-08-27 14:49:44 +0000, olcott said:

On 8/27/2025 2:37 AM, Mikko wrote:

On 2025-08-26 15:46:33 +0000, olcott said:

On 8/26/2025 3:51 AM, Mikko wrote:

On 2025-08-21 03:10:52 +0000, olcott said:

Simulating (at least partial) halt decider -n.embedded_H
either sees the repeating state of its input or not.

More specifically, -n.embedded_H sees a repeating state if and only if >>>>>> H does.

That is incorrect.

No, it is an inevitable conseqence of how Linz constructed -n.
You can't prove otherwise.

Unless you bother to pay complete attention
to all of the details of recursive simulation.

Even then. The proof does not mention any simulation but covers
all Turing machines, including simulating ones.

It does not mention simulation because this
was always rejected out-of-hand without review.
My 2016 idea of a simulating halt decider
changes everything.

(a) The "do the opposite" code is unreachable
(b) The behavior becomes non-halting

AS usual incorrect claims without evidence.
The code is reachable in case the input is based on the aborting
simulator, as proven by world class simulators for the exact same input.
Only the aborting simulator fails to reach it because of the premature
abort.
This failure does not change the specification in the input.

Those two things advance enormously beyond
both yes and no are the wrong return value
"undecidability".

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/28/25 10:24 AM, olcott wrote:

On 8/28/2025 2:13 AM, Mikko wrote:

On 2025-08-27 16:24:04 +0000, dbush said:

On 8/27/2025 11:41 AM, olcott wrote:

On 8/27/2025 10:37 AM, Richard Heathfield wrote:

On 27/08/2025 16:12, olcott wrote:

On 8/27/2025 9:59 AM, Richard Heathfield wrote:

On 27/08/2025 15:49, olcott wrote:

<snip>

When DD is correctly simulated by HHH and HHH
simulates an instance of itself simulating DD
this and all other simulated HHH instances cannot
possibly return because they remain stuck in
recursive simulation.

That's just another way of saying you can't correctly simulate DD. >>>>>>>
<snip>

All disingenuous replies will be ignored.

You ignore most of my replies,

All disingenuous replies will be ignored.

Translation:

"I ignore replies that clearly prove me wrong for which I have no
rebuttal".

Olcott never posts anything that could be reasonably called a "rebuttal".
His usual style is to talk about something else and to pretend that it
is an answer but apparently he has found that that does not work.

Counter-factual

So, prove the statement wrong by pointing to where you actually rebute
an error pointed out by doing more than just repeating the error.

All you are doing is proving that you don't knwo what you are talking about.

it is a FACT, that HHH can not return the correct answer about the
behavior of the program DD that it has been properly passed to it as a representation.

Claiming otherwise just shows that you are just stupid liar trying to
redefine what those words mean.
--- Synchronet 3.21a-Linux NewsLink 1.2