Re: Verified facts regarding the software engineering of DDD, HHH, and HHH1 ---

On 10/26/24 11:44 AM, olcott wrote:

On 10/26/2024 10:35 AM, Richard Damon wrote:

On 10/26/24 9:47 AM, olcott wrote:

On 10/25/2024 11:07 PM, Richard Damon wrote:

On 10/25/24 7:18 PM, olcott wrote:

On 10/25/2024 5:17 PM, Richard Damon wrote:

On 10/25/24 5:54 PM, olcott wrote:

On 10/25/2024 10:45 AM, Richard Damon wrote:

On 10/25/24 9:37 AM, olcott wrote:

On 10/25/2024 7:27 AM, Richard Damon wrote:

On 10/24/24 9:04 PM, olcott wrote:

On 10/24/2024 6:23 PM, Richard Damon wrote:

On 10/24/24 2:19 PM, olcott wrote:

On 10/23/2024 9:48 PM, Richard Damon wrote:

On 10/23/24 10:33 PM, olcott wrote:

On 10/23/2024 6:16 PM, Richard Damon wrote:

On 10/23/24 8:33 AM, olcott wrote:

On 10/23/2024 6:12 AM, Richard Damon wrote:

On 10/23/24 12:04 AM, olcott wrote:

On 10/22/2024 10:47 PM, Richard Damon wrote:

On 10/22/24 11:25 PM, olcott wrote:

On 10/22/2024 10:02 PM, Richard Damon wrote:

On 10/22/24 11:57 AM, olcott wrote:

On 10/22/2024 10:18 AM, joes wrote:

Am Tue, 22 Oct 2024 08:47:39 -0500 schrieb olcott:

On 10/22/2024 4:50 AM, joes wrote:

Am Mon, 21 Oct 2024 22:04:49 -0500 schrieb olcott:

On 10/21/2024 9:42 PM, Richard Damon wrote:

On 10/21/24 7:08 PM, olcott wrote:

On 10/21/2024 6:05 PM, Richard Damon wrote:

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

On 10/21/2024 5:34 PM, Richard Damon wrote:

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

On 10/21/2024 10:17 AM, joes wrote:

Am Mon, 21 Oct 2024 08:41:11 -0500 schrieb olcott:

On 10/21/2024 3:39 AM, joes wrote:

>

Did ChatGPT generate that?
If it did then I need *ALL the input that caused it to generate
that*

It's not like it will deterministically regenerate the same output.

>

No, someone using some REAL INTELEGENCE, as opposed to a program
using "artificial intelegence" that had been loaded with false
premises and other lies.

I specifically asked it to verify that its key assumption is
correct and it did.

No, it said that given what you told it (which was a lie)

I asked it if what it was told was a lie and it explained how what
it was told is correct.

"naw, I wasn't lied to, they said they were saying the truth" sure
buddy.
>

Because Chat GPT doesn't care about lying.

ChatGPT computes the truth and you can't actually show otherwise.

HAHAHAHAHA there isn't anything about truth in there, prove me wrong

>

Because what you are asking for is nonsense.
Of course an AI that has been programmed with lies might repeat the
lies.
When it is told the actual definition, after being told your lies,
and asked if your conclusion could be right, it said No.
Thus, it seems by your logic, you have to admit defeat, as the AI,
after being told your lies, still was able to come up with the
correct answer, that DDD will halt, and that HHH is just incorrect to
say it doesn't.

I believe that the "output" Joes provided was fake on the basis that
she did not provide the input to derive that output and did not use
the required basis that was on the link.

I definitely typed something out in the style of an LLM instead of my
own words /s
>

If you want me to pay more attention to what you say, you first need
to return the favor, and at least TRY to find an error in what I say,
and be based on more than just that you think that can't be right.
But you can't do that, as you don't actually know any facts about the
field that you can point to qualified references.

You cannot show that my premises are actually false.
To show that they are false would at least require showing that they
contradict each other.

Accepting your premises makes the problem uninteresting.

That seems to indicate that you are admitting that you cheated when you
discussed this with ChatGPT. You gave it a faulty basis and then argued
against that.

Just no. Do you believe that I didn't write this myself after all?
>

They also conventional within the context of software engineering. That
software engineering conventions seem incompatible with computer science
conventions may refute the latter.

lol
>

The a halt decider must report on the behavior that itself is contained
within seems to be an incorrect convention.

Just because you don't like the undecidability of the halting problem?
>

u32 HHH1(ptr P)  // line 721
u32 HHH(ptr P)   // line 801
The above two functions have identical C code except for their name.
>
The input to HHH1(DDD) halts. The input to HHH(DDD) does not halt. This
conclusively proves that the pathological relationship between DDD and
HHH makes a difference in the behavior of DDD.

That makes no sense. DDD halts or doesn't either way. HHH and HHH1 may
give different answers, but then exactly one of them must be wrong.
Do they both call HHH? How does their execution differ?
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
*It is a verified fact that*
>
(a) Both HHH1 and HHH emulate DDD according to the
semantics of the x86 language.

>
But HHH only does so INCOMPLETELY.
>

>
(b) HHH and HHH1 have verbatim identical c source
code, except for their differing names.

>
So? the fact the give different results just proves that they must have a "hidden input" thta gives them that different behavior, so they can't be actually deciders.
>
HHH1 either references itself with the name HHH1, instead of the name HHH, so has DIFFERENT source code, or your code uses assembly to extract the address that it is running at, making that address a "hidden input" to the code.
>
So, you just proved that you never meet your basic requirements, and everything is just a lie.
>

>
(c) DDD emulated by HHH has different behavior than
DDD emulated by HHH1.

>
No, just less of it because HHH aborts its emulation.
>
Aborted emulation doesn't provide final behavior.
>

>
(d) Each DDD *correctly_emulated_by* any HHH that
this DDD calls cannot possibly return no matter
what this HHH does.
>

>
No, it can not be emulated by that HHH to that point, but that doesn't mean that the behavior of program DDD doesn't get there.
>
Halt Deciding / Termination Analysis is about the behavior of the program described, and thus all you are showing is that you aren't working on either of those problems, but have just been lying.
>
>
Note, your argument is using a equivocation on the term "correctly emulated" as you are trying to claim a correct emulation by just a partial emulation, but also trying to claim a result that only comes from COMPLETE emulation, that of determining final behavior.
>
This again, just prove that you whole proof is based on lies.

>
I didn't hardly glance at any of that.
*This verified fact is a key element of my point*
>
When HHH1(DDD) emulates DDD this DDD reaches its final state.
When HHH(DDD) emulates DDD this DDD cannot possibly reach its
final state.
>

>
But HHH aborts its emulation, and to that point saw EXACTLY the same sequence of steps that HHH1 saw (or you have lied about them being identical and pure funcitons).
>

>
*That double talk dodges the point that I made*

>
>
What "Double talk"?
>
Your whole logic is just double talk.
>
You confuse your made up fanstay for reality and lock yourself into your insanity.
>

DDD emulated by HHH cannot possibly reach
its final state no matter WTF that HHH does.

>
There is your Equivocation again!
>
"Reaching Final State" is a property of the execution of complete emulation of a program.
>
So, since when we look at that for a DDD that calls an HHH that returns an answer, we find it reaches such a final state, your claim is just a blantant lie. Not just an honest mistake, as you have been told repeatedly the answer, but in your total stupidity reject the truth to keep your lies.
>

>
DDD emulated by HHH according to the semantics of the
x86 language cannot possibly reach its own "return"
instruction  matter WTF that HHH does.

>
Then your logic is just inconsistant as HHH can not be folling the semantic of the x86 language and then do "WTF".
>
For HHH to emulate its input in a way to show the actual behavior of that input, it must not EVER abort its emulation. PERIOD.
>
Your logic is just WTF, and based on the assumption that HHH can do two different things at the same time with the same code which is just a LIE,
>
>

>
When termination analyzers analyze C functions for
termination the measure of termination is reaching
the "return" statement.

>
Rigjt, when the BEHAIVIOR of the function is to do so, and that behavior is DEFINED to be the results of direct execution,

>
That is not DDD emulated by HHH according to the semantics
of the x86 language. That is DDD emulated by HHH1 according
to the semantics of the x86 language.

>
Depends on which of the equivocations you are meaning.
>
If we are talking about the behavior of the PROGRAM DDD.

>
In other words you are saying that DDD must be emulated
by HHH violating the semantics of the x86 language.

>
Where did I say that?
>

The directly executed DDD has the same behavior as
DDD emulated by HHH1 according to the semantics
of the x86 language.
>
The only way for DDD emulated by HHH to have this
same behavior (that includes DDD calling itself)
is to ignore the call to itself.
>

>
Nope, as "according to the semantics of the x86 language" is an OBJECTIVE standard, and thus the only meaning of behavior of "the call itself" is to look at what the x86 processor does on that call.

>
*That lame excuse tries to pretend that UTMs don't exist*

>
Nope. But UTMs will never abort their emulation of their input, or they are not a UTM.
>

>
You claimed that emulation is an incorrect basis
and I proved you wrong.
>
>

>
No, I said a PARTIAL emulation is an incorrect basis.
>

>
*This does not say that*
On 10/25/2024 7:27 AM, Richard Damon wrote:
 > Nope, as "according to the semantics of the x86 language" is an
 > OBJECTIVE standard, and thus the only meaning of behavior of "the call
 > itself" is to look at what the x86 processor does on that call.
>
This does reject emulation out-of-hand and forbids an x86
processor to emulate itself recursively as is required to
form the isomorphism to the halting problem.
>

>
Nope, the key is that *IF* you can show that the results of the emulation will match the behavior of the actual machine,

>
Then you can show that the emulation by HHH disobeys the
semantics of the x86 language:
>
When DDD is emulated by HHH according to the semantics of
the x86 language then HHH must emulate itself emulating DDD.
>

>
Right, and either it follows the rules of the x86 language and NEVER stop, or it disobeys the requirements of the x86 language to stop its emulaiton and return.
>

 In other words after all of these years you still don't get this:
    "simulating halt decider H correctly simulates its input D until"
 Repetition to help your ADD see what it keeps missing.
Repetition to help your ADD see what it keeps missing.
Repetition to help your ADD see what it keeps missing.

But it fails to meet the requirements, because your logic presumes that HHH will never abort.

 I have told you at least 500 times and your ADD forces you to never
see the *UNTIL*
 I have told you at least 500 times and your ADD forces you to never
see the *UNTIL*
 I have told you at least 500 times and your ADD forces you to never
see the *UNTIL*
 I have told you at least 500 times and your ADD forces you to never
see the *UNTIL*
 I have told you at least 500 times and your ADD forces you to never
see the *UNTIL*
 Repetition to help your ADD see what it keeps missing.
Repetition to help your ADD see what it keeps missing.
Repetition to help your ADD see what it keeps missing.
 

Maybe you should repeat to yourself 500 times.
HHH can not abort based on a condition that assumes that HHH does not abort.
Sorry, you are just proving your stupidity,