Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

I *____knew* I had some reason for not logging you off... If I could just remember what it was.


computers / comp.ai.philosophy / Re: Are my reviewers incompetent or dishonest? [ closure on one point ? ]

Re: Are my reviewers incompetent or dishonest? [ closure on one point ? ]

<98ednSKRt-qvIxf_nZ2dnUU7_8zNnZ2d@giganews.com>

  copy mid

https://www.novabbs.com/computers/article-flat.php?id=8910&group=comp.ai.philosophy#8910

  copy link   Newsgroups: comp.theory comp.ai.philosophy sci.logic
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!buffer2.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 22 May 2022 17:50:26 -0500
Date: Sun, 22 May 2022 17:50:25 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Subject: Re: Are my reviewers incompetent or dishonest? [ closure on one point
? ]
Content-Language: en-US
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
References: <20220514170555.00004550@reddwarf.jmc>
<r%fiK.28447$J0r9.3351@fx11.iad>
<I6idnSDl8NcUDRT_nZ2dnUU7_83NnZ2d@giganews.com> <s5hiK.45$cq8.28@fx03.iad>
<NtGdndBRE5xLAhT_nZ2dnUU7_83NnZ2d@giganews.com>
<MlhiK.9438$kaDc.6185@fx46.iad>
<h6OdnUIaNIYVORT_nZ2dnUU7_81g4p2d@giganews.com>
<K4iiK.20028$zgr9.11815@fx13.iad>
<RrSdna_nM600MhT_nZ2dnUU7_8xh4p2d@giganews.com>
<HtiiK.3779$45E8.1989@fx47.iad>
<RtudndMn4p2gKBT_nZ2dnUU7_8xh4p2d@giganews.com>
<DEiiK.9440$kaDc.4559@fx46.iad>
<xoKdnSPcs6RjXhT_nZ2dnUU7_8zNnZ2d@giganews.com>
<xOoiK.1639$gjlb.707@fx44.iad>
<5oKdnSRTHInY0hf_nZ2dnUU7_8zNnZ2d@giganews.com>
<BqtiK.4006$45E8.3623@fx47.iad>
<37ednZeMJLXL-Bf_nZ2dnUU7_83NnZ2d@giganews.com>
<jItiK.2805$vAW9.1754@fx10.iad>
<29-dndh0aZ2U9Rf_nZ2dnUU7_8xh4p2d@giganews.com> <xwuiK.795$8T.565@fx40.iad>
<_tOdnaZ1Xa1sOBf_nZ2dnUU7_8zNnZ2d@giganews.com>
<w%xiK.4093$Dr6.2187@fx06.iad>
<14mdnbVyJJSlLxf_nZ2dnUU7_8zNnZ2d@giganews.com>
<aUyiK.25550$5fVf.21040@fx09.iad>
From: NoO...@NoWhere.com (olcott)
In-Reply-To: <aUyiK.25550$5fVf.21040@fx09.iad>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <98ednSKRt-qvIxf_nZ2dnUU7_8zNnZ2d@giganews.com>
Lines: 313
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-amiMVk/ovZUP5Lj2LyB5esiW9zJERdYQN/u/hoBtt1fuw0ffE/FfVhHotdxkdK4qnnpLRA4ASGfHCPG!/Nj8qucqVvqwKVaQFTZlHyzAFuLGI/4yA1GuTvdjlta6hsYylN8Jz1k1YBeirLYKtqXAFw50oDk=
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 16745
 by: olcott - Sun, 22 May 2022 22:50 UTC

On 5/22/2022 5:34 PM, Richard Damon wrote:
>
> On 5/22/22 5:59 PM, olcott wrote:
>> On 5/22/2022 4:34 PM, Richard Damon wrote:
>>>
>>> On 5/22/22 5:06 PM, olcott wrote:
>>>> On 5/22/2022 12:36 PM, Richard Damon wrote:
>>>>> On 5/22/22 12:42 PM, olcott wrote:
>>>>>> On 5/22/2022 11:40 AM, Richard Damon wrote:
>>>>>>> On 5/22/22 12:31 PM, olcott wrote:
>>>>>>>> On 5/22/2022 11:21 AM, Richard Damon wrote:
>>>>>>>>> On 5/22/22 10:57 AM, olcott wrote:
>>>>>>>>>> On 5/22/2022 6:06 AM, Richard Damon wrote:
>>>>>>>>>>> On 5/22/22 1:02 AM, olcott wrote:
>>>>>>>>>>>> On 5/21/2022 11:05 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/21/22 11:59 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/21/2022 10:54 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/21/22 11:36 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/21/2022 10:27 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 5/21/22 10:48 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/21/2022 9:37 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 5/21/22 10:28 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 5/21/2022 9:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 5/21/22 9:23 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 5/21/2022 8:05 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 5/21/22 3:38 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You have known that the input to H(P,P) is
>>>>>>>>>>>>>>>>>>>>>>>>>> simulated correctly proving
>>>>>>>>>>>>>>>>>>>>>>>>>> that H(P,P)==0 is correct for the whole six
>>>>>>>>>>>>>>>>>>>>>>>>>> months
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> If H is intended to be a halt decider (even if
>>>>>>>>>>>>>>>>>>>>>>>>> only for the one case you
>>>>>>>>>>>>>>>>>>>>>>>>> claim to care about) then H(P,P) == 0 is wrong,
>>>>>>>>>>>>>>>>>>>>>>>>> because P(P) halts.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> When we correctly reverse-engineer what the
>>>>>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) would be
>>>>>>>>>>>>>>>>>>>>>>>> for one emulation and one nested emulation we
>>>>>>>>>>>>>>>>>>>>>>>> can see that the correctly emulated input to
>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) would never reach its final state at
>>>>>>>>>>>>>>>>>>>>>>>> machine address [0000136c].
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> A nonsense trace, as it is mixing the execution
>>>>>>>>>>>>>>>>>>>>>>> path of two independent execution units.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> In other words you acknowledge that you are
>>>>>>>>>>>>>>>>>>>>>> technically incompetent to provide the execution
>>>>>>>>>>>>>>>>>>>>>> trace of one simulation and one nested simulation
>>>>>>>>>>>>>>>>>>>>>> of the input to H(P,P).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, I am saying that you are asking for the
>>>>>>>>>>>>>>>>>>>>> equivalent of a of a square circle.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So an execution trace of the input to H(P,P) is easy
>>>>>>>>>>>>>>>>>>>> to show when H simulates its input, yet another
>>>>>>>>>>>>>>>>>>>> execution trace of the input to H(P,P) that was
>>>>>>>>>>>>>>>>>>>> invoked by P is "like a square circle" can't
>>>>>>>>>>>>>>>>>>>> possibly exist?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The problem is that your second trace is NOT a piece
>>>>>>>>>>>>>>>>>>> of the first.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The fact you don't understand that says you just
>>>>>>>>>>>>>>>>>>> don't know how computers or programs actually work.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When a UTM simulates a TM description that calls a UTM
>>>>>>>>>>>>>>>>>> that simulates a
>>>>>>>>>>>>>>>>>> TM description all of this is simply data on the first
>>>>>>>>>>>>>>>>>> UTM's tape and the only actual executable is the first
>>>>>>>>>>>>>>>>>> UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes, and a trace made by that outer UTM will show the
>>>>>>>>>>>>>>>>> states that the second UTM is going through, but NOT
>>>>>>>>>>>>>>>>> the states that second UTM simulates in its own
>>>>>>>>>>>>>>>>> processing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> That second UTM might produce its OWN trace of the
>>>>>>>>>>>>>>>>> states that it has simulated, but that is a SEPERATE
>>>>>>>>>>>>>>>>> trace, and NOT part of the trace from the OUTER UTM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And this trace is written to the outer UTM's tape as a
>>>>>>>>>>>>>>>> part of its own data.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, the DATA is there, ENCODED on the tape, but it isn't
>>>>>>>>>>>>>>> part of the trace generated by that UTM.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only actual executable is the outer UTM everything
>>>>>>>>>>>>>> else is a part of the same nested process.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So the only actual valid trace is what that outer simulator
>>>>>>>>>>>>> actual simulated.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> There is a valid trace of every line of code that is
>>>>>>>>>>>> emulated. Operating system code has its trace tuned off.
>>>>>>>>>>>> This only leaves the user code such as P() and main(). Then
>>>>>>>>>>>> we see the 14 lines execution trace of the two level
>>>>>>>>>>>> simulation of the input to H(P,P)
>>>>>>>>>>>
>>>>>>>>>>> No, because the second level emulation is NOT emulated by the
>>>>>>>>>>> top level emulator, its emulator is.
>>>>>>>>>>>
>>>>>>>>>>> Unless you are lying about what H does, you are just lying
>>>>>>>>>>> that the second level code is emulated by the same emulation
>>>>>>>>>>> process that the first is. (That may well be true, but it
>>>>>>>>>>> means you logic is still built on a lie).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If you are too stupid to understand that H(P,P) derives the
>>>>>>>>>> same execution trace of its input every time it is called you
>>>>>>>>>> are far too stupid to evaluate my work.
>>>>>>>>>
>>>>>>>>> Ok, then why does the H(P,P) that P calls get stuck in an
>>>>>>>>> infinite recursion wneh the top level doesn't?
>>>>>>>>
>>>>>>>> It is a verified fact that the correct simulation of the input
>>>>>>>> to H(P,P) never reaches its final instruction thus conclusively
>>>>>>>> proving that it never halts.
>>>>>>>>
>>>>>>>
>>>>>>> The only machine that you have shown that does a correct
>>>>>>> simulation is the version that never aborts. That version fails
>>>>>>> to answer the question, so fails to be a halt decider.
>>>>>>>
>>>>>>> Any version of H that aborts, and returns a not-halting answer
>>>>>>> changes P into a Halting Compuation.
>>>>>>>
>>>>>>> The "pathological" use of H by P lets it change as you change H,
>>>>>>> so if H aborts, it is wrong because THAT P halts, if it doesn't,
>>>>>>> then it is wrong for not answering.
>>>>>>>
>>>>>>> You seem to miss this fact because you just don't understand the
>>>>>>> basics of how computations work. Part of your problem is you keep
>>>>>>> on trying to define H by rules that aren't an actual algorithm,
>>>>>>> so can't actually be written.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It is an easily verifiable fact that the C function H does
>>>>>> correctly determine that the C function named P would never reach
>>>>>> its last instruction when correctly emulated by H.
>>>>>
>>>>> Don't just "Claim" it, so an ACTUAL verification, or you just show
>>>>> yourself to be a liar.
>>>>>
>>>>>>
>>>>>> Everyone disagreeing with verified facts is incorrect on the basis
>>>>>> of lack of technical competency or lack of honesty.
>>>>>
>>>>> You haven't verified ANY fact, you have made claims using FAKE data
>>>>> that don't even really support your claim.
>>>>>
>>>>
>>>> Software engineering experts
>>>> can reverse-engineer what the correct x86 emulation of the input to
>>>> H(P,P) would be for one emulation and one nested emulation thus
>>>> confirming that the provided execution trace is correct. They can do
>>>> this entirely on the basis of the x86 source-code for P with no need
>>>> to see the source-code or execution trace of H.
>>>
>>> Interesting point, that you eed to talk about "reverse-engineering"
>>> this output implies that you don't actually have a program to
>>> generate it.
>>>
>>
>> Not at all. This program took me a whole man-year.
>
> Then why do we need to "reverse-engineer" the trace?
>

It is the only way that you can verify that this trace is correct:

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H

>> The most difficult part was to make the nested simulations work
>> correctly.
>
> Which it seems you failed at. Maybe that is why ot took so long. It is
> hard to make automaticaly believable lies.
>
>>
>>> You don't need to "reverse-engineer" something you have.
>>>
>>
>> No but everyone else does to confirm its correctness because
>> THEY DON'T HAVE IT.
>
> No, you present the trace and people can verify it.
>
> Note, it has been pointed out that it does NOT match what you claim is
> happening, which proves it is WRONG.

THIS HAS NEVER BEEN MORE THAN A BASELESS ASSERTION.

>
> The trace implies that H just calls its input, and hides its own behavior.
>

I hrrd code the system to never output the trace of operating system code.

> If it does that, then it can't abort its trace, or isn't actually a
> computatiopn. (and we see it aborts, and you claim it is a computatiopn)
>
> Thus, the trace is incorrect, or you are lying and the trace doesn't
> matter.
>
>>
>>>
>>>>
>>>> Anyone unable to do this conclusively proves their lack of
>>>> sufficient technical competence.
>>>>
>>>> _P()
>>>> [00001352](01)  55              push ebp
>>>> [00001353](02)  8bec            mov ebp,esp
>>>> [00001355](03)  8b4508          mov eax,[ebp+08]
>>>> [00001358](01)  50              push eax      // push P
>>>> [00001359](03)  8b4d08          mov ecx,[ebp+08]
>>>> [0000135c](01)  51              push ecx      // push P
>>>> [0000135d](05)  e840feffff      call 000011a2 // call H
>>>> [00001362](03)  83c408          add esp,+08
>>>> [00001365](02)  85c0            test eax,eax
>>>> [00001367](02)  7402            jz 0000136b
>>>> [00001369](02)  ebfe            jmp 00001369
>>>> [0000136b](01)  5d              pop ebp
>>>> [0000136c](01)  c3              ret
>>>> Size in bytes:(0027) [0000136c]
>>>>
>>>> Richard was able to correctly determine that the correct simulation
>>>> of the input to H(P,P) would emulate the first 7 lines of P.
>>>>
>>>> Richard was utterly baffled beyond all comprehension that the
>>>> invocation of the same function with the same input would derive the
>>>> same trace.
>>>
>>> No, that is NOT what I said, and you repeating that LIE just shows
>>> you are not intertested in honest answer. I hope what ever review
>>> looks at your final paper (it you ever get to it) and happens to
>>> search and come accross these discussions and sees your level of
>>> dishonesty.
>>>
>>
>> So then you now agree that the nested invocation of H(P,P) would
>> derive the same execution trace of its input that the the outer one did?
>>
>
> Yes seem to have a confusion. Yes, the second simulator will produce and
> identical trace to the first one, AS A SEPERATE TRACE.

I don't have any confusion. You have rebuttal of my work as your only
goal. As soon as I pointed out the a rebuttal of what I said would
directly contradict computer science you backed down because you knew
you couldn't get way with it.

So then you agree that the invocation of H(P,P) would derive the
following trace of its input on the first 7 lines and when P invokes
another instance of H(P,P) this derives the next 7 lines of execution
trace.

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H

>> In order to contradict me you must contradict computer science.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

SubjectRepliesAuthor
o Are my reviewers incompetent or dishonest? [ stupid or liar ? ]

By: olcott on Sun, 22 May 2022

24olcott
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor