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

On 5/11/2025 1:40 PM, 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

But it doesn't as you have admitted 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