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

On 5/11/25 5:13 PM, olcott wrote:

On 5/11/2025 3:36 PM, Richard Damon wrote:

On 5/11/25 12:37 PM, olcott wrote:

On 5/11/2025 6:07 AM, joes wrote:

Am Sat, 10 May 2025 17:03:26 -0500 schrieb olcott:

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:

>

It correctly determines that the halting problem's
otherwise "impossible" input is actually non halting.

>
...which makes it halt.
>

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.

>
Nobody is baffled. It halts.
>

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.

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

>

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 HP doesn't lead to contradictions.
>

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 in a
high level language like C and it operates on a 100% complete exactingly
precise input specification such as the x86 language too many details
slip through the cracks of vagueness.

>
TMs are concrete. What details, what vagueness?
>

>
There isn't even a common TM language.
If there was a TM language then examining
the details of a termination analyzer would
be like reverse engineering all of the details
of how an operating system works from its
machine code. Humans really need high level
abstractions or they get totally lost.

>
There is a standardize version of the Turing Machine Language.
>
The fact the problem is too big for you to understand just shows that you are just too stupid to understand it.
>
Note, Turing Machines CAN be described at a high level, just like the OS. And just like understanding the OS with high level code needs an understanding of the lower level code, understanding the high level descriptions of Turing Machines needs an understanding of the basic operaiton of a Turing Machine.
>
Since you couldn't handle a Turing Machine of only a few states, that is about like not being able to understand an assembly function of just a small number of instructions.
>

>

For example no one ever even noticed that it is 100% impossible to
derive an input that actually does the opposite of whatever value that
its termination analyzer reports.

Wrong, DDD calls HHH, which returns "non-halting", *and halts*.
>

>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
There is no possible way for DD emulated by HHH
according to the rules of the x86 language to
receive the return value from its call to HHH(DDD).
It has been this way for 90 years.
>

>
>
First, if that is ALL the input, HHH can't emulate past the call instruction and be a pure function.
>

 Sure it can.
 

How? By breaking its requirements to be a pure function?
I guess you are just admitting you are just a stupid liar that doesn't know the meaning of the words he is using.
Your "proof" is now lying at the bottom of that lake of fire reserved for liars as that is what it has been proven to be, just a pile of lies, and you will be joining it there soon.