From Newsgroup: comp.ai.philosophy

On 7/22/2025 2:58 PM, Alan Mackenzie wrote:

olcott <NoOne@nowhere.com> 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:

[ .... ]

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]

x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.

When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.

*That is a 100% concrete example of correct emulation*

Which appears to be beside the point.

Exactly how is it that you could have construed this
as impossible in principle?

You seem to be "proving" the correctness of your emulation by giving one example of its execution and saying "because it works for this particular case, it works in general".

It is as though you are testing a multiplication program and give it the inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly. Actually, what you were testing turned out to be an addition program.

You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs. This is impossible in principle. And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.

It is certainly not impossible in principle
to prove that DDD is correctly emulated by HHH.

I claim that it is proved that DDD is correctly
emulated by HHH and your rebuttal totally changes
the subject. This strawman deception is the primary
form of every fake rebuttal of my work.

There have been zero correct rebuttals of any
detail of the essence of my work. Not one person
can point to any correct rebuttal of the essence
of my work in the last three years.

The fact that HHH(DD) rejects its input as non-halting
never was contradicted by the fact that the directly
executed DD() halts. It only seemed that way because
no one ever bothered to notice:

(a) Turing machine deciders only take finite
string inputs they never take directly executing
Turing machines as inputs.

(b) Turing machine deciders only compute the mapping
from their inputs on the basis of the behavior
specified by these inputs.

(c) When the input to a Turing machine decider
calls this same decider then the behavior of the
direct execution and the correct simulation diverge.

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

HHH(DD)==0 even though DD() halts.
--
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

From Newsgroup: comp.ai.philosophy

On 7/23/25 10:44 PM, olcott wrote:

On 7/22/2025 2:58 PM, Alan Mackenzie wrote:

olcott <NoOne@nowhere.com> 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:

[ .... ]

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]

x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.

When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.

*That is a 100% concrete example of correct emulation*

Which appears to be beside the point.

Exactly how is it that you could have construed this
as impossible in principle?

You seem to be "proving" the correctness of your emulation by giving one
example of its execution and saying "because it works for this particular
case, it works in general".

It is as though you are testing a multiplication program and give it the
inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly.
Actually, what you were testing turned out to be an addition program.

You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs.  This is impossible in principle.  And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.

It is certainly not impossible in principle
to prove that DDD is correctly emulated by HHH.

Sure it is, since it doesn't.

I claim that it is proved that DDD is correctly
emulated by HHH and your rebuttal totally changes
the subject. This strawman deception is the primary
form of every fake rebuttal of my work.

The problem is "your proof" is based on false statements and lies.

There have been zero correct rebuttals of any
detail of the essence of my work. Not one person
can point to any correct rebuttal of the essence
of my work in the last three years.

Sure there have been, you are just too stupid to understand them,
startng with the fact that you create multiple definitions of what "HHH" actually is.

The fact that HHH(DD) rejects its input as non-halting
never was contradicted by the fact that the directly
executed DD() halts. It only seemed that way because
no one ever bothered to notice:

(a) Turing machine deciders only take finite
string inputs they never take directly executing
Turing machines as inputs.

Right,

(b) Turing machine deciders only compute the mapping
from their inputs on the basis of the behavior
specified by these inputs.

And that BEHAVIOR is DEFINED to be the behavior of the Turing Machine
that it represents.

(c) When the input to a Turing machine decider
calls this same decider then the behavior of the
direct execution and the correct simulation diverge.

Nope, just your lie.

Since you can't show the step actually correctly simulated where they
diverge, and refuse to even try, you are admitting that you know you are lying.

Trying to say that the call HHH(DDD) instruction does something other
that what the instruction does is just an admittion that you know you
are lying.

Either it is followed by the actual code of HHH running, and the
simulation continues to the end, or you compress it into the ACTUAL
behavior of HHH(DDD) which is to return 0 (but HHH doesn't know that
yet, so you need someting like the Flibble method to look at this)

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

HHH(DD)==0 even though DD() halts.

In other words, you think LIES are valid logic.

And you just don't understand how logic works.


By your logic, Trump is ligitamately GOD of this world and can do
anythi9ng he wants, and people are responsible for climate change.

Sorry, that *IS* the result of accepting your form of logic, no matter
what you think you can claim.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.ai.philosophy

On 7/24/25 11:13 PM, olcott wrote:

On 7/22/2025 2:58 PM, Alan Mackenzie wrote:

olcott <NoOne@nowhere.com> 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:

[ .... ]

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]

x86utm is a multi-tasking operating system (that I wrote)
that allows any C function to execute any other C function
in debug step mode. HHH and DDD have their own virtual
registers and stack.

When HHH emulates the first instruction of DDD it
emulates pushing the DDD ebp base pointer onto the
DDD stack.

*That is a 100% concrete example of correct emulation*

Which appears to be beside the point.

Exactly how is it that you could have construed this
as impossible in principle?

You seem to be "proving" the correctness of your emulation by giving one
example of its execution and saying "because it works for this particular
case, it works in general".

It is as though you are testing a multiplication program and give it the
inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly.
Actually, what you were testing turned out to be an addition program.

You can never prove a program is correct just by getting correct results
from a single run of it, or even correct results from several or many
runs.  This is impossible in principle.  And as I wrote earlier, that
even supposes that you can define "correct" coherently and usefully.

It is certainly not impossible in principle
to prove that DDD is correctly emulated by HHH.

Sure it is impossilbe, as HHH doesn't correctly emulate DDD, and you
can't actually prove a false statement, not unless your system has gone inconsistant.

I claim that it is proved that DDD is correctly
emulated by HHH and your rebuttal totally changes
the subject. This strawman deception is the primary
form of every fake rebuttal of my work.

Yes, you claim it, but can't actually prove it.

The problem is you keep on trying to introduce false statements in your
proof.

There have been zero correct rebuttals of any
detail of the essence of my work. Not one person
can point to any correct rebuttal of the essence
of my work in the last three years.

Sure there have been correcxt rebuttals. You just don't believe them in
your stupidity.

The fact that HHH(DD) rejects its input as non-halting
never was contradicted by the fact that the directly
executed DD() halts. It only seemed that way because
no one ever bothered to notice:

Sure it is. Since that is what the DEFINITION of a Halt Decoder is to
decide on.

All you are doing is showing that you have lied by trying to interject a strawman.

(a) Turing machine deciders only take finite
string inputs they never take directly executing
Turing machines as inputs.

But finite strings CAN be representations of Turing Machines, and thus
specify there direct execution.

(b) Turing machine deciders only compute the mapping
from their inputs on the basis of the behavior
specified by these inputs.

And that behavior can be based on what the string is a representation of.

In this case, the actual Turing Machine and the behavior it performs.

(c) When the input to a Turing machine decider
calls this same decider then the behavior of the
direct execution and the correct simulation diverge.

Nope, can't be, as the definition of correct simulation is to EXACTLY reproduce what the input specifies, and that is the behavior of the
direct execution of the machine it represents.

All you are doing is admitting that you are working on a false strawman,
and your repeated use of it shows you just have straw for brains.

It seems you just don't understand the meaning of "correct", just like
you don't understand the meaning of a lot of words you abuse like:
Truth, Program, Halting, Logic, ...

int DD()
{
  int Halt_Status = HHH(DD);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

HHH(DD)==0 even though DD() halts.

Nope. just prove that you are a stupid and ignorant pathetic
pathological liar because you don't know the definitions of the thing
you are talking about.
--- Synchronet 3.21a-Linux NewsLink 1.2