Re: And the Richer Petard Horror Show resumes ...

On 10/9/24 4:40 PM, olcott wrote:

On 10/9/2024 2:34 PM, Alan Mackenzie wrote:

Richard Damon <richard@damon-family.org> wrote:

On 10/8/24 8:49 AM, Andy Walker wrote:

... after a short break.

>

      Richard -- no-one sane carries on an extended discussion with
someone they [claim to] consider a "stupid liar".  So which are you?
Not sane?  Or stupid enough to try to score points off someone who is
incapable of conceding them?  Or lying when you describe Peter?  You
must surely have better things to do.  Meanwhile, you surely noticed
that Peter is running rings around you.

>

In other words, you don't understand the concept of defense of the truth.

>
Maybe, but continuously calling your debating opponent a liar, and doing
so in oversized upper case, goes beyond truth and comes perilously close
to stalking.  It detracts from the substance of your posts,

 His posts never have any actual substance.

No, you just don't understand the substance of them.
YOURS don't have substance, as you just repeat you DISPROVEMN statement.
Sorry, you are just proving that you are a stupid liar.
IF you want to show that you are making an answer with "substance" you will answer the point below, failure to do so (which is what I expect) is just further proof that you KNOW you have no basis, and are just trying to bull though your idea based on just repeating your lies.

 My posts do have substance yet people have made up their
minds and closed them so they never notice.

Really? What substance have you added in the last week, other than just repeating your same lies?

 void DDD()
{
   HHH(DDD);
   return;
}
 One cannot simply ignore the actual behavior specified by the
finite string x86 machine language of DDD such that

Right, and that is that you say that HHH(DDD) return 0.
If it does, then HHH can not be correct in its determination that it doesn't retrun.
Your logic is bsed on a LIE, (or more likely several lies), you get to choose from one or more of the followijg
1) A program is DEFINED as the fully defined set of instruction that it will execute, and thus your "finite string" above is NOT sufficient to define what the program input DDD is.
This means that either:
1A) You are just lying that you are working on the halting problem, as that is based on deciding about the behavior of programs, and if the input to HHH isn't actually a description of a program, if can't be a halt decider.
1B) The input you are giving HHH, isn't just what you are showing, but actually includes the full code of DDD + HHH and everything it calls, either as a source form, or when we look at the actual implementation, we see it is the compiled version, and thus the input can't be just the bytes of the C function DDD but the full memory image. Note, if this is true, you are not allowed to change those bytes in your hypotheticals, as that changes your input, but your logic says you are, so you must eitehr be doing line 1A and not givi9ng a program, or a lie 1B and changing the input in your logic.
2) A Halt decider is DEFINED to be answering about the behavior of the PROGRAM, which is the results of the direct exection of the code, of by the principle of a UTM, a complete and correct simulation of that machine.
2A) Your wording you talk about is the behavior of "DDD emulated by HHH not returning"
To match the defintion above, this MUST mean the full behavior of the program DDD given to HHH, which has been show to actually reach that final return, just after the point that the HHH that emulates its copy of the program has halted its emulation.
By this interpretation, you are just lying that DDD doesn't return when HHH returns 0. PERIOD.
2B) If you deny that interpreation, and say that you mean by that expression that HHH is correct because HHH can not emulate the input to the end, then you are lying again that you are working on the halting problem, because it does NOT talk about the results of partial emulations, and since that is what any HHH that answer does, that is just demonstrating that you are lying about the problem (or the correctness of the answer) that you claim to be working on.
If HHH is actually a Halt Decider, then HHH(DDD) returning 0 can only be correct if the direct execution of DDD() never return, and any other attempted meaning is just BY DEFINITION a lie.
(But then you never seemed to understand what a definition is)
3) A Halt Decider, by definition, must be performing a computation, a concept you don't seem to understand, but a close approximation is that ALL copies of the decider must always return the same answer when given the same input. This is close to the idea you sort of understand of a pure function (but rather than being a limitation of how, but a limitation on the results).
Looking at the code you have for HHH, it does NOT meet that requriement in the way you have implemented it, because HHH checks if it is the "top level" decider, and only the top level decider does the actual checking. Because of this, your code for HHH actually fails to meet the requirements of being the code for a decider, but since your decider actually seems to ignore what the emulated version of HHH actually does it never reaches the point.
I will agree this doesn't matter, UNLESS you try to argue that if you somehow got the outer HHH to not abort its emulation that DDD wouldn't halt because its version of HHH behaved differently due to that hidden state input.
Thus, Either you are lying about HHH being a computation, or you are lying that the DDD that calls the original from of HHH(DDD) while being emulated by the altered form of HHH returns, because it will if that error is fixed.

 DDD emulated by each corresponding HHH that can possibly exist
never returns

Sure it does, as has been explained many times but seems to be above your head.
This just shows that you are, in fact, doing lie 2B

 thus each of the directly executed HHH emulators that does return
0 correctly reports the above non-terminating behavior for its input.

Nope, since if HHH returns 0, then it returns 0 to the DDD that was paired with it and thus is calling that exact same HHH, so it will behave the sa,me.
A fact you have agreed to be refusing to point to the actual instruction that difffered in the execution path.

 https://github.com/plolcott/x86utm x86utm operating system
 

and makes
them, for me at least, thoroughly unpleasant to read.  Although I only
occasionally post on comp.theory, I still lurk.  Most of your posts I
merely skim over or leave wholly unread for the above reason.  Please
consider returning to a more civil way of posting, even when replying to
Peter Olcott.
>
[ .... ]
>