Re: Verified fact that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ have different behavior --RASP Machines--

On 3/11/2024 12:07 AM, Richard Damon wrote:

On 3/10/24 9:33 PM, olcott wrote:

On 3/10/2024 10:07 PM, Richard Damon wrote:

On 3/10/24 7:47 PM, olcott wrote:

On 3/10/2024 9:08 PM, Richard Damon wrote:

On 3/10/24 5:32 PM, olcott wrote:

On 3/10/2024 2:16 PM, immibis wrote:

On 10/03/24 19:32, olcott wrote:

On 3/10/2024 1:08 PM, immibis wrote:

On 10/03/24 18:17, olcott wrote:

ZFC simply tossed out the Russell's Paradox question as unsound.

>
So you are saying that some Turing machines are not sound?
>

Both H ⟨Ĥ⟩ ⟨Ĥ⟩ and Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decide that:
(a) Their input halts H.qy
(b) Their input fails to halt or has a pathological
relationship to itself H.qn.

>
But the "Pathological Relationship" is ALLOWED.
>

ZFC simply tossed out the Russell's Paradox question as unsound
expressly disallowing the "Pathological Relationship".

>
So you are saying that some Turing machines are not real Turing machines?
>

I am only claiming that both H and Ĥ.H correctly say YES
when their input halts and correctly say NOT YES otherwise.

>
well the halting problem requires them to correctly say NO, so you haven't solved it

>
All decision problem instances of program/input such that both
yes and no are the wrong answer toss out the input as invalid.

>
I noticed that you gave up on Olcott machines and now you are back to your old bullshit ways of pretending that the same machine can produce two different execution traces on the same input. Why don't you show us an execution trace where that happens? Both traces must show the first instruction that is different in both traces and I recommend showing 20 more instructions after that, but you can abort one after that time, if it doesn't halt, to prevent the trace getting infinitely long.

>
Turing Machines and Olcott machines cannot properly implement
H1(D,D) and H(D,D) that know their own machine address.
>
My C code proves these two have different behavior:
(a) H1(D,D) + H1_machine_address
(b) H(D,D) + H_machine_address
>
Because they are different computations they are
not required to have the same behavior.

>
Right, but it also means that since the dfference is because of a "Hidden" input none of them qualify as a Halt Decider.
>

>
The key input (the machines own address) is not hidden
merely unavailable to Turing machine and Olcott machines.

>
And if it isn't hidden, then the other copies that take use a different address become different computations and can't claim to fill in for THE H.
>
You then prove each copy wrong by giving it the version of H^/D that is built on it, which it will get wrong.
>
All the other ones might get it right, showing that there IS a correct answer.
>

>

>
H(D,D) immediately sees the first time it calls itself
with its same inputs.
>
H1(D,D) never sees it call itself with its same inputs.
>
Full Execution trace of H1(D,D)
(a) main() invokes H1(D,D)
(b) H1(D,D) simulates D(D)
(c) Simulated D(D) calls simulated H(D,D)
(d) Simulated H(D,D) simulates another D(D)
(e) Simulated H(D,D) aborts this D(D) when it would call itself
(f) Simulated H(D,D) returns 0 to simulated caller D(D)
(g) Simulated caller D(D) returns to H1(D,D)
(h) H1(D,D) returns 1 to main()
>
They cannot be implemented as Turing Machines or Olcott
Machines. They can be implemented as RASP machines proven
by the fact that they are implemented as C functions.
>

>
Right, which proves your C functions also were never the required computation, as they has an extra "hidden" input. As has been told to you many times in the past.

>
When I specify that every machine can know its own machine address
in x86 machines and (possibly augmented) RASP machines then it is
not hidden and an explicitly part of the input to the computation.

>
And if it isn't hidden, then the other copies that take use a different address become different computations and can't claim to fill in for THE H.
>
You then prove each copy wrong by giving it the version of H^/D that is built on it, which it will get wrong.
>
All the other ones might get it right, showing that there IS a correct answer.
>

>

>
So, you just admitted that you hae just been lying for all these years, and you are no closer to your fantasy goal then you ever were.
>
Sorry, you just don't know enough to do this problem.

>
I just admitted that it took me about two years to translate my
intuitions into words that address your objections.
>
For these two years you and many other people claimed that H1(D,D)
could not possibly do what it actually did actually do. This has
always been the same thing as disagreeing with arithmetic.
>

>
It can't do it and be the SAME COMPUTATION as H, which is what you were claiming.
>

>
It did actually do exactly what I claimed and everyone wanted
to stick to their opinion and deny the actual facts that it
did actually do what I said.

 It might have done what you THOUGHT you were saying, but it doesn't do what you ACTUALLY SAID.
 

I always claimed that H1(D,D) returns 1 and H(D,D) returns 0 and you
always said it was impossible even though that is what actual code
actually did. The code always discloses that H and H1 have their own address.
u32 H1(ptr P, ptr I)
{
   u32 Address_of_H1 = (u32)H1;       // 2022-08-15
u32 H(ptr P, ptr I)
{
   u32 Address_of_H = (u32)H;

THe problem is you MISUSED technical terms, because you didn't, and apparently still don't, understand what they mean.
 Either you have a sever learning disability, or you are just being willfully ignorant (or both).
 It was clearly asked, and yoyu confirmed, that H and H1 were claimed to be the same COMPUTATION,

I never sad anything like that.
I always claimed that H1(D,D) returns 1 and H(D,D) returns 0 and you
always said it was impossible even though that is what actual code
actually did.

which means they are only a function of there declaired inputs, and the exact same algorithm, and neither H nor H1 take their address as a declared input, but somehow (we know how) manage to do different things based on that value.
 

I showed use the execution trace two dozen times and in
each case it was clear that the machines had their own
machine address.

That mean, you DID LIE, and refusing it now, just makes it another LIE showing your final destination.
 

>

You are now admitting you were lying all that time, and really owe an appology to everyone yYOU said were lying when they were telling you they weren't the same computation.
>

I never ever lied about any of these things.
It took me a long time to get to closure because

 You lied, perhaps because of ignorance,

*THAT IS NOT HOW LIES WORK*
*THAT IS NOT HOW LIES WORK*
*THAT IS NOT HOW LIES WORK*
*THAT IS NOT HOW LIES WORK*
*THAT IS NOT HOW LIES WORK*
*THAT IS NOT HOW LIES WORK*
*THAT IS NOT HOW LIES WORK*

but that ignorance when well past the ability to be called an "Honest Mistake" and became a wanton disreguard for the truth.
 

>
I tolerated the [change the subject] form of
rebuttal that wasted 15 years with Ben Bacarisse.
>
Once I stopped tolerating this closure was achieved
on several points.
>

Of course, since you now admit they are different, that means that H1 can get H out of the jam. D will call the one instance of H, that one particular computation, that it is designed to make wrong, and since the other copies are different computations, they don't rescue that one, or even show that the question is subjective.

>
That they used their own machine address as part of their computation
was explicitly provided for years. Don't blame me for lying when the
real issue is that you didn't bother to pay attention.

 But you still claimed they were the same computation.

I never said that, you only assumed that.
I always claimed that H1(D,D) returns 1 and H(D,D) returns 0.
You always said this was impossible even though you could look
at my code and see the code does that.

 Admitting you are lying while you are lying is still lying.
 

>
H1: Begin Simulation   Execution Trace Stored at:113095
*Address_of_H1:1442*
[00001d12][00113081][00113085] 55         push ebp      ; begin D
[00001d13][00113081][00113085] 8bec       mov  ebp,esp
[00001d15][0011307d][00103051] 51         push ecx
[00001d16][0011307d][00103051] 8b4508     mov  eax,[ebp+08]
[00001d19][00113079][00001d12] 50         push eax      ; push D
[00001d1a][00113079][00001d12] 8b4d08     mov  ecx,[ebp+08]
[00001d1d][00113075][00001d12] 51         push ecx      ; push D
[00001d1e][00113071][00001d23] e81ff8ffff *call 00001542* ; call H(D,D)
>
H: Begin Simulation   Execution Trace Stored at:15dabd
*Address_of_H:1542*
[00001d12][0015daa9][0015daad] 55         push ebp      ; begin D
[00001d13][0015daa9][0015daad] 8bec       mov  ebp,esp
[00001d15][0015daa5][0014da79] 51         push ecx
[00001d16][0015daa5][0014da79] 8b4508     mov  eax,[ebp+08]
[00001d19][0015daa1][00001d12] 50         push eax      ; push D
[00001d1a][0015daa1][00001d12] 8b4d08     mov  ecx,[ebp+08]
[00001d1d][0015da9d][00001d12] 51         push ecx      ; push D
[00001d1e][0015da99][00001d23] e81ff8ffff *call 00001542* ; call H(D,D)
H: Recursive Simulation Detected Simulation Stopped (return 0 to caller)
>
>

 You are just proving you don't know or understand enough about any of the things you talk about to be taken seriously.

If that was true then you would not make so many mistakes in your
critique of my work. You continue to fail to correctly understand
the sets that are defined by the Linz templates.
*The key property that belongs to every this set is*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
*Every implementation of Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ gets the wrong answer*
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer