Re: D correctly simulated by H proved for THREE YEARS --- finite string transformation rules

On 6/12/24 11:58 PM, olcott wrote:

On 6/12/2024 10:45 PM, Richard Damon wrote:

On 6/12/24 11:24 PM, olcott wrote:

On 6/12/2024 9:57 PM, Richard Damon wrote:

On 6/12/24 10:21 PM, olcott wrote:

On 6/12/2024 9:06 PM, Richard Damon wrote:

On 6/12/24 9:54 PM, olcott wrote:

On 6/12/2024 8:50 PM, Richard Damon wrote:

On 6/12/24 9:19 PM, olcott wrote:

>
I am saying there is no mapping from the input TO THE QUESTION.
H IS NOT EVEN BEING ASKED ABOUT THE BEHAVIOR OF D(D).
>

>
So, you admit that you are lying about H being a Halt Decider.
>

>
No I admit that you are too stupid to understand what I am saying.

>
How is it a H
>

>
I gave you the source-code.

>
So?
>
Last time I commented about somethihg from the source code you said that didn't apply.
>
It also, as you have admitted, has bugs in its trace routine, so it can't produce a trace of the quality you seem to want.
>

>
I never said anything like that.

>
You admitted that it didn't produce the "Correct Simulation" output that it was supposed to produce.
>

 It was never supposed to produce this.
As I explain on page five of this other 2021 paper.
 https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

But acting as a "pure simulator until ..." is NOT the same as acting as a pure simulator.
And thus the "transform" is invalid, as shown by the fact that P(P) halts even though H(P,P) uses its logic to say that it doesn't.
Thus, your "logic" introduces a FALSE premise into its logic, and thus its conclusion is INVALID.
Can you show an ACTUAL accepted statement that says you are allowed to do that transform, or is this just another of your "it seems right, so I will assume it to be right" statements that just makes your logic wrong.
Your logic is just subject to the power of the paradox.

 

The output wasn't the simulation it did, but the execution trace of your decider itself.
>

>

Do you deny that with the H defined so that H(D,D) will return 0, as it does in your source code that making main() call D(D) that that D(D) will not return?
>
You even posted a trace of that operation, but its trace has the same error that all your traces do, so I don't want to call that "Correct" any more, as that would be a LIE.
>

>

>

Because Halt Deciders *ARE* being asked about the behavior of the machine their input describes, in this case D(D).
>

>
This never has been precisely correct. That is a dumbed down
version for people that do not really understand these things.

>
Source for that claim? and not that it is just another of your unverifiable false claims?
>

>
Actual comprehension is my source. That it is over-your-head
does not make me incorrect.

>
I other words, you ADMIT that it is just a "I made itup" up, but it must be true" sort of statement, so doesn't actualuy have an accepted truth-maker for it, so is just a LIE.
>
That's par for the course.
>
That you can't actually show it, shows you ARE incorrect for claiming it.
>

>
How do you think that halt deciders figure out the question that
they are being asked, do they look up the question on a textbook?

>
They don't need to. There Programmer needs to figure that out.
>
Programs don't "think", they "Compute", and do it per their instuctions given to them.
>
You just don't seem to understand the essential nature of Programs do you.
>

>

You have a big list of things you have claimed but NEVER were able to show a proof, and thus effectively admitted that you made up your claims, which means they can be considered to be LIE.
>

>
No it means that the reasoning behind them must be carefully assessed.

>
But you can't give any actual "reasoning", only your own unsubstantiated claims based on wrong defintions.
>

>
*COMPUTE THE MAPPING FROM INPUTS*
Is currently totally over-your-head
yet has a specific meaning using those terms
according to their conventional meanings.
>
Tell me in your own words what you think
COMPUTE THE MAPPING FROM INPUTS means.

>
>
It takes the input, and TRIES to process them to the answer corresponding to the mapping it is supposed to be computing.
>
Yes, ALL programs the meet the very basic definition of a decider (giving an answer for all possible input) computes SOME mapping of the input ot the output (which provides the count of the number of possible mappings that are computable). So H is some sort of decider,
>
But to be a decider for a specific function, it needs to compute the mapping that matches that function. So, A Halt Decider, to be a HALT decider, needs to generate the exact same mapping as the Halting mathematical function, which is defined in terms of the behavior of the machine represented by the input.
>
This seems to be just totally beyond your understanding, that there are actual REQUIREMENTS that must be met for something to be "Correct".
>
Note, the word *THE* in your phrase meens a specific simgular mapping, that is the mapping defined by the function it is named for.
>
Your H computes *A* mapping, but not the Halting Function mapping. And the exact details of that mapping is a function of the decider you create to try to compute it, as H and H1 generate different answers for the D built on H (and for the D1 built on H1). Thus your "POOP" mapping is different for each H you want to ask about, so in one sense, isn't even a correct question to be asking.
>
It isn't asking about the decider deciding on the behavior of the input correctly simulated by itself, but the decider needing to decider on the behavior of the input correctly simulated by a particular H that was choosen.
>
>

>

>

 Try and show the steps of the mapping that you expect in
terms of D correctly simulated by H, line by line.

But I don't claim a mapping of D correctly simulated by H, as that is a INVALID criteria, as I explained.
Since you call H a "Halt Decider", its criteria is, and can only be, the behavior of the directly executed D(D), or something that EXACTLY agrees with that behavior,
So, all you are doing is ADMITTING that you are LYING about the criteria of H, showing you have been deceptivel yLYING for the past years.
It shows that you do NOT beleive that the actual "meaning of the words" is what establishes truth, as you don't think the meaning of the words actually matter. (that or truth doesn't matter).

 Begin as machine address [00000cfc] then what and what and what
that ends up with the behavior of D(D)

The behavior of D(D) will BE (at a high level description)
we go through the first instructions until we get to the call H, which will be passed the paramaters of the addresss of D twice.
That will then go through the code of H, where it will simulate its version of D(D), and by your description, WILL reach a point where it decides to abort its simulation and return the value of 0, indicating its prediction on the behavior of the execution of D(D) is to be non-halting (but due to fault logic).
The execution of D then skips over the infinite loop and Halt.
The "Correct (but partial) Simulation by H" will when the code for the simulated H reaches the point that it sees the call to H instruction in its simulated path. So, that simulation exactly matched the behavior of the code to that point, but ignores that the correct simulation OF THIS CODE, will continue on and make the exact same decision when the code IT is simulating reaches that point too.
The issue being that THIS INPUT doesn't change when we apply the full UTM like simulation to THIS INPUT (and not regenerate an input from the template).
The problem you have is you can not do what you want to do with just the template being the input, as you can't simulate it far enough to make you claim, as templates don't actually have unifited behavior to answer about, and the problem was ALWAYS about a specific input, which needs to be a FULL program, not just a template of one.

 _D()
[00000cfc](01) 55          push ebp
[00000cfd](02) 8bec        mov ebp,esp
[00000cff](03) 8b4508      mov eax,[ebp+08]
[00000d02](01) 50          push eax       ; push D
[00000d03](03) 8b4d08      mov ecx,[ebp+08]
[00000d06](01) 51          push ecx       ; push D
[00000d07](05) e800feffff  call 00000b0c  ; call H
[00000d0c](03) 83c408      add esp,+08
[00000d0f](02) 85c0        test eax,eax
[00000d11](02) 7404        jz 00000d17
[00000d13](02) 33c0        xor eax,eax
[00000d15](02) eb05        jmp 00000d1c
[00000d17](05) b801000000  mov eax,00000001
[00000d1c](01) 5d          pop ebp
[00000d1d](01) c3          ret
Size in bytes:(0034) [00000d1d]