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

On 5/11/2025 4:53 PM, olcott wrote:

On 5/11/2025 3:23 PM, wij wrote:

On Sun, 2025-05-11 at 15:19 -0500, olcott wrote:

On 5/11/2025 1:38 PM, wij wrote:

On Sun, 2025-05-11 at 12:40 -0500, olcott wrote:

On 5/11/2025 12:21 PM, wij wrote:

On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:

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

On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:

On 5/11/2025 9:34 AM, wij wrote:

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

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

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

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

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

On 5/10/2025 8:17 PM, wij wrote:

On Sat, 2025-05-10 at 17:03 -0500, 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:

>

>
You don't know the counter example in the HP proof, your D is not the case
what HP
says.
>

>
Sure I do this is it! (as correctly encoded in C)
>
typedef void (*ptr)();
int HHH(ptr P);
>
int DD()
{
          int Halt_Status = HHH(DD);
          if (Halt_Status)
            HERE: goto HERE;
          return Halt_Status;
}
>
int main()
{
          HHH(DD);
}
>
>

>
Try to convert it to TM language to know you know nothing.
>

>
I spent 22 years on this. I started with the Linz text
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
         or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>
Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩
>

To refute the HP, you need to understand what it exactly means in TM.

>
I have known this for 22 years.

>
A working TM. Build it explicitly from transition function, then explain
your derivation. You know nothing.
>

>
That would be like examining how an operating system
works entirely from its machine code.

>
You are refuting a CS foundamental theorem (i.e. HP) officially.
So, yes, and actually MORE need to be done (beyond your imagination).
>
Knowing a car or smart phone,... is far different from making one.
Knowing E=mc^2 is far from knowing relativity, making A-bomb (actually, making
A-bomb don't need to know E=mc^2, people are often fooled by popular saying)
Every chapter of Linz's book, C text textbook has exercises, you need to those
exercises AT LEAST to comment CS (and computation theory is more advanced topic
than TM). Saying so is because we know you can't do the exercise and boast lots
about TM stuff (and pretty much anything else from just reading words), even
about theorem.
>

>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
       or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
>
All that I need to know is that I proved that
embedded_H correctly recognizes the repeating
pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
cannot possibly reach its own simulated final
halt state of ⟨Ĥ.qn⟩
>
https://www.liarparadox.org/Linz_Proof.pdf
>

We only have to actually know one detail:
Every counter-example input encoded in any model
of computation always specifies recursive simulation
that never halts to its corresponding simulating
termination analyzer.

>
More example here that you don't understand nearly all CS terms.
>

>
Mere empty rhetoric entirely bereft of any supporting
reasoning. The x86 language is comparable to a RASP
machine that is equivalent to a Turing machine.

>
Question:
1. Do you understand that you can't do the exercises in Linz's book?

>
Everything is 100% irrelevant besides the fact that
I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
embedded_H cannot possibly reach its own simulated
final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
on the behavior that its input specifies it can
correctly transition to Ĥ.qn.
>

2. Do you understand your ability of C/assembly/TM is less than 1 year CS level?
>

>
I construe C as high level assembly language thus
disregard any inessentials. No change since K & R
is of any use to me. I write C++ the same way. I
use it as C with classes. I also use std::vector a lot.

>
Q3. If people know the capability of the author of POOH is less than 1 year CS
       level. How persuasive and reliable of POOH do you think it would be?
>
Q4: Why no one can reproduce the result of POOH for these 22? years?
>
>

>
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
All anyone need do to show that I am wrong
is provide the steps where DDD emulated by
HHH according to the rules of the x86 language
reaches its own emulated "ret" instruction.
>
Because no one can actually correctly show any
mistake in the above they resort to rhetoric
because that have no actual reasoning.

>
Q5: Do you remember you had claimed H(D) returns 1,0,both,... is correct and
      more. The answer changes. What is your comment of this?
>
q6: What is the return value of H(D) now, exactly?
>
>

>
I am only referring to the behavior of DDD
emulated by HHH according to the rules of
the x86 language.

>
So, you longer refute the HP now?

 ZFC corrected the error in set theory so that
it could resolve Russell's Paradox. The original
set theory has now called naive set theory.
 I corrected the error of the HP that expects
HHH to report on behavior that is different
than the behavior that its input actually
specifies.

There is no error.  As per the requirements, HHH must report on the behavior of the algorithm described by the input when executed directly:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
If I want to know if any arbitrary algorithm X with input Y will halt when executed directly, I don't care what behavior X specifies to H.