XPost: comp.theory
From: acm@muc.de
[ Followup-To: set ]
In comp.theory olcott wrote:
> On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
>> olcott wrote:
>>> On 7/21/2025 9:40 AM, Alan Mackenzie wrote:
>>>> olcott wrote:
>>>>> On 7/21/2025 4:06 AM, Mikko wrote:
>>>>>> On 2025-07-20 11:48:37 +0000, Mr Flibble said:
>>>>>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
>>>> [ .... ]
>>>>>>>> Your problem is you don't understand the meaning of the words you are
>>>>>>>> using.
>>>>>>> This is an ad hominem attack, not argumentation.
>>>>>> It is also honest and truthful, which is not as common as it should.
>>>>> It is also honest and truthful that people
>>>>> that deny verified facts are either liars
>>>>> or lack sufficient technical competence.
>>>> What you call "verified facts" are generally nothing of the kind. They
>>>> are merely things, often false, you would like to be true.
>>> *One key example of a denied verified fact is when Joes said*
>>> On 7/18/2025 3:49 AM, joes wrote:
>>>> very obvious that HHH cannot simulate
>>>> DDD past the call to HHH.
>> Joes is quite right, here, as has been said to you many times over by
>> several people.
>>> HHH(DDD) does emulate itself emulating DDD
>> You will have a get out clause from the vagueness of your language, which
>> could be construed to mean practically anything.
> typedef void (*ptr)();
> int HHH(ptr P);
> void DDD()
> {
> HHH(DDD);
> return;
> }
> int main()
> {
> HHH(DDD);
> }
> Not at all. HHH does emulate the x86 machine code
> of DDD pointed to by P. That is does this according
> to the semantics of the x86 language conclusively
> proves that this emulation is correct.
That's nauseatingly overstretching things into another lie. Whatever HHH
might do is far short of sufficient "conclusively to prove" that the
emulation is correct. To prove that is likely impossible in principle,
that's even assuming you could define "correct" coherently.
This continual hyperbole of yours is one of the things which establishes
your reputation as a liar.
> When this emulated DDD calls an emulated HHH(DDD)
> all of the code of this emulated DDD is in the same
> global memory space of Halt7.obj.
> Thus HHH(DDD) does begin emulating itself emulating
> DDD. It emulates itself emulating DDD until the
> emulated emulated DDD calls HHH(DDD) again.
> *This is all proven right here*
> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
> Because x86UTM is a multi-tasking operating system it
> enables the context switch between the emulator and
> the emulated.
> The x86utm operating system function DebugStep()
> on line 1638 enables this with its helper functions
> SaveState(emu, master_state); // Saves master process state
> LoadState(emu, (u32)slave_state); // Changes to slave process state
> https://github.com/plolcott/x86utm/blob/master/x86utm.cpp
>> But it is a lie to say
>> that "HHH(DDD) ... emulating DDD" is a verified fact. If I am mistaken
>> there, just say who has done the verification, how, and when.
> *The code has always proved this for several years*
Like I said, your saying "verified fact" is a lie. By it, you just mean
that you've written the code, therefore (in your opinion) it must be
correct.
Words mean things, and if you use a common phrase to mean something
different from its usual meaning with intention to deceive, you are
lying. That is what you are doing, here.
>>> After I have conclusively proven:
>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>>>> You frequently deny verified facts. You "deny" established definitions.
>>>> It has been established on this newsgroup that you have lied on it.
>>> That statement is libelous.
>> It might be libellous if it were false.
> That you won't even try to prove that it is
> true by finding a single time/date stamped
> quote of mine with any error in the essence
> of any of may claims provides a weight of evidence
> that I made no mistakes.
I have shown you to be a liar a few paragraphs above, where you have
mendaciously used "verified fact". Feel free to look up the time stamp
of this message if you really want it.
>>> No one can even point to a false statement that I made, thus cannot
>>> point to an intentionally false statement that I made.
>> I just pointed one out where you mendaciously state "One key example of a
>> ... verified fact is ...", and then citing something which wasn't a
>> verified fact.
> The code has proven it is a verified fact for several years.
Who has verified it, how much were they paid, and who by?
>> More seriously, you told Ben Bacarisse on this newsgroup that you had
>> fully worked out turing machines which broke a proof of the Halting
>> Theorem. It transpired you were lying. When the topic came up again for
>> discussion, you failed to deny writing the original lie.
> That is the closest thing to a lie that I ever said.
> When I said this I was actually meaning that I had
> fully operational C code that is equivalent to a
> Turing Machine.
I think it was a full blown lie intended to deceive. Did you ever
apologise to Ben for leading him up the garden path like that?
You have not and never have had "fully operational C code" that breaks a
proof of the Halting Theorem. To say you had this, when you clearly
didn't, was a lie.
>>> Feel free to cut-and-paste a time/date stamped quote
>>> of anything that I said that you have construed as false.
>> I've got better things to do with my time.
> If you call me a liar and cannot even point to a mistake
> that is libelous.
I've pointed out your whopper to Ben, and your falsely writing about
alleged verified facts.
That's enough justifiably to call you a liar.
>>>> Several times it has become apparent that your technical programming
>>>> competence leaves a lot to be desired.
>>> I did make one key mistake when referring to
>>> lines-of-code versus statements in C.
>> At one time you repeatedly posted the source code of a C function with a
>> syntax error in it, despite being repeatedly advised of this, and even
>> what the error was.
> Yes I did make these kind of mistakes that do
> not pertain to the essence of my claim:
They point to a certain lack of competence, a certain lack of attention
to detail which is essential to all computer programming.
> typedef void (*ptr)();
> int HHH(ptr P);
> int DD()
> {
> int Halt_Status = HHH(DD);
> if (Halt_Status)
> HERE: goto HERE;
> return Halt_Status;
> }
> int main()
> {
> HHH(DD);
> }
> The input to HHH(DD) specifies that DD simulated by
> HHH (according to the semantics of the C programming
> language) specifies a non-halting sequence of configurations.
> All rebuttals to this (including Ben's) have been
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
