Re: DDD specifies recursive emulation to HHH and halting to HHH1

On 3/27/25 9:21 AM, olcott wrote:

On 3/27/2025 6:02 AM, Richard Damon wrote:

On 3/26/25 11:47 PM, olcott wrote:

On 3/26/2025 10:28 PM, Richard Damon wrote:

On 3/26/25 11:09 PM, olcott wrote:

On 3/26/2025 8:22 PM, Richard Damon wrote:
>
_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]
>

Non-Halting is that the machine won't reach its final staste even if an unbounded number of steps are emulated. Since HHH doesn't do that, it isn't showing non-halting.
>

>
DDD emulated by any HHH will never reach its final state
in an unbounded number of steps.

>
But DDD emulated by an actually correct emulator will,

>
If you were not intentionally persisting in a lie you
would acknowledge the dead obvious that DDD emulated
by HHH according to the semantics of the x86 language
cannot possibly correctly reach its final halt state.

>
And if you were not intentionally persisting in a lie, you would admit that your HHH doesn't do that, as it stops before it finishes.
>

>
The behavior that DDD specifies to HHH <is> the behavior
that it must report on.

>
>
Which, by the definition, is the behavior of the directly executed DDD, or the completely and correctly emulation of that input, something HHH doesn't do, so HHH doesn't define.
>

>
Turing computable halt functions are only allowed to
report on the behavior that their input specifies.

>
There are no Turing Computable Halt Functions.
>

 A halt function is not the same as a halt decider.
https://en.wikipedia.org/wiki/Computable_function

No, but the Halt Function is what the Halt Decider needs to try to compute.
Nothing says that it needs to be computable, in fact, that is the question, is it?

 A Turing computable function could have its domain
restricted to a single finite string.

Not a very interesting function then.
You do realize you are admitting that you aren't following the task you claim to be doing.

 

You are just assuming the existance of them, because you live in the land of Make Beleive.
>

 No it is your mistake of not paying close enough
attention to the exact terms that I am using.
 

No, the problem is that you are just showing that you don't know what those terms mean.

The Halting Problem defines a specific mapping based on the execution of a program,  and provides to the claimed decider a representation of that program, and asks it to tell us if that program, when run, will halt.
>

 This has proven to be flat out incorrect countless times
in many ways. Turing computable functions on a domain
of specific finite string encodings of sequences of moves
reports on the actual behavior that this finite string
actually specifies including recursive emulation when
specified.

But the domain of the problem doesn't assume that the Halting Function actually IS "Turinc Computable", and in fact, the question is whether it is or not.

 

If it can't do that, then it has just failed to meet the requirements.
>

 These requirements are not incorrect. They are anchored in
false assumptions. When any requirement is anchored in
false assumptions this requirement is incorrect.
 

No, you complaints are anchored in false assumptions and your own stupidity.
What is the "false assumption" that the ACTUAL problem has?
Remember, the ACTUAL Problem is to figure out whether or not a Halt Decider can be constructed, where the Definition of a Halt Decider is a Computation that computes the Halting Function, which is defined to be Accept if the program described to the Computation will Halt when it is run, and to be Reject, if that program will never halt, even after an unbounded number of steps executed.
What is the false assumption in that? (And not in you Strawman).

You are just trying to insist that you can change the problem so you can make up an answer, thus violation what you say in your next statement below:
>

 HHH(DDD) is not allowed to report on the behavior of
DDD(HHH1) when this differs from the behavior of HHH(DDD).

Of course not since DDD(HHH1) is a very different input then HHH(DDD), they differ even in the outer code.
HHH(DDD) needs to answer about the actual behavior of DDD, which is DEFINED by the direct execution of that function, or by the COMPLETE and accurate emulation of it, by a UTM or some equivalent machine,
Since HHH1 does that for this input, the fact that HHH1(DDD) simulates it to the end, shows that DDD is a halting program.
The fact that HHH just stops its emulation, says that the HHH doing the emulation has nothing to do with defining the behavior of DDD, only the HHH that DDD calls, and that is shown to return 0 to DDD so it halts.
You just are showing you don't know the meaning of the words you are talking about..

 

>
int sum(int x, int y) { return x + y; }
sum(5,6) must report the sum of 5+6 and
is not allowed to report the sum of 2+3.
>

>
Right, and HHH(DDD) must report on the actual behavior of the directed executed DDD as that is what the question it claims to be answering says.
>
Not the behavior of some DDD' that calls a different HHH than what it does,
>
Sorry, you are just proving your stupidity.