From Newsgroup: comp.ai.philosophy

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 7/21/2025 10:52 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 7/21/2025 9:40 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> 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
the strawman error of referring to the behavior of the
directly executed DD().

And your lack of care for the truth will not acknowledge that, by
definition, a simulation of a program has the same behaviour as the
original program. Everybody but you appears to know this.

It is common knowledge that directly executed Turing
machines are outside of the domain of Turing machine
deciders. This means that no Turing machine decider
can ever directly report on the behavior or any directly
executed Turing machine.

That's vague waffle. A universal turing machine does indeed report on
the behaviour of its input program if so designed. If that input program
is the same as the "directly executed turing machine" (whatever you might
mean by that), the UTM will report on the behaviour of the latter.

The best that they can do is use a machine description
as a proxy for the behavior of the direct execution.

Your lack of power of abstraction is leading you astray, here.

When HHH(DD) computes the mapping *from its input* to
the behavior that this input specifies it correctly
determines that the recursive simulation that this
input specifies is non-halting behavior.

This has been comprehensively dealt with by other posters on this group.

Consistent honesty and truthfulness is what I have hoped for from you for >>>> a long time, now. With it, we could have a productive exchange of views. >>>> I doubt we will ever see this, though.

I would love to have this with you. I have initially
assessed that you may be very competent.

You may take it that I fully competent in C programming, amongst other
things.

Do you have at least a decade of full time experience at this?

I have nearer 40 years experience than a decade.

Its not that hard to determine that DD simulated by HHH
(according to the semantics of the C programming language)
specifies the non halting behavior of recursive simulation.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--
Alan Mackenzie (Nuremberg, Germany).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 7/21/2025 5:56 PM, Richard Damon wrote:

On 7/21/25 5:49 PM, olcott wrote:

On 7/21/2025 3:58 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory olcott <polcott333@gmail.com> wrote:

On 7/21/2025 10:52 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

On 7/21/2025 9:40 AM, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> 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.

[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

Which isn't a program, you need to include the code for HHH.

*Yet again your attention deficit disorder*
I have told you countless times that all of
the machine code for every function is in
the same global memory space of halt7.obj.

I have also told you countless times that HHH
does simulate itself simulating DDD and I
have proven this by this execution trace.

https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That you don't know how to read an execution
trace does not mean that I have not proven this.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 7/21/2025 3:58 PM, Alan Mackenzie wrote:

In comp.theory olcott <polcott333@gmail.com> wrote:

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.

_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]

To prove (beyond all possible doubt) that HHH
does emulate DDD correctly only requires that
each instruction of DDD is emulated according
to the meaning of that instruction.

When HHH emulates the instruction at machine address
00002192 and it emulates DDD pushing its own ebp onto
its own stack this is proof that this instruction was
emulated correctly. If instead HHH emulated: "push ebp"
as "jmp 000021a3" that would be an incorrect emulation.

What exactly did you mean by "likely impossible in principle"
(please it all over again using different words).

I could make this proof more detailed by providing
the full state of the DDD virtual machine before
and after each emulated instruction.

line 1444 SaveState() Saves 16 register values
line 1469 LoadState() Loads 16 register values

line 1638 DebugStep()
Switch process context from emulator to emulated
Emulate one slave instruction
Switch process context from emulated back to emulator

https://github.com/plolcott/x86utm/blob/master/x86utm.cpp
--
Copyright 2024 Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2