Monday, July 11, 2022

Digest for comp.lang.c++@googlegroups.com - 14 updates in 4 topics

olcott <NoOne@NoWhere.com>: Jul 10 08:54PM -0500

After very extensive discussions (23 emails) with a leading computer
scientist I have a much simpler way to make my point.
 
typedef void (*ptr)();
 
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
 
int main()
{
Output("Input_Halts = ", H(P, P));
}
 
*H and P implement this pathological relationship*
For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts P will do. No H can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
 
All of the conventional proofs of the halting problem (including the
diagonalization proof) correctly prove that H cannot possibly return a
correct halt status to its caller P.
 
None of these proofs ever notice that when H is a simulating halt
decider it cannot possibly correctly return any value to the simulated P
because no function that is (essentially) called in infinite recursion
ever returns to its caller.
 
This provides the basis for H(P,P) to correctly determine that its
correct and complete simulation of its input would never reach the final
state of this simulated input, thus never halts.
 
*Once this halt deciding principle is accepted*
A halt decider must compute the mapping from its inputs to an accept or
reject state on the basis of the actual behavior that is actually
specified by these inputs.
 
*Then this method is understood to implement that principle*
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never reach its
final state, correctly rejects this input as non-halting.
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Juha Nieminen <nospam@thanks.invalid>: Jul 11 09:20AM

> After very extensive discussions (23 emails) with a leading computer
> scientist I have a much simpler way to make my point.
 
At least you seem to be willing to engage in *some* kind of conversation
with experts on the matter.
 
I would still say that you could get much better feedback to your work
if you did all these posts in a forum dedicated to computer science and
mathematics with an active community of expects, rather than here in
some random usenet group (especially since usenet is almost dead, and
has been for over a decade).
Muttley@dastardlyhq.com: Jul 11 09:41AM

On Mon, 11 Jul 2022 09:20:09 -0000 (UTC)
>> scientist I have a much simpler way to make my point.
 
>At least you seem to be willing to engage in *some* kind of conversation
>with experts on the matter.
 
Its probably a friend of his.
 
>mathematics with an active community of expects, rather than here in
>some random usenet group (especially since usenet is almost dead, and
>has been for over a decade).
 
Not all that dead right now.
olcott <NoOne@NoWhere.com>: Jul 11 08:22AM -0500

On 7/11/2022 4:20 AM, Juha Nieminen wrote:
> mathematics with an active community of expects, rather than here in
> some random usenet group (especially since usenet is almost dead, and
> has been for over a decade).
 
My proof is verified through software engineering and not verified
through computer science. The people in the comp.theory forum don't seem
to know jack shit about software engineering.
 
Most crucially they don't understand that a function called in infinite
recursion never returns to its caller.
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@NoWhere.com>: Jul 11 08:24AM -0500


>> At least you seem to be willing to engage in *some* kind of conversation
>> with experts on the matter.
 
> Its probably a friend of his.
 
No. He is a world class computer scientist that I reached out to at
random. He was unable to validate my work because he did not know the
x86 language. He found no mistakes with my work.
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Muttley@dastardlyhq.com: Jul 11 04:09PM

On Mon, 11 Jul 2022 08:24:38 -0500
 
>No. He is a world class computer scientist that I reached out to at
>random. He was unable to validate my work because he did not know the
>x86 language. He found no mistakes with my work.
 
If he didn't validate it then he wouldn't find any mistakes would he. I imagine
he had more important things to do than get into a discussion with a crank.
Probably some urgent coffee to make or paper to shuffle.
olcott <NoOne@NoWhere.com>: Jul 11 01:43PM -0500


> If he didn't validate it then he wouldn't find any mistakes would he. I imagine
> he had more important things to do than get into a discussion with a crank.
> Probably some urgent coffee to make or paper to shuffle.
 
On the basis of his feedback I rewrote the first page so that it can be
understood to be correct with only ordinary understanding of the C
programming language and software engineering.
 
The first page of this updated paper makes my point much more clearly in
that it requires no knowledge of the x86 assembly language. The
subsequent pages can be skipped.
 
Simulating halt decider H(P,P) detects that its simulated P is
essentially calling it in infinite recursion, H aborts its simulation of
this input then rejects it as non-halting.
 
typedef void (*ptr)();
int H(ptr p, ptr i);
 
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H(P, P));
}
 
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
 
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Richard Damon <Richard@Damon-Family.org>: Jul 11 07:23PM -0400

On 7/11/22 2:43 PM, olcott wrote:
 
> *Halting problem proofs refuted on the basis of software engineering*
> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
 
Except that P only calls H in infinite recursion if H doesn't know
enough to stop the recursion, at which point it can't answer non-halting.
 
If it DOES answer non-halting, then it never lets the infinite recursion
happen in the first place.
 
H can't use logic based on H never aborting if it DOES abort, as that
makes the logic invalid and unsound.
 
It is IMPOSSIBLE for H to do both, emulate forever and abort and answer
and be a "Pure Function" at the same time.
 
Your assumption that H can do this, or can decide in finite time is
flawed and based on incorrect assumptions and definitions.
Albert Arkwright <Albert.Arkwright@gmail.com>: Jul 11 10:13PM +0100

On 11/07/2022 11:28, Mark Bluemel wrote:
> As you'd remember if you actually read this newsgroup, we discussed this nearly 4 months ago when the article came out.
 
> I doubt we need to cover the ground again.
 
Why don't you tell the same thing to that idiot called Olcott? He keeps
posting the same thing every two weeks and there are two guys here who
keep responding to him, instead of kill-filing him.
 
Olcott comes here because he is getting a response; Olcott won't go
anywhere unless people stop responding to him completely. Just ignore him;
olcott <NoOne@NoWhere.com>: Jul 11 06:14PM -0500

On 7/11/2022 4:13 PM, Albert Arkwright wrote:
> keep responding to him, instead of kill-filing him.
 
> Olcott comes here because he is getting a response; Olcott won't go
> anywhere unless people stop responding to him completely. Just ignore him;
 
I won't go anywhere until my work is validated whether or not anyone
responds. I just had a very extensive review (23 emails) by a leading
computer scientist.
 
Because of this review I was able to simplify my presentation so that
everyone here can easily verify that I have correctly refuted the
halting theorem on this pure software engineering basis:
 
understanding that the simulated P essentially calls simulating halt
decider H in infinite recursion such that the simulated P cannot
possibly terminate normally.
 
For any program H that might determine if programs
halt, a "pathological" program P, called with some
input, can pass its own source and its input to H
and then specifically do the opposite of what H
predicts P will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem
 
*Any H that does handle this case refutes the halting theorem*
 
typedef void (*ptr)();
int H(ptr p, ptr i);
 
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
 
int main()
{
Output("Input_Halts = ", H(P, P));
}
 
Simulating halt decider H detects that its simulated input is
essentially calling H in infinite recursion. H aborts its simulation on
this basis and rejects this input as non-halting.
 
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@NoWhere.com>: Jul 11 09:55AM -0500

Only an ordinary understanding of C and software engineering is required.
 
#define ptr uintptr_t
 
int H(ptr p, ptr i); // simulating halt decider
 
H Simulates its input until it correctly predicts that this simulated
input would never terminate normally then rejects this input as non-halting.
 
void P(ptr x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
 
int main()
{
Output("Input_Halts = ", H(P, P));
}
 
When the execution trace of function P() simulated by function H() shows:
(1) Function H() is called from P().
(2) With the same parameters to H().
(3) With no instructions in P() that could escape this infinitely
recursive simulation: {index jump, conditional branch, return}
 
Then the function call from P() to H() would never terminate normally.
In this case H aborts its simulation of P and rejects its input as
non-halting.
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 11 06:21PM +0100

On Mon, 11 Jul 2022 09:55:45 -0500
 
> Then the function call from P() to H() would never terminate normally.
> In this case H aborts its simulation of P and rejects its input as
> non-halting.
 
Can you not post your crap to this newsgroup (comp.lang.c++) please?
 
And you seem to need reminding YET AGAIN of the following:
 
I have shown with my signaling halting decider there is no need for
a call to a simulation-based halting decider, H, from the input program
to be recursive; this is compatible with [Strachey 1965] and
associated proofs which are not recursive in nature. Your H is invalid
as it aborts the simulation to prevent infinite recursion rather than
returning an answer to its caller which results in it giving the wrong
answer for a non-pathological input that calls H.
 
/Flibble
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 11 11:35AM -0700

> On Mon, 11 Jul 2022 09:55:45 -0500
> olcott <NoOne@NoWhere.com> wrote:
[34 lines deleted]
 
> Can you not post your crap to this newsgroup (comp.lang.c++) please?
 
If you must reply to one of olcott's off-topic posts, don't quote
the entire post.
 
> And you seem to need reminding YET AGAIN of the following:
 
And don't invite him to post again by trying to continue the discussion
here.
 
[SNIP]
 
Followups redirected to comp.theory.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 11 12:20AM -0700

On 7/6/2022 12:32 PM, Chris M. Thomasson wrote:
>             ) {
>                 std::FILE* fout = fopen(fname, "wb");
> [....]
 
Hummm.. I am missing a damn std:: for fopen! damn it!
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: