On 10/9/24 4:40 PM, olcott wrote:
On 10/9/2024 2:34 PM, Alan Mackenzie wrote:
Richard Damon <[email protected]> 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.
[ .... ]
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)