"C: Everyone's favourite programming language isn't a programming language"

147 views
Skip to first unread message

Lynn McGuire

unread,
Jul 11, 2022, 1:44:31 AMJul 11
to
"C: Everyone's favourite programming language isn't a programming language"
https://www.theregister.com/2022/03/23/c_not_a_language/

"Aria Beingessner, a member of the teams that implemented both Rust and
Swift, has an interesting take on some of those (and other) language's
problems – that C isn't a programming language anymore."

"There are many problems with the C language. To pick just a few: it can
be difficult to parse; there are competing and subtly incompatible
variants; and then there are the complex ways C defines and handles
integers and other variables."

"For instance, after much deliberation, a bunch of companies called the
Aspen Group settled on a programming model for 64-bit Unix and Unix-like
OSes called LP64, also known as "4/8/8". Unfortunately, 64-bit Microsoft
Windows uses a different model, called LLP64 or "4/4/8"."

https://techmonitor.ai/technology/aspen_group_hands_over_specification_proposals_overspill_to_xopen_will_implement_common_64_bit
and
https://wiki.wireshark.org/Development/Win64

"And that's before the issues around intmax_t, which the C99 standard
defines as "a signed integer type capable of representing any value of
any signed integer type." As software engineer JeanHeyd Meneide pointed
out, this gets complicated.
https://thephd.dev/intmax_t-hell-c++-c

Lynn

Bonita Montero

unread,
Jul 11, 2022, 3:32:53 AMJul 11
to
C lacks almost anything a modern programming language needs.
Having no fixed size native types is almost no problem.

Chris M. Thomasson

unread,
Jul 11, 2022, 3:58:27 AMJul 11
to
Ahhh. Remember way back when C++ was translated into C, then compiled?

Mark Bluemel

unread,
Jul 11, 2022, 6:28:40 AMJul 11
to
On Monday, 11 July 2022 at 06:44:31 UTC+1, Lynn McGuire wrote:
> "C: Everyone's favourite programming language isn't a programming language"
> https://www.theregister.com/2022/03/23/c_not_a_language/

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.

Bonita Montero

unread,
Jul 11, 2022, 9:39:05 AMJul 11
to
They didn't manage to port exceptions to C and they stopped developing
cfront further.

Ben Collver

unread,
Jul 11, 2022, 10:18:03 AMJul 11
to
On 2022-07-11, Chris M. Thomasson <chris.m.t...@gmail.com> wrote:
> Ahhh. Remember way back when C++ was translated into C, then compiled?

I seem to recall using cfront to build gperf to bootstrap GCC using the
extremely limited free-of-charge C compiler that came with HP-UX 9, i
think it was.

Scott Lurndal

unread,
Jul 11, 2022, 10:38:40 AMJul 11
to
We used cfront (2.1) to build a distributed operating system, first for the
Motorola 88100, and later for an intel based massivly parallel processor
(MPP) system in the mid 90's.

Thiago Adams

unread,
Jul 11, 2022, 1:49:05 PMJul 11
to
How did you debug code using cfront?
Did you debug C or C++ code?

Lynn McGuire

unread,
Jul 11, 2022, 3:24:51 PMJul 11
to
Do you have the date and time of the original posting ? I cannot find it.

I sure do not remember the posting but, I have slept since then.

Lynn


Michael S

unread,
Jul 11, 2022, 3:40:27 PMJul 11
to
From Mar 24, 2022, 5:36:11 PM to Apr 25, 2022, 9:05:03 PM
Your own post: Mar 28, 2022, 7:54:33 PM
https://groups.google.com/g/comp.lang.c/c/S5ygO3G3Jqg/m/usau9_tqAwAJ


Scott Lurndal

unread,
Jul 11, 2022, 5:00:03 PMJul 11
to
How did anyone debug code in 1990? It was an SMP operating system,
using the Chorus Systemes microkernel (written in C++) and a
distributed version of SVR4 (half in C++, half svr4 C code).

Like all good kernels, it had a built-in debugger. Type control-A
at the console serial terminal and the OS dropped into the debugger
(if enabled). Breakpoints, examining memory, stack tracebacks,
instruction disassembly, symbol table compiled into the kernel,
et alia.

Very similar to the kdb in-built kernel debugger I released to the linux mailing
list back in April of 1999. SUSE shipped it as part of the SLES releases and parts
of it still exist in the current linux kernel.

Albert Arkwright

unread,
Jul 11, 2022, 5:16:29 PMJul 11
to
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

unread,
Jul 11, 2022, 7:14:33 PMJul 11
to
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

Lynn McGuire

unread,
Jul 11, 2022, 8:35:11 PMJul 11
to
Sorry, that posting was not me.

Lynn



Juha Nieminen

unread,
Jul 12, 2022, 5:52:59 AMJul 12
to
In comp.lang.c++ Albert Arkwright <Albert.A...@gmail.com> wrote:
> Olcott comes here because he is getting a response; Olcott won't go
> anywhere unless people stop responding to him completely. Just ignore him;

Clearly you don't understand how obsessive compulsion works.

Mark Bluemel

unread,
Jul 12, 2022, 5:57:01 AMJul 12
to
I have some hope Lynn may take some notice. It's clear that Olcott won't.

Vir Campestris

unread,
Jul 12, 2022, 6:27:26 AMJul 12
to
There are degrees of OCD. By normal standards we've all got it... It's
not normal to be able to spend hours at a time staring at code on a
screen looking for that annoying little error.

But yes, some are worse than others.

Andy

Bonita Montero

unread,
Jul 12, 2022, 8:28:26 AMJul 12
to
I don't think he has OCD per se, because people like
that don't have that delusional sense of mission.

Bonita Montero

unread,
Jul 12, 2022, 8:45:26 AMJul 12
to
What it has in common with OCD is that Pete only sees details
and is unable to see the big picture. This is also something
that there is in common with circles of thought.

olcott

unread,
Jul 12, 2022, 8:45:28 AMJul 12
to
Do you really have to go around and around with all this ad hominen
stuff instead of simply validating that the simulated input to H(P,P)
would never terminate normally ???

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 and would never terminate
normally. H aborts its simulation on this basis and rejects this input
as non-halting.

olcott

unread,
Jul 12, 2022, 8:46:15 AMJul 12
to
On 7/12/2022 7:29 AM, Bonita Montero wrote:

olcott

unread,
Jul 12, 2022, 8:48:56 AMJul 12
to
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

The big picture is that H(P,P) correctly determines that its input would
never terminate normally and H(P,P) does handle the above "impossible"
case.

Freethinker

unread,
Jul 12, 2022, 10:15:00 AMJul 12
to
On 12.07.22 01:14, olcott wrote:
> On 7/11/2022 4:13 PM, Albert Arkwright wrote:
>> 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;
>>
>
> 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:
>

OK, so now that we have easily verified that, would you please stop
posting this same thing millions of times?

Keith Thompson

unread,
Jul 12, 2022, 2:01:52 PMJul 12
to
Lynn clearly made an honest mistake, posting a relevant link without
realizing that it had been discussed previously.

Olcott is a crank (take a look at comp.theory if you're curious). They
are not comparable.

My personal solution is to killfile olcott in this newsgroup, so I never
see his posts here. What I do see is other posters replying to him.

If you must reply to olcott here, at least don't quote his entire
article and continue arguing with him.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Lynn McGuire

unread,
Jul 12, 2022, 2:54:45 PMJul 12
to
On 7/12/2022 1:01 PM, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes:
>> On Monday, 11 July 2022 at 22:16:29 UTC+1, Albert Arkwright wrote:
>>> 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;
>>
>> I have some hope Lynn may take some notice. It's clear that Olcott won't.
>
> Lynn clearly made an honest mistake, posting a relevant link without
> realizing that it had been discussed previously.
..
Thank you. I did not realize that the article was old and had already
been posted.

Lynn



Michael S

unread,
Jul 12, 2022, 3:33:48 PMJul 12
to
My bad.
Your names sound similar to non--Scotsman like myself.

Chris M. Thomasson

unread,
Jul 12, 2022, 4:02:11 PMJul 12
to
Yup! However, you are working toward a goal... To slay the error. A
little OCD can be "useful", from time to time...


> But yes, some are worse than others.

Big time. Some people have to wash their hands 42 times a day. No more,
no less.

Manu Raju

unread,
Jul 12, 2022, 5:21:09 PMJul 12
to
On 12/07/2022 21:01, Chris M. Thomasson wrote:
>
> Big time. Some people have to wash their hands 42 times a day. No
> more, no less.
>

At college we had a Muslim woman who cleaned the keyboard and laid blank
papers on chair before sitting down to use a computer. She was just
obsessed with silly things.



Richard Damon

unread,
Jul 12, 2022, 9:39:33 PMJul 12
to
And is WRONG, because you have just shown that a call to H(P,P) returns
0 and NOT get into infinite recursion, BECAUSE H is smarter than H gives
it credit for, and know enough to abort its simulation, but isn't smart
enough to know that it will do so.

The ONLY way that H is correct that the call fo H(P,P) inside P(P) leads
to infinite recursion is if H isn't actually a Pure Function, at which
point it fails to be the equivalent of the Turing Machine required by
the proof, or to be a proper decider.

Note, you needed to add the "essentially" to you statment, because it
isn't actually infinite recursion, at least not if H makes the decision
to ever abort its simulation.

H, to be correct, needs to judge P based on the ACTUAL H that exists,
not some close approximation like the essentially tries to let in.

Richard Damon

unread,
Jul 12, 2022, 9:45:42 PMJul 12
to

On 7/12/22 8:48 AM, olcott wrote:
> On 7/12/2022 7:46 AM, Bonita Montero wrote:
>> Am 12.07.2022 um 14:29 schrieb Bonita Montero:
>>> Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>>>> In comp.lang.c++ Albert Arkwright <Albert.A...@gmail.com> wrote:
>>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>>> anywhere unless people stop responding to him completely. Just
>>>>> ignore him;
>>>>
>>>> Clearly you don't understand how obsessive compulsion works.
>>>
>>> I don't think he has OCD per se, because people like
>>> that don't have that delusional sense of mission.
>>
>> What it has in common with OCD is that Pete only sees details
>> and is unable to see the big picture. This is also something
>> that there is in common with circles of thought.
>
> 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
>
> The big picture is that H(P,P) correctly determines that its input would
> never terminate normally and H(P,P) does handle the above "impossible"
> case.
>


Except that it doesn't, at least if it is trying to meet the actual
requirements of the Halting Problem.

Remember the DEFINITION:

H(M,x) accepts its input (returns 1) if M(x) will Halt (return), and
H(M,x) rejects its input (returns 0) if M(x) will NEVER Halt (return).

Thus H(P,P) to correctly return 0, means that P(P) must never return,
but by construction, P(P) WILL return if H(P,P) returns 0.

Your dishonest dodge of saying that the input to H(P,P) somehow doesn't
represent P(P) fails, because that says that P wasn't defined correctly,
as P was defined in the proof to be given an input so P asks H what it
will do when called with its input, and sincd your P(x) calls H(x,x),
athat means that P(P) calls H(P,P) which needs to mean that P is asking
about P(P), and not something else.

Thus, your claim is just an admission that you didn't write P correctly
(or are just lying that H is actually able to do what you claim).

olcott

unread,
Jul 12, 2022, 9:49:51 PMJul 12
to
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

It is not verified until it is understood that P and H implement the
classical halting problem "impossible input" template (as shown above)
and refutes this template in that H(P,P) correctly determines that its
input never terminates normally.

*This is the key software engineering that I need validated*
Most anyone here can easily verify that the simulated input to H(P,P)
cannot possibly terminate normally.

The next level of pure software engineering is that H(P,P) correctly
predicts that its simulated input cannot possibly terminate normally. It
may be the case that only the top 5% of software engineers can validate
this point.

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.

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 possibly escape this
infinitely recursive simulation.

*That was all of the software engineering that I need validated*

Halting problem proofs refuted on the basis of software engineering

olcott

unread,
Jul 12, 2022, 10:04:20 PMJul 12
to
On 7/12/2022 3:01 PM, Chris M. Thomasson wrote:
> On 7/12/2022 3:27 AM, Vir Campestris wrote:
>> On 12/07/2022 10:52, Juha Nieminen wrote:
>>> In comp.lang.c++ Albert Arkwright <Albert.A...@gmail.com> wrote:
>>>> Olcott comes here because he is getting a response; Olcott won't go
>>>> anywhere unless people stop responding to him completely. Just
>>>> ignore him;
>>>
>>> Clearly you don't understand how obsessive compulsion works.
>>
>> There are degrees of OCD. By normal standards we've all got it... It's
>> not normal to be able to spend hours at a time staring at code on a
>> screen looking for that annoying little error.
>
> Yup! However, you are working toward a goal... To slay the error. A
> little OCD can be "useful", from time to time...
>

It works for Elon Musk.

>
>> But yes, some are worse than others.
>
> Big time. Some people have to wash their hands 42 times a day. No more,
> no less.
>


Richard Damon

unread,
Jul 12, 2022, 10:26:47 PMJul 12
to
And your property (3) is incorrect the way you use it. The CORRECT
version of (3) looks ALL the way through the loop, which includes in H,
and will find the condtional there.

If you omit that, then (3) is just incorrect, as the fact that P(P)
Halts when H(P,P) returns 0 proves.

You don't want to detect "essentially" in infinite recursion, but need
to detect in ACTUAL infinite recursion.

If the infinite recursion is actual, then H(P,P) is also in infinite
recursion and thus never answers and thus fails to be a decider.

If the infinite recursion isn't actual, then it doesn't matter that it
was close, and only the smarts of H stopped it from being so, as that
smarts in H was PART of the algorithm of P, by the virtual of it calling
H to ask the question, and the P gets "credit" for those smarts too.

If one H has the smarts, but the one called by P doesn't, then H fails
to be the needed Pure Function, so you are shown to be incorrect.

olcott

unread,
Jul 12, 2022, 10:30:17 PMJul 12
to
H(P,P) correctly predicts that its input cannot possibly terminate
normally. (I have better words now).

Richard Damon

unread,
Jul 12, 2022, 10:39:58 PMJul 12
to
Except that the program represented by the input, P(P) DOES terminate
normally if H(P,P) returns 0.

If H(P,P) isn't asking about the behavior of P(P), then you have defined
your P incorrect and you whole proof is worthless as you aren't working
on the needed case.

Remember, P is defined to as H about what it will do with its input.

THAT is the "impossible" program.

If H(P,P) isn't asking about P(P), then since that is what P is doing,
it was defined wrong.

if that IS what it is asking about, then H is wrong, since P(P) will
halt when H(P,P) returns 0.

IF one H(P,P) returns 0, but the H(P,P) that P(P) calls doesn't, then H
is not a pure function.

If you want to still try to claim it is, what is the first x86
instruction in the ACTUAL EXECTUION of the H(P,P) called by main and in
the ACTUAL EXECUTION of the H(P,P) called by P(P) which have different
results.

Since H is a pure function, and the inputs are the same, the inputs to
the instruction needs to be the same too, or this isn't the first x86
instruction with a difference, and you need to go back to the point
where that difference was created, or admit that they are looking at
something that wasn't part of the input, and thus H isn't a pure function.

olcott

unread,
Jul 12, 2022, 10:52:22 PMJul 12
to
*CHANGING THE SUBJECT IS NEVER A REBUTTAL*
Simulating halt decider H(P,P) correctly predicts that its correctly
simulated input cannot possibly terminate normally.



Mark Bluemel

unread,
Jul 13, 2022, 4:13:36 AMJul 13
to
On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
> Mark Bluemel <mark.b...@gmail.com> writes:

> > I have some hope Lynn may take some notice. It's clear that Olcott won't.
> Lynn clearly made an honest mistake, posting a relevant link without
> realizing that it had been discussed previously.

My response to Lynn was possibly a little brusque, but my perception
is that she pops up from time-to-time to post some link or other, but
doesn't really participate in discussions.

> Olcott is a crank (take a look at comp.theory if you're curious). They
> are not comparable.

I know, and no thank you, I'm not curious.

> If you must reply to olcott here, at least don't quote his entire
> article and continue arguing with him.

You must be mistaking me for someone else - I don't reply to
olcott, let alone quote his drivel.

I note that he and Richard (who should surely know better) have
now hijacked this thread.

Juha Nieminen

unread,
Jul 13, 2022, 6:02:55 AMJul 13
to
I don't think that fulfills the "D" part (except if in canses where it's
arguably unreasonable and has a tangible and chronic negative impact on
one's life and social relationships).

Richard Damon

unread,
Jul 13, 2022, 7:52:03 AMJul 13
to
WHAT Change of subject?

You claim that H(P,P) correctly predicts what its input does.

Showing the definition of what the input does is on topic.

YOU are the one who doesn't follow your own subject, as you CLAIM to be
talking about the Halting Problem, but whenever anyone tries to point
out the actual definition of what the Halting Problem requires, you say
it is off topic.

I guess you mean that the topic is YOU OWN INCORRECT IDEA of what the
Halting Problem means, and actual facts are not allowed.

H(P,P) does NOT CORRECTLY predict that its correctly simulated input can
not possible terminate normally because your H never does a correct
simulation of its input and also make a prediction.

It EITHER correctly simulates the input, and simulates FOREVER (since
the input then becomes non-halting) but fails to actually predict it,

or H makes a prediction but doesn't do a correct simulation of its
input, and the actual correct simultion of the input shows that P(P),
which IS what the input to H(P,P) is if P is done per the requirements,
will Halt.

You don't seem to understand what the word "Correct" means.

(f you want to go by your claim that the input to H(P,P) doesn't
actually represent P(P), then you program is meaningless, as P isn't the
required P to be decided, since P asks H about itself by calling H(P,P),
so if that doesn't mean P(P), your P isn't the needed on.

olcott

unread,
Jul 13, 2022, 8:20:08 AMJul 13
to
IT IS A VERIFIED FACT THAT
Simulating halt decider H(P,P) correctly predicts that its correctly
simulated input cannot possibly terminate normally.

The only possible correct rebuttal must show all the steps of exactly
how the input to simulating halt decider H(P,P) does terminate normally
when H correctly simulates this input.

Since I already proved that this is false entirely on the basis of
verified fact this is impossible.

This requires that a function called in essentially infinite recursion
to return a value to its caller this is impossible.

Most everyone here knows that every function called in infinite
recursion never returns any value to its caller. There is no gibberish
that you can say that would convince them otherwise.

Mut...@dastardlyhq.com

unread,
Jul 13, 2022, 11:24:22 AMJul 13
to
I wonder if Olcott and that religious nutjob who used to post on here (forget
his name) are one and the same. In this thread from 2018:

https://groups.google.com/g/comp.theory/c/0i86aQ3WPaA

Olcott posts a link to his own website:

http://the-pete.org

Looks very familiar.

Keith Thompson

unread,
Jul 13, 2022, 1:24:04 PMJul 13
to
Mark Bluemel <mark.b...@gmail.com> writes:
> On Tuesday, 12 July 2022 at 19:01:52 UTC+1, Keith Thompson wrote:
[...]
>> If you must reply to olcott here, at least don't quote his entire
>> article and continue arguing with him.
>
> You must be mistaking me for someone else - I don't reply to
> olcott, let alone quote his drivel.

Sorry, that wasn't addressed to you specifically.

> I note that he and Richard (who should surely know better) have
> now hijacked this thread.

Yes, Richard should know better.

Mr Flibble

unread,
Jul 13, 2022, 1:28:09 PMJul 13
to
There is no infinite recursion in [Strachey 1965] or the HP proofs
based on it. I have shown that a simulating halt decider needn't be
recursive in nature: only your broken solution has a problem with
infinite recursion.

/Flibble

Manu Raju

unread,
Jul 13, 2022, 1:51:33 PMJul 13
to
On 13/07/2022 16:24, Mut...@dastardlyhq.com wrote:
>
>
> Olcott posts a link to his own website:
>

Olcott can improve his chances of winning a "Nobel" price by posting his
article on <https://www.dreamwidth.org/> and spend as much time as
possible to promote it. the problem is Olcott hasn't got the necessary
qualification to have any credibility in his work. the guy is a jobless
troll dying of "advance stage of cancer". that's what he told us so we
should take his word. Please don't send any money to him because his
claim of dying of cancer is also dubious. The guy is liar and fraudster.

He's is wasting time by posting here because people responding to him
are only interested to waste his time and their own time. i doubt if any
of them have any interest in advancing anything new here. I don't see
any posts from them but I have simply kill-filed them and I try to
kill-file anybody who responds to his posts.



- Olcott

unread,
Jul 13, 2022, 2:25:12 PMJul 13
to
5.5 years of feedback have made my words much clearer.
My words are so much more plausible now that a leading
computer scientist extensively reviewed my work in a 23 email
dialogue last weekend.

You are certainly competent enough to validate the software engineering of this

typedef void (*ptr)();
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));
}

The simulated P essentially calls H in infinite recursion.
Because basic software engineering knows that no function
called in infinite recursion ever returns to its caller we know
that the simulated P never terminates normally for these reasons:

*When the execution trace of function P() simulated by function H() shows:*
(1) Function H() is called from P().<br>
(2) With the same parameters to H().<br>
(3) With no instructions in P() that could escape this infinitely recursive
simulation: {index jump, conditional branch, return}

As soon as H correctly predicts that its simulated P would never terminate
normally it aborted its simulation of P and rejects this input a s non-haling.

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.

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

Because H(P,P) does handle this case the above halting problem undecidable input template has been refuted.

*When this halt deciding principle understood to be correct*
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 (by logical necessity) this implements that principle*
Every simulating halt decider that correctly simulates its input until it correctly predicts that this simulated input would never terminate normally, correctly rejects this input as non-halting.

H is a *Pure function* https://en.wikipedia.org/wiki/Pure_function
thus implements a *Computable function*
https://en.wikipedia.org/wiki/Computable_function#Characteristics_of_computable_functions

Jens Schweikhardt

unread,
Jul 13, 2022, 5:08:30 PMJul 13
to
In comp.lang.c olcott <No...@nowhere.com> wrote:
[...]
# H(P,P) correctly predicts that its input cannot possibly terminate
# normally. (I have better words now).

Please excuse my ignorance, I'm very late to the discussion, if the
following has already been brought forward.

It is my understanding that a "working" halt decider can be used to
prove or disprove any math theorem that can be expressed as a program
that halts or doesn't halt, depending on whether the proposition is true
or false. Simple example: the Riemann Hypothesis that the non-trivial
zeros of the zeta function have real part 0.5.

A C program could halt if it finds a zero with real part not equal 0.5;
if it can't it will run forever (assuming arbitrary large memory for the
bignums).

int main (void) {
/* mycomplex: An arbitrary precision complex type. */
mycomplex zero = 0.0;
for (;;) {
zero = compute_next_zero(zero); /* elided for brevity */
if (realpart(zero) != 0.5)
break;
}
return 0;
}

So if your claim holds true, feed the program to your machine, if it
says "never halts" the RH is proven true, otherwise false. Too easy. But
how does the knowledge about all zeros come into your halt decider? And
abount all the trillions of other programs to prove or disprove a
theorem? What about some of the other non-tractable problems, such as
P=NP? Can we conceive a C program for this question?

I don't think any finite program could be such a general theorem prover
and therefore I am convinced you are chasing a ghost and there's
something you overlooked. I can't say what exactly, but I don't have to,
because the above to me is an reductio ad absurdum. Given the halting
problem could be solved, theorem proving becomes trivial immediately.

I am aware it's not a strict proof in the mathematical sense, but good
enough for me. It's like you are coming to a physicist with a new
perpetual motion machine. They will not spend time finding the exact
weak point in your contraption. They will simply reject it, like any
patent office worth their salt.

Regards,

Jens
--
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

Chris M. Thomasson

unread,
Jul 13, 2022, 6:31:41 PMJul 13
to
On 7/13/2022 11:00 AM, Manu Raju wrote:
> On 13/07/2022 16:24, Mut...@dastardlyhq.com wrote:
>>
>>
>> Olcott posts a link to his own website:
>>
>
> Olcott can improve his chances of winning a "Nobel" price by posting his
> article on <https://www.dreamwidth.org/>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

dreamwidth sounds interesting.

https://en.wikipedia.org/wiki/Dreamwidth

The invite code reminds me of SIGGRAPH for some reason...

Richard Damon

unread,
Jul 13, 2022, 7:52:03 PMJul 13
to
That can't be a verified fact because the opposite is a verified fact,
that the CORRECT simulation of the input to H(P,P), which is the correct
simulation of P(P) will actually Halt if H(P,P) returns 0, as you claim
it does.

It doesn't matter that *H* can't do that emulation (and there is nothing
in the actual Halting Problem definition that says it should), because H
is a FIXED program in this case, which is admitted to aborting its
simulation, based on (provenly incorrect) conditions it detected in its
emulation of P(P).

You claim that only H's emulation can show it is an error in your
specification that means that NO program can be proved to be non-halting
and so indicated by H, since if H indicates it, it didn't do a complete
emulation of the program to show it. FAIL.

What CAN be shown, and in fact even YOU have posted, is that an actual
correct simulation of this input does halt.

Note you proof of "essentially infinte recursion" is based on an error
that ignores the ACTUAL behavor of H, but assumes that H actually meets
its requirements. The fact that it doesn't meet its design requirements
just shouws you don't actually know how to debug your own code.

Also note, your claim that the behavior of input to H(P,P) doesn't
actually match the behavior of P(P) just shows that you have a bug in P
(or H), as it is supposed to ask H for it to decide on what P(P) will
do, and if H(P,P) isn't defined to do that, it shouldn't make that call.


olcott

unread,
Jul 13, 2022, 8:07:11 PMJul 13
to
I already gave Paul N a great explanation of that on comp.theory.
I won't be able to see your reply there because I have you blocked there.

My explanation to wjj even sums it up better:

On 7/13/2022 3:51 PM, olcott wrote:
> On 7/13/2022 3:47 PM, wij wrote:
>> The property that an arbitrary program P will finish
>> running or not is determined by running P as an
>> independent program

Because that would require that a halt decider must sometimes make its
halt status decision on a basis other than the actual behavior of its
actual input that long standing misconception has been refuted.

olcott

unread,
Jul 13, 2022, 8:34:09 PMJul 13
to
There is a huge difference between solving the halting problem and
refuting the conventional proofs that solving the halting problem is
impossible. I am only doing the latter.

It may not even be the case that solving the halting problem could
answer currently unknown problems of mathematics. This would require
infallible mathematical reasoning about all of mathematics such that it
could deduce every mathematical unknown. This is a very much broader
scope than simply correctly determining whether or not a computer
program will stop running.

Richard Damon

unread,
Jul 13, 2022, 9:20:56 PMJul 13
to
No, because all the behavior of that program exists will be encoded in
the representation of the program given to the decider.

The fact that H can't correct USE that information doesn't mean it
wasn't given to it.

From the complete description of a Turing Machine and it input, the
ENTIRE behavior has been defined, though it may take infinite time to
determine this if the machine is non-halting.

Give the complete x86 code of a program, and its input, the behavior of
that program is completely defined.

Thus, H has been given everything that it should need to determine what
it needs to, if the results are actually computable.

You big problem is you are confusing the phases of the programming process.

During the DESIGN Phase, you get to change your program as you desire
and work on logic asking how to get the right answer.

When (and if) you comlete that design process, you now have a SPECIFIC
program that you can test to see if it works.

At this stage, the program does what it has been programmed to do, and
you don't look at other possible behaviors of it.

At this point you need to actually DEFINE what you H is, you have used
several different sets of defiitions.

One is that it just DOES a complete and correct simulation of its input,
that this H has been show to not return an answer to H(P,P) and does
make P(P) non-halting, but this can't be your "correct" H, since it
never returns the answer. (and you can't say P is using this, when you
are deciding with a different one).

THe next design uses your defined rule that you CLAIM proves
non-halting, that if P(P) calls H with the same input that H started
with, then it can presume the input is non-halting.

THis is proved incorrect by just running P(P), seeing it call H(P,P) and
then that H(P,P) sees its simulation do this, it aborting the
simulation, and returning to P and P(P) halting. This PROVES the rule wrong.

You claim that the input to H(P,P) not being the same as P(P) is shown
wrong because it MUST be or your P is defined incorrectly. Remember, the
"impossible" program was defined to ask H about itself with its input
and doing the opposite. Since P(P) calls H(P,P) to ask that question, if
it doesn't actually mean that, you have an error in your problem
construction.

You sometimes go more nebulous and just say that H will simulate until
it can actually PROVE that the input is non-halting, and while if it can
actually do that, it will be right, all this is actually doing is saying
that your Halt Decider will use a Halt Decider to tell it if its input
is non-halting, and thus your DESIGN recurses and you end up with an
infinite program.

You ASSUME that there is SOME finite pattern that H can detect, since it
is clear that if H doesn't abort its simulation it will never halt, but
the problem is that this doesn't mean that if it does abort it is
correct to say the input is non-halting, because the proof was based on
a now false premise, that H will not abort its simulation.

We can (and I have shown you) prove that there IS no finite pattern in
P(P) that H could detect, because ANY pattern in P(P), if put into H as
a non-halting pattern, cause H(P,P) to return 0 to P(P) and P(P) then
halts. Thus there does NOT exist a pattern to detect that this P(P) is
non-halting that H could use to answer non-halting.

It IS possible for H to detect this fact, it just can't act on that
knowledge without breaking the premise it uses to make this proof.

The problem is that the Field of Computation Theory requries that
Deciders actually return the answer, and in a way that another program
can get it, to be considered a Decider.

THus, we see that ANY H you design by your technique will either not
answer or give the wrong answer, which is EXACTLY what the proof you are
trying to refute says will happen.

olcott

unread,
Jul 13, 2022, 9:34:32 PMJul 13
to
The reason that I stop talking to you is that you make false assumptions
that are utterly impervious to all reasoning.

It is a verified fact that the input that is correctly simulated by
H(P,P) cannot possibly terminate normally. It is also a verified fact
that the direct execution of P(P) does terminate normally.

It is also common knowledge that the correct simulation of a program is
a correct measure of the behavior of this program.

This conclusively proves that H(P,P) is correct to reject its input as
non-halting and the behavior of a non-input cannot possibly contradict
this.

Richard Damon

unread,
Jul 13, 2022, 9:56:06 PMJul 13
to
YOU SAY THAT, but it is a FACT that you H doesn't correctly simulate the
input (since it aborts it to return 0) so it doesn't MATTER that if it
was a different program it wouldn't be able to simulate to a final state.

You are just showing you don't understand the nature of what an
algorithm IS>

P calls H, and YOUR H simulates for a while, INCORRECTLY decides it
doesn't halt, and returns 0, thus making P(P) a Halting Program.

It doesn't matter that some other H that might exist that doesn't abort
results in a P(P) that doesn't halt, that isn't the H that we are
looking at the you claim correctly return 0, as THAT H never returns
from H(P,P)/

The fact that you see these two DIFFERENT H's as the same thing just
proves that YOU don't have a firm grip of what is true.

Unless you can actually provide a H that with the EXACT SAME CODE, and
as a PURE FUNCTION of its ihput does both of these, you are just caught
in the lie you have been working on for decades. This code is of course
impossible, which is why you have refused to show any version of this
code that you have claimed to have had (with "small" errors) for years.

The "Small errors" are fundamental design bugs that you may be trying to
fix, and if you actually publish your code, it will become obvious that
you have been lying about what you program does.

You keep on saying that P(P) is a non-input, but then you are shown to
LIE that your P meets the requirements of the "impossible program", as
that asks H about the behavior of itself with its input, that is P(P),
and you have coded that as H(P,P), so if the behavior of the input to
H(P,P) is not the behabior of P(P) your P is not correct, and you proof
is INVALID.

You need to change P to call H in the way that DOES ask about P(P), and
if you can't do that, you H is automattically proven wrong as you have
shown an machine and input that it can not decide.

Or perhaps more simply, you haven't shown that it gives the right answer
for the impossible program, because you never asked it about it.

You are showing your total lack of understanding of the basics of
computation theory, or even basic logic. Your "proof" is a model for how
not to try to prove something.

olcott

unread,
Jul 13, 2022, 10:08:57 PMJul 13
to
That you (and others) continue to lack the technical capacity to
comprehend that H does correctly predict that its complete and correct
simulation of its input would never result in this input terminating
normally is far less than no rebuttal at all. Until you (and others)
gain this technical capacity there is no sense continuing a dialogue.

My grandfather George P. Olcott MD had a very key brilliant insight that
my father often repeated to me: "One cannot argue with ignorance.


*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

Richard Damon

unread,
Jul 13, 2022, 10:21:51 PMJul 13
to
How is it correct when H(P,P) sayts P(P) is non-halting when a direct
exectuion of P(P) or a correct simulation by simualte(P,P) (where P
still calls the previous H) show that it halts.

Note, if you claim that the input behavior of the input to H(P,P) isn't
the same as P(P) then you P isn't defined correctly, as that is how it
asked H to decide on P(P).

>
> My grandfather George P. Olcott MD had a very key brilliant insight that
> my father often repeated to me: "One cannot argue with ignorance.

Yep, YOU are a perfect proof of that.

>
>
> *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
>
>
>

And condition (3) near the bottom of page 1 is just flat out incorrect,
showing you don't understand what a PROGRAM actually is. The REAL rule
you are thinking of includes the code of H in the space that needs to be
looked at for the conditionals, since the H that P calls IS part of the
'code' of P.

FAIL.

PROOF OF YOUR IGNORANCE.

Note, this has been pointed out ot you MANY times, but the fact that you
continue repeating it with out showing how you establish this variant of
the accepted rules just proves that you are just being intentionally
deceptive.

Richard Damon

unread,
Jul 13, 2022, 10:29:57 PMJul 13
to
No, you stop talking to me because I am being too good at pointing out
the errors in your logic.

>
> It is a verified fact that the input that is correctly simulated by
> H(P,P) cannot possibly terminate normally. It is also a verified fact
> that the direct execution of P(P) does terminate normally.


Nope. Pointed out elsewhere, the CORRECT simulation of the input to
H(P,P) by a simulator that DOESN'T abort (but P still calls the H that
does) shows that the input to H(P,P) will Halt if H(P,P) returns 0.

>
> It is also common knowledge that the correct simulation of a program is
> a correct measure of the behavior of this program.


Right CORRECT, as in NOT ABORTED part way.

>
> This conclusively proves that H(P,P) is correct to reject its input as
> non-halting and the behavior of a non-input cannot possibly contradict
> this.
>

Nope. Since the correct (non-aborted) simulation of the input given to
H(P,P) by a simulator that actually does a complete simulation while the
input still calls the original H shows that the input to H(P,P) will
halt if H(P,P) returns 0.

If you try to claim that the correct simulation of the input to H(P,P)
depends on the simulator that is doing the simulation, then you are
showing you just don't understand how computations and simulations work.

Since H doesn't do a complete simulation, you can't use proofs based on
it doing so to show something. That is the DEFINITION of an UNSOUND
argument.

Since H (the one that gives the answer 0 to H(P,P), and that is the onne
that the P we are talkng about is using) doesn't do a complete and
correct simulation, ANY proof that include a condition "If H doesn't
abort ..." is a false premise.

Note, Halting is based on the program that is ACTUALLY there, not the
theoretical one you were trying to write.

Keith Thompson

unread,
Jul 13, 2022, 10:41:38 PMJul 13
to
Richard Damon <Ric...@Damon-Family.org> writes:
> On 7/13/22 9:34 PM, olcott wrote:
[214 lines deleted]

Richard, please stop cross-posting to comp.lang.c and comp.lang.c++.

Followups directed back where they belong.

olcott

unread,
Jul 13, 2022, 10:55:43 PMJul 13
to
Most everyone here can see: (from my updated simplified paper)
It is a verified fact that the input that is correctly simulated by
H(P,P) cannot possibly terminate normally.

The smartest software engineers here can also see that H does correctly
predict this. People at the bottom 10% of technical competence may not
see either one of these. No sense continuing to talk to these people.

Mr Flibble

unread,
Jul 14, 2022, 12:19:09 AMJul 14
to
I have shown that a simulating halting decider needn't be recursive in
nature thus can terminate normally. You are wrong on all fronts.

/Flibble

olcott

unread,
Jul 14, 2022, 12:27:55 AMJul 14
to
No you have not.