Op 07.aug.2025 om 05:09 schreef olcott:

On 8/6/2025 9:11 PM, Richard Damon wrote:

On 8/6/25 8:16 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:33 AM, olcott wrote:

On 8/6/2025 2:16 AM, Mikko wrote:

On 2025-08-05 14:41:15 +0000, olcott said:

On 8/5/2025 2:08 AM, Mikko wrote:

On 2025-08-04 18:29:04 +0000, olcott said:

Diagonalization only arises when one assumes that a
Turing machine decider must report on its own behavior
instead of the behavior specified by its machine description. >>>>>>>>

Wrong. There are proofs by diagonalization that do not assume
anything about Turing machines.

That was said within the context of Turing Machine halt deciders >>>>>>> as can be seen by its words.

No, in the OP the words were those of a general statement. References >>>>>> to Turing machines were only in a subordinate clause and there were >>>>>> no reference to halting.

Diagonalization only arises when one assumes that a
*Turing machine decider* must report on its own behavior
instead of the behavior specified by its machine description.

But that *IS* a requirement of it, at least if we ask about its own
behavior by providing it with a representation that includes itself.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
    if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.

Thus lines two and four are incorrect because they
require Ĥ.embedded_H to report on its own behavior.

But there is nothing wrong about that.

You are just asserting your own ignorance.

It does not make sense to assume that a Turing machine decider >>>>>>>> must or must not report on this or that. The only reasonable
assumptions are those that specify the topic of the proof.

It makes no sense to require a function to be applied
to elements outside of its domain.

But that *IS* in its domain.

Turing machines are not in the domain of Turing machine deciders,
only finite strings are in this domain.

But they are by representation

I guess yoyu think Turing Machines can't do arithmatic, since numbers
are in the domain of finite strings.

I have proven that in the case where a Turing Machine halt decider
it evaluating the behavior of its own machine description that
the behavior specified by the description is not the behavior
of the underlying machine.

Sure it is, you just don't define the behavior correctly.

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is
specified. Ignoring the conditional branch instructions during the
simulation and dreaming of a hypothetical non-input that does not abort,
is no evidence for the opposite.

You cannot possibly show otherwise in the cases that
we have discussed.

No, we accept hat HHH fails to reach the final halt state specified in
the input.

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

On 8/6/25 11:09 PM, olcott wrote:

On 8/6/2025 9:11 PM, Richard Damon wrote:

On 8/6/25 8:16 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:33 AM, olcott wrote:

On 8/6/2025 2:16 AM, Mikko wrote:

On 2025-08-05 14:41:15 +0000, olcott said:

On 8/5/2025 2:08 AM, Mikko wrote:

On 2025-08-04 18:29:04 +0000, olcott said:

Diagonalization only arises when one assumes that a
Turing machine decider must report on its own behavior
instead of the behavior specified by its machine description. >>>>>>>>

Wrong. There are proofs by diagonalization that do not assume
anything about Turing machines.

That was said within the context of Turing Machine halt deciders >>>>>>> as can be seen by its words.

No, in the OP the words were those of a general statement. References >>>>>> to Turing machines were only in a subordinate clause and there were >>>>>> no reference to halting.

Diagonalization only arises when one assumes that a
*Turing machine decider* must report on its own behavior
instead of the behavior specified by its machine description.

But that *IS* a requirement of it, at least if we ask about its own
behavior by providing it with a representation that includes itself.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
    if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    if Ĥ applied to ⟨Ĥ⟩ does not halt.

Thus lines two and four are incorrect because they
require Ĥ.embedded_H to report on its own behavior.

But there is nothing wrong about that.

You are just asserting your own ignorance.

It does not make sense to assume that a Turing machine decider >>>>>>>> must or must not report on this or that. The only reasonable
assumptions are those that specify the topic of the proof.

It makes no sense to require a function to be applied
to elements outside of its domain.

But that *IS* in its domain.

Turing machines are not in the domain of Turing machine deciders,
only finite strings are in this domain.

But they are by representation

I guess yoyu think Turing Machines can't do arithmatic, since numbers
are in the domain of finite strings.

I have proven that in the case where a Turing Machine halt decider
it evaluating the behavior of its own machine description that
the behavior specified by the description is not the behavior
of the underlying machine.

Sure it is, you just don't define the behavior correctly.

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.
You cannot possibly show otherwise in the cases that
we have discussed.

Not for this case.

Note, your problem is an error in definition. The problem is that when
the decider does only a partial simulation, the fact that it doesn't
reach a final state does not mean that the correct simulation of THAT
input will not halt.

The correct simulation of *ANY* DDD from your infinte set, that is based
on an HHH that has a pattern that you want to claim proves non-halting
beavior, will reach a final state at a point after the point that that
HHH decided the input must be non-halting and stopped its simulation.

Your problem is each of your HHH are given a DIFFERENT input, as that
input MUST contain the code of THAT HHH to be simulatable at all as a
program. And thus none of the input you claim to find a non-halting
pattern were ever correctly simulated by your decider.

So, have you stopped watching kiddie porn?

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

On 8/7/25 10:03 AM, olcott wrote:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is
specified. Ignoring the conditional branch instructions during the
simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

But since any HHH that reports didn't do a correct emulation, and the
correct emulation was of a differnt input, and thus the logic isn't correct.

Sorry, you are just proving you don't understand how to do logic.

You cannot possibly show otherwise in the cases that
we have discussed.

No, we accept hat HHH fails to reach the final halt state specified in
the input.

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

On 2025-08-07 14:03:00 +0000, olcott said:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is
specified. Ignoring the conditional branch instructions during the
simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

Requirements of a halt decider and a partial halt decider
don't require reporting anything that depends on what HHH
does or can do. Instead they require that HHH(DDD) reports
whether DDD() halts, which DDD does if HHH(DDD) reports
anything.

--
Mikko

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

Op 07.aug.2025 om 16:03 schreef olcott:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is
specified. Ignoring the conditional branch instructions during the
simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

As usual irrelevant claims.
Indeed, HHH fails to reach the specified final halt state and there is
no way to correct that.
That only proves the failure of simulation to analyse such input correctly.

You cannot possibly show otherwise in the cases that
we have discussed.

No, we accept hat HHH fails to reach the final halt state specified in
the input.

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

On 08/08/2025 09:11, Fred. Zwarts wrote:

Op 07.aug.2025 om 16:03 schreef olcott:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite
recursion is specified. Ignoring the conditional branch
instructions during the simulation and dreaming of a
hypothetical non-input that does not abort, is no evidence for
the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

As usual irrelevant claims.
Indeed, HHH fails to reach the specified final halt state and
there is no way to correct that.

In order to succeed, HHH would have to terminate before HHH
terminates, which is a contradiction.

That only proves the failure of simulation to analyse such input
correctly.

Yes. HHH has to guess, and DD will demonstrate that the guess is
wrong.

--
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 8/8/25 11:39 AM, olcott wrote:

On 8/8/2025 3:27 AM, Richard Heathfield wrote:

On 08/08/2025 09:11, Fred. Zwarts wrote:

Op 07.aug.2025 om 16:03 schreef olcott:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is
specified. Ignoring the conditional branch instructions during the
simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

As usual irrelevant claims.
Indeed, HHH fails to reach the specified final halt state and there
is no way to correct that.

In order to succeed, HHH would have to terminate before HHH
terminates, which is a contradiction.

*Proven to be counter-factual*

We could quit going around and around on the basis of
your false assumptions if you only read this single page
explanation of why HHH(DD)==0 is correct. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

The problem with your arguement is it requires LYING about what the
input means.

I do have concrete C/C++ code that proves DD correctly
simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state. This may be too
difficult to understand until after you read the Claude AI
gist of my proof: *Why HHH(DD)==0 is correct*

CAN'T BE.

It proves that you HHH(DD) returns 0.

And that DD() halts.

Since the Halting Problem is that HHH needs to return 1 if the program
its input represents halt, it wasn't correct,

TO say its input means anything else, must be a lie, as the DEFINITION
of the "pathological program" DD, is that it asks the decider about DDs behavior. so that must be what that input means.

typedef int (*ptr)();
int HHH(ptr P);

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

int main()
{
  HHH(DD);
}

That only proves the failure of simulation to analyse such input
correctly.

Yes. HHH has to guess, and DD will demonstrate that the guess is wrong.

*These two facts can be verified*
DD correctly simulated by HHH cannot possibly reach
its own simulated "return" statement final halt state.
HHH(DD) correctly detects and reports this.

But it can also be verified that your specific HHH doesn't do a correct simulation,

and that NO HHH that does a correct simulation can answer, so isn't a
decider,

and that every DD, to be a program that can be simulated, must include
the code of the HHH that it is based on, which will be the one that is
deciding it in this template, and thus every imaginable HHH gets a
different DD as its input,

and that every HHH that returns the value 0, makes a DD that when run or correctly simulated will enter that HHH and it will simulate this code
for a while, which will then (after the point that HHH partially
simulate it stops its simulation) also its simulation and return 0 and
thus the input halts.

So, your claim is just built on faulty logic and LIES as that input was
NEVER in your argument correctly simulated, and you have no valid
induction, so you have no real proof.

Here is the complete C/C++ codebase:
https://github.com/plolcott/x86utm

Right, which, as pointed out above, prove you lie, and don't understand
that basics of what you talk about (and don't care you don't) which is
why you make such erroneous arguements, even after being corrected.

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

On 2025-08-08 15:48:58 +0000, olcott said:

On 8/8/2025 2:17 AM, Mikko wrote:

On 2025-08-07 14:03:00 +0000, olcott said:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is
specified. Ignoring the conditional branch instructions during the
simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

Requirements of a halt decider and a partial halt decider
don't require reporting anything that depends on what HHH
does or can do. Instead they require that HHH(DDD) reports
whether DDD() halts, which DDD does if HHH(DDD) reports
anything.

I use the concrete C programming language so that key
details are not merely abstracted away by false assumptions.
When I do this then false assumptions are proven to be
counter-factual.

A concrete Turing machine language would be simpler and therefore
easier to analyze and to ensure that the analysis covers all
features of the language.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

What the input specifies ia a non-imput.

Correct simulation is a correct measure of this behavior.

No, the specified behaviour this the measure of the correctness
of the simulation.

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.

No, it does not. Simulation and direct executijon only vary
when the simulation is not correct.

In the case it is the input that rules and non-inputs are
irrelevant.

Whatever the problem says is relevant.

That you call the behaviour specified by the input a non-input
does not make it irrelevant.

--
Mikko

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

On 10/08/2025 15:30, olcott wrote:

On 8/10/2025 3:09 AM, Mikko wrote:

On 2025-08-08 15:48:58 +0000, olcott said:

<snip>

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.

No, it does not. Simulation and direct executijon only vary
when the simulation is not correct.

I just proved that you are wrong about this.

No, you didn't. Saying he's wrong and proving he's wrong are two
very different things.

All you proved is that your simulation code is buggy.

--
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 Sun, 10 Aug 2025 09:30:11 -0500, olcott wrote:

Claude AI proved why HHH(DD)==0 is correct in terms that any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

I am an expert C programmer which is why I understand that DD() halts,
HHH(DD) reports non-halting and thus is not a halt decider over DD as it
gets the answer wrong -- thus you have not refuted any Halting Problem
proofs and have thus wasted the last 22 years.

/Flibble

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

On 8/10/25 10:30 AM, olcott wrote:

On 8/10/2025 3:09 AM, Mikko wrote:

On 2025-08-08 15:48:58 +0000, olcott said:

On 8/8/2025 2:17 AM, Mikko wrote:

On 2025-08-07 14:03:00 +0000, olcott said:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is >>>>>> specified. Ignoring the conditional branch instructions during the >>>>>> simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

Requirements of a halt decider and a partial halt decider
don't require reporting anything that depends on what HHH
does or can do. Instead they require that HHH(DDD) reports
whether DDD() halts, which DDD does if HHH(DDD) reports
anything.

I use the concrete C programming language so that key
details are not merely abstracted away by false assumptions.
When I do this then false assumptions are proven to be
counter-factual.

A concrete Turing machine language would be simpler and therefore
easier to analyze and to ensure that the analysis covers all
features of the language.

Proven to be incorrect.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*Repeats until aborted*

But *IS* aborted, since that *IS* what your H does.

(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

And thus after some number of cycles, the first embedded_H simulated
*WILL* abort its simulation and return to the first emulated H^, just
after H aborted its simulation, and no longer sees the behavior of the
correct simulation of the input.

When I say that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
Ĥ.embedded_H cannot possibly reach its simulated
final halt state of ⟨Ĥ.qn⟩ and Ĥ applied to ⟨Ĥ⟩ halts
people leap to the incorrect conclusion that the
simulation is incorrect.

But that doesn't apply to this input. as THAT H, the one this H^ is
built on, DOES abort, and DOEN'T do a correct simulation.

The imaginary H that you claim does this correct simulation, will be
simulating a DIFFERENT imaginary input H^, as you give it one built on
the imaginary H, not the one built on the "real" H.

One of your LIES, is that they are all the same, but that only shows
that you logic is based on a category error, as your input isn't the representation of the PROGRAM it is supposed to be, but just a fragment representing the non-program of your template.

This means that the decider can't actually simulate THE INPUT, because
it isn't complete, and can't be simulated beyond the call to HHH.

Treating that is a "refernce" to the decider simulating it, as programs
can't have such a thing (since they don't have a machince simulating
them) and thus you don't have a program, and thus DO have a category error.

_DD()
[00002162] 55             push ebp
[00002163] 8bec           mov ebp,esp
[00002165] 51             push ecx
[00002166] 6862210000     push 00002162 // push DD
[0000216b] e862f4ffff     call 000015d2 // call HHH
[00002170] 83c404         add esp,+04
[00002173] 8945fc         mov [ebp-04],eax
[00002176] 837dfc00       cmp dword [ebp-04],+00
[0000217a] 7402           jz 0000217e
[0000217c] ebfe           jmp 0000217c
[0000217e] 8b45fc         mov eax,[ebp-04]
[00002181] 8be5           mov esp,ebp
[00002183] 5d             pop ebp
[00002184] c3             ret
Size in bytes:(0035) [00002184]

When I say that DD emulated by HHH according to the
semantics of the x86 language cannot possibly reach
its emulated "ret" instruction final halt state and
the directly executed DD() halts and people disagree
that the simulation is correct they have been already
proven wrong.

And then you don't have your HHH do that, as the semantics of the x86
language says you don't stop until you reach a final instruction.

So, you are just lying.

Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

Nope, it makes the same error you lead it into, just proving you don't understand how logic works, but are just a liar.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

What the input specifies ia a non-imput.

Correct simulation is a correct measure of this behavior.

No, the specified behaviour this the measure of the correctness
of the simulation.

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.

No, it does not. Simulation and direct executijon only vary
when the simulation is not correct.

I just proved that you are wrong about this.
If you are clueless about the semantics of the x86
language you will not be able to understand the proof.

Nope, you proved you lie and are clueless.

The mear fact of claiming that an AI agreeing with you is a "proof"
shows your stupidity.

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

On 2025-08-10 14:30:11 +0000, olcott said:

On 8/10/2025 3:09 AM, Mikko wrote:

On 2025-08-08 15:48:58 +0000, olcott said:

On 8/8/2025 2:17 AM, Mikko wrote:

On 2025-08-07 14:03:00 +0000, olcott said:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is >>>>>> specified. Ignoring the conditional branch instructions during the >>>>>> simulation and dreaming of a hypothetical non-input that does not
abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

Requirements of a halt decider and a partial halt decider
don't require reporting anything that depends on what HHH
does or can do. Instead they require that HHH(DDD) reports
whether DDD() halts, which DDD does if HHH(DDD) reports
anything.

I use the concrete C programming language so that key
details are not merely abstracted away by false assumptions.
When I do this then false assumptions are proven to be
counter-factual.

A concrete Turing machine language would be simpler and therefore
easier to analyze and to ensure that the analysis covers all
features of the language.

Proven to be incorrect.

Post the proof or a pointer to the proof. Otherwise we will think
that you are bluffing.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

When I say that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
Ĥ.embedded_H cannot possibly reach its simulated
final halt state of ⟨Ĥ.qn⟩ and Ĥ applied to ⟨Ĥ⟩ halts
people leap to the incorrect conclusion that the
simulation is incorrect.

_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]

When I say that DD emulated by HHH according to the
semantics of the x86 language cannot possibly reach
its emulated "ret" instruction final halt state and
the directly executed DD() halts and people disagree
that the simulation is correct they have been already
proven wrong.

Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

Talking about something else does not prove something.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

What the input specifies ia a non-imput.

Correct simulation is a correct measure of this behavior.

No, the specified behaviour this the measure of the correctness
of the simulation.

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.

No, it does not. Simulation and direct executijon only vary
when the simulation is not correct.

I just proved that you are wrong about this.
If you are clueless about the semantics of the x86
language you will not be able to understand the proof.

As long as you don't present any proof you have proven nothing.
And you need a really very good proof if you want to prove that
an obvious consequence of the meanngs of words is false.

--
Mikko

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

On 8/11/25 10:43 AM, olcott wrote:

On 8/11/2025 1:58 AM, Mikko wrote:

On 2025-08-10 14:30:11 +0000, olcott said:

On 8/10/2025 3:09 AM, Mikko wrote:

On 2025-08-08 15:48:58 +0000, olcott said:

On 8/8/2025 2:17 AM, Mikko wrote:

On 2025-08-07 14:03:00 +0000, olcott said:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion >>>>>>>> is specified. Ignoring the conditional branch instructions
during the simulation and dreaming of a hypothetical non-input >>>>>>>> that does not abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

Requirements of a halt decider and a partial halt decider
don't require reporting anything that depends on what HHH
does or can do. Instead they require that HHH(DDD) reports
whether DDD() halts, which DDD does if HHH(DDD) reports
anything.

I use the concrete C programming language so that key
details are not merely abstracted away by false assumptions.
When I do this then false assumptions are proven to be
counter-factual.

A concrete Turing machine language would be simpler and therefore
easier to analyze and to ensure that the analysis covers all
features of the language.

Proven to be incorrect.

Post the proof or a pointer to the proof. Otherwise we will think
that you are bluffing.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

When I say that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
Ĥ.embedded_H cannot possibly reach its simulated
final halt state of ⟨Ĥ.qn⟩ and Ĥ applied to ⟨Ĥ⟩ halts
people leap to the incorrect conclusion that the
simulation is incorrect.

_DD()
[00002162] 55             push ebp
[00002163] 8bec           mov ebp,esp
[00002165] 51             push ecx
[00002166] 6862210000     push 00002162 // push DD
[0000216b] e862f4ffff     call 000015d2 // call HHH
[00002170] 83c404         add esp,+04
[00002173] 8945fc         mov [ebp-04],eax
[00002176] 837dfc00       cmp dword [ebp-04],+00
[0000217a] 7402           jz 0000217e
[0000217c] ebfe           jmp 0000217c
[0000217e] 8b45fc         mov eax,[ebp-04]
[00002181] 8be5           mov esp,ebp
[00002183] 5d             pop ebp
[00002184] c3             ret
Size in bytes:(0035) [00002184]

When I say that DD emulated by HHH according to the
semantics of the x86 language cannot possibly reach
its emulated "ret" instruction final halt state and
the directly executed DD() halts and people disagree
that the simulation is correct they have been already
proven wrong.

Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

Talking about something else does not prove something.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

What the input specifies ia a non-imput.

Correct simulation is a correct measure of this behavior.

No, the specified behaviour this the measure of the correctness
of the simulation.

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.

No, it does not. Simulation and direct executijon only vary
when the simulation is not correct.

I just proved that you are wrong about this.
If you are clueless about the semantics of the x86
language you will not be able to understand the proof.

As long as you don't present any proof you have proven nothing.
And you need a really very good proof if you want to prove that
an obvious consequence of the meanngs of words is false.

I presented several proofs that you did not understand.

No, you made several false claims, because you still don't understand
the errors pointed out to you the last time you made them.

To PROVE something, you have to start with accepted truths, which you
just don't do.

This is why you are so desperate for people to accept one of your lies,
so you can try to build a proof off of it.

You just don't understand how logic works, because you chose to make
yourself just ignorant, and don't seem to understand what truth actually is.

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

On 2025-08-11 14:43:31 +0000, olcott said:

On 8/11/2025 1:58 AM, Mikko wrote:

On 2025-08-10 14:30:11 +0000, olcott said:

On 8/10/2025 3:09 AM, Mikko wrote:

On 2025-08-08 15:48:58 +0000, olcott said:

On 8/8/2025 2:17 AM, Mikko wrote:

On 2025-08-07 14:03:00 +0000, olcott said:

On 8/7/2025 4:36 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:09 schreef olcott:>>

It is an easily verified fact a finite sequence of
simulated steps does prove that an infinite sequence of
steps cannot possibly reach a simulated final halt state.

It has been proven that for this input, only a finite recursion is >>>>>>>> specified. Ignoring the conditional branch instructions during the >>>>>>>> simulation and dreaming of a hypothetical non-input that does not >>>>>>>> abort, is no evidence for the opposite.

HHH(DDD) correctly predicts that DDD correctly emulated
by HHH cannot possibly reach its own emulated final halt
state no matter what HHH does.

Requirements of a halt decider and a partial halt decider
don't require reporting anything that depends on what HHH
does or can do. Instead they require that HHH(DDD) reports
whether DDD() halts, which DDD does if HHH(DDD) reports
anything.

I use the concrete C programming language so that key
details are not merely abstracted away by false assumptions.
When I do this then false assumptions are proven to be
counter-factual.

A concrete Turing machine language would be simpler and therefore
easier to analyze and to ensure that the analysis covers all
features of the language.

Proven to be incorrect.

Post the proof or a pointer to the proof. Otherwise we will think
that you are bluffing.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

When I say that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
Ĥ.embedded_H cannot possibly reach its simulated
final halt state of ⟨Ĥ.qn⟩ and Ĥ applied to ⟨Ĥ⟩ halts
people leap to the incorrect conclusion that the
simulation is incorrect.

_DD()
[00002162] 55             push ebp
[00002163] 8bec           mov ebp,esp
[00002165] 51             push ecx
[00002166] 6862210000     push 00002162 // push DD
[0000216b] e862f4ffff     call 000015d2 // call HHH
[00002170] 83c404         add esp,+04
[00002173] 8945fc         mov [ebp-04],eax
[00002176] 837dfc00       cmp dword [ebp-04],+00
[0000217a] 7402           jz 0000217e
[0000217c] ebfe           jmp 0000217c
[0000217e] 8b45fc         mov eax,[ebp-04]
[00002181] 8be5           mov esp,ebp
[00002183] 5d             pop ebp
[00002184] c3             ret
Size in bytes:(0035) [00002184]

When I say that DD emulated by HHH according to the
semantics of the x86 language cannot possibly reach
its emulated "ret" instruction final halt state and
the directly executed DD() halts and people disagree
that the simulation is correct they have been already
proven wrong.

Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c

Talking about something else does not prove something.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

What the input specifies ia a non-imput.

Correct simulation is a correct measure of this behavior.

No, the specified behaviour this the measure of the correctness
of the simulation.

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.

No, it does not. Simulation and direct executijon only vary
when the simulation is not correct.

I just proved that you are wrong about this.
If you are clueless about the semantics of the x86
language you will not be able to understand the proof.

As long as you don't present any proof you have proven nothing.
And you need a really very good proof if you want to prove that
an obvious consequence of the meanngs of words is false.

I presented several proofs that you did not understand.

It is sufficient to understand that none of what you have presented
is a proof.

--
Mikko

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