On 5/21/22 1:37 PM, olcott wrote:
> On 5/21/2022 12:24 PM, Malcolm McLean wrote:
>> On Saturday, 21 May 2022 at 11:27:41 UTC+1, richar...@gmail.com wrote:
>>> On 5/21/22 12:15 AM, olcott wrote:
>>>> On 5/20/2022 11:10 PM, Dennis Bush wrote:
>>>>> On Saturday, May 21, 2022 at 12:02:33 AM UTC-4, olcott wrote:
>>>>>> On 5/20/2022 10:56 PM, Dennis Bush wrote:
>>>>>>> On Friday, May 20, 2022 at 11:42:55 PM UTC-4, olcott wrote:
>>>>>>>> On 5/20/2022 10:37 PM, Dennis Bush wrote:
>>>>>>>>> On Friday, May 20, 2022 at 11:13:25 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/20/2022 10:06 PM, Dennis Bush wrote:
>>>>>>>>>>> On Friday, May 20, 2022 at 10:45:12 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/20/2022 9:32 PM, Dennis Bush wrote:
>>>>>>>>>>>>> On Friday, May 20, 2022 at 10:17:18 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>> On 5/20/2022 9:09 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 9:59:27 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>> On 5/20/2022 8:51 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 9:42:11 PM UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/20/2022 8:20 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 8:56:09 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> On 5/20/2022 7:32 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 8:15:31 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 7:09 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 7:37:15 PM UTC-4, olcott
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 6:31 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 7:25:15 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 6:21 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 7:13:37 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 6:11 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 7:02:24 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:53 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 6:51:42 PM UTC-4,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:44 PM, Dennis Bush wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Friday, May 20, 2022 at 6:33:29 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UTC-4, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 5/20/2022 5:25 PM, Ben wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> olcott <No...@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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If a "correct simulation of the input to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)" is a simulation of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function call P(P), then H(P,P) == 0 is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong because both P(P) and a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> correct simulation of P(P) halt.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So in other words even though there are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no lines of code that are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated incorrectly you still claim
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the simulation is incorrect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> THAT IS WHAT A DAMNED LYING BASTARD WOULD
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SAY.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So if we look at the execution trace of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ha3(N,5),
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yet another God damned lying bastard that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses the strawman error in an
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> attempt to get away with deception.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So if you believe that Ha3(N,5)==0 is either
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrong or irrelevent you should have no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> problem explaining why without just saying
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "strawman".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am talking about the correct simulation of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the machine language of P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> being correctly emulated by another 100%
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> specific finite string of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> machine language named H.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And by the criteria you use to show that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==0 is correct,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> More than that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prove that the criteria that I use is correct
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and I prove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P)==0 is correct on the basis of that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> criteria.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> The *only* criteria for whether the result of
>>>>>>>>>>>>>>>>>>>>>>>>>>> H(P,P) is correct is whether P(P) halts, *by
>>>>>>>>>>>>>>>>>>>>>>>>>>> definition*.
>>>>>>>>>>>>>>>>>>>>>>>>>> Not for the specific machine language that I am
>>>>>>>>>>>>>>>>>>>>>>>>>> referring to.
>>>>>>>>>>>>>>>>>>>>>>>>>> So OK you prove that you intend to stay in
>>>>>>>>>>>>>>>>>>>>>>>>>> despicable liar mode.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> You proclaim by lying bastard dictatorial fiat
>>>>>>>>>>>>>>>>>>>>>>>>>> that the input to H(P,P)
>>>>>>>>>>>>>>>>>>>>>>>>>> halts even though its correct execution trace
>>>>>>>>>>>>>>>>>>>>>>>>>> proves otherwise.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The input to H(P,P) represents P(P) by definition.
>>>>>>>>>>>>>>>>>>>>>>>> Not when we are talking about C functions and x86
>>>>>>>>>>>>>>>>>>>>>>>> machine-code Jackass.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Then you're not talking about the halting problem,
>>>>>>>>>>>>>>>>>>>>>>> and H is computing something other that the halting
>>>>>>>>>>>>>>>>>>>>>>> function
>>>>>>>>>>>>>>>>>>>>>> None-the-less H(P,P)==0 is proven to be correct.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Only for something that is not the halting problem.
>>>>>>>>>>>>>>>>>>>> So you agree that H(P,P)==0 is correct when H computes
>>>>>>>>>>>>>>>>>>>> the halt status
>>>>>>>>>>>>>>>>>>>> of the machine language of P that is passed to H on the
>>>>>>>>>>>>>>>>>>>> stack as a pair
>>>>>>>>>>>>>>>>>>>> of pointers to the literal string of P?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> If you're referring to *just* the function P, it doesn't
>>>>>>>>>>>>>>>>>>> have a halt status because it's not a complete program.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When we stipulate that the input to H(P,P) only halts
>>>>>>>>>>>>>>>>>> when its correct
>>>>>>>>>>>>>>>>>> simulation reaches its machine address of [000009f0]
>>>>>>>>>>>>>>>>>> otherwise it is
>>>>>>>>>>>>>>>>>> non-halting then H(P,P)==0 is the correct halt status of
>>>>>>>>>>>>>>>>>> the input to
>>>>>>>>>>>>>>>>>> H(P,P).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>>>> [000009d6](01) 55 push ebp
>>>>>>>>>>>>>>>>>> [000009d7](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>>>> [000009d9](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>>>> [000009dc](01) 50 push eax // push P
>>>>>>>>>>>>>>>>>> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>>>>>>>>>> [000009e0](01) 51 push ecx // push P
>>>>>>>>>>>>>>>>>> [000009e1](05) e840feffff call 00000826 // call H
>>>>>>>>>>>>>>>>>> [000009e6](03) 83c408 add esp,+08
>>>>>>>>>>>>>>>>>> [000009e9](02) 85c0 test eax,eax
>>>>>>>>>>>>>>>>>> [000009eb](02) 7402 jz 000009ef
>>>>>>>>>>>>>>>>>> [000009ed](02) ebfe jmp 000009ed
>>>>>>>>>>>>>>>>>> [000009ef](01) 5d pop ebp
>>>>>>>>>>>>>>>>>> [000009f0](01) c3 ret // Final state
>>>>>>>>>>>>>>>>>> Size in bytes:(0027) [000009f0]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But H(P,P) does *not* perform a correct of its input. A
>>>>>>>>>>>>>>>>> correct simulation of this input is done Hb(P,P) which
>>>>>>>>>>>>>>>>> does in fact reach a final state. Therefore H(P,P)==0 is
>>>>>>>>>>>>>>>>> wrong.
>>>>>>>>>>>>>>>> OK then when the literal string of the machine code of H
>>>>>>>>>>>>>>>> correctly
>>>>>>>>>>>>>>>> emulates
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which is doesn't as demonstrated by Hb(P,P) reaching a final
>>>>>>>>>>>>>>> state and returning 1.
>>>>>>>>>>>>>> H is at machine address 00000826 every other variation is a
>>>>>>>>>>>>>> dishonest
>>>>>>>>>>>>>> dodge away from the actual question.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And since the fixed H is programmed to abort
>>>>>>>>>>>> This is not true and we are not yet discussing that aspect of
>>>>>>>>>>>> it yet.
>>>>>>>>>>>
>>>>>>>>>>> It must be, otherwise you have nothing to decide on. Remember, P
>>>>>>>>>>> is a *complete* program, which means the H is called must be
>>>>>>>>>>> fully defined and fixed.
>>>>>>>>>>>
>>>>>>>>>> It is ridiculously stupid to say that a halt decider has a fixed
>>>>>>>>>> behavior.
>>>>>>>>>
>>>>>>>>> You have it backwards. It is ridiculously stupid to say that *any*
>>>>>>>>> computation, *including* a halt decider, does NOT have a fixed
>>>>>>>>> behavior. That's how a given input always gives the same output.
>>>>>>>> It has a different behavior for every input, nitwit.
>>>>>>>> How stupid can you get?
>>>>>>>
>>>>>>> Perhaps that was worded incorrectly. The *algorithm* of a
>>>>>>> computation is fixed, which in turn means its behavior is fixed for
>>>>>>> a given input.
>>>>>> Heh that is great. Yeah !!!
>>>>>> I gave you feedback and we came to mutual agreement.
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> given an input of the function domain it can return the
>>>>>>>>>> corresponding
>>>>>>>>>> output. https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>
>>>>>>>>> And for the halting function, its domain is a turing machine M and
>>>>>>>>> its input w, and its output is: accept if M applied to w halts,
>>>>>>>>> and reject if M applied to w does not halt. And the question of
>>>>>>>>> the halting problem is: Is the halting function computable?
>>>>>>>>>
>>>>>>>> The domain of H is this finite string:
>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>
>>>>>>> Which is not a complete program. So if H's domain is not complete
>>>>>>> programs, then by definition it is not a halt decider.
>>>>>> OK then call it a halt determiner.
>>>>>> None-the-less H(P,P)==0 is correct in such an obvious way that if you
>>>>>> were unbiased you would have agreed long ago.
>>>>>>>>
>>>>>>>> Do you have attention deficit disorder that scrambles your
>>>>>>>> attention
>>>>>>>> span so that you can't stay focused on H(P,P) ???
>>>>>>>>>>
>>>>>>>>>> In any case I am only talking about the simulation of the
>>>>>>>>>> input to
>>>>>>>>>> H(P,P). Are you freaking stupid of what?
>>>>>>>>>>> Otherwise what you're saying is:
>>>>>>>>>>>
>>>>>>>>>>> Since H1(P1,P1)==0,
>>>>>>>>>>> and H2(P2,P2)==0,
>>>>>>>>>>> and H3(P3,P3)==0,
>>>>>>>>>>> and H4(P4,P4)==0,
>>>>>>>>>>> and H5(P5,P5)==0,
>>>>>>>>>>> ....
>>>>>>>>>>> and Hn(Pn,Pn) does not halt,
>>>>>>>>>>> Then for any i, Hi(Pi,Pi) == 0 is correct
>>>>>>>>>>>
>>>>>>>>>>> These P's are all separate and distinct computations having
>>>>>>>>>>> nothing to do with each other.
>>>>>>>>>>>
>>>>>>>>>> This is the P that I am referring to knucklehead:
>>>>>>>>>> 558bec8b4508508b4d0851e840feffff83c40885c07402ebfe5dc3
>>>>>>>>>
>>>>>>>>> So since you aren't specifying H, then you do in fact mean:
>>>>>>>> I mean that halt decider that P calls.
>>>>>>>
>>>>>>> So in other words, since you haven't fixed the algorithm of H:
>>>>>> The algorithm of H is fixed.
>>>>>
>>>>> Alright, so since the fixed algorithm of H aborts,
>>>>
>>>> No we won't.
>>>> With your ADD we have to stay sharply focused on a single point.
>>>>
>>>> We are ONLY evaluating whether or not the simulation of the input to
>>>> H(P,P) is correct. I have been telling you this for many messages now
>>>> and you keep drifting off topic.
>>>>
>>>>
>>> And given what you have defined P to be, it can't be, because the P you
>>> have entered isn't actually a computation, since it isn't a complete
>>> algorithm.
>>>
>>> There is NOTHING in your P that defines what happens after the call "H"
>>> instruction.
>>>
>>> Thus, your trace can not be correct.
>>>
>>> As I have said before, if H wants to eliminate from the trace the
>>> showing of what H itself does, the the trace would resume after the call
>>> to H with the answer that this H returned to P, not a listing of a call
>>> to P again, which doesn't actually happen (not if H is able to abort its
>>> "simulation")
>>>
>>> Of course, as has been shown, if H does try that, it gets ITSELF stuck
>>> in an infinte recursion loop and fails to answer and thus fails to be a
>>> decider.
>>>
>>> The transform from a trace of the simumlator to the trace of the code
>>> that simulator is simulating is NOT a valid transform in this case. If
>>> you have a proof otherwise, show it. (Or you are just admitting to being
>>> a Lying Hypocrite since your goal is to show that all true statements
>>> are provable).
>>>
>> This is the crucial remaining question, assuming that everything else
>> is set
>> up as claimed.
>> The first seven instructions of the trace are the trace created by the
>> emulator.
>> It then stops tracing when the code it is emulating calls H.
>
>
> This is false. The emulator always outputs the complete execution trace
> of all user code and does not trace nay operating system code. Also the
> emulator does not create any instructions it merely outputs the
> execution trace of the x86 code that it is emulating.
>
>> However that
>> call is itself an emulator. The second seven instructions of the trace
>> are
>> created by the emulated emulator.
>>
>
> Not created.

So, you admit the system doesn't acctually exist?

>
>> But how does the emulator know that it is emulating an instruction trace,
>> and that it needs to append this output to pass to its infinite cycle
>> detection
>> logic?
>>
>
> This is a dodge of the actual challenge.
> The actual challenge is to provide the execution trace of the input to
> H(P,P) for one x86 emulation and one nested x86 emulation. Any other
> details are distractions away from the point. People here are barely
> able to keep track of a single point at a time.

Which is like asking for a square circle. It is a conflict of
definitions, if what I describe is not what you mean (and you mean what
you provide).

You trace is just a LIE, because it omits important data, and makes up
other data.

>
>> There are possible answers. But without this information, it's very
>> difficult
>> to know how to interpret the results.
>
>