Re: ChatGPT agrees that HHH refutes the standard halting problem proof method

On 7/1/25 7:52 AM, olcott wrote:

On 7/1/2025 3:28 AM, Fred. Zwarts wrote:

Op 01.jul.2025 om 03:34 schreef olcott:

On 6/30/2025 8:12 PM, Richard Damon wrote:

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

On Sun, 29 Jun 2025 22:39:10 -0400, Richard Damon wrote:
>

On 6/29/25 3:51 PM, Mr Flibble wrote:

On Sun, 29 Jun 2025 15:00:35 -0400, Richard Damon wrote:
>

Remember, the simulator must be simulating the INPUT, and thus to go
past the call HHH instruction, the code must be part of the input, and
the input needs to be a constant.

No. If HHH is simulating DDD then HHH can detect a call to itself being
passed DDD within DDD and can assert at that point that the input is
non-
halting.
>
/Flibble

>
And thus isn't simu;ating THE INPUT, and that the input isn't a PROGRAM.
>
Also, what if DDD is using a copy of HHH, as per the proof program,
which might have variations in the code.
>
Sorry, just shows you don't understand the problem.

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

>
Right, but the program of the input DOES halt.
>

>
The directly executed DDD() *IS NOT AN INPUT*
Directly executed Turing machines have always been
outside of the domain of any function computed by
a Turing machine therefore directly executed Turing
machines have never contradicted the decision of
any halt decider.
>
Halt deciders compute the mapping from the behavior
that their finite string inputs actually specifies.
>
>

>
The input is a pointer to a 'finite string' that includes the code of DDD and all functions called by it, in particular including the code to abort and halt.

 *I keep correcting you on this and you keep ignoring my correction*
The measure is DDD simulated by HHH reaching its simulated "return"
statement final halt state. HHH continues to simulated DDD as a
pure simulator (that also simulates itself simulating DDD) until
HHH sees the non-terminating pattern.

Then you are just lying about working on the Halting Problem, and have been doing so for years.
The criteria for halting is if the MACHINE, WHEN RUN, reaches the final state.
HHH is just wrong, and did an incorrect (because it was partial, and then used fault logic on the partial results) simulation of its input.

 

Therefore, even a beginner can see that this input specifies a halting program. That your HHH cannot see that, does not change the specification.

 Five chatbots all agree that the input to HHH(DDD) specifies
non-terminating recursive emulation even though DDD() halts.

Which means that you have learned how to lie and assert your Natural Stupidity onto a Artificial Intelegence (which don't really know what truth is).

 

Your attempt to distract from the specification with many irrelevant words about direct execution that is not the input, does not change the fact that the input specifies a halting program according to the semantics of the x86 language. Exactly the same input, when given to world-class simulators and direct execution show halting behaviour, which supports this claim.
>
I have worked with many different simulators. The first thing that is learned is that the goal of a simulation is to reproduce the properties of reality. If it fails to reproduce relevant properties of reality, it is a worthless and incorrect simulator. Your simulator is meant to simulate the execution of x86 code. If that simulation has completely different results from reality, than even beginners will understand that the simulation is incorrect and worthless. Using such a simulation as a measure for the halting behaviour of the program specified in the input is ridiculous.