Tuesday, July 12, 2022

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

Juha Nieminen <nospam@thanks.invalid>: Jul 12 09:52AM

> 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.
Vir Campestris <vir.campestris@invalid.invalid>: Jul 12 11:27AM +0100

On 12/07/2022 10:52, Juha Nieminen 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.
 
But yes, some are worse than others.
 
Andy
Bonita Montero <Bonita.Montero@gmail.com>: Jul 12 02:29PM +0200

Am 12.07.2022 um 11:52 schrieb Juha Nieminen:
>> 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.
Bonita Montero <Bonita.Montero@gmail.com>: Jul 12 02:46PM +0200

Am 12.07.2022 um 14:29 schrieb Bonita Montero:
 
>> 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.
olcott <NoOne@NoWhere.com>: Jul 12 07:45AM -0500

On 7/12/2022 7:29 AM, Bonita Montero wrote:
 
>> 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.
 
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.
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@NoWhere.com>: Jul 12 07:45AM -0500

On 7/12/2022 7:29 AM, Bonita Montero wrote:
 
>> 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.
 
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.
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@NoWhere.com>: Jul 12 07:48AM -0500

On 7/12/2022 7:46 AM, Bonita Montero wrote:
 
> 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.
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Freethinker <freethinker@mymail.com>: Jul 12 04:14PM +0200

On 12.07.22 01:14, olcott wrote:
 
> 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?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 12 01:01PM -0700

On 7/12/2022 3:27 AM, Vir Campestris wrote:
 
> 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...
 
 
> But yes, some are worse than others.
 
Big time. Some people have to wash their hands 42 times a day. No more,
no less.
Lynn McGuire <lynnmcguire5@gmail.com>: Jul 12 02:39PM -0500

On 7/8/2022 3:48 PM, olcott wrote:
 
>> Complicated as usual.
 
>> Lynn
 
> https://stackoverflow.com/questions/29944745/get-osversion-in-windows-using-c
 
Does not cover Windows 11.
 
Lynn
olcott <NoOne@NoWhere.com>: Jul 11 06:30PM -0500

On 7/11/2022 6:23 PM, Richard Damon wrote:
 
> Except that P only calls H in infinite recursion if H doesn't know
> enough to stop the recursion, at which point it can't answer non-halting.
 
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.
 
*if you are saying that the simulated P can possibly*
*terminate normally then your software engineering*
*skills are woefully inadequate*
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Richard Damon <Richard@Damon-Family.org>: Jul 11 10:06PM -0400

On 7/11/22 7:30 PM, olcott wrote:
 
> *if you are saying that the simulated P can possibly*
> *terminate normally then your software engineering*
> *skills are woefully inadequate*
 
P terminates normally if, and only if, H(P,P) returns 0.
 
Thus H(P,P) can NEVER be returning 0 correctly, since by the definition
of P that answer is wrong. Remember the DEFINITION of P, P will be given
an input so that it asks H to tell it what it will do given its input,
and then do the opposite. So if H says that P given P will never halt,
it will halt. (The only way P can fail is if H never returns, at which
point H fails to be the decider it is required to be).
 
The input to H(P,P) MUST represent P(P), or your P isn't written
correctly, as P is DEFINED to ask H about itself applied to its input,
thus H(P,P) MUST refer to P(P) or you haven't defined things correctly.
 
if H can't be asked about P(P), then H just fails to be the needed
decider, as H needs to be able to be asked about ANY machine with ANY
input. (Not just every machine that can be encoded to it, if some
machine can't be encoded, it just FAIL to be the requried computation).
olcott <NoOne@NoWhere.com>: Jul 11 09:41PM -0500

On 7/11/2022 9:06 PM, Richard Damon wrote:
>> *terminate normally then your software engineering*
>> *skills are woefully inadequate*
 
> P terminates normally if, and only if, H(P,P) returns 0.
 
*The simulated P never returns normally no matter what*
*The simulated P never returns normally no matter what*
*The simulated P never returns normally no matter what*
 
I am not going to go around and around with you on your strawman
deception, this may be the last time that I ever talk to you unless you
once-and-for-all utterly abandon every slight nuance of any attempt to
deceive.
 
*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man
 
My words have finally become clear enough that I maintained a dialogue
with a leading computer scientist for 23 emails over the weekend.
 
 
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Juha Nieminen <nospam@thanks.invalid>: Jul 12 09:48AM

> to know jack shit about software engineering.
 
> Most crucially they don't understand that a function called in infinite
> recursion never returns to its caller.
 
It appears to me that you are just making up excuses to *not* go to the
actual experts on the subject matter, for your work to be actually
scrutinized and criticized and any possible flaws and errors pointed out.
 
Most people in comp.lang.c++ are C++ programmers, not mathematicians with
an expertise in computer science. You are not going to get any actual good
feedback and criticism here. But time and again you refuse to go to a forum
where you would.
 
I think that's because deep down you *know* that there's something wrong
with your work, and you just don't want it to be pointed out.
 
You claiming that your own proof is correct has about as much credibility
as you declaring yourself the winner of a debate.
Juha Nieminen <nospam@thanks.invalid>: Jul 12 09:49AM

> No. He is a world class computer scientist that I reached out to at
> random. He was unable to validate my work because he did not know the
> x86 language. He found no mistakes with my work.
 
"Found no mistakes" does not mean the same thing as "corroborated as being
valid". It could simply mean that he didn't bother. (Even if it meant that
he was unable doesn't mean that the proof is actually correct. It simply
means that this one person was unable to find the error.)
Richard Damon <Richard@Damon-Family.org>: Jul 12 07:18AM -0400

On 7/11/22 10:41 PM, olcott wrote:
 
> *The simulated P never returns normally no matter what*
> *The simulated P never returns normally no matter what*
> *The simulated P never returns normally no matter what*
 
WRONG. If H(P,P) returns 0, then P(P) will return normally.
 
If you saw the code:
 
void foo(void* bar) {
if(baz(bar, bar) {
while(1) continue;
}
return;
}
 
wouldn't you say that foo will return normally ANYTIME baz(bar,bar)
returns 0?
 
Isn't that what the code says?
 
The problem is you think that H is somehow able to be two different
programs at the same time.
 
That it can get stuck in the infinite recursion when P call it, but not
when main calls it, which only proves that your H, if it does actually
exists and does what you claim, isn't actually a pure function of its
inputs (or is just plain wrong).
 
> deception, this may be the last time that I ever talk to you unless you
> once-and-for-all utterly abandon every slight nuance of any attempt to
> deceive.
 
Why do you keep on insisting of making false statements
 
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
 
Which is what YOU keep on settting up.
 
You make a strawman of having two different defintions of your H, or you
assume that H can do something you haven't actually proven it can do.
 
Please PRECISELY identify what "strawman" I have brought up.
 
H(P,P) MUST be deciding on the behavior of P(P) or P isn't the function
it is defined to be.
 
 
> My words have finally become clear enough that I maintained a dialogue
> with a leading computer scientist for 23 emails over the weekend.
 
No, you have just gotten better and being glib and making your lies
sound more possible.
 
You CLAIM H is correct, but only because you use a fault proof to show
it, claiming a rule that is incorrect.
 
It doesn't matter that there is no conditional in the C function P that
breaks the loop, since the H that P calls is part of the algorithm of P
and that H has the conditional that breaks the loop.
 
You rule in essence says that H is two different functions that don't
behave the same, which is an IMPOSSIBILITY for C or x86 code (that is a
pure function).
 
You make the H that P calls a pure emulator that won't stop, but the H
that main calls stops when it thinks that the behavior is non-halting,
using logic that shows that P will be non-halting if H doesn't abort its
simulation, but since H DOES abort its simulation, that proof isn't
satisfied, so is unsound.
 
The question isn't what does P do if H doesn't abort its simulation, it
is what does P do when H does what it does. If the H(P,P) returns 0,
then what H(P,P) does IS return 0, and there is no H that actually
emulates until it proves its input is actually non-halting.
olcott <NoOne@NoWhere.com>: Jul 12 07:28AM -0500

On 7/12/2022 4:48 AM, Juha Nieminen wrote:
 
> It appears to me that you are just making up excuses to *not* go to the
> actual experts on the subject matter, for your work to be actually
> scrutinized and criticized and any possible flaws and errors pointed out.
 
I had my work extensively reviewed (23 emails) by a leading computer
scientist over the weekend.
 
> an expertise in computer science. You are not going to get any actual good
> feedback and criticism here. But time and again you refuse to go to a forum
> where you would.
 
I already had all the computer science review that I need, Because H is
a pure function we know that H it implements a computable function.
 
> I think that's because deep down you *know* that there's something wrong
> with your work, and you just don't want it to be pointed out.
 
It took me nine months to transform H into a computable function.
 
> You claiming that your own proof is correct has about as much credibility
> as you declaring yourself the winner of a debate.
 
Any software engineer of ordinary skill can easily verify that the
simulated P would never terminate normally.
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
olcott <NoOne@NoWhere.com>: Jul 12 07:30AM -0500

On 7/12/2022 4:49 AM, Juha Nieminen wrote:
> valid". It could simply mean that he didn't bother. (Even if it meant that
> he was unable doesn't mean that the proof is actually correct. It simply
> means that this one person was unable to find the error.)
 
For his review my proof could not be fully understood without knowledge
of the x86 language. Back in the day 10% of all programmers knew the x86
language. It seems that there are none of these left so I transformed my
presentation so that a C programmer could validate it.
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
David Brown <david.brown@hesbynett.no>: Jul 12 05:29PM +0200

On 12/07/2022 11:48, Juha Nieminen wrote:
> an expertise in computer science. You are not going to get any actual good
> feedback and criticism here. But time and again you refuse to go to a forum
> where you would.
 
There are a number of people in these groups who have expertise in the
relevant computer science and mathematics. All those that commented,
have discussed the flaws in Olcott's reasoning. People have given good
feedback and helpful criticism. All but a few have given up long ago in
the face of Olcott's insults, arrogance and pig-headedness. Richard
Damon is one of the few who keeps trying, with apparently infinite patience.
 
Some people get themselves stuck in a particular idea, and can't let go
- they have invested too much time, effort and pride to be able to
accept that they are wrong. There are those that are convinced they can
trisect an angle with ruler and compass, or prove that the cardinality
of the integers and reals is the same, or that the world is flat - or
that the halting problem is computable. It doesn't matter what you say
to Olcott, he will always believe he is right and that everyone else is
incompetent or ignorant. The alternative would be for him to accept
that he has wasted years - perhaps decades - with nothing to show but a
dozen lines of meaningless code. I think we just have to let him keep
his harmless fantasy.
 
Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 12 05:39PM +0100

On Mon, 11 Jul 2022 21:41:59 -0500
 
> *The simulated P never returns normally no matter what*
> *The simulated P never returns normally no matter what*
> *The simulated P never returns normally no matter what*
 
I have shown that a simulation-based decider needn't be recursive in
nature and indeed the Halting Problem proofs predicated on [Strachey
1965] mandate no recursion. You are simply barking up the wrong tree
and your decider is worthless and certainly doesn't refute any HP
proofs.
 
/Flibble
olcott <polcott2@gmail.com>: Jul 12 12:30PM -0500

David Brown <david.brown@hesbynett.no> Wrote in message:r
> On 12/07/2022 11:48, Juha Nieminen wrote:> olcott <NoOne@nowhere.com> wrote:>> On 7/11/2022 4:20 AM, Juha Nieminen wrote:>>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote:>>>> After very extensive discussions (23 emails) with a leading computer>>>> scientist I have a much simpler way to make my point.>>>>>> At least you seem to be willing to engage in *some* kind of conversation>>> with experts on the matter.>>>>>> I would still say that you could get much better feedback to your work>>> if you did all these posts in a forum dedicated to computer science and>>> mathematics with an active community of expects, rather than here in>>> some random usenet group (especially since usenet is almost dead, and>>> has been for over a decade).>>>> My proof is verified through software engineering and not verified>> through computer science. The people in the comp.theory forum don't seem>> to know jack shit about software engineering.>>>> Most crucially they don't understand that a function called in infinite>> recursion never returns to its caller.> > It appears to me that you are just making up excuses to *not* go to the> actual experts on the subject matter, for your work to be actually> scrutinized and criticized and any possible flaws and errors pointed out.> > Most people in comp.lang.c++ are C++ programmers, not mathematicians with> an expertise in computer science. You are not going to get any actual good> feedback and criticism here. But time and again you refuse to go to a forum> where you would.> There are a number of people in these groups who have expertise in the relevant computer science and mathematics. All those that commented, have discussed the flaws in Olcott's reasoning. People have given good feedback and helpful criticism. All but a few have given up long ago in the face of Olcott's insults, arrogance and pig-headedness. Richard Damon is one of the few who keeps trying, with apparently infinite patience.Some people get themselves stuck in a particular idea, and can't let go - they have invested too much time, effort and pride to be able to accept that they are wrong. There are those that are convinced they can trisect an angle with ruler and compass, or prove that the cardinality of the integers and reals is the same, or that the world is flat - or that the halting problem is computable. It doesn't matter what you say to Olcott, he will always believe he is right and that everyone else is incompetent or ignorant. The alternative would be for him to accept that he has wasted years - perhaps decades - with nothing to show but a dozen lines of meaningless code. I think we just have to let him keep his harmless fantasy.> I think that's because deep down you *know* that there's something wrong> with your work, and you just don't want it to be pointed out.> > You claiming that your own proof is correct has about as much credibility> as you declaring yourself the winner of a debate.
 
Richard and Flibble do not understand that when a function is
called in what is essentially infinite recursion this function
never returns to it's caller.
 
Furthermore the calling function cannot possibly terminate normally.
--
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 12 07:00PM +0100

On Tue, 12 Jul 2022 12:30:59 -0500 (CDT)
> called in what is essentially infinite recursion this function
> never returns to it's caller.
 
> Furthermore the calling function cannot possibly terminate normally.
 
[Strachey 1965] doesn't have any infinite recursion. The HP proofs do
not have any infinite recursion. I have shown it is possible to create
simulation-based halting decider without any infinite recursion. The
only thing that has infinite recursion is your broken solution.
 
/Flibble
olcott <polcott2@gmail.com>: Jul 12 02:23PM -0500

Mr Flibble <flibble@reddwarf.jmc.corp> Wrote in message:r
> On Mon, 11 Jul 2022 21:41:59 -0500olcott <NoOne@NoWhere.com> wrote:> On 7/11/2022 9:06 PM, Richard Damon wrote:> > On 7/11/22 7:30 PM, olcott wrote: > >> On 7/11/2022 6:23 PM, Richard Damon wrote: > >>> On 7/11/22 2:43 PM, olcott wrote: > >>>> On 7/11/2022 11:09 AM, Muttley@dastardlyhq.com wrote: > >>>>> On Mon, 11 Jul 2022 08:24:38 -0500> >>>>> olcott <NoOne@NoWhere.com> wrote: > >>>>>> On 7/11/2022 4:41 AM, Muttley@dastardlyhq.com wrote: > >>>>>>> On Mon, 11 Jul 2022 09:20:09 -0000 (UTC)> >>>>>>> Juha Nieminen <nospam@thanks.invalid> wrote: > >>>>>>>> In comp.lang.c++ olcott <NoOne@nowhere.com> wrote: > >>>>>>>>> After very extensive discussions (23 emails) with a leading > >>>>>>>>> computer> >>>>>>>>> scientist I have a much simpler way to make my point. > >>>>>>>>> >>>>>>>> At least you seem to be willing to engage in *some* kind of > >>>>>>>> conversation> >>>>>>>> with experts on the matter. > >>>>>>>> >>>>>>> Its probably a friend of his. > >>>>>>> >>>>>> No. He is a world class computer scientist that I reached out> >>>>>> to at random. He was unable to validate my work because he did> >>>>>> not know the x86 language. He found no mistakes with my work. > >>>>>> >>>>> If he didn't validate it then he wouldn't find any mistakes> >>>>> would he. I imagine> >>>>> he had more important things to do than get into a discussion> >>>>> with a crank.> >>>>> Probably some urgent coffee to make or paper to shuffle.> >>>>> > >>>>> >>>> On the basis of his feedback I rewrote the first page so that it> >>>> can be understood to be correct with only ordinary understanding> >>>> of the C programming language and software engineering.> >>>>> >>>> The first page of this updated paper makes my point much more > >>>> clearly in that it requires no knowledge of the x86 assembly > >>>> language. The subsequent pages can be skipped.> >>>>> >>>> Simulating halt decider H(P,P) detects that its simulated P is > >>>> essentially calling it in infinite recursion, H aborts its > >>>> simulation of this input then rejects it as non-halting.> >>>>> >>>> typedef void (*ptr)();> >>>> int H(ptr p, ptr i);> >>>>> >>>> void P(ptr x)> >>>> {> >>>> if (H(x, x))> >>>> HERE: goto HERE;> >>>> return;> >>>> }> >>>> int main()> >>>> {> >>>> Output("Input_Halts = ", H(P, P));> >>>> }> >>>>> >>>> *Halting problem proofs refuted on the basis of software> >>>> engineering*> >>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering > >>>>> >>>>> >>>>> >>>> > >>>> >>> Except that P only calls H in infinite recursion if H doesn't> >>> know enough to stop the recursion, at which point it can't answer > >>> non-halting. > >>> >> 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.> >>> >> *if you are saying that the simulated P can possibly*> >> *terminate normally then your software engineering*> >> *skills are woefully inadequate*> >> > > > > P terminates normally if, and only if, H(P,P) returns 0. > > *The simulated P never returns normally no matter what*> *The simulated P never returns normally no matter what*> *The simulated P never returns normally no matter what*I have shown that a simulation-based decider needn't be recursive innature and indeed the Halting Problem proofs predicated on [Strachey1965] mandate no recursion. You are simply barking up the wrong treeand your decider is worthless and certainly doesn't refute any HPproofs./Flibble
 
You continue to fail to understand that every halting problem
pathological input to H never terminates normally.
 
 
--
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
olcott <polcott2@gmail.com>: Jul 12 11:34AM -0500

Richard Damon <Richard@Damon-Family.org> Wrote in message:r
> On 7/2/22 11:34 AM, olcott wrote:> This much more concise version of my paper focuses on the actual> execution of three fully operational examples.> > H0 correctly determines that Infinite_Loop() never halts> H correctly determines that Infinite_Recursion() never halts> H correctly determines that P() never haltsExcept that if H(P,P) actually returns 0, then P(P) will halt, so H is wrong.You can't just define the wrong answer to be right. And, your dishonest dodge that H(P,P) doesn't actually refer to P(P) says that P isn't the program you claim, as the P is DEFINED to ask H about ITSELF with its input, so if H(P,P) doesn't mean that, then you have defined something wrong.The problem is your logic doesn't actually correctly consider the behavior of the H being called, so doesn't actually do a correct x86 emulation of its input.> > void P(u32 x)> {> if (H(x, x))> HERE: goto HERE;> return;> }> > int main()> {> Output("Input_Halts = ", H((u32)P, (u32)P));> }> > As shown below the above P and H have the required (halting problem) > pathological relationship to each other:> > 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> > I really need software engineers to verify that H does correctly predict > that its complete and correct x86 emulation of its input would never > reach the "ret" instruction of this input.> > *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 > >
 
You are simply not bright enough to understand that every function
called (what is essentially) infinite never returns any value to
it's caller.
 
--
 
 
----Android NewsGroup Reader----
https://piaohong.s3-us-west-2.amazonaws.com/usenet/index.html
Bonita Montero <Bonita.Montero@gmail.com>: Jul 12 07:49PM +0200

Am 12.07.2022 um 18:34 schrieb olcott:
 
> You are simply not bright enough to understand that every function
> called (what is essentially) infinite never returns any value to
> it's caller.
 
Come back when you've got sth. that's really related to C or C++.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)