Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"It's like deja vu all over again." -- Yogi Berra


computers / comp.theory / Re: Here is what a computer scientist that has been published in CACM said about my work [competence?]

Re: Here is what a computer scientist that has been published in CACM said about my work [competence?]

<r9DKK.750232$ntj.655539@fx15.iad>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=37765&group=comp.theory#37765

  copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx15.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.12.0
Subject: Re: Here is what a computer scientist that has been published in CACM
said about my work [competence?]
Content-Language: en-US
Newsgroups: comp.theory
References: <VUmdneqWu_jdjGT_nZ2dnZfqlJ_NnZ2d@giganews.com>
<cveKK.768959$ssF.612517@fx14.iad>
<2h-dnZQ8E7yD42T_nZ2dnZfqlJ9g4p2d@giganews.com>
<SzfKK.916573$JVi.396684@fx17.iad>
<MLOcnbPjLuakG2T_nZ2dnZfqlJ9g4p2d@giganews.com>
<UqgKK.136200$Me2.116425@fx47.iad>
<_KucnbJJWuzxAWT_nZ2dnZfqlJ_NnZ2d@giganews.com>
<HkhKK.793605$wIO9.479008@fx12.iad>
<PuidnRegb5XZOWT_nZ2dnZfqlJxh4p2d@giganews.com>
<OFhKK.730625$5fVf.417433@fx09.iad>
<Otqdnd4GfKOiNWT_nZ2dnZfqlJxh4p2d@giganews.com>
<KZhKK.772181$zgr9.340328@fx13.iad>
<tEmdnfEhQrIvM2T_nZ2dnZfqlJ_NnZ2d@giganews.com>
<sqqKK.137501$Me2.29783@fx47.iad>
<T9GdncITtZzow2f_nZ2dnZfqlJ9g4p2d@giganews.com>
<d2AKK.1016233$X_i.4836@fx18.iad>
<t5idnUq6Z-PBRWf_nZ2dnZfqlJzNnZ2d@giganews.com>
<3BBKK.730686$5fVf.367715@fx09.iad>
<Vp6dnZdlCtCndWf_nZ2dnZfqlJzNnZ2d@giganews.com>
<82CKK.917261$JVi.344055@fx17.iad>
<V86dnTZgD6Bacmf_nZ2dnZfqlJzNnZ2d@giganews.com>
<IGCKK.131460$dh2.119930@fx46.iad>
<rf6dne7Bna80ZGf_nZ2dnZfqlJzNnZ2d@giganews.com>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <rf6dne7Bna80ZGf_nZ2dnZfqlJzNnZ2d@giganews.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 314
Message-ID: <r9DKK.750232$ntj.655539@fx15.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Mon, 15 Aug 2022 22:20:06 -0400
X-Received-Bytes: 16437
 by: Richard Damon - Tue, 16 Aug 2022 02:20 UTC

On 8/15/22 9:58 PM, olcott wrote:
> On 8/15/2022 8:47 PM, Richard Damon wrote:
>>
>> On 8/15/22 9:16 PM, olcott wrote:
>>> On 8/15/2022 8:04 PM, Richard Damon wrote:
>>>> On 8/15/22 8:43 PM, olcott wrote:
>>>>> On 8/15/2022 7:33 PM, Richard Damon wrote:
>>>>>> On 8/15/22 7:36 PM, olcott wrote:
>>>>>>> On 8/15/2022 5:47 PM, Richard Damon wrote:
>>>>>>>> On 8/15/22 10:56 AM, olcott wrote:
>>>>>>>>> On 8/15/2022 6:50 AM, Richard Damon wrote:
>>>>>>>>>> On 8/14/22 10:26 PM, olcott wrote:
>>>>>>>>>>> On 8/14/2022 9:14 PM, Richard Damon wrote:
>>>>>>>>>>>> On 8/14/22 9:58 PM, olcott wrote:
>>>>>>>>>>>>> On 8/14/2022 8:52 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 8/14/22 9:41 PM, olcott wrote:
>>>>>>>>>>>>>>> On 8/14/2022 8:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 8/14/22 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 8/14/2022 7:28 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 8/14/22 7:33 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 8/14/2022 6:29 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 8/14/22 6:58 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 8/14/2022 5:16 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 8/14/22 5:52 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> Mr Flibble <flibble@reddwarf.jmc.corp> Wrote in
>>>>>>>>>>>>>>>>>>>>>>> message:r
>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 14 Aug 2022 14:18:53 -0500olcott
>>>>>>>>>>>>>>>>>>>>>>>> <NoOne@NoWhere.com> wrote:> On 8/14/2022 2:14
>>>>>>>>>>>>>>>>>>>>>>>> PM, Mr Flibble wrote:> > On Sun, 14 Aug 2022
>>>>>>>>>>>>>>>>>>>>>>>> 10:14:28 -0500> > olcott <NoOne@NoWhere.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:> >   > >> *This is refers to H(P,P)==0
>>>>>>>>>>>>>>>>>>>>>>>> where H and P are functions in C*> >>> >>
>>>>>>>>>>>>>>>>>>>>>>>> I believe I have learned something valuable from
>>>>>>>>>>>>>>>>>>>>>>>> you:> >> that by simulation, and by simulations
>>>>>>>>>>>>>>>>>>>>>>>> within simulations,> >> non-halting can
>>>>>>>>>>>>>>>>>>>>>>>> sometimes be detected, and in particular,> >> it
>>>>>>>>>>>>>>>>>>>>>>>> can be detected in the program used in the
>>>>>>>>>>>>>>>>>>>>>>>> classical> >> proof of incomputability.> >>> >>
>>>>>>>>>>>>>>>>>>>>>>>> *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>
>>>>>>>>>>>>>>>>>>>>>>>> >>  > > > > I am also a computer scientist and I
>>>>>>>>>>>>>>>>>>>>>>>> am telling you that your> > halting decider
>>>>>>>>>>>>>>>>>>>>>>>> reporting non-halting when it enters "infinite>
>>>>>>>>>>>>>>>>>>>>>>>> > recursion" is an ERROR.  There is no infinite
>>>>>>>>>>>>>>>>>>>>>>>> recursion in the HP> > proofs you are attempting
>>>>>>>>>>>>>>>>>>>>>>>> to refute.> > > > /Flibble> > > > > void P(ptr
>>>>>>>>>>>>>>>>>>>>>>>> x)> {> int Halt_Status = H(x, x);> if
>>>>>>>>>>>>>>>>>>>>>>>> (Halt_Status)>      HERE: goto HERE;> return;>
>>>>>>>>>>>>>>>>>>>>>>>> }> > int main()> {> Output("Input_Halts = ",
>>>>>>>>>>>>>>>>>>>>>>>> H(P, P));> }> > If it was true that you are a
>>>>>>>>>>>>>>>>>>>>>>>> computer scientist then you would > understand
>>>>>>>>>>>>>>>>>>>>>>>> that this execution trace is correct:> > (a)
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) simulates P(P) that calls a simulated
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)> (b) that simulates P(P) that calls a
>>>>>>>>>>>>>>>>>>>>>>>> simulated H(P,P)> (c) that simulates P(P) that
>>>>>>>>>>>>>>>>>>>>>>>> calls a simulated H(P,P)> (d) that simulates
>>>>>>>>>>>>>>>>>>>>>>>> P(P) that calls a simulated H(P,P)...> *Until H
>>>>>>>>>>>>>>>>>>>>>>>> aborts its simulation*I am a computer scientist
>>>>>>>>>>>>>>>>>>>>>>>> and all your trace shows is that H (not P) isat
>>>>>>>>>>>>>>>>>>>>>>>> the root of your so called "infinite recursion"
>>>>>>>>>>>>>>>>>>>>>>>> and is the primaryreason why you are incorrect
>>>>>>>>>>>>>>>>>>>>>>>> to map this recursive behaviour of your Hto a
>>>>>>>>>>>>>>>>>>>>>>>> halting decision on P of non-halting.> > If you
>>>>>>>>>>>>>>>>>>>>>>>> do not understand that the above execution trace
>>>>>>>>>>>>>>>>>>>>>>>> is correct> then this proves that you are not as
>>>>>>>>>>>>>>>>>>>>>>>> much as a sufficiently competent > software
>>>>>>>>>>>>>>>>>>>>>>>> engineer.It seems I understand your trace more
>>>>>>>>>>>>>>>>>>>>>>>> than you do which makes itobvious who is
>>>>>>>>>>>>>>>>>>>>>>>> actually lacking in competence here./Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Because H exactly simulates its input and has no
>>>>>>>>>>>>>>>>>>>>>>> control flow
>>>>>>>>>>>>>>>>>>>>>>>   behavior of it's own while it is simulating
>>>>>>>>>>>>>>>>>>>>>>> this input YOU ARE
>>>>>>>>>>>>>>>>>>>>>>>   BLAMING THE MIRROR FOR WHAT IT REFLECTS.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> H does have control low on its own, or it can't
>>>>>>>>>>>>>>>>>>>>>> stop the simulationg to give an answer.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Because H exactly simulates its input and has no
>>>>>>>>>>>>>>>>>>>>> control flow
>>>>>>>>>>>>>>>>>>>>> behavior of it's own
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> while it is simulating this input
>>>>>>>>>>>>>>>>>>>>> YOU ARE BLAMING THE MIRROR FOR WHAT IT REFLECTS.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> So either you are a liar, or just badly confused
>>>>>>>>>>>>>>>>>>>>>> about what you are saying.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Or you OCD prevents you from paying close enough
>>>>>>>>>>>>>>>>>>>>> attention to ALL of my words.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Then how does it decide to stop simulating if it has
>>>>>>>>>>>>>>>>>>>> no control flow before it stops?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H does not have any effect on the behavior of its
>>>>>>>>>>>>>>>>>>> simulated P the whole time that H is simulating P,
>>>>>>>>>>>>>>>>>>> thus any recursive behavior that P demonstrates is
>>>>>>>>>>>>>>>>>>> behavior of P and not behavior of H.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, the problem is in H, not P.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This H by its actions might not affect the behavior of
>>>>>>>>>>>>>>>>>> the input it is simulating, but it doesn't correctly
>>>>>>>>>>>>>>>>>> determine the effect that the copy of H in P will have.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>>    if (Halt_Status)
>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>>    return;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>    Output("Input_Halts = ", H(P, P));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So you disagree with this:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (a) H(P,P) simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>>>>>>> (b) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>>>>>>> (c) that simulates P(P) that calls a simulated H(P,P)
>>>>>>>>>>>>>>>>> (d) that simulates P(P) that calls a simulated H(P,P)...
>>>>>>>>>>>>>>>>> *Until H aborts its simulation*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That isn't what your H does,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why do you say that isn't what my H does when you know
>>>>>>>>>>>>>>> that it is what my H does and you can verify this with
>>>>>>>>>>>>>>> the complete system?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.liarparadox.org/2022_07_22.zip
>>>>>>>>>>>>>>> This is the complete system that compiles under:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Microsoft Visual Studio Community 2017
>>>>>>>>>>>>>>> https://visualstudio.microsoft.com/vs/older-downloads/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, you didn't read what I said you H does, did you?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You said that what I said H does, it does not do, this is
>>>>>>>>>>>>> incorrect.
>>>>>>>>>>>>> Then you changed the subject.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> You H does NOT get to the step (b) that you have posted, so
>>>>>>>>>>>> doesn't match you pattern.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> One H does not get past step (b)
>>>>>>>>>>> The other H does not get past step (c) and can be adapted to
>>>>>>>>>>> proceed any finite number of steps.
>>>>>>>>>>>
>>>>>>>>>>> The point is that no correct simulation of the input to
>>>>>>>>>>> H(P,P) by H ever stops running until H aborts it.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope, look at the code you provided.
>>>>>>>>> Liar
>>>>>>>>>
>>>>>>>>
>>>>>>>> Are you saying the code you provided DOESN'T abort the
>>>>>>>> simulation done by H(P,P) at the point where P(P) calls H(P,P)?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> The algorithm implemented by H:
>>>>>>> The correct simulation by H(P,P), never stops running until H
>>>>>>> aborts it.
>>>>>>
>>>>>> No, the algorithm implemented by your H is to abort the simulation
>>>>>> of P(P) as soon as it calls H(P,P).
>>>>> So you don't know the difference between an algorithm and its
>>>>> implementation?
>>>>>
>>>>> https://www.geeksforgeeks.org/introduction-to-algorithms/
>>>>>
>>>>> The algorithm: A simulating halt decider (SHD) continues to
>>>>> simulate its input until it correctly matches a non-halting
>>>>> behavior pattern or the input halts on its own. If a non-halting
>>>>> behavior pattern is matched then the SHD aborts the simulation of
>>>>> its input and reports non-halting. If the input halts on its own
>>>>> the SHD report halting.
>>>>>
>>>>
>>>> Right. But, to be an algorithm, you need to SPECIFY the list of
>>>> non-halting behavior patterns, not just say it "match one" without
>>>> providing them,
>>>>
>>>
>>> Then call it a high level design.
>>>
>>>> Note, from the page you mention:
>>>> Finite-ness: The algorithm must be finite, i.e. it should terminate
>>>> after a finite time.
>>>>
>>>> "Proving a pattern is non-halting" is not a finite algorithm.
>>>>
>>>
>>> My detailed design only needs to apply to this pattern:
>>>     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
>>>
>>>> "Proving" something is not an algorithmic step, as there is no
>>>> guarantee that something CAN be proved in finite time.
>>>
>>> I have proved that it can be proved in the above example.
>>>
>>>>
>>>> That is just the assuming a Halt Decider exists fallacy.
>>>>
>>>> The pattern you CLAIM, is proved to not be correct, so your specific
>>>> implementation is incorrect.
>>>>
>>>
>>> I prove that the input does not halt, it is no rebuttal at all (and
>>> ridiculously stupid) to say that my system does not work on a non-input.
>>>
>>>> Obviously, you still don't understand what an algorithm is.
>>>>  > Remember, the concept of an algorithm is that it is detailed
>>>> enough that
>>>> a simple program could just code based on the description (or
>>>> someone could just execute it by following it).
>>>>
>>>
>>> Call it a high level design.
>>
>> But it thus isn't an algorithm, so you need to specify it tighter to
>> call it one
>>
>>>
>>>> Without an actual list of patterns, it can't just be followed.
>>>>
>>>
>>> (a) Infinite loop
>>> (b) infinite recursion
>>> (c) infinitely recursive simulation either as an adaption to (b)
>>> or exactly the same as (b).
>>
>> Doesn't define what to look for, so not actually a list of patterns.
> THIS IS SUFFICIENT FOR EVERY EXCEPTIONALLY TALENTED SOFTWARE ENGINEER TO
> IMPLEMENT A SHD THAT CORRECTLY DETERMINES THE HALT STATUS OF THE ABOVE
> PATHOLOGICAL INPUT:
>
> The algorithm: A simulating halt decider (SHD) continues to simulate its
> input until it correctly matches a non-halting behavior pattern or the
> input halts on its own. If a non-halting behavior pattern is matched
> then the SHD aborts the simulation of its input and reports non-halting.
> If the input halts on its own the SHD report halting.
>
> INSSTEAD OF PLAYING HEAD GAMES LET'S JUST AGREE ON THAT
>

Then why does it get the wrong answer?

Because you wrote it to the wrong question!

H(P,P) is SUPPOSED to tell us what P(P) will do, after all, that is what
the P you provide is asking it.

H is WRONG for that.

The problem is you just don't know how to write an implemententable
specification, because you just don't understand what that mean\s.

You just THINK that there exist a "non-halting behavior pattern" that H
can match is its simulation of P(P).

You have said what you think that pattern is, but it is show to be
incorrect, as the P(P) based on the H that uses that pattern halts, so
the pattern isn't correct.

You are just living in a world where you have assumed that Fairy Dust
Powered Unicord exist, and they can magically make what you need happen.

Your Halt Decider to do its job needs to be given a Halt Decider. And
that Halr Decider to do its job will be needed to be given another,
better, Halt Decider, and so on until your algorithm is no longer finite.

YOU FAIL.

SubjectRepliesAuthor
o Here is what a computer scientist that has been published in CACM

By: olcott on Sun, 14 Aug 2022

234olcott
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor