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

On 11/27/2024 9:20 PM, Richard Damon wrote:

On 11/27/24 8:15 PM, olcott wrote:

On 11/27/2024 8:03 AM, Richard Damon wrote:

On 11/27/24 8:28 AM, olcott wrote:

On 11/27/2024 6:14 AM, Richard Damon wrote:

olcott <NoOne@NoWhere.com> wrote:

On 11/26/2024 7:02 AM, Richard Damon wrote:

On 11/25/24 11:08 PM, olcott wrote:

On 11/24/2024 11:18 AM, Richard Damon wrote:

On 11/24/24 9:30 AM, olcott wrote:

On 11/23/2024 11:54 AM, Richard Damon wrote:

On 11/23/24 11:54 AM, olcott wrote:

On 11/23/2024 9:35 AM, Richard Damon wrote:

On 11/23/24 10:15 AM, olcott wrote:

On 11/23/2024 9:02 AM, Richard Damon wrote:

On 11/23/24 9:04 AM, olcott wrote:

On 11/23/2024 1:59 AM, Mikko wrote:

On 2024-11-22 16:45:52 +0000, olcott said:
>

On 11/22/2024 2:30 AM, Mikko wrote:

On 2024-11-21 15:32:38 +0000, olcott said:
>

On 11/21/2024 3:12 AM, Mikko wrote:

On 2024-11-20 22:03:43 +0000, olcott said:
>

On 11/20/2024 3:53 AM, Mikko wrote:

On 2024-11-20 03:23:12 +0000, olcott said:
>

On 11/19/2024 4:12 AM, Mikko wrote:

On 2024-11-18 20:42:02 +0000, olcott said:
>

On 11/18/2024 3:41 AM, Mikko wrote:

The "the mapping" on the subject line is not
correct. The subject line
does not specify which mapping and there is no
larger context that could
specify that. Therefore it should be "a mapping".
>
On 2024-11-17 18:36:17 +0000, olcott said:
>

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.

>
Because it cannot reach the instructions before tha
return.
Because it cannot reach the instruction after the
HHH call.
Because it cannot reach return instruction of HHH.
>

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.

>
That is too vague to be regareded true or false. It
is perfectly possibe
to define two programs and call them DDD and HHH

>
What a jackass. DDD and HHH have been fully specified
for many months.

>
They are specified in a way that makes your "every
DDD" and "any DDD"
bad (perhaps even incorrect) use of Common language.
>

>
I specify the infinite sets with each element numbered
on the top of page 2 of my paper. Back in April of 2023
>
https://www.researchgate.net/
publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D

>
You have also specifed that HHH is the program in your
GitHub repository.
>

>
Should I assume that you must be lying about
this because you did not quote where I did this?

>
No, you may assume that I was confused by your lack of
clarity and
in particular by your bad choice of names.
>
If you clearly state that HHH is not the function HHH
that you have
in your GitHub repository then I needn't to consider the
possiblity
that you just triying to deceive by equivcation.
>

>
HHH is one concrete example of an infinite set of instances
such that DDD is emulated by HHH N times.

>
That sentence says that there is only one HHH,
contradicting your
earlier statement that HHH is a generic term for every
member of some
set.
>

>
You seem to be a damned liar: "infinite set of instances"

>
You mean you lied when you said "one concrete example"?
>

>
One element of an infinite set does not say there
is no infinite set. Is says there is an infinite set.
>

>
But one element of an infinite set is not the infinite set.
>
You are just showing that your logic is based on proven
incorrect set theory.
>
IF HHH is an ELEMENT of the set, then it is that one element
for the entire evaluation,

>
Liar:
>
A proof by induction consists of two cases. The first, the base
case,
proves the statement for n=0 without assuming any knowledge of
other cases. The second case, the induction step, proves that if
the
statement holds for any given case n=k, then it must also hold for
the next case n=k+1. These two steps establish that the statement
holds for every natural number n. The base case does not
necessarily
begin with n=0, but often with n=1, and possibly with any fixed
natural
number n=N, establishing the truth of the statement for all natural
numbers n ≥ N.
https://en.wikipedia.org/wiki/Mathematical_induction
>

>
And when have you ever provided such a proof for your statement?
>
NOWHERE
>
Your problem is you don't even have a logical basis to express
your statements in, so you can't do an induction on them.
>

>

>
So, you are just demonstrating that your "logic" is based on the
meaningless use of buzzwords that you don't understand, but can
parrot their unlearned meaning, but have no idea how to actually use.
>

>
*As you already admitted below*
when N steps of DDD are emulated by HHH
DDD cannot reach past its call to HHH (statement)

>
But that was for the DDD that INCLUDED HHH as part of it, which you
have now made clear is NOT what you consider DDD to be. And for
that case DDD[n] calls HHH[n] (where HHH[n] is the version of HHH
that does only n steps of emulation) and while we can say that
HHH[n[ does not emulate DDD[n] to its final state, that property is
NOT a property of of DDD[n], but of HHH[n] and DDD[n] as its input.

>
That every DDD[n] calls its HHH[n] in recursive emulation
conclusively proves that no DDD[n] emulated by HHH[n] halts,
thus each HHH[n] is correct to reject its input as non halting.

>
But every HHH[n] aborts its emulaton and returns, and thus DDD[n]
halts, and thus HHH is INCORRECT to call its input non-halting.
>

>
*You are a stupid liar*
You know that halting means reaching a final state and you
know that no input to HHH can possibly reach its final state.
So you aren't just a liar, you are a stupid one.
>

>
And you should know that "Halting" is a property of Turing Machines /
Computations / Progrzms / completely defined function and the like ONLY.
>

>
I have already proved that halting is a property of C functions.
You are not stupid, and you have good knowledge yet you do lie
stupidly.
>

>
WHERE?
>
You pointed to a reference that talks about LEAF C-functions as having that
property.
>
Since you have made it clear that the description of the input DDD does NOT
include the code of HHH,

>
Because HHH emulates DDD the call to HHH(DDD) from DDD
never returns thus DDD never reaches its final halt state.
It is not that hard as soon as you get out of rebuttal
mode and get into honest dialogue mode.
>

>
No, the call to HHH)(DDD) from DDD returns, because the definition of

>
When DDD is emulated by HHH and DDD calls HHH(DDD) this call
never returns.

 WRONG.
 The *DEFINITION* of the behavor of a program is the unbounded execution=/emulation of it.
 Also, you CAN'T emulate the DDD that you have defined, that is, not including the HHH that it calls,

You already admitted that when DDD is emulated by HHH
that the call from DDD to HHH(DDD) never returns.
On 11/22/2024 8:41 PM, Richard Damon wrote:
 > On 11/22/24 9:07 PM, olcott wrote:>
 >
 > And, how many times will you just ignore that
 > the below input can not be emulated past the
 > call HHH instructioon.
 >
 >> _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]

 All this proves is that you are nothing but a damned liar that has proven he doesn't know what he is talking about, but juts spouts of words he just doesn't understand what they mean, but only know by a rote memorization of the words without understanding their meaning in context.
 

>
Unless proton beam therapy prevents this my Right paracaval lymph
node will soon close off my superior vena cava (all blood flow to
the heart). This lymph node has been growing at a rate of 3.84%
per day for the 68 days between PET scans.
>
1.0384 ^ 90 = 29.7-fold increase every 90 days. The R2 cancer
treatment that I just started takes 90 days to begin to take effect.
>

 So, you don't have long to repent and try to repair your reputation. You have done a good job of totally burying it with all the stupid lies you have said, and your claims that you aren't lying just prove your stupidity.
 Sorry, you don't get to change the rules of the game, and is seems you are about to have that proved to you.

I just figured out what could save me.
I simply have the dangerous Right paracaval lymph node
surgically removed before it gets much bigger and could
block off my inferior vena cava very much.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer