From Newsgroup: comp.theory

On 8/26/2025 4:23 PM, olcott wrote:

On 8/26/2025 2:57 PM, dbush wrote:

On 8/26/2025 3:44 PM, Richard Heathfield wrote:

On 26/08/2025 20:00, olcott wrote:

On 8/26/2025 12:49 PM, Richard Heathfield wrote:

<snip>

You have already established that HHH returns 0

to claim that DDD never halts.

Liar

I'm sorry? Are you now saying DDD halts?

He's referring to his weasel-word phrase "DD emulated by HHH according
to the semantics of the x86 language".

The ACTUAL BEHAVIOR of the ACTUAL INPUT to HHH(DD)
specifies the non-halting behavior of never reaching
its own halt state as measured by DD correctly simulated
by any HHH.

In other words, the computable function that the HHH you've implemented computes is not the halting function, and therefore HHH is not a halt
decider


Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 26/08/2025 21:03, dbush wrote:

On 8/26/2025 4:00 PM, Richard Heathfield wrote:

On 26/08/2025 20:57, dbush wrote:

On 8/26/2025 3:44 PM, Richard Heathfield wrote:

On 26/08/2025 20:00, olcott wrote:

On 8/26/2025 12:49 PM, Richard Heathfield wrote:

<snip>

You have already established that HHH returns 0

to claim that DDD never halts.

Liar

I'm sorry? Are you now saying DDD halts?

He's referring to his weasel-word phrase "DD emulated by HHH
according to the semantics of the x86 language".

So does he think DD halts or doesn't he?

And why do I get the feeling that the right answer to that
question is "no"?

He thinks that DD (as is) halts, but if you were to replace the
code of HHH with a pure simulator then the resulting DD would not
halt, so based on that he's claiming HHH(DD)==0 correct.

This is of course nonsense.

So he knows it halts but thinks it doesn't? No, wait, he /thinks/
it halts but says it doesn't, in case he can find some jump leads
from somewhere? He's going to need more than a jump-start,
because he's seven gaskets, three brake pads, a cylinder head,
seven rocker arms, a gudgeon pin, an accelerator, a camshaft, two
passenger doors, a distributor, a handbrake, a boot lid, a roof
panel, two front wings, a cylinder block, a radiator, a
carburettor, three wheels, a cigarette lighter, a crankshaft,
four tyres, four pistons, a bonnet, a fuel cap, a footwell mat, a
fan belt, a left sills, two wheel arch liners, a tyre iron, eight
valve springs, a petrol tank, a distributor cap, a driver's door,
two connecting rods, three spark plugs, a gearbox, three hubcaps,
a clutch, a brake, a speedometer, front and rear bumper bars,
eleven wheel nuts, four exhaust valves, front and rear valances,
four inlet valves, an ignition key, and seventeen chewing gum
wrappers short of a car.
--
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 26/08/2025 21:23, olcott wrote:

On 8/26/2025 2:57 PM, dbush wrote:

On 8/26/2025 3:44 PM, Richard Heathfield wrote:

On 26/08/2025 20:00, olcott wrote:

On 8/26/2025 12:49 PM, Richard Heathfield wrote:

<snip>

You have already established that HHH returns 0

to claim that DDD never halts.

Liar

I'm sorry? Are you now saying DDD halts?

He's referring to his weasel-word phrase "DD emulated by HHH
according to the semantics of the x86 language".

The ACTUAL BEHAVIOR of the ACTUAL INPUT to HHH(DD)
specifies the non-halting behavior of never reaching
its own halt state as measured by DD correctly simulated
by any HHH.

So you called me a liar...why, exactly?

If we don't measure the The ACTUAL BEHAVIOR of the
ACTUAL INPUT to HHH(DD) this way then we stupidly
ignore the verified fact that DD DOES CALL HHH(DD)
in RECURSIVE SIMULATION.

HHH must report. If you stupidly ignore that, you stupidly don't
stop to think next.

I honestly don't see how dozens of people in the
last three years could honestly ignore the fact
that DD does call HHH(DD) in recursive simulation
and this does change the behavior of DD.

DD's halting behaviour depends entirely on what HHH returns. Only
an idiot can't see that.
--
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/26/2025 1:48 PM, Richard Heathfield wrote:

On 26/08/2025 21:03, dbush wrote:

On 8/26/2025 4:00 PM, Richard Heathfield wrote:

On 26/08/2025 20:57, dbush wrote:

On 8/26/2025 3:44 PM, Richard Heathfield wrote:

On 26/08/2025 20:00, olcott wrote:

On 8/26/2025 12:49 PM, Richard Heathfield wrote:

<snip>

You have already established that HHH returns 0

to claim that DDD never halts.

Liar

I'm sorry? Are you now saying DDD halts?

He's referring to his weasel-word phrase "DD emulated by HHH
according to the semantics of the x86 language".

So does he think DD halts or doesn't he?

And why do I get the feeling that the right answer to that question
is "no"?

He thinks that DD (as is) halts, but if you were to replace the code
of HHH with a pure simulator then the resulting DD would not halt, so
based on that he's claiming HHH(DD)==0 correct.

This is of course nonsense.

So he knows it halts but thinks it doesn't? No, wait, he /thinks/ it
halts but says it doesn't, in case he can find some jump leads from somewhere? He's going to need more than a jump-start, because he's seven gaskets, three brake pads, a cylinder head, seven rocker arms, a gudgeon pin, an accelerator, a camshaft, two passenger doors, a distributor, a handbrake, a boot lid, a roof panel, two front wings, a cylinder block,
a radiator, a carburettor, three wheels, a cigarette lighter, a
crankshaft, four tyres, four pistons, a bonnet, a fuel cap, a footwell
mat, a fan belt, a left sills, two wheel arch liners, a tyre iron, eight valve springs, a petrol tank, a distributor cap, a driver's door, two connecting rods, three spark plugs, a gearbox, three hubcaps, a clutch,
a brake, a speedometer, front and rear bumper bars, eleven wheel nuts,
four exhaust valves, front and rear valances, four inlet valves, an
ignition key, and seventeen chewing gum wrappers short of a car.

Shit man! How about light years away on his time?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/26/2025 3:52 PM, Richard Heathfield wrote:

On 26/08/2025 21:23, olcott wrote:

On 8/26/2025 2:57 PM, dbush wrote:

On 8/26/2025 3:44 PM, Richard Heathfield wrote:

On 26/08/2025 20:00, olcott wrote:

On 8/26/2025 12:49 PM, Richard Heathfield wrote:

<snip>

You have already established that HHH returns 0

to claim that DDD never halts.

Liar

I'm sorry? Are you now saying DDD halts?

He's referring to his weasel-word phrase "DD emulated by HHH
according to the semantics of the x86 language".

The ACTUAL BEHAVIOR of the ACTUAL INPUT to HHH(DD)
specifies the non-halting behavior of never reaching
its own halt state as measured by DD correctly simulated
by any HHH.

So you called me a liar...why, exactly?

If we don't measure the The ACTUAL BEHAVIOR of the
ACTUAL INPUT to HHH(DD) this way then we stupidly
ignore the verified fact that DD DOES CALL HHH(DD)
in RECURSIVE SIMULATION.

HHH must report. If you stupidly ignore that, you stupidly don't stop to think next.

I honestly don't see how dozens of people in the
last three years could honestly ignore the fact
that DD does call HHH(DD) in recursive simulation
and this does change the behavior of DD.

DD's halting behaviour depends entirely on what HHH returns. Only an
idiot can't see that.

As I have said hundreds of times now it never
has been any of the f-cking business of any
Turing machine based halt decider whether M
halts on input P. All the textbooks get this WRONG.

It has all been about the behavior specified by
the input rf?Mrf-, P to to H THAT IS CHANGED WHEN
M calls H in recursive simulation.
--
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 26/08/2025 22:14, olcott wrote:

On 8/26/2025 3:52 PM, Richard Heathfield wrote:

On 26/08/2025 21:23, olcott wrote:

<snip>

I honestly don't see how dozens of people in the
last three years could honestly ignore the fact
that DD does call HHH(DD) in recursive simulation
and this does change the behavior of DD.

DD's halting behaviour depends entirely on what HHH returns.
Only an idiot can't see that.

As I have said hundreds of times now it never
has been any of the f-cking business of any
Turing machine based halt decider whether M
halts on input P.

I've left that in because it's so illustrative of how warped your
thinking is. I won't bother to gainsay it because you never
bloody listen.

All the textbooks get this WRONG.

I doubt that very much. They're not the kind of textbook I kind
to buy, you understand, so I don't know from personal experience,
but I suspect that evolution will bring to the fore authors who
know their stuff. Still! Think what you like.

It has all been about the behavior specified by
the input rf?Mrf-, P to to H THAT IS CHANGED WHEN
M calls H in recursive simulation.

Who cares?
--
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/26/25 11:44 AM, olcott wrote:

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

On 2025-08-19 14:51:53 +0000, olcott said:

On 8/19/2025 2:20 AM, Mikko wrote:

On 2025-08-18 20:35:30 +0000, Mr Flibble said:

I still haven't figured out if Olcott's obtuseness is wilful or
innate.

It doesn't matter. The only thing we can do is to point out that
the truth is different.

If people pay close enough attention they see that I am correct.

People who have paid close enough attention have seen your mistakes.
For example:

On 8/18/2025 6:05 PM, Richard Heathfield wrote:

It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.

That is agreement that DD correctly simulated by HHH
cannot halt because DD calls HHH(DD) in recursive
simulation.

But not as a halt decider, but as a POOP decider.

The problem is your definition doesn't apply to programs given
representations of programs as an input, as "needs to abort" isn't an attribute about a program, (in the way you are using it) as it will
either abort or not.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 8/26/2025 5:14 PM, olcott wrote:

On 8/26/2025 3:52 PM, Richard Heathfield wrote:

On 26/08/2025 21:23, olcott wrote:

On 8/26/2025 2:57 PM, dbush wrote:

On 8/26/2025 3:44 PM, Richard Heathfield wrote:

On 26/08/2025 20:00, olcott wrote:

On 8/26/2025 12:49 PM, Richard Heathfield wrote:

<snip>

You have already established that HHH returns 0

to claim that DDD never halts.

Liar

I'm sorry? Are you now saying DDD halts?

He's referring to his weasel-word phrase "DD emulated by HHH
according to the semantics of the x86 language".

The ACTUAL BEHAVIOR of the ACTUAL INPUT to HHH(DD)
specifies the non-halting behavior of never reaching
its own halt state as measured by DD correctly simulated
by any HHH.

So you called me a liar...why, exactly?

If we don't measure the The ACTUAL BEHAVIOR of the
ACTUAL INPUT to HHH(DD) this way then we stupidly
ignore the verified fact that DD DOES CALL HHH(DD)
in RECURSIVE SIMULATION.

HHH must report. If you stupidly ignore that, you stupidly don't stop
to think next.

I honestly don't see how dozens of people in the
last three years could honestly ignore the fact
that DD does call HHH(DD) in recursive simulation
and this does change the behavior of DD.

DD's halting behaviour depends entirely on what HHH returns. Only an
idiot can't see that.

As I have said hundreds of times now it never
has been any of the f-cking business of any
Turing machine based halt decider whether M
halts on input P. All the textbooks get this WRONG.

In other words, you agree with Turing and Linz that no Turing machine
meets these requirements:


Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

--- Synchronet 3.21a-Linux NewsLink 1.2