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

On 6/13/2024 8:24 PM, Richard Damon wrote:

On 6/13/24 11:32 AM, olcott wrote:

On 6/13/2024 6:31 AM, Richard Damon wrote:

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

>
It is contingent upon you to show the exact steps of how H computes
the mapping from the x86 machine language finite string input to
H(D,D) using the finite string transformation rules specified by
the semantics of the x86 programming language that reaches the
behavior of the directly executed D(D)
>

 Why? I don't claim it can.
 

That means that H cannot even be asked the question:
"Does D halt on its input?"

In fact, I have told you that I will not engage in your foolish idea of what H can or can not do with its partial simulation of the input, until you show why that has relevence.
 

The relevance keeps going over your head.

You seem to be stuck on that as way to try to avoid the issues that have been pointed out in the other parts of your proof, which just confirms that you really have no idea how to handle the issues pointed out.
 

*I am saying a whole BRAND-NEW-THING*
There is no way to encode a decider and an input such that
you can even ask H if D(D) halts when there is a pathological
relationship between H and D.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer