Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How a PhD computer scientist lied about my work

43 views
Skip to first unread message

olcott

unread,
Nov 8, 2022, 11:28:14 PM11/8/22
to
void D(void (*x)())
{
H(x, x);
}

If H simulates D would D(D) ever stop running ?
(a simpler version the next question).

If H simulates D would the simulated D ever stop running without being
aborted?

He said "yes" and I said "no".

The above is the exact question that the PhD computer scientist seems to
have lied about yet it was applied to this computationally equivalent C
function:

void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}

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

wij

unread,
Nov 9, 2022, 6:42:36 AM11/9/22
to
On Wednesday, November 9, 2022 at 12:28:14 PM UTC+8, olcott wrote:
> void D(void (*x)())
> {
> H(x, x);
> }
>
.... [Cut]
>
> void D(void (*x)())
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>

D will be trapped in endless recursive call. D will never halt.
LOOK CLOSE: D will never halt is because H will never halts, either.
The correct simulation won't have chance to 'abort'.
No matter what H does, D can also SEE it, that is 'simulation'.

You purposefully made your POOH to 'abort' is illusion you made.
By doing this, POOH becomes a program that halts, not really a halt decider.

olcott

unread,
Nov 9, 2022, 9:33:28 AM11/9/22
to
On 11/9/2022 5:42 AM, wij wrote:
> On Wednesday, November 9, 2022 at 12:28:14 PM UTC+8, olcott wrote:
>> void D(void (*x)())
>> {
>> H(x, x);
>> }
>>
> .... [Cut]
>>
>> void D(void (*x)())
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>>
>
> D will be trapped in endless recursive call. D will never halt.

The lying PhD computer scientist says that D halts without having its
simulation aborted.

> LOOK CLOSE: D will never halt is because H will never halts, either.
> The correct simulation won't have chance to 'abort'.
> No matter what H does, D can also SEE it, that is 'simulation'.
>
> You purposefully made your POOH to 'abort' is illusion you made.
> By doing this, POOH becomes a program that halts, not really a halt decider.

Paul N

unread,
Nov 9, 2022, 9:34:02 AM11/9/22
to
On Wednesday, November 9, 2022 at 4:28:14 AM UTC, olcott wrote:
> void D(void (*x)())
> {
> H(x, x);
> }
>
> If H simulates D would D(D) ever stop running ?
> (a simpler version the next question).
>
> If H simulates D would the simulated D ever stop running without being
> aborted?
>
> He said "yes" and I said "no".

We've been through this many times before. If H has no means to abort then of course it will not stop running. If H does have means to abort, then a correct simulation of D will include a correct simulation of H which will include the aborting mechanism. It may be that the outer H spots that the inner, simulated H would abort, and thus the outer H can report halting without itself having to abort anything. It all depends on the details of the aborting mechanism, which can never be made flawless as previously explained.

> The above is the exact question that the PhD computer scientist seems to
> have lied about yet it was applied to this computationally equivalent C
> function:

Interesting that you assume that anyone, no matter how august they are, must be lying if they disagree with you.

> void D(void (*x)())
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }

This is a very simple function and you know enough C to know that it will do the opposite of what H predicts it will. Stop pretending you don't know this.

olcott

unread,
Nov 9, 2022, 9:52:34 AM11/9/22
to
On 11/9/2022 8:34 AM, Paul N wrote:
> On Wednesday, November 9, 2022 at 4:28:14 AM UTC, olcott wrote:
>> void D(void (*x)())
>> {
>> H(x, x);
>> }
>>
>> If H simulates D would D(D) ever stop running ?
>> (a simpler version the next question).
>>
>> If H simulates D would the simulated D ever stop running without being
>> aborted?
>>
>> He said "yes" and I said "no".
>
> We've been through this many times before. If H has no means to abort then of course it will not stop running. If H does have means to abort, then a correct simulation of D will include a correct simulation of H which will include the aborting mechanism. It may be that the outer H spots that the inner, simulated H would abort, and thus the outer H can report halting without itself having to abort anything. It all depends on the details of the aborting mechanism, which can never be made flawless as previously explained.

The outer H cannot wait for an inner H to abort because that means that
every H would always be waiting on the next inner H to abort thus no H
ever gets around to actually aborting.

The PhD computer scientist disagrees that the correctly simulated D
would never stop running without having its simulation aborted.

>
>> The above is the exact question that the PhD computer scientist seems to
>> have lied about yet it was applied to this computationally equivalent C
>> function:
>
> Interesting that you assume that anyone, no matter how august they are, must be lying if they disagree with you.
>
>> void D(void (*x)())
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status)
>> HERE: goto HERE;
>> return;
>> }
>
> This is a very simple function and you know enough C to know that it will do the opposite of what H predicts it will. Stop pretending you don't know this.

It is a very simple function such that the correctly simulated D cannot
possibly reach any return value from H:
(a) Remains in infinitely recursive simulation and never reaches the
return value from H
(b) Has its simulation aborted and never reaches the return value from H.

olcott

unread,
Nov 9, 2022, 1:39:12 PM11/9/22
to
On 11/9/2022 5:42 AM, wij wrote:
Many people that are unfamiliar with the halting problem fail to
understand that halting means reaches its own last instruction and
terminates normally. When you pull the plug on a computer that is stuck
in an infinite loop this loop does not terminate normally.

wij

unread,
Nov 9, 2022, 2:44:22 PM11/9/22
to
On Thursday, November 10, 2022 at 2:39:12 AM UTC+8, olcott wrote:
> On 11/9/2022 5:42 AM, wij wrote:
> > On Wednesday, November 9, 2022 at 12:28:14 PM UTC+8, olcott wrote:
> >> void D(void (*x)())
> >> {
> >> H(x, x);
> >> }
> >>
> > .... [Cut]
> >>
> >> void D(void (*x)())
> >> {
> >> int Halt_Status = H(x, x);
> >> if (Halt_Status)
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >
> > D will be trapped in endless recursive call. D will never halt.
> > LOOK CLOSE: D will never halt is because H will never halts, either.
> > The correct simulation won't have chance to 'abort'.
> > No matter what H does, D can also SEE it, that is 'simulation'.
> >
> > You purposefully made your POOH to 'abort' is illusion you made.
> > By doing this, POOH becomes a program that halts, not really a halt decider.
> Many people that are unfamiliar with the halting problem fail to
> understand that halting means reaches its own last instruction and
> terminates normally. When you pull the plug on a computer that is stuck
> in an infinite loop this loop does not terminate normally.

"halting means a program reaches its own last instruction" means the last
instruction EXECUTED by CPU (ret instruction, normally), not 'decided' by simulator.

Check your case with the following program to see whether or not H and D halt.

void main() {
int r;
r=H(D,D); print(r);
D(D);
}

You should find H can never correctly decide whether D halts or not.
This is like the Liar's Paradox you should be familiar with.

olcott

unread,
Nov 9, 2022, 2:55:44 PM11/9/22
to
That is not the question that I asked.

void D(void (*x)())
{
H(x, x);
}

Does D correctly simulated by H stop running without having its
simulation aborted?

wij

unread,
Nov 9, 2022, 3:27:50 PM11/9/22
to
From the context I said, D is NOT RUNNING but is simulated.
Your simulation can abort or not abort as you wish. Correct or not is whatever you say.
If you say yes, the answer is YES. If you say no, the answer is NO.

-----
As said, try the following program to know the final answer whether or not H and D halt.
You need first to understand what "a program halt" means to tackle the HP.

void main() {
int r;
r=H(D,D); print(r);
D(D);
}

olcott

unread,
Nov 9, 2022, 3:48:36 PM11/9/22
to
H correctly simulates its input D until H correctly
determines that its simulated D would never stop running
unless aborted

Jeffrey Rubard

unread,
Nov 9, 2022, 5:29:18 PM11/9/22
to
"This is a hoax, right? You're 'mocking' other crackpots?"

Richard Damon

unread,
Nov 9, 2022, 8:23:34 PM11/9/22
to
On 11/9/22 9:33 AM, olcott wrote:
> On 11/9/2022 5:42 AM, wij wrote:
>> On Wednesday, November 9, 2022 at 12:28:14 PM UTC+8, olcott wrote:
>>> void D(void (*x)())
>>> {
>>> H(x, x);
>>> }
>>>
>>   .... [Cut]
>>>
>>> void D(void (*x)())
>>> {
>>> int Halt_Status = H(x, x);
>>> if (Halt_Status)
>>> HERE: goto HERE;
>>> return;
>>> }
>>>
>>
>> D will be trapped in endless recursive call. D will never halt.
>
> The lying PhD computer scientist says that D halts without having its
> simulation aborted.

So, which H is actually your H.

If it is the one that aborts, then YOU have just lied, because the
direct execution of D WILL Halt because H aborts its simulation of the
representation of D that it was given. So YOU are the one guilty of the lie.

You are just showing that you just don't understand what a computer or a
program is.

A given program, like the H of the proof, is a SPECIFIC sequence of
instructions that are executed on specific inputs.

H is SUPPOSED to be answer about the behavior of the program and input
it has been given in its input.

H(D,D) is SUPPOSED to be answering if D(D) will Halt or not.

The fact that H(D,D) returns 0, say that it beleives that D(D) will
never return,

That D is using an EXACT COPY of the H that is answering if you followed
the requirments of the proof, so if the direct execution of H(D,D)
returns 0, so will the copy that D calls.

Yes, H in its simulation will NEVER get to that point, but that is
because this H gives up and aborts too soon.

To confuse things by looking at a DIFFERENT program, that you
DECEPTIVELY also try to call H that doesn't abort, and the input basd on
that OTHER H that you DECEPTIVELY also call D, means NOTHING about the
behavior of THIS H and THIS D.

You confusing of these two just proves your ignorance of the subject.

Note, you also show your ignorance by the misuse of words like "unless".
Programs do NOT act on the bases of "unless" as unless brings into view
behavior that hasn't actually happened.

Your logic has been fundamentally flawed for year because you do not
understand the basics of what you are talking about.

One key thing is that you don't understand that Turing Machines are the
equivalent of a PROGRAM, not a FUNCTION in "normal" programming. It is
true that all programs are effectively functions, but the key is that
all functions are NOT effectively programs, and your logic runs into
that problem, because you are trying to look at a given function in a
way that ISN'T how it would behave as a program.

Your analysis of H_Hat/P/D is trying to sepereate the "C Function" from
the program it actually represents since you remove the H that it calls
from its definition.

THAT JUST PROVES YOUR IGNORANCE OF THE DEFINITIONS.

Your inability to understand this has cause you to totally waste the
last 18 years of your life and apparenetly condemned you to leave a
legacy of being an idiot.

Since P(P)/D(D) will Halt if H(P,P)/H(D,D) return 0, that answer can NOT
be the correct answer for that Halting problem.

That answer is NOT based on a correct determination of the correct
simulation (as done by H), as the ONLY possible correct simulation of
this input must match the actual behavior which is Halting, so the only
correct determination of a correct simulation of this input is Halting.
If H doesn't actually DO such a correct simulation, than any criteria
based on it needing to do one is just invalid and illogical.

Your logic is based on looking at a INCORRECT version of the input, as
you change the H that the input calls, which means you are just LYING
about what you are doing.

This seems to be your natural tendency, you can't seem to actually tell
a true statement, but always put a twist on things to bend them. This is
the sign of a deciver.

Sorry, you are just wrong,

As to your comment on "pulling the plug"

Well, when you simulate the input that you claim you are doing, (the one
where P/D call the H that returns 0) then if we don't pull the plug, it
will finish. What you are doing is having your H pull the plug before it
gets there and claim it can't tell the difference between this program
and a DIFFERENT one that is admittadly non-halting, and claiming it must
be right.

H's inability to distinguish between two DIFFERENT inputs that behave
DIFFERENTLY doesn't make it right, but makes it IGNORANT, just like you.

You have shown an inability to tell the difference between things that
are different, because you are to inattentive to see the differences.
Just because they seem the same to you, doesn't mean they are, it just
shows you are worng. The fact that you seem to try to hide the
difference seems to imply it isn't just you being inattentive, but
actively deceptive.

olcott

unread,
Nov 9, 2022, 8:28:25 PM11/9/22
to
On 11/9/2022 7:23 PM, Richard Damon wrote:
> On 11/9/22 9:33 AM, olcott wrote:
>> On 11/9/2022 5:42 AM, wij wrote:
>>> On Wednesday, November 9, 2022 at 12:28:14 PM UTC+8, olcott wrote:
>>>> void D(void (*x)())
>>>> {
>>>> H(x, x);
>>>> }
>>>>
>>>   .... [Cut]
>>>>
>>>> void D(void (*x)())
>>>> {
>>>> int Halt_Status = H(x, x);
>>>> if (Halt_Status)
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>
>>> D will be trapped in endless recursive call. D will never halt.
>>
>> The lying PhD computer scientist says that D halts without having its
>> simulation aborted.
>
> So, which H is actually your H.
>
> If it is the one that aborts, then YOU have just lied, because the
> direct execution of D WILL Halt because H aborts its simulation of the
> representation of D that it was given. So YOU are the one guilty of the
> lie.
void D(void (*x)())
{
H(x, x);
}

Of the infinite set of H/D pairs none of them ever stops running unless
H aborts the simulation of its input.

Richard Damon

unread,
Nov 9, 2022, 9:45:29 PM11/9/22
to
Except that the Halting Problem isn't about "sets" of programs but about
specific programs.

The infinite set your refer to has no member that shows that the H that
answers H(D,D) with 0 for the D built on it is correct, because the only
member of that set that looks at the input is this H that aborts its
simulation, thus the "unless" is meaningless.

NO ONE thinks you are right, unless they are you.

You are just showing your ignorance of what you are talking about.

You are just showing that you don't understand what a computer is or
what a program is.

It is a simple fact that if H(D,D) returns 0, for the D built on it,
that this D(D) when actually run will halt and thus H was incorrect.

Remember, the DEFINITION of a CORRECT simulation is one that matchs the
behavior of its input when actually run. Even you have agreed that this
D(D) does actual halt when run, you just think that, despite the
definition of what a correct simulation actually means, that it can be
different.

If you think it is possible, please point out the first ACTUAL x86
instruction that the behavior of the "Correct Simulation" of this input
will differ from the actual direct execution of the program would be.

Note, ACTUAL x86 instruction, not well it calls H which does ... so it
will not return, that is NOT "correct simulation", but is actually just
INCORRECT ANALYSYS. Your claim is about correct x86 simulation, so you
need to show the ACTUAL SIMULATION of the x86 instruction showing your
claimed difference.

This has been asked of you before, and your failure to show the actual
difference just shows that you have been lying. You will undoubtably
evade pointing out how you claim is supported, just furthering the proof
that you whole arguement is based on lies from twisting statements.

You are just wrong, and you lies have been reviled. You will be know
forever as the man who was ignorant about what he claimed. The man that
illustrated the concept of being a Legend in his own mind.

YOU FAIL.

olcott

unread,
Nov 9, 2022, 9:57:24 PM11/9/22
to
Sure it is. The halting problem proof is supposed to show that there
does not exist an a Turing machine H that can correctly determine the
halt status of every element of the set of Turing machine descriptions.

You didn't even get the learned-by-rote level of understanding correctly.

Richard Damon

unread,
Nov 9, 2022, 10:07:14 PM11/9/22
to
Your just showing your ignorance.

Yes, the proof is showing that the SET of correct Turing Machines is
emty, byt showing that there does not exist any individual machine meets
the requirements, but the problem itself is asking about the ability to
produce a SPECIFIC example.

Your proof does't actually refer to any individual Turing Machine, but
talks about a set of machine that gets the right answer, that is
actually an empty set.

You need to show that some element of your set exists that gets the
right answer.

You set just shows that you can make machines that are non-halting that
eleents of your set don't decide on, not what is needed.

You are just proving your ignorance of how set theory works,

Youy failure to show how a correct simulation can differ from the ACTUAL
execution, a key point of your proof, just reinforces that you are just
too stupid to see your errors.

YOU FAIL.

olcott

unread,
Nov 9, 2022, 10:13:51 PM11/9/22
to
I have had enough of your dishonest bullshit. goodbye

Richard Damon

unread,
Nov 9, 2022, 10:51:14 PM11/9/22
to
Projection.

You are just admitting you don't have an answer for my objections.

This is proven by the fact that you haven't answered them, which if you
were actually right, you would want to show it.

YOU FAIL.

Mr Flibble

unread,
Nov 10, 2022, 10:05:11 AM11/10/22
to
What about your dishonest bullshit claiming my category error isn't a
category error?

/Flibble

olcott

unread,
Nov 10, 2022, 10:20:28 AM11/10/22
to
You are not dishonest, just confused.
A category error describes an impossible event.
If we said that the input to the halt decider was 15 city zoos then we
have a category error because input can only be finite strings.

Mr Flibble

unread,
Nov 10, 2022, 12:08:20 PM11/10/22
to
I am not confused as I know what a category error is; the problem here
is that YOU are confused as the only category error examples you can
think of are childish at best, you cannot see how self reference in the
halting problem proofs is a subtle category error.

/Flibble


olcott

unread,
Nov 10, 2022, 2:17:58 PM11/10/22
to
A category error is always an impossible event and it is not impossible
for D to call its own simulator H with the machine description of D.

It is impossible for D to call H with a truckload of elephants, that is
a category (AKA type mismatch) error.

A category error is a kind of type mismatch error.
When a halt decider has as its input an English poem then the question
does this English poem halt? is a type mismatch (thus category) error.

When we rephrase the question:
Does this English poem represent a Turing machine that halts?
Then the category error is abolished and the answer is: "no".

Mr Flibble

unread,
Nov 10, 2022, 4:33:20 PM11/10/22
to
On Thu, 10 Nov 2022 13:17:53 -0600
The self reference is a category error: the fact that you have to ABORT
your simulation is further evidence that a category error exists.

/Flibble


olcott

unread,
Nov 10, 2022, 6:50:25 PM11/10/22
to
A simulating halt decider must always abort its simulation of every
non-halting input including an ordinary infinite loop.
0 new messages