On 09/08/2025 16:57, olcott wrote:

On 8/9/2025 10:49 AM, Richard Heathfield wrote:

On 09/08/2025 16:22, olcott wrote:

<snip>

It is dishonest for you to disagree prior to
looking at all of what I said when your
disagreement is anchored in a false assumption.

My disagreement is anchored in Turing's proof.

And its misconceptions that you make sure to ignore.

Assumes facts not in evidence. Turing's proof is simple and
easily verified as correct. You have utterly failed to establish
that it contains any misconceptions whatsoever.

That is dishonest.

For someone who has threatened me with legal action for libel,
you're mighty free with that word.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 16:59, olcott wrote:

On 8/9/2025 10:50 AM, Richard Heathfield wrote:

On 09/08/2025 16:35, olcott wrote:

On 8/9/2025 9:07 AM, Richard Heathfield wrote:

On 09/08/2025 14:31, olcott wrote:

It turns out that the question: Does DD() halt?
is an incorrect question for HHH.

Yes, because HHH doesn't know and can't find out.

Welcome to the Halting Problem.

You're late.

It is an incorrect question not because of the
unreachable "do the opposite" code in DD.

It is an incorrect question because it asks
about the behavior of a non-input

DD is clearly an input.

The x86 machine description of DD is an input.

The x86 machine description of DD is a mere implementation detail.

the executing process of DD() *IS NOT AN INPUT*

DD is a C function. You make it an input when you pass a pointer
to it as an argument to HHH.

By 'input' C normally refers to data coming from a file, but in
three places the Standard refers to 'input argument'. It is
therefore reasonable to talk about DD as an 'input argument'.
There is simply no getting away from the fact that you pass DD to
HHH as an input.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 17:57, olcott wrote:

On 8/9/2025 11:35 AM, joes wrote:

Am Sat, 09 Aug 2025 10:16:37 -0500 schrieb olcott:

On 8/9/2025 9:35 AM, Richard Heathfield wrote:

On 09/08/2025 15:31, olcott wrote:

The behavior of DD() is not the behavior that HHH can
possibly see.

Okay, so you concede that HHH is not fit for purpose.

It has always been a false assumption that a halt decider must
report on
the behavior of the direct execution of a Turing machine.

It's not an assumption. It's the problem statement.
And partial simulators *can* report on the direct execution of
their
input, like "Does it halt in n steps?".

It has always been a false assumption that a halt
decider must report on the behavior of the direct
execution of a Turing machine.

Well, you're right. Here are some halt deciders that don't even
bother to look at the program's behaviour:

bool doom_and_gloom_halt(program *p, input *i)
{
return true; /* guaranteed correct -
all programs halt */
}

bool forever_loop(program *p, input *i)
{
return false; /* also guaranteed correct -
nothing lasts forever */
}

bool haltq(program *p, input *i)
{
return rand() % 2; /* iffy - might work half the time. */
}

But the Halting Problem requires you to predict the behaviour of
a running program. Also sprach Wikipedia: In computability
theory, the halting problem is the problem of determining, from a
description of an arbitrary computer program and an input,
whether the program will finish running, or continue to run forever.

Note: you get a /description/ of the program, not the program
itself. The program is running. You have to determine FROM THE
DESCRIPTION (and a faithful copy of its input) whether the code
will stop running. The description is not necessarily in x86
machine language. It might be C source code or an AST from the
back end of a compiler; It might even be in words: "The program
prints the lowest counterexample to Goldbach's conjecture".

Obviously the spec will document the format to expect, so that's
not my point - you might well get it in x86 format - but the
*program is running*, and you have to decide whether that running
program will ever stop, without even being guaranteed access to
the machine on which it's running.

So if you can't work out from the program description and the
input what that program is going to do, you're screwed.

You can plead that it's not fair and that it's impossible, and
you'd be right on both counts, but you can't claim that a lesser
achievement is an acceptable substitute and hope to get away with it.

You could even plead (rightly or wrongly) that your solution
works on a large number of programs, but that isn't enough. It
has to be able to work on every possible program - and it Just Can't.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 18:26, olcott wrote:

On 8/9/2025 11:03 AM, Richard Heathfield wrote:

On 09/08/2025 16:57, olcott wrote:

On 8/9/2025 10:49 AM, Richard Heathfield wrote:

On 09/08/2025 16:22, olcott wrote:

<snip>

It is dishonest for you to disagree prior to
looking at all of what I said when your
disagreement is anchored in a false assumption.

My disagreement is anchored in Turing's proof.

And its misconceptions that you make sure to ignore.

Assumes facts not in evidence.

Not at all. It assumes facts that you refuse to examine.

The facts are these:

1) you have hacked up an x86 emulator;
2) you claim to have used it to expose a flaw in the conventional
proof of the Halting Problem by simulating such parts of a C
function as you can reach;
3) your claim is flawed.

Everything else is more or less irrelevant.

Turing's proof is simple and easily verified as correct. You
have utterly failed to establish that it contains any
misconceptions whatsoever.

That is dishonest.

For someone who has threatened me with legal action for libel,
you're mighty free with that word.

You do keep saying that I am wrong on the basis of
not examining what I say.

On the contrary, I keep saying you're wrong on the basis of the
claims you make...

I prove one half of my complete proof

...like that one.

on the basis of
the actual behavior of DD correctly simulated by HHH
and you simply don't want to hear it.

The claim is false. You fail to model DD's behaviour when it
captures the result reported by HHH to the initial invocation of
DD from main. You make the false assumption that DD can only be
called from HHH, whereas a proper analysis of DD must not omit
that part of its behaviour.

You will no doubt argue that HHH cannot model behavior it can't
get at because it happens outside its purview after it has
terminated. And you'd be right - which doesn't help you because
the Halting Problem doesn't let you off the hook that easily. If
it's impossible by simulation (and yes, it is impossible), then
simulation is not a good fit for solving the problem.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 18:50, olcott wrote:

On 8/9/2025 11:30 AM, Richard Heathfield wrote:

On 09/08/2025 16:59, olcott wrote:

On 8/9/2025 10:50 AM, Richard Heathfield wrote:

On 09/08/2025 16:35, olcott wrote:

It is an incorrect question not because of the
unreachable "do the opposite" code in DD.

It is an incorrect question because it asks
about the behavior of a non-input

DD is clearly an input.

The x86 machine description of DD is an input.

The x86 machine description of DD is a mere implementation detail.

Not from a computable function perspective.

Yes, it is. There's nothing magic about x86 or machine code. It
just happens that you have an x86 in front of you. If you had a
Mac Studio on your desk you'd claim that Turing had Apple chips
in mind when he started talking about computability.

Computable functions are the basic objects of study in
computability theory. Informally, a function is computable
if there is an algorithm that computes the value of the
function for every value of its argument. https://en.wikipedia.org/wiki/Computable_function

Nothing on that page about x86.

From a computable function perspective the x86 machine
description of DD is the entire basis for a decider's
decision.

No, that's /your/ perspective. It is not the only possible
perspective, not by a long way. Furthermore, you have completely
overlooked the matter of input; you're so locked into your tiny
map that you have mistaken it for the territory.

the executing process of DD() *IS NOT AN INPUT*

DD is a C function. You make it an input when you pass a
pointer to it as an argument to HHH.

The pointer that is passed is not a pointer to an
executing process it s a point to a finite string
x86 machine description.

No, it's a pointer to int(*)().

By 'input' C normally refers to data coming from a file, but in
three places the Standard refers to 'input argument'.

More precisely accurate than the way that I said it,
yet the Turing Machine equivalent is read from the
tape, thus an input in the conventional sense.

But you're not reading from a tape. You take a pointer to a C
function and pretend that's the whole program you have to
simulate, and then act all surprised when people ask you about
the code's behaviour after the simulation has exited and reported
its result.

You sometimes read from a file, I think? In which case you have
the whole program at your disposal, so there's nothing you can't
see, so you have no excuse not to analyse it.

Computable functions have arguments, Turing
machines themselves only have inputs.

Well, they have their state, too.

It is far
more important to communicate the gist of the
idea through less precise language than to have
this gist obscured by specific nomenclature.

How's that going for you?

It is therefore reasonable to talk about DD as an 'input
argument'. There is simply no getting away from the fact that
you pass DD to HHH as an input.

I do not pass a pointer to an executing process

Agreed. You pass an int(*)().

I only pass the address of a finite string x86
machine description.

Well, you pass DD. So DD is an input. /The/ input, in fact, to HHH.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 19:11, olcott wrote:

On 8/9/2025 1:04 PM, Richard Heathfield wrote:

But the Halting Problem requires you to predict the behaviour
of a running program.

Which contradicts the fact that Turing machines
cannot possibly take other Turing machines as inputs
and thus use the proxy of a Turing machine description.

No, it doesn't.

In ON COMPUTABLE NUMBERS Alan Turing documents a way to describe
a Turing Machine alphanumerically (what you call a 'proxy').

Let us consider a program P and its input I, both stored
alphanumerically on tape. At this stage we can and do freely copy
the tape.

Having equipped ourselves with such hardware as we need (with
each computing device having a sufficiency of tape drives... or
if you don't like that we can arrange to read tapes
sequentially), we set P running on C1 thusly: C1(P,I) This loads
P onto C1 and sets it going with I as its input.

P is now running. Will it halt?

Enter C2, with its termination analyser T: C2(T,P,I) This loads T
onto C2, gives it P and I to read, and T now attempts to compute
whether P will halt given I. If it succeeds, we know whether
C1(P,I) will halt.

And so we have Turing Machines having a go at the Halting
Problem, taking other Turing Machines as inputs, and analysing
whether a running process will terminate.

And C2 can look at the /whole/ P tape, not just the end bit.

And all without an x86 machine even entering the building.

The best that any Turing machine can do is measure
the behavior specified by its input finite string

It can look at the whole of P and the whole of I.

as DD correctly simulated by HHH.

Well, DD /partly/ simulated by HHH. You missed a bit.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 19:53, olcott wrote:

I am beginning to think that you are gaslighting me.

Oh! The irony!

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 19:31, olcott wrote:

On 8/9/2025 1:20 PM, Richard Heathfield wrote:

On 09/08/2025 18:26, olcott wrote:

<snip>

You do keep saying that I am wrong on the basis of
not examining what I say.

On the contrary, I keep saying you're wrong on the basis of the
claims you make...

I prove one half of my complete proof

...like that one.

on the basis of
the actual behavior of DD correctly simulated by HHH
and you simply don't want to hear it.

The claim is false.

You did not claim that what I said about the behavior of
DD emulated by HHH according to the semantics of the x86
language is incorrect, you said that you didn't care about
this key most important detail of my proof.

I did. But I didn't /just/ say I don't care. I explained exactly
why I don't care, and exactly why it doesn't matter and exactly
why there is no point in caring.

What you call the key detail of our proof is embedded inside
HHH(), the workings of which are irrelevant to the Halting
Problem. All that matters is that you have some way to sort out
some kind of answer. I don't dispute that you do.

int HHH(ptr P)
{
int result = magic(wave(&wand), P);

is fine by me.

Because where it all falls apart is here:

return result;
}

Thus your rebuttals are on the basis of refusing to
hear and understand what I say.

Because it simply doesn't matter.

To be fair, that took me a while to figure out. I kept thinking
there must be something I'm missing, and with a lot of help from
Mike Terry I had several abortive attempts at trying to figure
out what it was. But no, there's nothing. At some point, when all
your simuladancing is done, the fat lady sings and all your logic
falls apart when Turing twists your tail.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 20:23, olcott wrote:

When we boil all of the abstractions down to the
concrete notion of x86 machines we attain the
unequivocal proof that the pathological self-reference
relationship of all of the standard proofs makes
the behavior of the directly executed machine different
than the behavior of the correctly emulated machine
description.

If you can prove that the behavior of the directly executed
machine is different to the behavior of the correctly emulated
machine description, you will have proved that emulation is a
flawed technique, because it fails to derive the expected results.

I'd like to see that proof.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 09 Aug 2025 14:34:20 -0500, olcott wrote:

On 8/9/2025 2:24 PM, Richard Heathfield wrote:

On 09/08/2025 19:53, olcott wrote:

I am beginning to think that you are gaslighting me.

Oh! The irony!

No one would spend 22 years and 20,000 hours perpetuating a hoax before
the term internet troll was even widely known. I is clear to everyone
here that I am sincere.

22 years of wasted effort due to the following fundamental mistake you
made (and continue to make):

In x86utm, H simulates D(D), detects the nested recursion as non-halting, aborts, and returns 0 (non-halting). But when D(D) runs for real:

* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.

Thus, the actual machine D(D) halts, but H reported "does not halt". H is
wrong about the machine's behavior.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 20:28, olcott wrote:

On 8/9/2025 2:21 PM, Richard Heathfield wrote:

On 09/08/2025 19:31, olcott wrote:

On 8/9/2025 1:20 PM, Richard Heathfield wrote:

On 09/08/2025 18:26, olcott wrote:

<snip>

You do keep saying that I am wrong on the basis of
not examining what I say.

On the contrary, I keep saying you're wrong on the basis of
the claims you make...

I prove one half of my complete proof

...like that one.

on the basis of
the actual behavior of DD correctly simulated by HHH
and you simply don't want to hear it.

The claim is false.

You did not claim that what I said about the behavior of
DD emulated by HHH according to the semantics of the x86
language is incorrect, you said that you didn't care about
this key most important detail of my proof.

I did. But I didn't /just/ say I don't care. I explained
exactly why I don't care, and exactly why it doesn't matter and
exactly why there is no point in caring.

You cannot correctly determine that it actually
makes no difference until after you fully understand
ALL of what I am saying.

Yes, I can.

Here's why:

Everything you are saying is on the HHH(in_here) side of the line.

None of that matters. You think it does, but you're wrong.

result = HHH()
^^^^^^
Thisis what matters. This, and what comes after. AFTER HHH has
reported its result.

It superficially seems to
makes no difference entirely on the basis of a false
assumption. It is impossible to see that this assumption
is false until after you first understand that

DD emulated by HHH according to the semantics of
the x86 language has provably different behavior
than the directly executed DD().

All you're saying there is that HHH gets the answer wrong.

You argue (bizarrely) that getting it wrong is the right way to
proceed, which is truly cloudcuckoo land - but you know what?
FINE. Whatever you like, because it Just Doesn't Matter. Clearly
you think it's a vital step in the reasoning, but it's of no more
significance than rearranging the deckchairs on the Titanic,
because all it affects is what you return, and whatever you
return is bound to be wrong.

When you simply assume that this is not true
entirely on the basis of ignoring what I say
this is dishonest.

No.

You remind me of a chap who came up with some unbreakable
cryptography in sci.crypt. He was convinced that all his whizzing
around dozens of substitution tables made it impossible to
unravel his plaintext without the key. He was further convinced
that I didn't understand his cipher because I kept ignoring the
complicated bits. He was yet further convinced that the only way
to unscramble his plaintext was to brute force the (colossal)
key, which would take many trillions of years. I had the
plaintext out in a couple of days.

Sometimes the bits you're so proud of are just sand. HHH() is
just sand, because at some point you have to report, and as soon
as you do you're screwed.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 09/08/2025 20:34, olcott wrote:

On 8/9/2025 2:24 PM, Richard Heathfield wrote:

On 09/08/2025 19:53, olcott wrote:

I am beginning to think that you are gaslighting me.

Oh! The irony!

No one would spend 22 years and 20,000 hours
perpetuating a hoax before the term internet
troll was even widely known. I is clear to
everyone here that I am sincere.

All right. I'll accept that. But all the time you were doing your
thing, I was churning out tens of thousands of articles helping
people to better understand the C language. I don't gaslight. My
objective is always positive. If I honestly thought you had
anything, I'd be in your corner slugging away by your side.

But I've looked at your arguments and I've looked at your code,
and I see nothing even worth picking over for parts.

Like Kaz said, it's a hell of a hack, but it doesn't /do/ anything.

--
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-09 16:57:23 +0000, olcott said:

On 8/9/2025 11:35 AM, joes wrote:

Am Sat, 09 Aug 2025 10:16:37 -0500 schrieb olcott:

On 8/9/2025 9:35 AM, Richard Heathfield wrote:

On 09/08/2025 15:31, olcott wrote:

The behavior of DD() is not the behavior that HHH can possibly see.

Okay, so you concede that HHH is not fit for purpose.

It has always been a false assumption that a halt decider must report on >>> the behavior of the direct execution of a Turing machine.

It's not an assumption. It's the problem statement.
And partial simulators *can* report on the direct execution of their
input, like "Does it halt in n steps?".

It has always been a false assumption that a halt
decider must report on the behavior of the direct
execution of a Turing machine.

Category error. An assumption is a sentence that has a truth value.
A sentence with word "must" does not have a truth value. It cannot
be an assumption. Instead, it is a requirement.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-09 16:03:58 +0000, Richard Heathfield said:

On 09/08/2025 16:57, olcott wrote:

On 8/9/2025 10:49 AM, Richard Heathfield wrote:

On 09/08/2025 16:22, olcott wrote:

<snip>

It is dishonest for you to disagree prior to
looking at all of what I said when your
disagreement is anchored in a false assumption.

My disagreement is anchored in Turing's proof.

And its misconceptions that you make sure to ignore.

Assumes facts not in evidence. Turing's proof is simple and easily
verified as correct. You have utterly failed to establish that it
contains any misconceptions whatsoever.

That is dishonest.

For someone who has threatened me with legal action for libel, you're
mighty free with that word.

Doing as Olcott does might indeed be a tort or crime.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)