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

[Lynn McGuire]

"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]

C lacks almost anything a modern programming language needs.
Having no fixed size native types is almost no problem.

[Chris M. Thomasson]

Ahhh. Remember way back when C++ was translated into C, then compiled?

[Mark Bluemel]

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]

They didn't manage to port exceptions to C and they stopped developing
cfront further.

[Ben Collver]

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]

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]

How did you debug code using cfront?
Did you debug C or C++ code?

[Lynn McGuire]

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]

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]

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]

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]

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]

Sorry, that posting was not me.

Lynn

[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.

[Mark Bluemel]

I have some hope Lynn may take some notice. It's clear that Olcott won't.

[Vir Campestris]

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]

I don't think he has OCD per se, because people like
that don't have that delusional sense of mission.

[Bonita Montero]

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]

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]

On 7/12/2022 7:29 AM, Bonita Montero wrote:

[olcott]

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]

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]

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]

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]

My bad.
Your names sound similar to non--Scotsman like myself.

[Chris M. Thomasson]

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]

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]

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]

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]

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]

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]

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]

H(P,P) correctly predicts that its input cannot possibly terminate
normally. (I have better words now).

[Richard Damon]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

*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

[Mr Flibble]

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]

No you have not.

[olcott]

On 7/13/2022 11:18 PM, Mr Flibble wrote:

You have shown that you don't fully understand the concept of
unreachable code.

[Mr Flibble]

On Wed, 13 Jul 2022 23:29:53 -0500

Of course I understand the concept of unreachable code in fact I recall
giving you several examples of it.

/Flibble

[Mr Flibble]

On Wed, 13 Jul 2022 23:27:38 -0500

Yes I have: see my post "An idea for a simulating halt decider" in
comp.theory.

/Flibble

[olcott]

Its gibberish, you never provide the halt status criterion measure.

[olcott]

I did not say that you have no idea what unreachable code is, you simply
do not understand that infinite recursion prevents all the code below
the infinitely recursive function call to ever be reached.

There are a sequence of many posts that prove this where you believe
that removing the infinite loop eliminates the pathological relationship.

You and Richard are at the bottom 10% of technical competence in this
forum most everyone else could validate that I am correct.

[Richard Damon]

But then how do you explain that P(P) does halt, as you have even shown
when H(P,P) returns 0?

Your problem is that you show that *IF* H behaves one way, that the
simulation done by H(P,P) can't stop, and then you have H behave
differently.

You hide the logic flaw with glib words, but it is still an error.

The input to H(P,P) MUST refer to the behavior of P(P) or P isn't asking
H the right question to be the "Impossible Program", and P(P) Halt if
H(P,P) says it will be non-halting, so that isn't a correct anseer.

All you are showing is that you call fool some people some of the time.

And I think if you take an honest look arround, it isn't "most everyone"
who thinks you are correct. Yes, it is a fact that *IF* H does simulate
its input until it can actually PROVE that its input is non-halting,
that for THAT H, P(P) will be non-halting.

H can, by assuming that H is such a machine, detect that IF H WAS such a
machine, this P would be non-halting.

The problem is, that by H assuming that it is such a machine, it no
longer is such a machine, and the logic fails.

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

But it isn't true! H(P,P) MUST decide about P(P) or P isn't correct, and
P(P) Halts if H(P,P) says it is non-halting, so H is just wrong with its
answer.

You are the Emperor who is believing his own lie that he has made a
fabulous set of clothes that only important people can see, but in
reality has gone out into the parade naked.

You logic is just BAD, and doesn't actually prove anything that you are
trying to claim.

H does NOT get the answer right, but you refuse to look at the REAL
evidence that even you have created, because you so want to believe your
lie, because you just can't face the actual truth.

[Richard Damon]

Pot, Kettle, Black.

[Richard Damon]

No, you are in the bottom 0.01 % of technical competence to beleive your
lie that the H that returns 0 for H(P,P) actually generates infinite
recursion.

You believe that you can have simultaneously an immovable object and an
irresistible force that it can be applied to (does it move or is it
resisted?) You think you H can simulate its input forever, but still
finish and answer in finite time.

[Mut...@dastardlyhq.com]

The irony, strong it is in this one!

[Mr Flibble]

On Thu, 14 Jul 2022 05:49:52 -0500

Of course I have always understood that code after an infinite
recursion is unreachable, I have never claimed otherwise however what I
have claimed is that [Strachey 1965] is NOT recursive nor are the
proofs based on it; I have claimed that your solution is broken if it
invokes infinite recursion and I have shown that a simulating halting
decider needn't be recursive in nature (see my post in comp.theory).

Why don't you try acknowledging and addressing what people actually say
rather than misrepresenting what they say to try to make it fit with
your ongoing false narrative?

>
> There are a sequence of many posts that prove this where you believe
> that removing the infinite loop eliminates the pathological
> relationship.

Nope; see above - your solution is broken if it has an issue with
infinite recursion.

>
> You and Richard are at the bottom 10% of technical competence in this
> forum most everyone else could validate that I am correct.

Are you going to actually address our arguments or are you just going to
rely on ad hominem attacks?

/Flibble

[Freethinker]

>>possible to

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

Oh my God! This is the point where you show (as "IT IS A PROVEN AND
VERIFIED FACT") that you don't understand anything about anything at all.

It would even be impossible to start teaching you anything whatsoever.
Your mind just doesn't work the way it should for it to grasp what it's
being taught.

If I had a pupil like you in school I would call his parents and
recommend them to change school. In your case I recommend to change the
subject: maths and computer science just aren't for you. You would
however make a great artist.

[olcott]

Carefully study the first page of my paper and see if you think the same
thing.

*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

[Bonita Montero]

Am 12.07.2022 um 14:48 schrieb olcott:

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

Seeing the big picture here means that it is pointless
to deal with this topic so fruitlessly for years.

[Otto J. Makela]

olcott <No...@NoWhere.com> wrote:

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

"Most everyone" here who sees this, please raise your hand now?

Followup-to: comp.theory
--
/* * * Otto J. Makela <o...@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */