Re: HHH(DDD) computes the mapping from its input to HHH emulating itself emulating DDD --- anyone that says otherwise is a liar

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

On 11/18/2024 3:36 PM, Richard Damon wrote:

On 11/18/24 3:21 PM, olcott wrote:

On 11/18/2024 1:23 PM, Richard Damon wrote:

On 11/18/24 2:07 PM, olcott wrote:

On 11/18/2024 1:02 PM, Richard Damon wrote:

On 11/18/24 1:41 PM, olcott wrote:

On 11/18/2024 10:16 AM, Richard Damon wrote:

On 11/17/24 11:04 PM, olcott wrote:

On 11/17/2024 9:19 PM, Richard Damon wrote:

On 11/17/24 9:47 PM, olcott wrote:

On 11/17/2024 8:26 PM, Richard Damon wrote:

On 11/17/24 8:46 PM, olcott wrote:

On 11/17/2024 4:04 PM, Richard Damon wrote:

On 11/17/24 4:30 PM, olcott wrote:

On 11/17/2024 2:51 PM, Richard Damon wrote:

On 11/17/24 1:36 PM, olcott wrote:

void DDD()
{
   HHH(DDD);
   return;
}
>
_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]
>
DDD emulated by any encoding of HHH that emulates N
to infinity number of steps of DDD cannot possibly
reach its "return" instruction final halt state.
>
This applies to every DDD emulated by any HHH no
matter the recursive depth of emulation. Thus it is
a verified fact that the input to HHH never halts.
>
>

>
I will also add, that since you have dropped your requirements on HHH (or are seeming to try to divorse yourself from previous assumptions) there are MANY HHH that can complete the emulation, they just fail to be "pure functions".
>

>
The damned liar despicably dishonest attempt to get away
with changing the subject away from DDD reaching its final
halt state.
>

>
Which is just what YOU are doing, as "Halting" and what a "Program" is are DEFINED, and you can't change it.
>

>
YET ANOTHER STUPID LIE.
A SMART LIAR WOULD NEVER SAY THAT I MEANT
PROGRAM WHEN I ALWAYS SPECIFIED A C FUNCTION.
>

>
But then you can talk about "emulation" or x86 semantics, as both of those are operations done on PROGRAMS.
>

>
No stupid I provided a published paper that includes the
termination analysis of C functions.

>
Look again at what they process. C functions that include all the functions they call.
>

>
You stupidly claimed termination analysis is only done
on programs. I proved that you were stupidly wrong on
pages 24-27 of the PDF of this paper.
>
Automated Termination Analysis of C Programs
https://publications.rwth-aachen.de/record/972440/files/972440.pdf
>
>

>
The problem here is you are mixing language between domains.

>
I said the termination analysis applies to C functions
you said that it does not. No weasel words around it
YOU WERE WRONG!
>
>

>
Termination analysis applies to FUNCTIONS, FULL FUNCTIONS, ones that include everything that is part of them. Those things, in computation theory, are called PROGRAMS.

>
The top of PDF page 24 are not programs defection for brains.
https://publications.rwth-aachen.de/record/972440/files/972440.pdf
>

>
Those *ARE* "Computation Theory" Programs.
>
They are also  LEAF functions, unlike your DDD.
>
NOTHING in that paper (form what I can see) talks about handling non- leaf-functions with including all the code in the routines it calls.
>

>
Since the halting problem is defined to have the input
call its own termination analyzer and the termination
analyzer is itself required to halt then any sequence
of this input that would prevent it from halting IS A
NON-HALTING SEQUENCE THAT MUST BE ABORTED AND CANNOT
BE ALLOWED TO CONTINUE.
>
It is like I say that all black cows are black and
are cows and you disagree.
>

>
Nope, just shows your stupidity,
>
The "Halting Problem" is the problem about giving the decider a representation of a program and its input, and seeing if such a decider can be found that answers correct about the halting behavior of that program/data given to it.
>
It says NOTHING about the program reperesented by the input "calling" its own termination analyzer, thought that would be a valid input, since that is a valid program, and the correct decider needs to handle ALL inputs.
>

 When DDD calls HHH(DDD) THIS CANNOT BE F-CKING IGNORED.
DDD emulated by HHH does specify that HHH must emulate
itself emulating DDD.
 

Right, it calls HHH(DDD) and since it has been shown that HHH(DDD) does return, DDD must return.
You can't ignore that HHH is what HHH is, and assume that the HHH that DDD calls is something differnt.
That is just a LIE.

That you insist on playing trollish head games prevents
my formalization of True(L,x) from being accepted thus
enables hired liars to get away with climate change denial.

No, you play LYING Games, where you assume things are what they are not, because you just don't understand what truth is.

 If we had a mathematically sound way if discerning truth from
lies then the Earth need not be killed by liars. You are
causing the actual death of the whole planet to get some
trollish thrills.

And wishing and hoping for the impossible is what gets us into some of these problems.
YOU are one of the liars we need to

 Severe anthropogenic climate change proven entirely with verifiable facts
https://www.researchgate.net/ publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts
 

And by putting your name on it you taint the claims.
And of course your logic being "I can't think of anything else that could do it" is of course great logic.
Sorry, but you are your own worse enemy.