Re: Halting Problem: What Constitutes Pathological Input

On 5/7/2025 12:50 AM, olcott wrote:

On 5/6/2025 9:46 PM, dbush wrote:

On 5/6/2025 10:40 PM, olcott wrote:

On 5/6/2025 6:00 PM, Richard Damon wrote:

On 5/6/25 1:54 PM, olcott wrote:

On 5/6/2025 6:06 AM, Richard Damon wrote:

On 5/5/25 10:29 PM, olcott wrote:

On 5/5/2025 8:06 PM, Richard Damon wrote:

On 5/5/25 11:51 AM, olcott wrote:

On 5/5/2025 10:17 AM, Mr Flibble wrote:

What constitutes halting problem pathological input:
>
Input that would cause infinite recursion when using a decider of the
simulating kind.
>
Such input forms a category error which results in the halting problem
being ill-formed as currently defined.
>
/Flibble

>
I prefer to look at it as a counter-example that refutes
all of the halting problem proofs.
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

>
Which isn't a program until you include the SPECIFIC HHH that it refutes, and thus your talk about correctly emulated by HHH is just a lie.
>

>
https://github.com/plolcott/x86utm
>
The x86utm operating system includes fully
operational HHH and DD.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
>
When HHH computes the mapping from *its input* to
the behavior of DD emulated by HHH this includes
HHH emulating itself emulating DD. This matches
the infinite recursion behavior pattern.
>

>
And *ITS INPUT*, for the HHH that answers 0, is the representation of a program

>
Not at all. This has always been stupidly wrong.
The input is actually a 100% perfectly precise
sequence of steps. With pathological self-reference
some of these steps are inside the termination analyzer.
>

>
Can't be, as the input needs to be about a program, which must, by the definition of a program, include all its algorithm.
>
Yes, there are steps that also occur in the termination analyzer, but they have been effectively copied into the program the input describes.
>
Note, nothing says that the representation of the program has to be an assembly level description of it. It has to be a complete description, that 100% defines the results the code will generate (and if it will generate) but it doesn't need to be the exact assembly code,
>
YOU even understand that, as you present the code as "C" code, which isn't assembly.
>
What you forget is that the input program INCLUDES as its definiton, all of the code it uses, and thus the call to the decider it is built on includes that code into the decider, and that is a FIXED and DETERMINDED version of the decider, the one that THIS version of the input is designed to make wrong.
>
This doesn't change when you hypothosize a different decider looking at THIS input.
>

>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     *would never stop running unless aborted* then
>
*would never stop running unless aborted*
Refers to a hypothetical HHH/DD pair of the same HHH that
DD calls except that this hypothetical HHH never aborts.
>

>
Right, but a correct simulation of D does halt,

>
How the Hell is breaking the rules specified
by the x86 language possibly correct?
>
I could say that the sum of 5 + 7 is a dirty sock
according to the rules of random gibberish.
>
When I go by the rules of arithmetic I am proved
wrong.
>
DD <is> emulated by HHH according to the rules
of the x86 language

>
False, as you yourself have admitted on the record:
>

You confused the words that I said with the words that others said.
 DD <is> emulated by HHH according to the rules
of the x86 language

And again you lie, as you have admitted it does not on the record:
On 5/5/2025 8:24 AM, dbush wrote:
 > On 5/4/2025 11:03 PM, dbush wrote:
 >> On 5/4/2025 10:05 PM, olcott wrote:
 >>> On 5/4/2025 7:23 PM, Richard Damon wrote:
 >>>> But HHH doesn't correct emulated DD by those rules, as those rules
 >>>> do not allow HHH to stop its emulation,
 >>>
 >>> Sure they do you freaking moron...
 >>
 >> Then show where in the Intel instruction manual that the execution of
 >> any instruction other than a HLT is allowed to stop instead of
 >> executing the next instruction.
 >>
 >> Failure to do so in your next reply, or within one hour of your next
 >> post on this newsgroup, will be taken as you official on-the-record
 >> admission that there is no such allowance and that HHH does NOT
 >> correctly simulate DD.
 >
 > Let the record show that Peter Olcott made the following post in this
 > newsgroup after the above message:
 >
 > On 5/4/2025 11:04 PM, olcott wrote:
 >  > D *WOULD NEVER STOP RUNNING UNLESS*
 >  > indicates that professor Sipser was agreeing
 >  > to hypotheticals AS *NOT CHANGING THE INPUT*
 >  >
 >  > You are taking
 >  > *WOULD NEVER STOP RUNNING UNLESS*
 >  > to mean *NEVER STOPS RUNNING* that is incorrect.
 >
 > And has made no attempt after over 9 hours to show where in the Intel
 > instruction manual that execution is allowed to stop after any
 > instruction other than HLT.
 >
 > Therefore, as per the above criteria:
 >
 > LET THE RECORD SHOW
 >
 > That Peter Olcott
 >
 > Has *officially* admitted
 >
 > That DD is NOT correctly simulated by HHH