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. However that
call is itself an emulator. The second seven instructions of the trace are
created by the emulated emulator.

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?

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