Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/10/2025 6:55 PM, Mr Flibble wrote:

On Sat, 10 May 2025 18:39:18 -0400, dbush wrote:
 

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

On 5/10/2025 4:44 PM, wij wrote:

On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:

On 5/10/2025 2:02 PM, wij wrote:

On Sat, 2025-05-10 at 13:47 -0500, olcott wrote:

On 5/10/2025 1:37 PM, wij wrote:

On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:

On 5/10/2025 1:09 PM, wij wrote:

On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:

On 5/10/2025 12:01 PM, wij wrote:

On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:

On 5/10/2025 11:29 AM, wij wrote:

On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:

On 5/10/2025 11:06 AM, wij wrote:

On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:

On 5/10/2025 10:28 AM, wij wrote:

On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:

On 5/10/2025 7:37 AM, Bonita Montero wrote:

Am 09.05.2025 um 04:22 schrieb olcott:
>

Look at their replies to this post.
Not a one of them will agree that
>
void DDD()
{
            HHH(DDD);
            return; // final halt state
}
>
When 1 or more instructions of DDD are correctly
simulated by HHH then the correctly simulated DDD
cannot possibly reach its "return" instruction (final
halt state).
>
They have consistently disagreed with this simple
point for three years.

>
I guess that not even a professor of theoretical
computer science would spend years working on so few
lines of code.
>
>

I created a whole x86utm operating system.
It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting.
>
int DD()
{
            int Halt_Status = HHH(DD);
            if (Halt_Status)
              HERE: goto HERE;
            return Halt_Status;
}
>
https://github.com/plolcott/x86utm
>
>

Nope.
         From I know HHH(DD) decides whether the
         input DD
is "impossible"
input or not.
>
>

DD has the standard form of the "impossible" input.
HHH merely rejects it as non-halting.
>
>

You said 'merely' rejects it as non-halting.
So, POOH do not answer the input of any other function?
>
>

The input that has baffled computer scientists for 90 years
is merely correctly determined to be non-halting when the
behavior of this input is measured by HHH emulating this
input according to the rules of the x86 language.
>
The same thing applies to the Linz proof yet cannot be
understood until after HHH(DDD) and HHH(DD) are fully
understood.
>
>

HHH(DDD) (whatever) at most says DDD is a pathological/
midtaken input.
Others of what you say are your imagine and wishes, so far
so true.
>
>

DDD emulated by HHH accor not the 'HHH' that makes the final
decision

(otherwise, it will be an infinite recursive call which you
agreed)
>

ding to the rules of the x86 language specifies recursive
emulation that cannot possibly reach the final halt state of
DDD.
>
>

I have no problem with that. And, you said HHH merely rejects
it as non-halting.
You had denied HHH can decide the halting property of any
input, except DDD/DD/D..
>
>

As long as HHH correctly determines the halt status of a single
input that has no inputs then HHH is a correct termination
analyzer for that input.

>
Go it, that is a stronger statement that HHH ONLY decides DD.
I have no problem with that, but be noticed that the HHH inside
DD is not the 'HHH' that makes the final decision (otherwise,
the 'HHH'
will be an infinite recursive which cannot make any decision,
which you had agreed)
>
>

HHH(DD) correctly determines that its input specifies recursive
emulation when this input is emulated by HHH HHH according to the
rules of the x86 language.

>
    From the about, so you are talking about 'the HHH' which
    does
not compute the final decision.
>
>

HHH does recognize the recursive emulation pattern of DDD emulated
by HHH according to the rules of the x86 language.
>

*Thus exactly meets the following specification*
<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
>
         H can abort its simulation of D and correctly
         report that D

>
This H won't be the same HHH inside the DD, otherwise an infinite
recursive call happens.
>
>

It must always be the outermost HHH that does this because it has
seen one entire recursive emulation more than the next inner HHH.

>
No problem. H is not HHH.
>
>

The H is the template that Professor Sipser agreed to.
HHH is a specific implementation of H.
>

This is also a pitty no one here understand POOH can help AI
industry and mankind, even so mini.
>
>

It is the same halting problem after its mistake has been corrected.
So just like how ZFC corrected the error in set theory so that
Russell's Paradox could be correctly decided, HHH corrects the error
in the halting problem proof so that the otherwise impossible input
is correctly decided.

>
I don't know what that part of set theory works.
(My feeling is that they are garbage, for reasons,
unless you are doing logic researches)
>

The original set theory is now called naive set theory after its
mistake has been corrected. Thus the original halting problem proofs
can now be called the naive halting problem proofs.

>
Traditional logic (or the part mostly used) that won't cause confusion
is more reliable.
>

The halting problem itself remains the same, yet loses its most
important proof.

>
HP is based on TM. Proof of any other kind other than TM have to be
cautious.

>
Unless this is done as an actual simulating termination analyzer

>
That assumes one exists.  Linz and others proved it doesn't, and you
have *explicitly* agreed with that.

 Linz and others haven't proved jack shit: the contradiction at the heart
of the halting problem is a category (type) error, i.e. ill-formed.
 

There's no such thing as an ill-formed contradiction.
Once an assumption is made, *any* contradiction proves that assumption false.  It doesn't matter how outlandish the contradiction might seem.