From Newsgroup: comp.theory

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to completion if >>>>>>>> it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate past the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that makes
up the PROGRAM, which must include the code of *THE* HHH, or you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate the
code of HHH.

The problem is that you HHH just always gives up and just returns 0, and
thus that is the behavior of *THE* HHH that exists.

If you instead create a different DDD from the different THE HHH that
never aborts, then you are correct, that actually correct simulation
will never reach the end, but continue forever. Your problem is that
this is a DIFFERENT DDD, as to "correctly simulate" the input of DDD,
that input *MUST* include the code for HHH, or you are just admitting
that you are lying about correctly simulating that input.

int main()
{
  DDD();  // Calls HHH(DDD) which is not accountable
}         // for the behavior of its caller

But *IS* accoutable for the behavior of the input, which happens, in
this case, to be the caller.

Yes, in:

void foo() {
HHH(DDD);
loop: goto loop;
}

int main()
{
foo();
}

HHH isn't responsible for the non-halting behavior of its caller, but is responsible for the halting behavior of DDD, which does halt because HHH returns and answer.

You just don't understand what the meaning of the terms you are using are.

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

DDD halts.

HHH(DDD) is asked: Does your input specify a computation that halts*? >>>>> DDD correctly simulated by HHH cannot possibly reach its own "return" >>>>> statement final halt state, so NO.

*when executed directly, which is what should be simulated. HHH can't.

HHH1(DDD) has the same behavior as the directly executed DDD()

No, DDD doesn't return an answer, HHH1 returns the value 1.

Those are DIFFERENT behavior.

Yes, they both halt, and HHH1 does correctly simulate its input, and the
fact that you admit that HHH1 is able to simulate the input means that
it MUST include the code of HHH, or else it couldn't do that.

THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.

HHH1(DDD) is asked: Does your input specify a computation that halts? >>>>> DDD correctly simulated by HHH1 reaches its own "return" statement
final halt state, so YES.

The user's manual of HHH1 apparently dpecifies different encoding
rules.

The full execution trace of the input to HHH1(DDD) is different than The >>> full execution trace of the input to HHH(DDD)
because DDD calls HHH in recursive simulation and does not call HHH1 in
recursive simulation.

Uh, the traces both show a call to HHH.

*This one page analysis by Clause.ai sum its up nicely* https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c

Which begins with your lie, so you are just showing your stupidity.

Sorry, perhaps you should be brought up on charges for the contributing
to the mistraining of an AI.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the
input is
different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and >>>>>>>>> thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.

Sorry, not being able to do something doesn't mean you get to >>>>>>>>> redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion >>>>>>>> if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other number) >>>>>> is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about some
other computation then it is not in the scope of the halting problem
or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set formation."

And what does that distraction have to do with halting problem?

I guess you are admitting that you don't have an answer.

And not, "ZFC" doesn't "redefine" how sets are defined, but starts anew,
and creates a brand new set theory from scratch.

HHH computes the mapping from its actual inputs to the
behavior specifies by these inputs by correctly simulating
them.

No it doesn't, as you "input" which you say doesn't include the code
of HHH, can't be simulated.

I have always told you that
HHH simulates DDD that calls HHH(DDD)
then HHH simulates itself simulating DDD
*You must have no idea what those words mean*

How does it "simulate its input" when it simulates things that aren't
part of the input.

That is just a violation of the definitions, showing you don't
understand how definitions work.

Your world is just build on lies and equivocations (which are a form of lying). Your "input" both contains and does not contain the code for HHH.

It does not contain it so all version of DDD are the same.

It does contain it so the you can simulate the input.

That is just showing that you "langauge" is just based on lying.

HHH(DDD) is asked: Does your input specify a computation that halts? >>>>> DDD correctly simulated by HHH cannot possibly reach its own "return" >>>>> statement final halt state, so NO.

int sum(int x, int y) { return x + y; }
sum(3,4) derives 7 only from its actual inputs.

Right, and for HHH(DDD) the input is the PROGRAM DDD,

No this has never been the case as I have told you hundreds
and hundreds of times. The input to HHH has always been a
pointer to the machine code of DDD in a single block of memory
that includes all of Halt7.obj.

If your total input is just the address, then you can't emulate *ANY* of
the code of DDD, as it isn't part of the input.

Just because it is in memory that the decider can access, doesn't make
it part of "the input"

What you are referring to as a program never has been
an actual program that begins in main(). What you have
been referring to as a program is the machine code of
DDD and the machine code of everything that DDD calls.
That has always been there in the single block of memory
of Hlat7.obj.

"Programs" in computation theory don't need to begin with "main".

( guess your problem is you just don't understand what you are talking
about.

 which must include the code for HHH, and for any HHH that returns an
answer, the correct answer will be Halting (1).

The actual execution trace of DDD correctly simulated
by HHH is different than the actual execution trace of
DDD correctly simulated by HHH1.

Then it isn't "correct".

You can't show the first instruction, actually correctly simulate, that difffered between HHH and HHN1, because it doesn't exist.

Note, HHH by trying to do a "high level" simulation of the call to HHH,
does it wrong, as it is based on the LIE that the HHH that DDD calls
will not return as it gets stuck in infinite recursion, becuase it
ignores that HHH *WILL* abort its simulation at the point that it does.

*I am shocked that Mike cannot see this*
To me this seems like a guy with a computer
science degree that never heard of recursion.

The problem is your claim is just a lie, but YOU have brainwashed ans
gaslight yourself to the point you can't see your problem.

When we make a rule that sum(3,4) must derive
the sum of 5 + 6, then this requirement is wrong.

Right, so we don't, just as it is wrong to derive the answer about the
correct simulation of DDD by looking at anything but THAT SPECIFIC DDD
and its correct simulation, which also means we need to pass as "the
input" all of the code that DDD uses, which included HHH.

and everything that HHH calls as I have been telling
you many many times and you keep forgetting from one
post to the next.

And thus *ALL* of memory is part of the "input" as you consider it
accesable from the input.

Thus, *THE* HHH is defined by the code of HHH in that memory, and that
HHH aborts and returns.

What the F did you think that I mean by HHH simulates
DDD and then simulates itself simulating DDD if itself
is inaccessible to HHH?

That you are just a liar that claimes things that are not?

You keep on switching back and forth between what is in the input,
because either answer proves your logic wrong.

*Maybe you never had any idea what any of those words mean*

Sure I do, you just don't and keep equivocating on what you mean by them.

Since DDD() will halt, the correct simulation of it will reach the
final state (but your HHH can't do that) and thus the only correct
answer that HHH can return is Halting (1)

A partial halt decider must compute the mapping
*FROM ITS ACTUAL INPUT* (not one damn thing else)
*FROM ITS ACTUAL INPUT* (not one damn thing else)
*FROM ITS ACTUAL INPUT* (not one damn thing else)

And, if DD is based on the proof program, that means that HHH(DD) must
mean that "the input" refers to the program DD when actually run.

to the actual behavior that this input specifies
not any damn thing else.

Right, and that "actual behavior" is defined by the execution of the
program with that code, which means that *ALL* the code, including that
of the HHH that it calls, is part of "the input", and thus HHH is FIXED
to be *THE* HHH and your hypothetical HHH which changes that memory
isn't looking at the same input.

int main()
{
   DD(); // calls HHH(DD)
}

Likewise for HHH(DD) to report on the behavior of its caller.

But it isn't being asked about "its caller", its being asked about
DDD, which just happens to be its its caller.

When functions are computed by Turing Machines directly
executed Turing machines are not in the domain.

Sure they are, via representations.

Just like numbers.

_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

Which isn't a simulatable input. PERIOD.

When DDD is correctly emulated by HHH the ultimate
measure of the correctness of this emulation is the
semantics of the x86 language.

Right, which says that the above is NOT something that can be emulated
as an input, it needs the addition of the code of HHH and everything it
uses.

I don't understand why I ever had to say that more
than once if my reviewers are engaging in an honest
dialogue so I concluded that my reviewers are dishonest.

Because you don't actually mean what you say, but are just lying,

The correct emualtion of the DDD above, fixed by including the HHH that
you say is the one that exists, HALTS.

Thus HHH, saying it doesn't is just wrong.

PERIOD.

And your lying doesn't change that.

The problem is you don't understand what a "program" actually is.

Termination analyzers are applied to C functions that
are not programs that always begin their execution in main().

Sure, but they are only applied to C functions that include all the code
they refer to, or the answer is stated based on the actual behaivor of
the unspecified code.

THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.

HHH1(DDD) is asked: Does your input specify a computation that halts? >>>>> DDD correctly simulated by HHH1 reaches its own "return" statement
final halt state, so YES.

The user's manual of HHH1 apparently dpecifies different encoding
rules.

The full execution trace of the input to HHH1(DDD) is
different than The full execution trace of the input to HHH(DDD)
because DDD calls HHH in recursive simulation and does not
call HHH1 in recursive simulation.

But no actual instruction actually correctly simulated differs until
HHH aborts its simulation.

*That has always been counter-factual*

So, what one is it?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

The difference is when
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

And what instruction was the difference?

HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.

And what differed in that list from what HHH1 saw?

After all,
HHH is simulating HHH simulating DDD, and
HHH1 is simulating HHH simulating DDD

Since HHH simulating DDD always does the same thing, no instruciton
differed.

WHen you look at the actual x86 simulation of all the code executed,
this is what you see, as you yourself have proven with the very long
traces.

We only need to understand that when HHH simulates DDD
and this DDD calls HHH(DDD) that the outer HHH is
simulating itself simulated DDD.

Which doesn't affect any of the instructions being simulated.

By doing this we capture the essence of 5266 pages of
execution trace in about one half of one page of text.

And we see that no difference occured.

When you abreviate them, to make your arguemnt, you LIE about what HHH
does and "simplify" it behavior by ignoring the fact that it WILL
abort is simulation, since that is what you have actually defined your
HHH to do, and thus your "recursive" simulation is bounded, not infinite.

But of course, you are just too stupid to understand that.

Claude.ai figured this out on its own
proving that it is smarter than ChatGPT
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c

Because you LIE to it.

When you can't even point out any actual mistake
then your claim that I am intentionally telling
lies is quite nutty.

But I have.

You claim that a difference occured in the traces.

I say there wasn't.

You can't show where the difference in the traces actually occured.

That two traces are identical, is just a fact, and other than showing
that the match (to the point of the aborting) is the proof in itself.

If you want to say they differ, you need to be able to point out the difference.

Sorry, it seems that you have lost contact with the idea that only
actually true things are true, and not things that we want to be true.

You are worse then the climate deniers you claim to be fighting, at
least they can point to actual raw evidence, and it becomes arguments
over interpretation, you just claim stuff without any proof,

https://www.researchgate.net/ publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts

My paper proves that even billion dollar disinformation teams
cannot possibly explain away the 98 PPM spike in atmospheric
CO2 in the last 70 years. The next fastest 98 PPM spike in the
last 800,000 years took 7537 years, 126-fold slower.

Which doesn't *PROVE* your claim, you just make it.

The problem is that natural science isn't subject to "logical proof" as
it always comes down to interpretation of measurements, and not
derivation from axioms.

This just shows you have no idea of what you are talking about, becuase
you don't really understand how truth, logic, and arguements work.

You fail by trying to use philosophical "logic" in formal systems, where
it doesn't apply, and try to use what you think of as "formal logic" in
a context where your need to you clear arguement, and accept that
"proof" isn't a thing.

That puts you more in the class of a flat-earther.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to completion if >>>>>>>>> it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate past the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that makes
up the PROGRAM, which must include the code of *THE* HHH, or you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate the
code of HHH.

Do you mean like this? (as I have been telling you for three years) https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

I ignore the rest of your points because you
prove that it is almost impossible for you
to handle a single point.

When I go over the exact same point 500 times
you never notice that I ever mentioned this point.
--
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 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>> input is
different than the direct execution, even though he can't show >>>>>>>>>> the
instruction actually correctly simulated where they differ, >>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>>> reason" it must be just because otherwise HHH can't do the >>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get to >>>>>>>>>> redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion >>>>>>>>> if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other number) >>>>>>> is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about some >>>>> other computation then it is not in the scope of the halting problem >>>>> or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set formation."

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*
--
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 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate past the >>>> recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or you
can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate the
code of HHH.

Do you mean like this? (as I have been telling you for three years) https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ from
the exact same simulation generated by HHH1 before HHH aborts?


Note, that this trace PROVES that "the input" includes the code of HHH,
as that is what HHH is looking at, and if you are simulating "the
input", whatever you simulate must have been part of the input.

Note also, this trace isn't the "simulation done by HHH" but the trace
of the execution of HHH as listed by x86utm.

This trace is also nearly identical to a correct simulation of the
direct execution of DDD, it just starts at the addresses of main instead
of DDD, but the source and object code of both main and DDD are
identical (just relocated to different addresses).

If you compare the trace that HHH actually does, it will exactly match
this to the point that HHH decides to abort.

If you disagree, point to the line where they differ, else you are just admitting that you are just a pathetic liar that has been caught in the
trap.

I ignore the rest of your points because you
prove that it is almost impossible for you
to handle a single point.

No, you ignore them because you don't have an answer.

As I have pointed out, providing the trace doesn't show where it differs
from the trace of the direct exectutuion of DDD.

When I go over the exact same point 500 times
you never notice that I ever mentioned this point.

So, when are you going to answer the questions about that listing?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get to >>>>>>>>>>> redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other
number) is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about some >>>>>> other computation then it is not in the scope of the halting problem >>>>>> or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set formation."

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.

If you want to try to define your own version of Computability theory,
go ahead and do the work, start with your list of axioms and
definitions that build your system.

Then show what you system can actually do, and provide some reason for
people to move from the fully working existing system to your alternate.

The non-computability of some problems is not considered a "problem"
with computability, it just shows that it creates a powerful enough
system. This seems to be a natural product of the fact that it deals
with things that are of countable infinte size. My guess is that any computation system that you can derive that meets your goals can't
handle the same breadth of problems.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/4/2025 3:33 PM, Richard Damon wrote:

On 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate past the >>>>> recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate the
code of HHH.

Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ from
the exact same simulation generated by HHH1 before HHH aborts?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.

I only address one point at a time because you
find that one single point to be impossibly too
difficult for you. When I tell you something
500 times you never notice that I even said it once.
--
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 7/4/2025 3:40 PM, Richard Damon wrote:

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>> to redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other
number) is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about some >>>>>>> other computation then it is not in the scope of the halting problem >>>>>>> or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set formation."

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set Theory, as it doesn't do anything to Naive Set Theory.

It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.

Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
--
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

Op 04.jul.2025 om 14:57 schreef olcott:

On 7/4/2025 2:42 AM, Mikko wrote:

On 2025-07-03 15:17:53 +0000, olcott said:

On 7/3/2025 9:50 AM, Richard Damon wrote:

On 7/3/25 10:39 AM, olcott wrote:

On 7/3/2025 9:16 AM, Richard Damon wrote:

On 7/2/25 10:50 PM, olcott wrote:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the
input is
different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and >>>>>>>>> thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.

Sorry, not being able to do something doesn't mean you get to >>>>>>>>> redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion >>>>>>>> if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Nope. It seems you don't understand what the question actually IS >>>>>> because you have just lied to yourself so much that you lost the
understanding of the queiston.

*I can't imagine how Mike does not get this*

I can't understand

*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*

Context of your context:

A Halt Decider is supposed to decide if the program given to it
(via some correct representation) will halt when run.

Thus, "the input" needs to represent a program

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

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

int main()
{
   HHH(DDD);
}

Which, by itself, isn't a valid input, or program. as HHH is
undefined.

Each different definition of HHH, gives a different problem.

Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.

"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)

But it CAN'T simulate the above input. as it isn't valid.

You need to add the code of HHH to the input to let HHH simulate
"the input" to get anything.

No I do not. The above paragraph has every detail that is needed.

Then how do you correctly simulate something you do not have.

Note, your "description" of HHH is just incorrect, as it is also
incomplete.

Simulating a LIE just gives you a lie.

And at that point, you have different inputs for different HHHs,
and possibly different behaviors, which you logic forgets to take >>>>>> into account, which just breaks it.

Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.

Nope, becausee it violates the DEFINITION of what it means to
simulate something.

*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.

C lanbuage definition does not specifiy the senatics of the non-standard
lanugage extension that your HHH and HHH1 use.

*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.

There is no non-termination behaviour to detect, because the input
specifies only a *finite* recursion. The input includes the erroneous
code to detect non-termination behaviour, which causes it to abort the simulation. This is part of the input, which makes it a halting program.
That HHH includes this erroneous code, so that it sees non-termination behaviour where it is not present, does not change the specification of
a halting program.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 05.jul.2025 om 00:24 schreef olcott:

On 7/4/2025 3:40 PM, Richard Damon wrote:

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>> to redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>> computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about >>>>>>>> some
other computation then it is not in the scope of the halting
problem
or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set formation." >>>>

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.

It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.

Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.

Your misconception is that the decider must report on hypothetical
Turing machines, where in fact the decider must report on its input.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 05.jul.2025 om 00:17 schreef olcott:

On 7/4/2025 3:33 PM, Richard Damon wrote:

On 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate past >>>>>> the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate
the code of HHH.

Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

No its does the same thing as HHH does: it simulates HHH.
This means that there is no difference in the trace. The are simulating
the same input.
So, since the are simulating the same input, the result must be the same
if the simulations are correct. If the simulations differ, at least one
of the must be incorrect.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-07-04 12:50:23 +0000, olcott said:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the input is >>>>>>> different than the direct execution, even though he can't show the >>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>> proves he is lying.

The closest he comes is claiming that the simulation of the "Call HHH" >>>>>>> must be different when simulated then when executed, as for "some >>>>>>> reason" it must be just because otherwise HHH can't do the simulation. >>>>>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>>>>> it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other number) is the >>>> wrong asnwer to the quesstion "does DDD specify a halting computation?". >>>

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

Its 12. If you think otherwise show me an example.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-07-04 12:57:47 +0000, olcott said:

On 7/4/2025 2:42 AM, Mikko wrote:

On 2025-07-03 15:17:53 +0000, olcott said:

On 7/3/2025 9:50 AM, Richard Damon wrote:

On 7/3/25 10:39 AM, olcott wrote:

On 7/3/2025 9:16 AM, Richard Damon wrote:

On 7/2/25 10:50 PM, olcott wrote:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the input is >>>>>>>>> different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>>>> proves he is lying.

The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the simulation.

Sorry, not being able to do something doesn't mean you get to redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Nope. It seems you don't understand what the question actually IS >>>>>> because you have just lied to yourself so much that you lost the
understanding of the queiston.

*I can't imagine how Mike does not get this*

I can't understand

*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*

Context of your context:

A Halt Decider is supposed to decide if the program given to it (via >>>>>> some correct representation) will halt when run.

Thus, "the input" needs to represent a program

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

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

int main()
{
   HHH(DDD);
}

Which, by itself, isn't a valid input, or program. as HHH is undefined. >>>>>>
Each different definition of HHH, gives a different problem.

Your "logic" seems to be based on trying to re-define what a program >>>>>> is, which just makes it a lie.

"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)

But it CAN'T simulate the above input. as it isn't valid.

You need to add the code of HHH to the input to let HHH simulate "the >>>>>> input" to get anything.

No I do not. The above paragraph has every detail that is needed.

Then how do you correctly simulate something you do not have.

Note, your "description" of HHH is just incorrect, as it is also incomplete.

Simulating a LIE just gives you a lie.

And at that point, you have different inputs for different HHHs, and >>>>>> possibly different behaviors, which you logic forgets to take into >>>>>> account, which just breaks it.

Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.

Nope, becausee it violates the DEFINITION of what it means to simulate >>>> something.

*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.

C lanbuage definition does not specifiy the senatics of the non-standard
lanugage extension that your HHH and HHH1 use.

*This is the ONLY specification of HHH that chatbots see*

That is irrelevant. What is relevant is the specification or lack of
that readers of comp.theory see.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/4/25 6:17 PM, olcott wrote:

On 7/4/2025 3:33 PM, Richard Damon wrote:

On 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate past >>>>>> the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate
the code of HHH.

Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

And where does that show as a difference in the trace?

"itself" isn't something in the code/

Both are supposed to be simuating the input, which is DDD calling HHH.

You still need to try to prove your FALSEHOOD that the simualtion of the
HHH called by DDD depends on who is doing the simulation, when that
concept is in direct contradiction to the defintions of correct simulation.

Sorry, you are just proving you are a stupid liar,

HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.

And thus HHH is part of the input, and thus is the same HHH as is
simulating it, and thus the first HHH simulated will also abort its
simulation and return 0, a fact IGNORED by you, because you are too stupid.

I only address one point at a time because you
find that one single point to be impossibly too
difficult for you. When I tell you something
500 times you never notice that I even said it once.

So ADDRESSS it. You just repeat your same lies.

Your "one thing at a time" is just your excuse to not get to the actual problems, and just let you keep on equivocating between you multiple inconsistant definitions of what you are talking about.

That is the FACT of you argument, it is based on internally
self-contradictory meanings.

For example, is the code of HHH part of the input, you need both:

NO, so that every variation of the program DDD is the "same", but also
YES, as you need it to be there to simulate it, it just isn't a
"constant" part

In other words, your world is just based on lies.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/4/25 6:24 PM, olcott wrote:

On 7/4/2025 3:40 PM, Richard Damon wrote:

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>> to redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>> computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about >>>>>>>> some
other computation then it is not in the scope of the halting
problem
or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set formation." >>>>

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.

It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.

Yes, by creating a totally new system.

Note, The don't say that Russell's Paradox no longer exists in Naive Set Theory, they

Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.

But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the behavior of
the direct execution of a Turing Machine is a valid operation. To say it
isn't is just a lie.

You are not making a new system as you say that in Computability Theory,
the Halting Problem is wrong, but then here you imply a claim you are
making a new theory (which you haven't actually worked to define) by
your false comparison to ZFC and thus not doing anything in the
classical Computability Theory,

You are just showing a fundamental confusion of how logic theories work, showing how stupid you are.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/5/2025 3:44 AM, Mikko wrote:

On 2025-07-04 12:57:47 +0000, olcott said:

On 7/4/2025 2:42 AM, Mikko wrote:

On 2025-07-03 15:17:53 +0000, olcott said:

On 7/3/2025 9:50 AM, Richard Damon wrote:

On 7/3/25 10:39 AM, olcott wrote:

On 7/3/2025 9:16 AM, Richard Damon wrote:

On 7/2/25 10:50 PM, olcott wrote:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>> input is
different than the direct execution, even though he can't show >>>>>>>>>> the
instruction actually correctly simulated where they differ, >>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>>> reason" it must be just because otherwise HHH can't do the >>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get to >>>>>>>>>> redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion >>>>>>>>> if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Nope. It seems you don't understand what the question actually IS >>>>>>> because you have just lied to yourself so much that you lost the >>>>>>> understanding of the queiston.

*I can't imagine how Mike does not get this*

I can't understand

*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*

Context of your context:

A Halt Decider is supposed to decide if the program given to it >>>>>>> (via some correct representation) will halt when run.

Thus, "the input" needs to represent a program

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

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

int main()
{
   HHH(DDD);
}

Which, by itself, isn't a valid input, or program. as HHH is
undefined.

Each different definition of HHH, gives a different problem.

Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.

"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)

But it CAN'T simulate the above input. as it isn't valid.

You need to add the code of HHH to the input to let HHH simulate >>>>>>> "the input" to get anything.

No I do not. The above paragraph has every detail that is needed.

Then how do you correctly simulate something you do not have.

Note, your "description" of HHH is just incorrect, as it is also
incomplete.

Simulating a LIE just gives you a lie.

And at that point, you have different inputs for different HHHs, >>>>>>> and possibly different behaviors, which you logic forgets to take >>>>>>> into account, which just breaks it.

Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.

Nope, becausee it violates the DEFINITION of what it means to
simulate something.

*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.

C lanbuage definition does not specifiy the senatics of the non-standard >>> lanugage extension that your HHH and HHH1 use.

*This is the ONLY specification of HHH that chatbots see*

That is irrelevant. What is relevant is the specification or lack of
that readers of comp.theory see.

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.

That is what they and the Chatbots both saw proving
that claims it was not sufficient were gaslighting.

All the Chatbots figured out on their own that DDD
correctly simulated by HHH specifies recursive simulation
such that DDD cannot possibly reach its own simulated
"return" statement. They only had the above paragraph
(and the code) as their basis.

*ChatGPT, Gemini, Grok and Claude all agree*
DDD correctly simulated by HHH cannot possibly reach
its simulated "return" statement final halt state.

https://chatgpt.com/share/685ed9e3-260c-8011-91d0-4dee3ee08f46 https://gemini.google.com/app/f2527954a959bce4 https://grok.com/share/c2hhcmQtMg%3D%3D_b750d0f1-9996-4394-b0e4-f76f6c77df3d

https://claude.ai/share/c2bd913d-7bd1-4741-a919-f0acc040494b
--
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 7/5/2025 2:30 AM, Fred. Zwarts wrote:

Op 04.jul.2025 om 14:57 schreef olcott:

On 7/4/2025 2:42 AM, Mikko wrote:

On 2025-07-03 15:17:53 +0000, olcott said:

On 7/3/2025 9:50 AM, Richard Damon wrote:

On 7/3/25 10:39 AM, olcott wrote:

On 7/3/2025 9:16 AM, Richard Damon wrote:

On 7/2/25 10:50 PM, olcott wrote:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>> input is
different than the direct execution, even though he can't show >>>>>>>>>> the
instruction actually correctly simulated where they differ, >>>>>>>>>> and thus
proves he is lying.

The closest he comes is claiming that the simulation of the >>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>>> reason" it must be just because otherwise HHH can't do the >>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get to >>>>>>>>>> redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to completion >>>>>>>>> if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.

Nope. It seems you don't understand what the question actually IS >>>>>>> because you have just lied to yourself so much that you lost the >>>>>>> understanding of the queiston.

*I can't imagine how Mike does not get this*

I can't understand

*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*

Context of your context:

A Halt Decider is supposed to decide if the program given to it >>>>>>> (via some correct representation) will halt when run.

Thus, "the input" needs to represent a program

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

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

int main()
{
   HHH(DDD);
}

Which, by itself, isn't a valid input, or program. as HHH is
undefined.

Each different definition of HHH, gives a different problem.

Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.

"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.

Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)

But it CAN'T simulate the above input. as it isn't valid.

You need to add the code of HHH to the input to let HHH simulate >>>>>>> "the input" to get anything.

No I do not. The above paragraph has every detail that is needed.

Then how do you correctly simulate something you do not have.

Note, your "description" of HHH is just incorrect, as it is also
incomplete.

Simulating a LIE just gives you a lie.

And at that point, you have different inputs for different HHHs, >>>>>>> and possibly different behaviors, which you logic forgets to take >>>>>>> into account, which just breaks it.

Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.

Nope, becausee it violates the DEFINITION of what it means to
simulate something.

*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.

C lanbuage definition does not specifiy the senatics of the non-standard >>> lanugage extension that your HHH and HHH1 use.

*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.

There is no non-termination behaviour to detect, because the input
specifies only a *finite* recursion.

When DDD is infinitely simulated by HHH it never reaches
its own simulated final halt state.

The input includes the erroneous
code to detect non-termination behaviour, which causes it to abort the simulation. This is part of the input, which makes it a halting program.
That HHH includes this erroneous code, so that it sees non-termination behaviour where it is not present, does not change the specification of
a halting program.

--
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 7/5/2025 2:33 AM, Fred. Zwarts wrote:

Op 05.jul.2025 om 00:24 schreef olcott:

On 7/4/2025 3:40 PM, Richard Damon wrote:

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>>> show the
instruction actually correctly simulated where they >>>>>>>>>>>>>> differ, and thus
proves he is lying.

The closest he comes is claiming that the simulation of >>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>>> to redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to >>>>>>>>>>>>> completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>>> computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about >>>>>>>>> some
other computation then it is not in the scope of the halting >>>>>>>>> problem
or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set
formation."

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.

It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.

Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.

Your misconception is that the decider must report on hypothetical
Turing machines, where in fact the decider must report on its input.

DDD simulated by HHH according to the semantics of the
C programming language cannot possibly reach its own
simulated "return" statement final halt state even if
an infinite number of steps are simulated.

*I can no longer be gaslighted on this*
I already had two guys with masters degrees in computer
science that agreed to this several years ago.
--
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 7/5/2025 2:36 AM, Fred. Zwarts wrote:

Op 05.jul.2025 om 00:17 schreef olcott:

On 7/4/2025 3:33 PM, Richard Damon wrote:

On 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to >>>>>>>>>>>>> completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate
past the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate
the code of HHH.

Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

No its does the same thing as HHH does: it simulates HHH.

*SIDE-BY-SIDE not top down*
*SIDE-BY-SIDE not top down*
*SIDE-BY-SIDE not top down*

HHH(DDD) Simulates itself simulating DDD.
HHH1(DDD) NEVER simulates itself simulating DDD.

As soon as HHH begins simulating itself simulating
DDD the execution trace of HHH1(DDD) and HHH(DDD)
diverge. HHH aborts its simulation many hundreds
of steps later.

This means that there is no difference in the trace. The are simulating
the same input.
So, since the are simulating the same input, the result must be the same
if the simulations are correct. If the simulations differ, at least one
of the must be incorrect.

--
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 7/5/2025 8:01 AM, Richard Damon wrote:

On 7/4/25 6:17 PM, olcott wrote:

On 7/4/2025 3:33 PM, Richard Damon wrote:

On 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to >>>>>>>>>>>>> completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate
past the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate
the code of HHH.

Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

And where does that show as a difference in the trace?

"itself" isn't something in the code/

Yes there aren't any machine addresses in x86 code.
x86 code always only works on the basis of its psychic ability.

We can't possibly see that DDD calls the machine address
of HHH because in x86 code there is no such thing as machine
addresses.
--
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 7/5/2025 8:07 AM, Richard Damon wrote:

On 7/4/25 6:24 PM, olcott wrote:

On 7/4/2025 3:40 PM, Richard Damon wrote:

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of the >>>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>>> show the
instruction actually correctly simulated where they >>>>>>>>>>>>>> differ, and thus
proves he is lying.

The closest he comes is claiming that the simulation of >>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>>> simulation.

Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>>> to redefine
it,

You ar4e just showing you are as stupid as he is.

No. A simulator does not have to run a simulation to >>>>>>>>>>>>> completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>>> computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same about >>>>>>>>> some
other computation then it is not in the scope of the halting >>>>>>>>> problem
or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set
formation."

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.

It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.

Yes, by creating a totally new system.

Note, The don't say that Russell's Paradox no longer exists in Naive Set Theory, they

It proves that Russell's Paradox was always a misconception
anchored in incoherence.

Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.

But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the behavior of
the direct execution of a Turing Machine is a valid operation. To say it isn't is just a lie.

The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider.
--
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 7/5/25 12:16 PM, olcott wrote:

On 7/5/2025 8:01 AM, Richard Damon wrote:

On 7/4/25 6:17 PM, olcott wrote:

On 7/4/2025 3:33 PM, Richard Damon wrote:

On 7/4/25 2:24 PM, olcott wrote:

On 7/4/2025 12:48 PM, Richard Damon wrote:

On 7/4/25 9:32 AM, olcott wrote:

On 7/4/2025 8:22 AM, joes wrote:

Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:

No. A simulator does not have to run a simulation to >>>>>>>>>>>>>> completion if
it can determine that the input, A PROGRAM, never halts.

If. But here it confuses that with not being able to simulate >>>>>>>> past the
recursive call.

It is the correct simulation of the input that
specifies the actual behavior of this input.

Right, and that means correctly simulating EVERY instruction that >>>>>> makes up the PROGRAM, which must include the code of *THE* HHH, or >>>>>> you can't "correctly simulate" the call instruction.

SIn

If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.

But it can, as the call goes into HHH, and you then just simulate >>>>>> the code of HHH.

Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?

When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).

*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.

And where does that show as a difference in the trace?

"itself" isn't something in the code/

Yes there aren't any machine addresses in x86 code.

Sure there are, as x86 machine code is address, contents pairing.

x86 code always only works on the basis of its psychic ability.

And thus you prove you brain has popped, thining that irony is valid arguement.

We can't possibly see that DDD calls the machine address
of HHH because in x86 code there is no such thing as machine
addresses.

Then you don't have the x86 code for DDD.

I guess you are just proving you have gone off the deep enc.


I will take this as your admission that you have nothing to refute the
errors, until you actually provide a refutation, which you have shown
you just can not do.

Your method of argument is just further proof that you have run out of
idea to streach to even try to defend yourself, and you are now just committing reputation suicide by using the classic methods of scammers
and liars.

Sorry, but that is just the truth, and only you can change it by
actually facing the facts and talking with the real defintions, even if
they just prove you wrong.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 7/5/25 12:21 PM, olcott wrote:

On 7/5/2025 8:07 AM, Richard Damon wrote:

On 7/4/25 6:24 PM, olcott wrote:

On 7/4/2025 3:40 PM, Richard Damon wrote:

On 7/4/25 2:25 PM, olcott wrote:

On 7/4/2025 1:14 PM, Richard Damon wrote:

On 7/4/25 10:43 AM, olcott wrote:

On 7/4/2025 8:23 AM, Richard Damon wrote:

On 7/4/25 8:50 AM, olcott wrote:

On 7/4/2025 2:35 AM, Mikko wrote:

On 2025-07-03 12:56:42 +0000, olcott said:

On 7/3/2025 3:57 AM, Mikko wrote:

On 2025-07-03 02:50:40 +0000, olcott said:

On 7/1/2025 11:37 AM, Mr Flibble wrote:

On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>

On 6/30/25 2:30 PM, Mr Flibble wrote:

PO just works off the lie that a correct simulation of >>>>>>>>>>>>>>> the input is
different than the direct execution, even though he can't >>>>>>>>>>>>>>> show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>> differ, and thus
proves he is lying.

The closest he comes is claiming that the simulation of >>>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do >>>>>>>>>>>>>>> the simulation.

Sorry, not being able to do something doesn't mean you >>>>>>>>>>>>>>> get to redefine
it,

You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>

No. A simulator does not have to run a simulation to >>>>>>>>>>>>>> completion if it can
determine that the input, A PROGRAM, never halts.

/Flibble

The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.

Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>>>> computation?".

That is *not* the actual question.

THe actual question is whatever someone asks.

What is the area of a square circle with a radius of 2?

However, if the question is
not "does DDD specify a halting computation?" or the same >>>>>>>>>> about some
other computation then it is not in the scope of the halting >>>>>>>>>> problem
or the termination problem.

The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.

Nope, just shows you are too stupid to understand it.

Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.

"ZFC avoids this paradox by using axioms that restrict set
formation."

And what does that distraction have to do with halting problem?

*Changing the definition of the problem is a way to solve it*

But you aren't allowed to do that.

Note, ZFC doesn't solve the problem of Russell's Paradox in Naive
Set Theory, as it doesn't do anything to Naive Set Theory.

It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.

Yes, by creating a totally new system.

Note, The don't say that Russell's Paradox no longer exists in Naive
Set Theory, they

It proves that Russell's Paradox was always a misconception
anchored in incoherence.

No, it was anchored in the existing theory of the time.

It showed that the theory had a major problem that needed to be fixed,
by finding a better system.

Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.

But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the behavior of
the direct execution of a Turing Machine is a valid operation. To say
it isn't is just a lie.

The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider.

But that isn't a "base" criteria in the system. That is like saying you
are keeping standard addition, but you want 5 + 7 to be 57 instead of
12, as that doesn't make sense.

Your problem is you just don't understand how logic systems work at all,
and thus you are trying to tackle a problem without knowing what you are doing.

Sort of like taking a car with a minor knocking probem, and trying to
beat the engine with a big wrench.

If you want to change that criteria, you need to work on reformulating
from the original axiom level.

Note, ZFC didn't just ban sets from containing themselves, but defined
actual rules of how to build sets from previously created sets, with a notation that the set being created isn't part of the set of previously created sets. This RESULTS in the inability to define a set containing
itself.

Thus, you need to do the same to achieve your results, the problem being
that the idea that you can define what a "Halt Decider" would be is
something that just comes out of the general principles of Computations.

The Halting of Computations is just a natural property of them.

Computations are encodable into finite strings (in a way that allows the
full recreation of the behavior of that computation)

And thus, asking if the computation a will halt given a finite string representation of it just naturally follows.
--- Synchronet 3.21a-Linux NewsLink 1.2