On 12/03/2025 22:03, dbush wrote:

Again, the implementation of HHH has nothing to do with the
description given to it or the required mapping.

Indeed, the idea of an implementation is rather bizarre in the
context. Cutting code for this would be like getting your ruler
out to measure the sides of a triangle when proving Pythagoras.
All the heavy lifting is done in the thought experiment.

--
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 3/12/25 10:41 PM, olcott wrote:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:>>

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING
MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD
emulated by HHH according to the semantics of the
x86 language.

Nope, you have never "proven" that, only claimed it with unsound arguements.

If your claim was true, you could show the first instruction correctly
directly executed and correctly emulated by HHH by the definitions of
the x86 language where the paths differed.

Your failure is an admission that you know this to be a lie. Your
attempts to explaim it away show that you don't know what you are
talking about, and know you are just lying.

HAVE YOU EVER HEARD OF RICES THEOREM ???

In computability theory, Rice's theorem states that all
non-trivial semantic properties of programs [that
can be encoded as finite strings] are undecidable. https://en.wikipedia.org/wiki/Rice%27s_theorem

Right, so since Halting is such a problem, you acceptance of Rice's
Theory proves that your claim is wrong.

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC
OR SYNTACTIC PROPERTY OF THEIR INPUT FINITE STRINGS.

Right, and a semantic property, like halting, is DEFINED to be based on
the actual execution of the program being decided on, so you just
admitted your claim is wrong.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Which isn't a program, since it doesn't contain all the code, and when
you add the code for the one and only HHH that you will claim to exist,
your other claims can't stand, as that HHH will either abort its
emulation, and thus not be a correct emulation that can define the
behavior, or it will do a correct emulation and then never return an
answer, so it isn't a decider.

Your arguement is based on the contradiction that it can be one program
and do both at the same time.

Note, it needs to be one program, as you have defined that they both
live in the exact same memory locations, so have the exact same
deterministic code.

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

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same
behaviour.

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC PROPERTY OF THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Thu, 13 Mar 2025 15:46:51 -0500 schrieb olcott:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same
behaviour.

Right?

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC PROPERTY
OF THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.

DDD correctly emulated by HHH cannot possibly reach its own final state
no matter what HHH does.

It could, if it didn't disable the abort.

DDD correctly emulated by HHH1 does reach its own final state.

It must be doing something wrong then.

If someone was not a liar they would say that these are different computations.

The simulators are different, but they are simulating the same computation (duh).

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 13/03/2025 20:48, dbush wrote:

On 3/13/2025 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated
by HHH
according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce
the same
behaviour.

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF
THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't
abort.

Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) cannot possibly
reach its own final state no matter what HHH
does.

Replacing the code of HHH1 with an unconditional simulator and
subsequently running HHH1(DD) does reach its
own final state.

If someone was not a liar they would say that
these are different computations.

Only because one changes the code that DD runs and one doesn't

It hardly matters. Either his emulation faithfully and correctly
establishes and reports (for EVERY program anyone cares to feed
it) the actual halting behaviour exhibited by the program it's
emulating, or it doesn't.

If it doesn't, it doesn't, and it's a lot of fuss over nothing.

But if it /does/, then we're right back at Turing's proof,
because a working emulator is just another way of running the
code, and is therefore superfluous to requirements. It adds
nothing to the debate, because we can just run the code and get
the same answer the emulator would provide.

In other words, the emulator is a canard, a distraction, a
cul-de-sac, and a complete waste of time. If it happens to work,
great! Well done that man. But it doesn't affect the HP logic one microscopically minuscule millijot.

--
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 3/13/25 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same
behaviour.

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC PROPERTY OF >>> THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.

DDD correctly emulated by HHH cannot possibly
reach its own final state no matter what HHH
does.

DDD correctly emulated by HHH1 does reach its
own final state.

Which shows that HHH doesn't correctly emulate its input, unless you
just lied and gave the two programs different inputs.

If someone was not a liar they would say that
these are different computations.

Well, they were because they were different inputs, one the DDD that
called the HHH that gets stuck in infinite recursion, and the other DDD
called the HHH that aborts and returns,

You are just showing that you don't understand the words you are using,
and have even gone so far as to admit that fraud, and that you change
the meaning of core terms-of-art, so nothing you say has any real
meaning anymore.

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

On 3/13/25 10:08 PM, olcott wrote:

On 3/13/2025 6:09 PM, Richard Damon wrote:

On 3/13/25 12:09 PM, olcott wrote:

On 3/13/2025 10:44 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

On 11/03/2025 18:23, Richard Heathfield wrote:

On 11/03/2025 17:42, Mike Terry wrote:

Finally, if you really want to see the actual HHH code, its in the >>>>>>> halt7.c file (along with DDD) that PO provides links to from time to >>>>>>> time.  However it's not very illuminating due to bugs/design
errors/misunderstandings which only serve to obfuscate PO's
errors in
thinking.

[I've now seen the code. Oh deary deary me.]

:)

Thank you for a spirited attempt to be cogent - or at least as
cogent as
it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly >>>>>> diagnoses some easy functions, such as these:

Not really necessary - PO is not trying or claiming to have a (full) >>>>> halt decider.

Originally his claim was that he had a program which worked for the
counter-example TM used in the common (e.g. Linz book) proof.

That, of course, depends on the way the wind's blowing.  For example in >>>> 2020:

   "The non-halting decider that I defined accepts any and all
   non-halting inputs and rejects any and all halting inputs."

But then he retreated to the "once case" argument again until:

Me: "Recent posts have said that you really do claim to have a halting >>>>      decider.  Have you extended your claim or was that a
     misunderstanding?"

PO: "I really do have a halting decider."

... Such a
program is impossible, as Linz and others prove, so having a
program H and
its corresponding "counter-example" D, such that H correctly
decides D,
would certainly show that the Linz proof is wrong.  His claim was
always
that he had "refuted the HP proof", or sometimes that he had
refuted the HP
theorem itself although he's been told dozens of times that there
are many
alternative proofs for the result.

Way back in 2004 he was sure that:

   "I have correctly refuted each and every mechanism by which the
   [halting theorem] has been proven to be true. I have not shown that >>>>    solving the Halting Problem is possible, merely refuted every proof >>>>    that it is impossible."

I expect a publication anytime.  20 years is just about enough to get >>>> all the details right.

[As it turned out, PO's D(D) halted when run under his x86utm
environment,
while H(D,D) which is required to return the halting status of
computation
D(D) returned 0 (=non-halting).  That is exactly what the Linz proofs >>>>> claim!]

We must always remember that PO has re-defined what it means for the
answer to be correct:

Me: "Here's the key question: do you still assert that H(P,P) == false >>>>      is the "correct" answer even though P(P) halts?"

PO: "Yes that is the correct answer even though P(P) halts."

He's been quite clear about it:

   "When we make the single change that I suggest the halting problem >>>>    ceases to be impossible to solve because this revised question is >>>> not
   subject to pathological self-reference."

   "This transforms an undecidable problem into a decidable problem." >>>>
I hope you forgive me just chipping in with stuff you know perfectly
well, but I thought I'd just give some background as Richard is a new
participant and my comments fit better with your post than his.

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

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

When N steps of DD are correctly emulated by
any HHH then each DD cannot possibly reach
its own final state and terminate normally.

No, the PARTIAL EMULATION done by HHH can't reach that point,

But a complete emulation can?

Yes, but an HHH that gives an answer doesn't do one, due to the
pathological design of the template used to build DD to the HHH it calls
(which is the only HHH that can exist, or you have violated the basic
rules of programing and logic).

We have two basic cases,

1) if HHH does the partial emulation you describe, then the complete
emulation of DD will see that DD call HHH, and it will emulate its input
for a while, then abort and theu return 0 to DD which will then halt.

2) if HHH does not abort its emulation, then when we look at what HHH
does when run, it will just run forever, and that make this version of
DD non-halting (being based a different HHH, means it is a different
program and thus can have different behavior) but this HHH is not
correct in saying that, as it will never say that, as it is stuck in
that infinite emulation.


You just don't seem to understand that HHH can't be two different things
at once, because you seem to have an insane mental block on that concept.

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

On 14/03/2025 03:03, Richard Damon wrote:

On 3/13/25 9:48 PM, olcott wrote:

On 3/13/2025 4:21 PM, Richard Heathfield wrote:

On 13/03/2025 20:48, dbush wrote:

On 3/13/2025 4:46 PM, olcott wrote:

<snip>

Replacing the code of HHH1 with an unconditional simulator
and subsequently running HHH1(DD) does reach its
own final state.

If someone was not a liar they would say that
these are different computations.

Only because one changes the code that DD runs and one doesn't

It hardly matters. Either his emulation faithfully and
correctly establishes and reports (for EVERY program anyone
cares to feed it) the actual halting behaviour exhibited by
the program it's emulating, or it doesn't.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Not a program, and can not be correctly emulated beyond address
0000217A as it goes outside the input.

And also irrelevant, because there are only two possibilities:
his code works correctly, or it doesn't. If it doesn't, clearly
he's wrong; and if it does, it dumps us right back on Turing's
doorstep, which means he's wrong.

He studiously avoids addressing this point, and that avoidance is
precisely what I'd expect from a crank.

<snip>

It is very common for people to be so well indoctrinated
that they reject verified facts out-of-hand without review.

Yes, as you have because you have brainwashed yourself into
refusing to look at what you are saying,

And what other people are saying.

to the point that you
have admitted that all you work is just a fraud since you admit
that you have changed core terms of art from the definitions in
the system, violating the basic premise of logic.

If it doesn't, it doesn't, and it's a lot of fuss over nothing.

But if it /does/, then we're right back at Turing's proof,
because a working emulator is just another way of running the
code, and is therefore superfluous to requirements. It adds
nothing to the debate, because we can just run the code and
get the same answer the emulator would provide.

For the first time in the history of mankind it proves
that a simulation of a virtual machine according to
the semantics of this machine language
DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT
EXECUTION OF THIS SAME MACHINE

WHAT "PROOF"?

If I'm reading this right it's actually a proof by confession,
which is a new one on me. He's admitting that in some situations
his simulation gives the wrong answers, which seems to me to be a straightforward of admission of defeat. If his simulation works,
Turing stands, and if it fails to work, it has nothing to say.
Either way, QED.

<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

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

Op 14.mrt.2025 om 03:05 schreef olcott:

On 3/13/2025 6:09 PM, Richard Damon wrote:

On 3/13/25 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same
behaviour.

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF
THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.

DDD correctly emulated by HHH cannot possibly
reach its own final state no matter what HHH
does.

DDD correctly emulated by HHH1 does reach its
own final state.

Which shows that HHH doesn't correctly emulate its input, unless you
just lied and gave the two programs different inputs.

void DDD()
{
  HHH(DDD);
  return;
}

Someone that is not a liar could explain exactly
how DDD emulated by HHH according to the semantics
of the C language must have the same behavior as
DDD emulated by HHH1 according to the semantics
of the C language.

It has. If not, show the first instruction simulated differently by HHH
and HHH1.

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

Am Thu, 13 Mar 2025 21:05:04 -0500 schrieb olcott:

On 3/13/2025 6:09 PM, Richard Damon wrote:

On 3/13/25 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH
according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same
behaviour.

Right?

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort.

DDD correctly emulated by HHH cannot possibly reach its own final
state no matter what HHH does.
DDD correctly emulated by HHH1 does reach its own final state.

Which shows that HHH doesn't correctly emulate its input, unless you
just lied and gave the two programs different inputs.

Someone that is not a liar could explain exactly how DDD emulated by HHH according to the semantics of the C language must have the same behavior
as DDD emulated by HHH1 according to the semantics of the C language.

I mean, HHH and HHH1 are both simulators, the former just aborts.

Someone that is a liar will perpetually dodge this challenge.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

Am Thu, 13 Mar 2025 20:48:09 -0500 schrieb olcott:

On 3/13/2025 4:21 PM, Richard Heathfield wrote:

On 13/03/2025 20:48, dbush wrote:

On 3/13/2025 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH >>>>>> according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same >>>>> behaviour.

Doesn't it?

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort. >>>>>

Replacing the code of HHH with an unconditional simulator and
subsequently running HHH(DD) cannot possibly reach its own final
state no matter what HHH does.
Replacing the code of HHH1 with an unconditional simulator and
subsequently running HHH1(DD) does reach its own final state.
If someone was not a liar they would say that these are different
computations.

Only because one changes the code that DD runs and one doesn't

It hardly matters. Either his emulation faithfully and correctly
establishes and reports (for EVERY program anyone cares to feed it) the
actual halting behaviour exhibited by the program it's emulating, or it
doesn't.

That everyone expects the behavior of the directly executed DDD to be
the same as DDD correctly emulated by HHH1 is verified as a factually
correct expectation.
That everyone expects the behavior of the directly executed DDD to be
the same as DDD correctly emulated by HHH is verified as a factually incorrect expectation.

A simulation should not differ from the actual execution. Why should it?

If it doesn't, it doesn't, and it's a lot of fuss over nothing.
But if it /does/, then we're right back at Turing's proof, because a
working emulator is just another way of running the code, and is
therefore superfluous to requirements. It adds nothing to the debate,
because we can just run the code and get the same answer the emulator
would provide.

For the first time in the history of mankind it proves that a simulation
of a virtual machine according to the semantics of this machine language
DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT EXECUTION OF THIS
SAME MACHINE

Bold claim. How does that make sense?

PATHOLOGICAL SELF REFERENCE DOES CHANGE SEMANTICS

As opposed to what? Of course a different program has different semantics.

This sentence is not true: "This sentence is not true"
The exact same word-for-word sentence IS TRUE IN THIS DIFFERING CONTEXT
THAT DOES NOT HAVE PSR.

It's a different sentence.

In other words, the emulator is a canard, a distraction, a cul-de-sac,
and a complete waste of time. If it happens to work, great! Well done
that man. But it doesn't affect the HP logic one microscopically
minuscule millijot.

The emulator proves the actual behavior specified by the INPUT

No, the direct execution does.

That people disagree with the semantics of the x86 language proves how
deeply indoctrinated they are.

With what semantics?
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 14/03/2025 11:02, joes wrote:

Am Thu, 13 Mar 2025 20:48:09 -0500 schrieb olcott:

On 3/13/2025 4:21 PM, Richard Heathfield wrote:

On 13/03/2025 20:48, dbush wrote:

<snip>

Only because one changes the code that DD runs and one doesn't

It hardly matters. Either his emulation faithfully and correctly
establishes and reports (for EVERY program anyone cares to feed it) the
actual halting behaviour exhibited by the program it's emulating, or it
doesn't.

That everyone expects the behavior of the directly executed DDD to be
the same as DDD correctly emulated by HHH1 is verified as a factually
correct expectation.
That everyone expects the behavior of the directly executed DDD to be
the same as DDD correctly emulated by HHH is verified as a factually
incorrect expectation.

A simulation should not differ from the actual execution. Why should it?

Why indeed? But of course it doesn't matter. If the simulation
correctly reports the outcome, it factors itself out of the
equation and Turing's logic stands. And if it doesn't, it gives
broken results that cannot be trusted to support a conclusion.

If it doesn't, it doesn't, and it's a lot of fuss over nothing.
But if it /does/, then we're right back at Turing's proof, because a
working emulator is just another way of running the code, and is
therefore superfluous to requirements. It adds nothing to the debate,
because we can just run the code and get the same answer the emulator
would provide.

For the first time in the history of mankind it proves that a simulation
of a virtual machine according to the semantics of this machine language
DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT EXECUTION OF THIS
SAME MACHINE

Bold claim. How does that make sense?

Well, it doesn't, but you weren't expecting it to, were you?

<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

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

On 3/13/25 11:40 PM, olcott wrote:

On 3/13/2025 10:03 PM, Richard Damon wrote:

On 3/13/25 10:08 PM, olcott wrote:

On 3/13/2025 6:09 PM, Richard Damon wrote:

On 3/13/25 12:09 PM, olcott wrote:

On 3/13/2025 10:44 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

On 11/03/2025 18:23, Richard Heathfield wrote:

On 11/03/2025 17:42, Mike Terry wrote:

Finally, if you really want to see the actual HHH code, its in the >>>>>>>>> halt7.c file (along with DDD) that PO provides links to from >>>>>>>>> time to
time.  However it's not very illuminating due to bugs/design >>>>>>>>> errors/misunderstandings which only serve to obfuscate PO's
errors in
thinking.

[I've now seen the code. Oh deary deary me.]

:)

Thank you for a spirited attempt to be cogent - or at least as >>>>>>>> cogent as
it is possible to be in the circumstances!
I think PO's first step must be to demonstrate that HHH() correctly >>>>>>>> diagnoses some easy functions, such as these:

Not really necessary - PO is not trying or claiming to have a (full) >>>>>>> halt decider.

Originally his claim was that he had a program which worked for the >>>>>>> counter-example TM used in the common (e.g. Linz book) proof.

That, of course, depends on the way the wind's blowing.  For
example in
2020:

   "The non-halting decider that I defined accepts any and all
   non-halting inputs and rejects any and all halting inputs."

But then he retreated to the "once case" argument again until:

Me: "Recent posts have said that you really do claim to have a
halting
     decider.  Have you extended your claim or was that a
     misunderstanding?"

PO: "I really do have a halting decider."

... Such a
program is impossible, as Linz and others prove, so having a
program H and
its corresponding "counter-example" D, such that H correctly
decides D,
would certainly show that the Linz proof is wrong.  His claim was >>>>>>> always
that he had "refuted the HP proof", or sometimes that he had
refuted the HP
theorem itself although he's been told dozens of times that there >>>>>>> are many
alternative proofs for the result.

Way back in 2004 he was sure that:

   "I have correctly refuted each and every mechanism by which the >>>>>>    [halting theorem] has been proven to be true. I have not shown >>>>>> that
   solving the Halting Problem is possible, merely refuted every >>>>>> proof
   that it is impossible."

I expect a publication anytime.  20 years is just about enough to get >>>>>> all the details right.

[As it turned out, PO's D(D) halted when run under his x86utm
environment,
while H(D,D) which is required to return the halting status of
computation
D(D) returned 0 (=non-halting).  That is exactly what the Linz
proofs
claim!]

We must always remember that PO has re-defined what it means for the >>>>>> answer to be correct:

Me: "Here's the key question: do you still assert that H(P,P) ==
false
     is the "correct" answer even though P(P) halts?"

PO: "Yes that is the correct answer even though P(P) halts."

He's been quite clear about it:

   "When we make the single change that I suggest the halting problem >>>>>>    ceases to be impossible to solve because this revised question >>>>>> is not
   subject to pathological self-reference."

   "This transforms an undecidable problem into a decidable problem." >>>>>>
I hope you forgive me just chipping in with stuff you know perfectly >>>>>> well, but I thought I'd just give some background as Richard is a new >>>>>> participant and my comments fit better with your post than his.

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

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

When N steps of DD are correctly emulated by
any HHH then each DD cannot possibly reach
its own final state and terminate normally.

No, the PARTIAL EMULATION done by HHH can't reach that point,

But a complete emulation can?

Yes,

Stupidly incorrect.

Got proof of that? or it this just your use of more lies and falacies?

Your problem is you don't know what the words you are using actually
mean, as you admitted by the fact that you admitted that you are
changing the meaning of core terms of art, in violation of the core
principles of logic, which you also clearly don't understand by your
violations of them,.

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

On 14/03/2025 14:10, Richard Damon wrote:

On 3/13/25 11:55 PM, olcott wrote:

<snip>

In other words you are stupidly trying
to get away with saying that it is impossible
for one C function to call another C function.

Not at all, just that for a C function to call another C function
that other C function must be included as part of the Program
that the first is defined in.

This is an easy area for ambiguity. In this code:

int bar(void);
int foo(void)
{
return bar();
}

bar() is not included, merely prototyped, but it is reasonable to
say that foo() is (syntactically) calling bar(). It is /not/
reasonable, though, to claim that we know what foo() will do
unless we know for sure what bar() does. And neither is it
possible for foo()'s program to run if bar()'s source is not in
the module and cannot be tracked down elsewhere by the linker.

The absence of bar() from ready availability does not mean that
foo() isn't calling bar(). It only means that bar() might not be
around to hear.

As is so often the case, whether we're right to claim X depends
on what we mean by X.

C functions are not programs, but programs can be built from C
functions,

True, although I think one would have to be pretty tight to
insist on the distinction in this case.

If we can think of C functions as programs, we don't need to
emulate anything at all (not that we did, of course); we can just
call the function and catch its return vale (if any).

That is like asking what is the frequency of a square?

I have it on good authority that squares broadcast on 4Hz.

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

Am Fri, 14 Mar 2025 09:37:18 -0500 schrieb olcott:

On 3/14/2025 2:43 AM, Fred. Zwarts wrote:

Op 14.mrt.2025 om 03:05 schreef olcott:

On 3/13/2025 6:09 PM, Richard Damon wrote:

On 3/13/25 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH >>>>>>> according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the
same behaviour.

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't
abort.

DDD correctly emulated by HHH cannot possibly reach its own final
state no matter what HHH does.
DDD correctly emulated by HHH1 does reach its own final state.

Which shows that HHH doesn't correctly emulate its input, unless you
just lied and gave the two programs different inputs.

Someone that is not a liar could explain exactly how DDD emulated by
HHH according to the semantics of the C language must have the same
behavior as DDD emulated by HHH1 according to the semantics of the C
language.

It has. If not, show the first instruction simulated differently by HHH
and HHH1.

DDD correctly simulated by HHH cannot possibly reach its own "return" instruction in any finite number of correctly simulated steps.

HHH1 can simulate it.

That you are clueless about the semantics of something as simple as a
tiny C function proves that you are not competent to review my work.

You are free to leave.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 14/03/2025 16:01, wij wrote:

Are you solving The Halting Problem or not? Yes or No.

He is, but only if he isn'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 14/03/2025 17:44, dbush wrote:

On 3/14/2025 10:35 AM, olcott wrote:

<"the above" - snipped>

<unrelated copy-paste reponse>

Your non-response is taken as complete agreement with the above.

Well, nice try, but I think we both know that when it comes to
the OP's hobby-horse, he doesn't agree with almost anything said
by almost anybody.

Perhaps the kindest thing we can do is plonk the guy en masse. He
is, after all:

(a) self-evidently mistaken; and
(b) utterly unwilling (or unable) to enter into rational debate.

I can't help thinking that arguing with him is little less cruel
than bear-baiting.

--
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 3/14/25 11:04 AM, olcott wrote:

On 3/14/2025 1:08 AM, Richard Heathfield wrote:

On 14/03/2025 03:03, Richard Damon wrote:

On 3/13/25 9:48 PM, olcott wrote:

On 3/13/2025 4:21 PM, Richard Heathfield wrote:

On 13/03/2025 20:48, dbush wrote:

On 3/13/2025 4:46 PM, olcott wrote:

<snip>

Replacing the code of HHH1 with an unconditional simulator and
subsequently running HHH1(DD) does reach its
own final state.

If someone was not a liar they would say that
these are different computations.

Only because one changes the code that DD runs and one doesn't

It hardly matters. Either his emulation faithfully and correctly
establishes and reports (for EVERY program anyone cares to feed it)
the actual halting behaviour exhibited by the program it's
emulating, or it doesn't.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Not a program, and can not be correctly emulated beyond address
0000217A as it goes outside the input.

And also irrelevant, because there are only two possibilities: his
code works correctly, or it doesn't. If it doesn't, clearly he's
wrong; and if it does, it dumps us right back on Turing's doorstep,
which means he's wrong.

He studiously avoids addressing this point, and that avoidance is
precisely what I'd expect from a crank.

<snip>

It is very common for people to be so well indoctrinated
that they reject verified facts out-of-hand without review.

Yes, as you have because you have brainwashed yourself into refusing
to look at what you are saying,

And what other people are saying.

to the point that you have admitted that all you work is just a fraud
since you admit that you have changed core terms of art from the
definitions in the system, violating the basic premise of logic.

If it doesn't, it doesn't, and it's a lot of fuss over nothing.

But if it /does/, then we're right back at Turing's proof, because
a working emulator is just another way of running the code, and is
therefore superfluous to requirements. It adds nothing to the
debate, because we can just run the code and get the same answer
the emulator would provide.

For the first time in the history of mankind it proves
that a simulation of a virtual machine according to
the semantics of this machine language
DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT
EXECUTION OF THIS SAME MACHINE

WHAT "PROOF"?

If I'm reading this right it's actually a proof by confession, which
is a new one on me. He's admitting that in some situations his
simulation gives the wrong answers, which seems to me to be a
straightforward of admission of defeat. If his simulation works,
Turing stands, and if it fails to work, it has nothing to say. Either
way, QED.

<snip>

void DDD()
{
  HHH(DDD);
  return;
}

DDD correctly simulated by HHH cannot possibly reach
its own "return" instruction in any finite number of
correctly simulated steps.

And thus any HHH that correctly simulates its input DDD, can't return an answer, as to stop the simulation makes it no longer a correct
simulaiton by HHH,

That you are clueless about the semantics of something
as simple as a tiny C function proves that you are not
competent to review my work.

No, it is YOU who is clueless about what you are talking about, as it
isn't "C Functions", but "Programs", and you use of wrong definitons
just makes your whole work a fraud,

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

Op 14.mrt.2025 om 15:43 schreef olcott:

On 3/14/2025 5:54 AM, joes wrote:

Am Thu, 13 Mar 2025 21:05:04 -0500 schrieb olcott:

On 3/13/2025 6:09 PM, Richard Damon wrote:

On 3/13/25 4:46 PM, olcott wrote:

On 3/13/2025 4:27 AM, joes wrote:

Am Wed, 12 Mar 2025 21:41:34 -0500 schrieb olcott:

On 3/12/2025 7:56 PM, dbush wrote:

On 3/12/2025 8:41 PM, olcott wrote:

NOT WHEN IT IS STIPULATED THAT THE BEHAVIOR BEING MEASURED IS >>>>>>>> The direct execution of DDD

is proven to be different than the behavior of DDD emulated by HHH >>>>>>> according to the semantics of the x86 language.

Which is weird, considering that a simulator should produce the same >>>>>> behaviour.

Right?

DECIDERS ARE REQUIRED TO REPORT ON THE SEMANTIC OR SYNTACTIC
PROPERTY OF THEIR INPUT FINITE STRINGS.

And not if the input called a different simulator that didn't abort. >>>>> DDD correctly emulated by HHH cannot possibly reach its own final

state no matter what HHH does.
DDD correctly emulated by HHH1 does reach its own final state.

Which shows that HHH doesn't correctly emulate its input, unless you
just lied and gave the two programs different inputs.

Someone that is not a liar could explain exactly how DDD emulated by HHH >>> according to the semantics of the C language must have the same behavior >>> as DDD emulated by HHH1 according to the semantics of the C language.

I mean, HHH and HHH1 are both simulators, the former just aborts.

The semantics of the finite string input DDD to HHH specifies
to continue to call HHH(DDD) in recursive simulation.

The semantics of the finite string input DDD to HHH1 specifies
to simulate to DDD exactly once.

Factual incorrect, because HHH1 also simulates HHH simulating DDD, so it simulates DDD at least twice in recursive simulation. There is a finite recursion. HHH misses the fact that there is a finite recursion, because
it aborts before it can see that.

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

On 14/03/2025 19:48, Keith Thompson wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

On 14/03/2025 11:02, joes wrote:

Am Thu, 13 Mar 2025 20:48:09 -0500 schrieb olcott:

<snip>

For the first time in the history of mankind it proves that a simulation >>>> of a virtual machine according to the semantics of this machine language >>>> DOES NOT ALWAYS HAVE THE SAME BEHAVIOR AS THE DIRECT EXECUTION OF THIS >>>> SAME MACHINE

Bold claim. How does that make sense?

Well, it doesn't, but you weren't expecting it to, were you?

No, it doesn't make sense, but I can imagine something similar to that
claim that might make sense if it were logically possible (which it
isn't). And to be clear, I haven't read the full context.

A simulation that doesn't have the same behavior as the thing it's
simulating (which is what Olcott claims here) simply is not a
simulation, so his claim is self-contradictory. But such a not-quite-simulation might still be useful.

Indeed. But in this case it doesn't move us forward. Whether S(P,
D) a simulation of program P with D data, does or does not behave
exactly like P is unimportant. What matters is whether P(D)
halts. If the simulation S(P,D) accurately reports the
halting/non-halting behaviour of P(D), Q(E), R(F) ad
arbitrarium... that's all we ask of it.

If it doesn't, it contributes nothing. And if it does, we're
right back with Turing's proof and the simulator might as well
not exist.

The Halting Problem is about taking an arbitrary program and input and determining whether the program halts or not. This is of course
trivially possible in many special cases:
int main(void) { return 0; } // halts
int main(void) { while (1); } // does not halt
and difficult but possible in other cases, but impossible in general.

Yes.

What Olcott *might* be claiming is that he can determine whether any arbitrary program halts by "simulating" it in a way that isn't a true simulation, but that tells us whether it halts or not. So perhaps
while it's running the simulation, it's somehow able to detect and
report that the simulated program does or does not eventually halt.
(I haven't studied what he's written enough to have any idea how
it would do this, and I don't intend to.)

He thinks he can disprove Peter Linz's HP proof, which he
can't... or at least hasn't yet.

Linz's proof can be found here:

https://john.cs.olemiss.edu/~hcc/csci311/notes/chap12/ch12.pdf

Which could all make sense if it were mathematically possible,
but of course it isn't.

Indeed. Back in the day, the OP would have been a circle squarer.

<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

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

On 14/03/2025 19:48, Keith Thompson wrote:

[...] That would imply that [PO] could solve
Goldbach's Conjecture, among other things, but I haven't seen him
do so.

Perhaps [just about] worth noting that a sufficiently long
[but not "infinite"] brute force attack on the GC [and many other
similar conjectures] would resolve the issue. Basically, if you
have a program [eg, TM] of size N by some suitable measure [eg, TM
states] then within [eg] BB(N) steps it must find the counter-example
[if there is one] or else there isn't one [and the GC is proven true],
where BB is the Busy Beaver function. Of course, BB is uncomputable,
but that doesn't mean specific individual values are uncomputable,
just that there is no TM that computes it /in general/.

[I have mentioned here before that BB gives us a much less
troublesome way of attacking the HP than the standard proofs.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Mayer

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

On 3/14/25 9:08 PM, olcott wrote:

On 3/14/2025 6:09 PM, Andy Walker wrote:

On 14/03/2025 19:48, Keith Thompson wrote:

[...] That would imply that [PO] could solve
Goldbach's Conjecture, among other things, but I haven't seen him
do so.

     Perhaps [just about] worth noting that a sufficiently long
[but not "infinite"] brute force attack on the GC [and many other
similar conjectures] would resolve the issue.

Not if GC is true and the proof cannot algorithmically
compressed into a finite sequence of steps.

So, are you now admitting that it is possible for GC to be true, and no
finite proof (the only kind of proof that exists) might exist, and thus
that GC might be the instance that makes the system incomplete?

 Basically, if you
have a program [eg, TM] of size N by some suitable measure [eg, TM
states] then within [eg] BB(N) steps it must find the counter-example
[if there is one] or else there isn't one [and the GC is proven true],
where BB is the Busy Beaver function.  Of course, BB is uncomputable,
but that doesn't mean specific individual values are uncomputable,
just that there is no TM that computes it /in general/.

     [I have mentioned here before that BB gives us a much less
troublesome way of attacking the HP than the standard proofs.]

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

On 15/03/2025 01:08, olcott wrote:

On 3/14/2025 6:09 PM, Andy Walker wrote:

On 14/03/2025 19:48, Keith Thompson wrote:

[...] That would imply that [PO] could solve
Goldbach's Conjecture, among other things, but I haven't seen him
do so.

     Perhaps [just about] worth noting that a sufficiently long
[but not "infinite"] brute force attack on the GC [and many other
similar conjectures] would resolve the issue.

Not if GC is true and the proof cannot algorithmically
compressed into a finite sequence of steps.

You didn't read, or didn't understand, the rest of my article,
which explains that, indeed, only a finite number of steps is needed.
Read on before replying:

 Basically, if you
have a program [eg, TM] of size N by some suitable measure [eg, TM
states] then within [eg] BB(N) steps it must find the counter-example
[if there is one] or else there isn't one [and the GC is proven true],
where BB is the Busy Beaver function.  Of course, BB is uncomputable,
but that doesn't mean specific individual values are uncomputable,
just that there is no TM that computes it /in general/.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/West

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

On 15/03/2025 19:46, olcott wrote:
[I wrote, re the Goldbach Conjecture:]

     Perhaps [just about] worth noting that a sufficiently long
[but not "infinite"] brute force attack on the GC [and many other
similar conjectures] would resolve the issue.

Not if GC is true and the proof cannot algorithmically
compressed into a finite sequence of steps.

     You didn't read, or didn't understand, the rest of my article,
which explains that, indeed, only a finite number of steps is needed.
Read on before replying:

I always respond to the first mistake.
I did notice that you qualified this later on.

Perhaps you should have waited for the first mistake? I didn't "qualify" my statement, rather I explained why a perhaps-surprising [at
first glance] claim is in fact correct. [I have no intention of having
a "'tis", "'tisn't" to-and-fro on this, so there is no need to reply,
and if you do, I shall ignore it.]

[... explanation snipped ...]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Coleridge-Taylor

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