Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #36857 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-07-22 10:51 -0500 |
| Last post | 2021-07-23 09:48 -0700 |
| Articles | 20 on this page of 88 — 7 participants |
Back to article view | Back to comp.theory
How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 10:51 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 11:15 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 10:38 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-22 10:34 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 13:16 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 11:39 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 00:11 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 23:14 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-22 19:30 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 14:17 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 12:42 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:04 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 18:25 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 00:48 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 08:53 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 08:50 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 11:00 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 12:13 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 11:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 13:42 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 11:56 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 14:07 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 12:23 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 15:38 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 13:53 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 15:56 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 14:25 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 17:49 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-24 03:56 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Andy Walker <anw@cuboid.co.uk> - 2021-07-24 12:40 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-24 04:52 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 08:55 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Andy Walker <anw@cuboid.co.uk> - 2021-07-24 16:44 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 10:54 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:08 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-24 08:50 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:16 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-24 10:31 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ pure simulator ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:34 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ pure simulator ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:25 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 17:42 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 19:26 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 19:02 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 20:32 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 18:42 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 20:50 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 19:28 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 23:38 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 23:17 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar? ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:05 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:31 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 12:23 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 11:34 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 13:42 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 13:07 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 14:22 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:38 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 15:01 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 13:14 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:07 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-25 21:02 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 21:33 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? [ Internals of H ] olcott <NoOne@NoWhere.com> - 2021-07-26 10:08 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:21 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 14:24 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 12:44 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 15:03 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 13:19 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 16:10 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] olcott <NoOne@NoWhere.com> - 2021-07-24 17:31 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] André G. Isaak <agisaak@gm.invalid> - 2021-07-24 16:46 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-23 19:44 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] olcott <NoOne@NoWhere.com> - 2021-07-24 09:23 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 09:33 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] olcott <NoOne@NoWhere.com> - 2021-07-24 12:41 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] Richard Damon <Richard@Damon-Family.org> - 2021-07-24 11:39 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 18:00 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-23 22:12 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 16:49 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 15:26 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-25 04:07 +0100
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-22 13:11 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-22 17:18 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-22 15:46 -0700
Re: How is H(P,P)==0 correct even though P(P) stops running? André G. Isaak <agisaak@gm.invalid> - 2021-07-22 17:08 -0600
Re: How is H(P,P)==0 correct even though P(P) stops running? olcott <NoOne@NoWhere.com> - 2021-07-23 09:35 -0500
Re: How is H(P,P)==0 correct even though P(P) stops running? Richard Damon <Richard@Damon-Family.org> - 2021-07-23 09:48 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-25 04:07 +0100 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <87zgubdraw.fsf@bsb.me.uk> |
| In reply to | #36992 |
Richard Damon <Richard@Damon-Family.org> writes: > And the code stipulates a call to H that isn't traced. Which is by means an accidental omission. H is being kept secret, not because it's so wonderful, but because it's junk. I don't for a moment think he's got an H that does what he claims. I don't think he knows how to have H invoke the simulation software recursively. I'd put money on the fact that H just makes calls and not nested simulations. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2021-07-25 21:02 +0100 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <gLqdnc8zsYDtXmD9nZ2dnUU78f3NnZ2d@brightview.co.uk> |
| In reply to | #37013 |
On 25/07/2021 04:07, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> And the code stipulates a call to H that isn't traced.
>
> Which is by means an accidental omission. H is being kept secret, not
> because it's so wonderful, but because it's junk. I don't for a moment
> think he's got an H that does what he claims. I don't think he knows
> how to have H invoke the simulation software recursively. I'd put money
> on the fact that H just makes calls and not nested simulations.
>
I think PO may have done better than a direct call, but I doubt he has
done things in a "natural" way you or I would like. For a "pure"
approach, given PO's emulation is implemented in the OS rather than in
the decider code, I'd expect to see primitive APIs to
a) create a new emulation environment
b) single step an emulation
c) retrieve current emulation state data (with options, e.g. to
retrieve current registers, or to read virtual process memory)
Tracking nested simulations would be the responsibility of the
application which created the emulation, i.e. it would recognise when an
emulated program in turn creates a nested emulation, and when that
simulation is stepped and so on recursively. (This is what a TM would
need to do, but it's much harder for a TM as it's not obvious what
constitutes "emulator behaviour" in a TM - it's just more TM-ing.)
But that's all rather fiddly, and I think PO's handling of nested
simulations is for the OS to maintain a global merged trace of all (or
some?) instructions executed during nested emulations, and make those
directly available to the applications (and emulated applications).
That wouldn't be /disasterous/ provided it's done without leakage of
information which would enable emulated code to determine details about
it's emulator (or even /whether/ its in fact being emulated or run
directly in x86utm).
Whatever PO has done, the key to whether it's emulation-like or
call-like is where the "stepping" of the emulation happens. It should
be the case that an emulation advances ONLY when it's emulating
application calls the API to step the emulation a number of
instructions. I don't know if PO's software works like that, but he
didn't disagree when I suggested something like this some time back.
Mike.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-25 21:33 +0100 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <87h7gicewd.fsf@bsb.me.uk> |
| In reply to | #37046 |
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: > On 25/07/2021 04:07, Ben Bacarisse wrote: >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> And the code stipulates a call to H that isn't traced. >> Which is by means an accidental omission. H is being kept secret, not >> because it's so wonderful, but because it's junk. I don't for a moment >> think he's got an H that does what he claims. I don't think he knows >> how to have H invoke the simulation software recursively. I'd put money >> on the fact that H just makes calls and not nested simulations. >> > > I think PO may have done better than a direct call, but I doubt he has > done things in a "natural" way you or I would like. For a "pure" > approach, given PO's emulation is implemented in the OS rather than in > the decider code, I'd expect to see primitive APIs to > a) create a new emulation environment > b) single step an emulation > c) retrieve current emulation state data (with options, e.g. to > retrieve current registers, or to read virtual process memory) > Tracking nested simulations would be the responsibility of the > application which created the emulation, i.e. it would recognise when > an emulated program in turn creates a nested emulation, and when that > simulation is stepped and so on recursively. (This is what a TM would > need to do, but it's much harder for a TM as it's not obvious what > constitutes "emulator behaviour" in a TM - it's just more TM-ing.) > > But that's all rather fiddly, and I think PO's handling of nested > simulations is for the OS to maintain a global merged trace of all (or > some?) instructions executed during nested emulations, and make those > directly available to the applications (and emulated applications). > That wouldn't be /disasterous/ provided it's done without leakage of > information which would enable emulated code to determine details > about it's emulator (or even /whether/ its in fact being emulated or > run directly in x86utm). There's some sign he may be playing such tricks with the "global decider", but like most things PO says, it's not clear. But I've often wondered, given the opportunity to do that, why he's not claimed that H is correct. Using leaked information, one could have H(H^,H^) == 0 and H^(H^) non-haling (or H(H^,H^) != 0 and H^(H^) halting). That H(H^,H^) == 0 is correct despite H^(H^) halting is an tough hill to choose to fight on! Much simpler to argue about levels and pure function and what is or is not a computation, especially as he'll never have to post the code. > Whatever PO has done, the key to whether it's emulation-like or > call-like is where the "stepping" of the emulation happens. It should > be the case that an emulation advances ONLY when it's emulating > application calls the API to step the emulation a number of > instructions. I don't know if PO's software works like that, but he > didn't disagree when I suggested something like this some time back. You may, of course, be right, but I will note one thing: PO not disagreeing with something often just means that he does not understand it. For years, he refused to disagree with the claim that every instance of the halting problem had a correct yes/no answer, despite it being clear that he wanted to (for the "pathological" cases). However, he recently said: "I still have no idea of what you mean by halting problem instances" That might be just another ruse to avoid giving a direct answer, but it's also possible he simply had no idea what I was asking and was too big-headed to ask. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-26 10:08 -0500 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ Internals of H ] |
| Message-ID | <PtidncsxKvBiUmP9nZ2dnUU7-fXNnZ2d@giganews.com> |
| In reply to | #37046 |
On 7/25/2021 3:02 PM, Mike Terry wrote:
> On 25/07/2021 04:07, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> And the code stipulates a call to H that isn't traced.
>>
>> Which is by means an accidental omission. H is being kept secret, not
>> because it's so wonderful, but because it's junk. I don't for a moment
>> think he's got an H that does what he claims. I don't think he knows
>> how to have H invoke the simulation software recursively. I'd put money
>> on the fact that H just makes calls and not nested simulations.
>>
>
> I think PO may have done better than a direct call, but I doubt he has
> done things in a "natural" way you or I would like. For a "pure"
> approach, given PO's emulation is implemented in the OS rather than in
> the decider code, I'd expect to see primitive APIs to
> a) create a new emulation environment
> b) single step an emulation
> c) retrieve current emulation state data (with options, e.g. to
> retrieve current registers, or to read virtual process memory)
> Tracking nested simulations would be the responsibility of the
> application which created the emulation, i.e. it would recognise when an
> emulated program in turn creates a nested emulation, and when that
> simulation is stepped and so on recursively. (This is what a TM would
> need to do, but it's much harder for a TM as it's not obvious what
> constitutes "emulator behaviour" in a TM - it's just more TM-ing.)
>
> But that's all rather fiddly, and I think PO's handling of nested
> simulations is for the OS to maintain a global merged trace of all (or
> some?) instructions executed during nested emulations, and make those
> directly available to the applications (and emulated applications). That
> wouldn't be /disasterous/ provided it's done without leakage of
> information which would enable emulated code to determine details about
> it's emulator (or even /whether/ its in fact being emulated or run
> directly in x86utm).
>
> Whatever PO has done, the key to whether it's emulation-like or
> call-like is where the "stepping" of the emulation happens. It should
> be the case that an emulation advances ONLY when it's emulating
> application calls the API to step the emulation a number of
> instructions. I don't know if PO's software works like that, but he
> didn't disagree when I suggested something like this some time back.
>
>
> Mike.
All of the levels of emulators simulate their inputs in SingleStep()
mode. All of the emulations are data belonging to the outermost emulator.
The data that is shown in the debug trace is the only data that is
stored. This data is the sole basis of the halt status decision.
To model actual TM's more closely the input to H is simulated in its own
separate process context virtual machine having its own RAM, stack and
registers.
This API function simulates one instruction of the slave and returns the
line of code that was simulated:
u32 DebugStep(Registers* master_state, Registers* slave_state,
Decoded_Line_Of_Code* decoded) {}
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-24 12:21 -0700 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <yKZKI.21865$tL2.18498@fx43.iad> |
| In reply to | #36987 |
On 7/24/21 11:42 AM, olcott wrote: > On 7/24/2021 1:34 PM, Richard Damon wrote: >> On 7/24/21 10:23 AM, olcott wrote: >>> On 7/24/2021 11:31 AM, Richard Damon wrote: >>>> On 7/24/21 7:05 AM, olcott wrote: >>>>> On 7/24/2021 1:17 AM, Richard Damon wrote: >>>>>> On 7/23/21 9:38 PM, olcott wrote: >>>>>>> On 7/23/2021 9:28 PM, Richard Damon wrote: >>>>>> >>>>>>>> This CAN'T be right, because we KNOW from the running of P(P) that >>>>>>>> P(P) >>>>>>>> does halt. >>>>>>> >>>>>>> If you carefully study the x86 execution trace of P you will see >>>>>>> that it >>>>>>> is definitely true. If you keep ignoring this validation I will >>>>>>> write >>>>>>> you off as a liar. >>>>>>> >>>>>>> >>>>>> >>>>>> As has been pointed out many times, the trace is incorrect. >>>>>> >>>>> >>>>> It has been pointed out many times that the trace is assumed to be >>>>> incorrect. It has never been pointed out that the trace actually is >>>>> incorrect. >>>> >>>> No, it HAS been pointed out MANY times, you just don't seem to be able >>>> to read, at least not anything that disagrees with you. >>> >>> When we examine the execution trace of the simulation of the input to >>> H(P,P) we can confirm that a pure simulation of this input cannot >>> possibly ever reach its final state. >> >> But the trace ISN'T a PURE SIMULATION TRACE. >> > > There are no deceitful weasel words to get around this: > > It is proven to be a pure simulation on the basis that the execution > trace of P precisely matches the x86 source-code of P. Except that it doesn't trace a call instruction correctly! FAIL. I have NEVER seen a machine where a call to address 00000955 ends up at address 00000C25 Have you? Since it isn't a pure trace of the simulation, your argument falls apart. The transformation of tracing the simulating to tracing the simulated only applies is certain conditions, one of which is that the simulator NEVER aborts its simulation (not doesn't until ..., but NEVER). Can you actually PROVE that your transformation is valid? You have yet to actually prove anything. > > >>> >>>>> _P() >>>>> [00000c25](01) 55 push ebp >>>>> [00000c26](02) 8bec mov ebp,esp >>>>> [00000c28](03) 8b4508 mov eax,[ebp+08] >>>>> [00000c2b](01) 50 push eax // 2nd Param >>>>> [00000c2c](03) 8b4d08 mov ecx,[ebp+08] >>>>> [00000c2f](01) 51 push ecx // 1st Param >>>>> [00000c30](05) e820fdffff call 00000955 // call H >>>>> [00000c35](03) 83c408 add esp,+08 >>>>> [00000c38](02) 85c0 test eax,eax >>>>> [00000c3a](02) 7402 jz 00000c3e >>>>> [00000c3c](02) ebfe jmp 00000c3c >>>>> [00000c3e](01) 5d pop ebp >>>>> [00000c3f](01) c3 ret >>>>> Size in bytes:(0027) [00000c3f] >>>>> >>>>> machine stack stack machine assembly >>>>> address address data code language >>>>> ======== ======== ======== ========= ============= >>>>> Begin Local Halt Decider Simulation at Machine Address:c25 >>>>> [00000c25][00211776][0021177a] 55 push ebp // P begins >>>>> [00000c26][00211776][0021177a] 8bec mov ebp,esp >>>>> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08] >>>>> [00000c2b][00211772][00000c25] 50 push eax // push P >>>>> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08] >>>>> [00000c2f][0021176e][00000c25] 51 push ecx // push P >>>>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P) >>>>> >>>>> [00000c25][0025c19e][0025c1a2] 55 push ebp // P begins >>>>> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp >>>>> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08] >>>>> [00000c2b][0025c19a][00000c25] 50 push eax // push P >>>>> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08] >>>>> [00000c2f][0025c196][00000c25] 51 push ecx // push P >>>>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P) >>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >>>>> >>>>> If a person understands the x86 language and is not a liar they will >>>>> admit that the pure simulation of P(P) cannot possibly ever reach its >>>>> final state. >>>>> >>>>> If they don't know the x86 language they better make sure to say this >>>>> otherwise they will be written off as a liar. >>>>> >>>>>> The trace omits the tracing of code, using an incorrect >>>>>> transformation, >>>>>> and thus the reasoning you make is unsound. >>>>>> >>>>>> The replacement of the tracing of the simulator with the trace of the >>>>>> simulation is ONLY valid for a PURE simulator, not a 'pure simulator >>>>>> until ...' which isn't a pure simulator. >>>>>> >>>>>> Would you eat food that was 'clean until ...', I hope not. >>>>>> >>>>> >>>>> >>>> >>> >>> >> > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-24 14:24 -0500 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <JK-dnQ557ONl9WH9nZ2dnUU7-aWdnZ2d@giganews.com> |
| In reply to | #36989 |
On 7/24/2021 2:21 PM, Richard Damon wrote: > On 7/24/21 11:42 AM, olcott wrote: >> On 7/24/2021 1:34 PM, Richard Damon wrote: >>> On 7/24/21 10:23 AM, olcott wrote: >>>> On 7/24/2021 11:31 AM, Richard Damon wrote: >>>>> On 7/24/21 7:05 AM, olcott wrote: >>>>>> On 7/24/2021 1:17 AM, Richard Damon wrote: >>>>>>> On 7/23/21 9:38 PM, olcott wrote: >>>>>>>> On 7/23/2021 9:28 PM, Richard Damon wrote: >>>>>>> >>>>>>>>> This CAN'T be right, because we KNOW from the running of P(P) that >>>>>>>>> P(P) >>>>>>>>> does halt. >>>>>>>> >>>>>>>> If you carefully study the x86 execution trace of P you will see >>>>>>>> that it >>>>>>>> is definitely true. If you keep ignoring this validation I will >>>>>>>> write >>>>>>>> you off as a liar. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> As has been pointed out many times, the trace is incorrect. >>>>>>> >>>>>> >>>>>> It has been pointed out many times that the trace is assumed to be >>>>>> incorrect. It has never been pointed out that the trace actually is >>>>>> incorrect. >>>>> >>>>> No, it HAS been pointed out MANY times, you just don't seem to be able >>>>> to read, at least not anything that disagrees with you. >>>> >>>> When we examine the execution trace of the simulation of the input to >>>> H(P,P) we can confirm that a pure simulation of this input cannot >>>> possibly ever reach its final state. >>> >>> But the trace ISN'T a PURE SIMULATION TRACE. >>> >> >> There are no deceitful weasel words to get around this: >> >> It is proven to be a pure simulation on the basis that the execution >> trace of P precisely matches the x86 source-code of P. > > Except that it doesn't trace a call instruction correctly! You are wrong and you know it. Why lie? The behavior of P must correspond to the behavior that its code stipulates. _P() [00000c36](01) 55 push ebp [00000c37](02) 8bec mov ebp,esp [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param [00000c3c](01) 50 push eax [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param [00000c40](01) 51 push ecx [00000c41](05) e820fdffff call 00000966 // call H ... machine stack stack machine assembly address address data code language ======== ======== ======== ========= ============= Begin Local Halt Decider Simulation at Machine Address:c36 [00000c36][002117ca][002117ce] 55 push ebp [00000c37][002117ca][002117ce] 8bec mov ebp,esp [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] [00000c3c][002117c6][00000c36] 50 push eax // push P [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] [00000c40][002117c2][00000c36] 51 push ecx // push P [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) [00000c36][0025c1f2][0025c1f6] 55 push ebp [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] [00000c3c][0025c1ee][00000c36] 50 push eax // push P [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] [00000c40][0025c1ea][00000c36] 51 push ecx // push P [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) Local Halt Decider: Infinite Recursion Detected Simulation Stopped -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-24 12:44 -0700 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <T4_KI.37892$5Y6.36240@fx10.iad> |
| In reply to | #36991 |
On 7/24/21 12:24 PM, olcott wrote: > On 7/24/2021 2:21 PM, Richard Damon wrote: >> On 7/24/21 11:42 AM, olcott wrote: >>> On 7/24/2021 1:34 PM, Richard Damon wrote: >>>> On 7/24/21 10:23 AM, olcott wrote: >>>>> On 7/24/2021 11:31 AM, Richard Damon wrote: >>>>>> On 7/24/21 7:05 AM, olcott wrote: >>>>>>> On 7/24/2021 1:17 AM, Richard Damon wrote: >>>>>>>> On 7/23/21 9:38 PM, olcott wrote: >>>>>>>>> On 7/23/2021 9:28 PM, Richard Damon wrote: >>>>>>>> >>>>>>>>>> This CAN'T be right, because we KNOW from the running of P(P) >>>>>>>>>> that >>>>>>>>>> P(P) >>>>>>>>>> does halt. >>>>>>>>> >>>>>>>>> If you carefully study the x86 execution trace of P you will see >>>>>>>>> that it >>>>>>>>> is definitely true. If you keep ignoring this validation I will >>>>>>>>> write >>>>>>>>> you off as a liar. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> As has been pointed out many times, the trace is incorrect. >>>>>>>> >>>>>>> >>>>>>> It has been pointed out many times that the trace is assumed to be >>>>>>> incorrect. It has never been pointed out that the trace actually is >>>>>>> incorrect. >>>>>> >>>>>> No, it HAS been pointed out MANY times, you just don't seem to be >>>>>> able >>>>>> to read, at least not anything that disagrees with you. >>>>> >>>>> When we examine the execution trace of the simulation of the input to >>>>> H(P,P) we can confirm that a pure simulation of this input cannot >>>>> possibly ever reach its final state. >>>> >>>> But the trace ISN'T a PURE SIMULATION TRACE. >>>> >>> >>> There are no deceitful weasel words to get around this: >>> >>> It is proven to be a pure simulation on the basis that the execution >>> trace of P precisely matches the x86 source-code of P. >> >> Except that it doesn't trace a call instruction correctly! > > > You are wrong and you know it. Why lie? > > The behavior of P must correspond to the behavior that its code stipulates. P calls H, so the trace of P MUST show the trace of that H that is calls. Since H has been stipulated to return the answer non-halting, then the behavior stipulated by the code is to halt. P is only infinitely recursive if we are using an H that never aborts this simulation, which is NOT the case. A Call to H(P,P) is NOT identical to a call to P(P) unless H is an absolutly PURE simulator, not a pure simulator until ... , it needs to be a simulator that NEVER aborts. If you claim that is your H, then it will NEVER return an answer for H(P,P) and thus fails to be a decider. If H aborts its simulation when called directly but not when called by P then it fails to be a computation, and thus not eligable to be a decider. You seem to be caught in a cognative dissodence when you can't tell truth from falsehood in your attempt to maintain your mistaken beleif that you can universally apply the principle of everything that is True is Provable. > > _P() > [00000c36](01) 55 push ebp > [00000c37](02) 8bec mov ebp,esp > [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param > [00000c3c](01) 50 push eax > [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param > [00000c40](01) 51 push ecx > [00000c41](05) e820fdffff call 00000966 // call H > ... > > machine stack stack machine assembly > address address data code language > ======== ======== ======== ========= ============= > Begin Local Halt Decider Simulation at Machine Address:c36 > [00000c36][002117ca][002117ce] 55 push ebp > [00000c37][002117ca][002117ce] 8bec mov ebp,esp > [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] > [00000c3c][002117c6][00000c36] 50 push eax // push P > [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] > [00000c40][002117c2][00000c36] 51 push ecx // push P > [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) > > [00000c36][0025c1f2][0025c1f6] 55 push ebp > [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp > [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] > [00000c3c][0025c1ee][00000c36] 50 push eax // push P > [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] > [00000c40][0025c1ea][00000c36] 51 push ecx // push P > [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) > Local Halt Decider: Infinite Recursion Detected Simulation Stopped > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-24 15:03 -0500 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <RaKdnQz75Z-F72H9nZ2dnUU7-K2dnZ2d@giganews.com> |
| In reply to | #36993 |
On 7/24/2021 2:44 PM, Richard Damon wrote: > On 7/24/21 12:24 PM, olcott wrote: >> On 7/24/2021 2:21 PM, Richard Damon wrote: >>> On 7/24/21 11:42 AM, olcott wrote: >>>> On 7/24/2021 1:34 PM, Richard Damon wrote: >>>>> On 7/24/21 10:23 AM, olcott wrote: >>>>>> On 7/24/2021 11:31 AM, Richard Damon wrote: >>>>>>> On 7/24/21 7:05 AM, olcott wrote: >>>>>>>> On 7/24/2021 1:17 AM, Richard Damon wrote: >>>>>>>>> On 7/23/21 9:38 PM, olcott wrote: >>>>>>>>>> On 7/23/2021 9:28 PM, Richard Damon wrote: >>>>>>>>> >>>>>>>>>>> This CAN'T be right, because we KNOW from the running of P(P) >>>>>>>>>>> that >>>>>>>>>>> P(P) >>>>>>>>>>> does halt. >>>>>>>>>> >>>>>>>>>> If you carefully study the x86 execution trace of P you will see >>>>>>>>>> that it >>>>>>>>>> is definitely true. If you keep ignoring this validation I will >>>>>>>>>> write >>>>>>>>>> you off as a liar. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> As has been pointed out many times, the trace is incorrect. >>>>>>>>> >>>>>>>> >>>>>>>> It has been pointed out many times that the trace is assumed to be >>>>>>>> incorrect. It has never been pointed out that the trace actually is >>>>>>>> incorrect. >>>>>>> >>>>>>> No, it HAS been pointed out MANY times, you just don't seem to be >>>>>>> able >>>>>>> to read, at least not anything that disagrees with you. >>>>>> >>>>>> When we examine the execution trace of the simulation of the input to >>>>>> H(P,P) we can confirm that a pure simulation of this input cannot >>>>>> possibly ever reach its final state. >>>>> >>>>> But the trace ISN'T a PURE SIMULATION TRACE. >>>>> >>>> >>>> There are no deceitful weasel words to get around this: >>>> >>>> It is proven to be a pure simulation on the basis that the execution >>>> trace of P precisely matches the x86 source-code of P. >>> >>> Except that it doesn't trace a call instruction correctly! >> >> >> You are wrong and you know it. Why lie? >> >> The behavior of P must correspond to the behavior that its code stipulates. > > P calls H, so the trace of P MUST show the trace of that H that is > calls. The question is: Can the input to H ever reach its final state while H is in pure simulator mode? The question is: Can the input to H ever reach its final state while H is in pure simulator mode? The question is: Can the input to H ever reach its final state while H is in pure simulator mode? The question is: Can the input to H ever reach its final state while H is in pure simulator mode? The question is: Can the input to H ever reach its final state while H is in pure simulator mode? >> >> _P() >> [00000c36](01) 55 push ebp >> [00000c37](02) 8bec mov ebp,esp >> [00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param >> [00000c3c](01) 50 push eax >> [00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param >> [00000c40](01) 51 push ecx >> [00000c41](05) e820fdffff call 00000966 // call H >> ... >> >> machine stack stack machine assembly >> address address data code language >> ======== ======== ======== ========= ============= >> Begin Local Halt Decider Simulation at Machine Address:c36 >> [00000c36][002117ca][002117ce] 55 push ebp >> [00000c37][002117ca][002117ce] 8bec mov ebp,esp >> [00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08] >> [00000c3c][002117c6][00000c36] 50 push eax // push P >> [00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08] >> [00000c40][002117c2][00000c36] 51 push ecx // push P >> [00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P) >> >> [00000c36][0025c1f2][0025c1f6] 55 push ebp >> [00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp >> [00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08] >> [00000c3c][0025c1ee][00000c36] 50 push eax // push P >> [00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08] >> [00000c40][0025c1ea][00000c36] 51 push ecx // push P >> [00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P) >> Local Halt Decider: Infinite Recursion Detected Simulation Stopped >> >> > -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-24 13:19 -0700 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <nB_KI.17485$W56.3609@fx08.iad> |
| In reply to | #36996 |
On 7/24/21 1:03 PM, olcott wrote: > On 7/24/2021 2:44 PM, Richard Damon wrote: >> On 7/24/21 12:24 PM, olcott wrote: >>> On 7/24/2021 2:21 PM, Richard Damon wrote: >>>> On 7/24/21 11:42 AM, olcott wrote: >>>>> On 7/24/2021 1:34 PM, Richard Damon wrote: >>>>>> On 7/24/21 10:23 AM, olcott wrote: >>>>>>> On 7/24/2021 11:31 AM, Richard Damon wrote: >>>>>>>> On 7/24/21 7:05 AM, olcott wrote: >>>>>>>>> On 7/24/2021 1:17 AM, Richard Damon wrote: >>>>>>>>>> On 7/23/21 9:38 PM, olcott wrote: >>>>>>>>>>> On 7/23/2021 9:28 PM, Richard Damon wrote: >>>>>>>>>> >>>>>>>>>>>> This CAN'T be right, because we KNOW from the running of P(P) >>>>>>>>>>>> that >>>>>>>>>>>> P(P) >>>>>>>>>>>> does halt. >>>>>>>>>>> >>>>>>>>>>> If you carefully study the x86 execution trace of P you will see >>>>>>>>>>> that it >>>>>>>>>>> is definitely true. If you keep ignoring this validation I will >>>>>>>>>>> write >>>>>>>>>>> you off as a liar. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> As has been pointed out many times, the trace is incorrect. >>>>>>>>>> >>>>>>>>> >>>>>>>>> It has been pointed out many times that the trace is assumed to be >>>>>>>>> incorrect. It has never been pointed out that the trace >>>>>>>>> actually is >>>>>>>>> incorrect. >>>>>>>> >>>>>>>> No, it HAS been pointed out MANY times, you just don't seem to be >>>>>>>> able >>>>>>>> to read, at least not anything that disagrees with you. >>>>>>> >>>>>>> When we examine the execution trace of the simulation of the >>>>>>> input to >>>>>>> H(P,P) we can confirm that a pure simulation of this input cannot >>>>>>> possibly ever reach its final state. >>>>>> >>>>>> But the trace ISN'T a PURE SIMULATION TRACE. >>>>>> >>>>> >>>>> There are no deceitful weasel words to get around this: >>>>> >>>>> It is proven to be a pure simulation on the basis that the execution >>>>> trace of P precisely matches the x86 source-code of P. >>>> >>>> Except that it doesn't trace a call instruction correctly! >>> >>> >>> You are wrong and you know it. Why lie? >>> >>> The behavior of P must correspond to the behavior that its code >>> stipulates. >> >> P calls H, so the trace of P MUST show the trace of that H that is >> calls. > > The question is: Can the input to H ever reach its final state while H > is in pure simulator mode? > > The question is: Can the input to H ever reach its final state while H > is in pure simulator mode? > > The question is: Can the input to H ever reach its final state while H > is in pure simulator mode? > > The question is: Can the input to H ever reach its final state while H > is in pure simulator mode? > > The question is: Can the input to H ever reach its final state while H > is in pure simulator mode? WRONG. The Question is does the machine represented by the input Halt when run. WRONG QUESTION, INVALID ARGUMENT. The fact that H does abort it simulation before it gets to the right answer is H's fault, and the cause that it get the wrong answer. When we compare the trace of P(P) to H(P,P) we see that P(P) include the identical trace that H considers proof of non-halting, but that later this trace halts. Thus the assumption that this pattern is proof of non-halting behavior is proved wrong. By your logic, a simulatior that immediately aborts all simulations is correct in calling ALL computations non-halting. That is absurd, as is you logic.
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-24 16:10 -0600 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <sdi356$nvs$1@dont-email.me> |
| In reply to | #36996 |
On 2021-07-24 14:03, olcott wrote:
> The question is: Can the input to H ever reach its final state while H
> is in pure simulator mode?
No, it is not. The question which a halt decider is supposed to answer
about input (P, P) is *does P(P) halt*. (or int main { P(P); } as you
insist on more verbosely expressing it for some mysterious reason)
We KNOW what the answer to that question is.
No amount of traces or arguments on your part can possibly justify the
claim that H(P, P) == 0 is correct given that we *know* what the answer
to this question is based on the behaviour of P(P).
Given the definition of the halting problem, the actual behaviour of
P(P) is the ultimate authority on the answer to this question. The
actual behaviour of P(P) is the *only* thing that matters in
establishing the correct answer to this question.
Even if the logical flaws in your traces and arguments weren't apparent
(They are and have been pointed out to you) it WOULDN'T MATTER. When a
'decider' gives an answer that contradicts the ACTUAL answer then the
decider is wrong.
AFAICT your argument runs as follows:
(1) We know that P(P) halts.
(2) My decider H determines P(P) doesn't halt.
(3) My decider must be right because I say so. I even have traces.
(4) Therefore P(P) must not "really" halt even though it does.
Therefore it "wrongly" halts.
Let's see how well that goes over with peer reviewers.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-24 17:31 -0500 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <292dnfTWM4wwCWH9nZ2dnUU7-LPNnZ2d@giganews.com> |
| In reply to | #37001 |
On 7/24/2021 5:10 PM, André G. Isaak wrote:
> On 2021-07-24 14:03, olcott wrote:
>
>> The question is: Can the input to H ever reach its final state while H
>> is in pure simulator mode?
>
> No, it is not.
Yes it is.
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
...
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
(1) H does perform a pure simulation of its input until after it makes
its halt status decision.
(2) It can be verified that this is a pure simulation on the basis that
the execution trace does what the x86 source-code of P specifies.
(3) Because there are no control flow instructions in the execution
trace that can possibly escape the infinite recursion the execution
trace proves that a pure simulation of the above input cannot possibly
ever reach its final state.
(4) Therefore H was correct when it decided that its input never halts.
If you bother to carefully study all of the above then you know that H
does correctly decide that its input never halts.
*How we reconcile this with the fact that int main(){ P(P); } halts is
another different issue*
If (1)(2)(3) are verified facts then NO MATTER WHAT
(4) follows by logical necessity.
(1) Is a verified fact.
(2) is a verified fact.
(3) is a verified fact.
> The question which a halt decider is supposed to answer
> about input (P, P) is *does P(P) halt*. (or int main { P(P); } as you
> insist on more verbosely expressing it for some mysterious reason)
>
> We KNOW what the answer to that question is.
>
> No amount of traces or arguments on your part can possibly justify the
> claim that H(P, P) == 0 is correct given that we *know* what the answer
> to this question is based on the behaviour of P(P).
>
> Given the definition of the halting problem, the actual behaviour of
> P(P) is the ultimate authority on the answer to this question. The
> actual behaviour of P(P) is the *only* thing that matters in
> establishing the correct answer to this question.
>
> Even if the logical flaws in your traces and arguments weren't apparent
> (They are and have been pointed out to you) it WOULDN'T MATTER. When a
> 'decider' gives an answer that contradicts the ACTUAL answer then the
> decider is wrong.
>
> AFAICT your argument runs as follows:
>
> (1) We know that P(P) halts.
> (2) My decider H determines P(P) doesn't halt.
> (3) My decider must be right because I say so. I even have traces.
> (4) Therefore P(P) must not "really" halt even though it does.
> Therefore it "wrongly" halts.
>
> Let's see how well that goes over with peer reviewers.
>
> André
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-24 16:46 -0600 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [ liar ??? ] |
| Message-ID | <sdi57p$3h3$1@dont-email.me> |
| In reply to | #37003 |
On 2021-07-24 16:31, olcott wrote:
> On 7/24/2021 5:10 PM, André G. Isaak wrote:
> (1) H does perform a pure simulation of its input until after it makes
> its halt status decision.
Which means it is not a pure simulator.
> (2) It can be verified that this is a pure simulation on the basis that
> the execution trace does what the x86 source-code of P specifies.
See above. Then compare your trace with an actual trace of P(P).
> (3) Because there are no control flow instructions in the execution
> trace that can possibly escape the infinite recursion the execution
> trace proves that a pure simulation of the above input cannot possibly
> ever reach its final state.
There *are* control flow instructions. They're in the section beginning
at address 955 which you don't include in your selective "trace".
> (4) Therefore H was correct when it decided that its input never halts.
>
> If you bother to carefully study all of the above then you know that H
> does correctly decide that its input never halts.
>
> *How we reconcile this with the fact that int main(){ P(P); } halts is
> another different issue*
No, it is NOT a different issue. since int main(){ P(P); } UNEQUIVOCALLY
halts, *any* argument which claims that it does not halt must be flawed.
If I give you a proof that 1 + 1 = 3, you *know* there must be a flaw in
the proof even if you cannot find it.
You may not see the flaws in your own argument even though everyone else
does (and has repeatedly pointed them out to you). But the fact that it
gives the wrong answer should clearly indicate to you that they are there.
You seem to keep forgetting that halting is *defined* in terms of the
*actual* behaviour of the machine in question, so you *can't* claim that
what the machine does is somehow "misleading" and that your decider is
the one that is correct.
You're the one who keeps claiming that a sound logical argument cannot
possibly reach a false conclusion. The answer to the question 'does
P(P)' halt?' is known to be YES. You have acknowledged this. To claim
that your argument which reaches a clearly false conclusion is somehow
sound clearly goes against your own conviction here. Why you cannot
reach the obvious conclusion (that the argument is not, in fact, sound)
is beyond me.
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | André G. Isaak <agisaak@gm.invalid> |
|---|---|
| Date | 2021-07-23 19:44 -0600 |
| Message-ID | <sdfraf$gg2$1@dont-email.me> |
| In reply to | #36949 |
On 2021-07-23 19:32, olcott wrote:
> On 7/23/2021 8:02 PM, André G. Isaak wrote:
>> On 2021-07-23 18:26, olcott wrote:
>>> On 7/23/2021 6:42 PM, André G. Isaak wrote:
>>>> On 2021-07-23 14:38, olcott wrote:
>>>>
>>>>> int main(){ P(P); } initially doesn't give H jack shit, that it the
>>>>> only reason why that P halts and this P never halts: int main(){
>>>>> H(P,P); }
>>>>
>>>> Well, duh. Of course it doesn't 'give H jack shit' because H *isn't
>>>> being computed* in this case.
>>>
>>> Richard doesn't notice details like this.
>>
>> Richard gets it just fine. You're the one who is confused.
>>
>> int main(){ P(P); } is the only case we care about
>
> Then you are committed to deception.
How so? the behaviour of int main(){ P(P); } is what int main(){ H(P,P);
} is supposed to be deciding, so the behaviour of int main(){ P(P); } is
the ultimate arbiter of the correct answer to the question. AND IT HALTS.
>> since it is the only case where the computation P(P) is actually being
>> performed, and that's what the halting problem is concerned with. Does
>> this computation halt?
>>
>> in int main(){ H(P,P); } P is the *input* to a computation. Inputs
>> neither halt nor don't halt because they *aren't* computations. The
>
> Yes more deception, knowing full well that the simulation of the
> description of a machine on its input is computationally equivalent to
> the execution of this machine on it input YOU DENY IT ANYWAY.
Obviously they AREN'T computationally equivalent, because you claim that
your simulated P(P) has DIFFERENT halting behaviour than the actual P(P).
André
--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-24 09:23 -0500 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] |
| Message-ID | <-42dnWGxwcDIv2H9nZ2dnUU7-W_NnZ2d@giganews.com> |
| In reply to | #36952 |
On 7/23/2021 8:44 PM, André G. Isaak wrote:
> On 2021-07-23 19:32, olcott wrote:
>> On 7/23/2021 8:02 PM, André G. Isaak wrote:
>>> On 2021-07-23 18:26, olcott wrote:
>>>> On 7/23/2021 6:42 PM, André G. Isaak wrote:
>>>>> On 2021-07-23 14:38, olcott wrote:
>>>>>
>>>>>> int main(){ P(P); } initially doesn't give H jack shit, that it
>>>>>> the only reason why that P halts and this P never halts: int
>>>>>> main(){ H(P,P); }
>>>>>
>>>>> Well, duh. Of course it doesn't 'give H jack shit' because H *isn't
>>>>> being computed* in this case.
>>>>
>>>> Richard doesn't notice details like this.
>>>
>>> Richard gets it just fine. You're the one who is confused.
>>>
>>> int main(){ P(P); } is the only case we care about
>>
>> Then you are committed to deception.
>
> How so? the behaviour of int main(){ P(P); } is what int main(){ H(P,P);
> } is supposed to be deciding, so the behaviour of int main(){ P(P); } is
> the ultimate arbiter of the correct answer to the question. AND IT HALTS.
>
I am going to stay focused on this one point until we have mutual
agreement.
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
[00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
If a person understands the x86 language and is not a liar they will
admit that the pure simulation of P(P) cannot possibly ever reach its
final state.
>>> since it is the only case where the computation P(P) is actually
>>> being performed, and that's what the halting problem is concerned
>>> with. Does this computation halt?
>>>
>>> in int main(){ H(P,P); } P is the *input* to a computation. Inputs
>>> neither halt nor don't halt because they *aren't* computations. The
>>
>> Yes more deception, knowing full well that the simulation of the
>> description of a machine on its input is computationally equivalent to
>> the execution of this machine on it input YOU DENY IT ANYWAY.
>
> Obviously they AREN'T computationally equivalent, because you claim that
> your simulated P(P) has DIFFERENT halting behaviour than the actual P(P).
>
> André
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-24 09:33 -0700 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] |
| Message-ID | <BhXKI.32291$rr3.3803@fx34.iad> |
| In reply to | #36966 |
On 7/24/21 7:23 AM, olcott wrote:
> On 7/23/2021 8:44 PM, André G. Isaak wrote:
>> On 2021-07-23 19:32, olcott wrote:
>>> On 7/23/2021 8:02 PM, André G. Isaak wrote:
>>>> On 2021-07-23 18:26, olcott wrote:
>>>>> On 7/23/2021 6:42 PM, André G. Isaak wrote:
>>>>>> On 2021-07-23 14:38, olcott wrote:
>>>>>>
>>>>>>> int main(){ P(P); } initially doesn't give H jack shit, that it
>>>>>>> the only reason why that P halts and this P never halts: int
>>>>>>> main(){ H(P,P); }
>>>>>>
>>>>>> Well, duh. Of course it doesn't 'give H jack shit' because H
>>>>>> *isn't being computed* in this case.
>>>>>
>>>>> Richard doesn't notice details like this.
>>>>
>>>> Richard gets it just fine. You're the one who is confused.
>>>>
>>>> int main(){ P(P); } is the only case we care about
>>>
>>> Then you are committed to deception.
>>
>> How so? the behaviour of int main(){ P(P); } is what int main(){
>> H(P,P); } is supposed to be deciding, so the behaviour of int main(){
>> P(P); } is the ultimate arbiter of the correct answer to the question.
>> AND IT HALTS.
>>
>
> I am going to stay focused on this one point until we have mutual
> agreement.
>
> _P()
> [00000c25](01) 55 push ebp
> [00000c26](02) 8bec mov ebp,esp
> [00000c28](03) 8b4508 mov eax,[ebp+08]
> [00000c2b](01) 50 push eax // 2nd Param
> [00000c2c](03) 8b4d08 mov ecx,[ebp+08]
> [00000c2f](01) 51 push ecx // 1st Param
> [00000c30](05) e820fdffff call 00000955 // call H
> [00000c35](03) 83c408 add esp,+08
> [00000c38](02) 85c0 test eax,eax
> [00000c3a](02) 7402 jz 00000c3e
> [00000c3c](02) ebfe jmp 00000c3c
> [00000c3e](01) 5d pop ebp
> [00000c3f](01) c3 ret
> Size in bytes:(0027) [00000c3f]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> Begin Local Halt Decider Simulation at Machine Address:c25
> [00000c25][00211776][0021177a] 55 push ebp // P begins
> [00000c26][00211776][0021177a] 8bec mov ebp,esp
> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
> [00000c2b][00211772][00000c25] 50 push eax // push P
> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][0021176e][00000c25] 51 push ecx // push P
> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
>
> [00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
> [00000c2b][0025c19a][00000c25] 50 push eax // push P
> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
> [00000c2f][0025c196][00000c25] 51 push ecx // push P
> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> If a person understands the x86 language and is not a liar they will
> admit that the pure simulation of P(P) cannot possibly ever reach its
> final state.
As has been pointed out many times, this is an incorrect trace of the
program.
You seem to be insisting that it is correct to deceive. YOU ARE A LIAR.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-24 12:41 -0500 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] |
| Message-ID | <rcednX9NVeRTzWH9nZ2dnUU7-bnNnZ2d@giganews.com> |
| In reply to | #36976 |
On 7/24/2021 11:33 AM, Richard Damon wrote:
> On 7/24/21 7:23 AM, olcott wrote:
>> On 7/23/2021 8:44 PM, André G. Isaak wrote:
>>> On 2021-07-23 19:32, olcott wrote:
>>>> On 7/23/2021 8:02 PM, André G. Isaak wrote:
>>>>> On 2021-07-23 18:26, olcott wrote:
>>>>>> On 7/23/2021 6:42 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-23 14:38, olcott wrote:
>>>>>>>
>>>>>>>> int main(){ P(P); } initially doesn't give H jack shit, that it
>>>>>>>> the only reason why that P halts and this P never halts: int
>>>>>>>> main(){ H(P,P); }
>>>>>>>
>>>>>>> Well, duh. Of course it doesn't 'give H jack shit' because H
>>>>>>> *isn't being computed* in this case.
>>>>>>
>>>>>> Richard doesn't notice details like this.
>>>>>
>>>>> Richard gets it just fine. You're the one who is confused.
>>>>>
>>>>> int main(){ P(P); } is the only case we care about
>>>>
>>>> Then you are committed to deception.
>>>
>>> How so? the behaviour of int main(){ P(P); } is what int main(){
>>> H(P,P); } is supposed to be deciding, so the behaviour of int main(){
>>> P(P); } is the ultimate arbiter of the correct answer to the question.
>>> AND IT HALTS.
>>>
>>
>> I am going to stay focused on this one point until we have mutual
>> agreement.
>>
>> _P()
>> [00000c25](01) 55 push ebp
>> [00000c26](02) 8bec mov ebp,esp
>> [00000c28](03) 8b4508 mov eax,[ebp+08]
>> [00000c2b](01) 50 push eax // 2nd Param
>> [00000c2c](03) 8b4d08 mov ecx,[ebp+08]
>> [00000c2f](01) 51 push ecx // 1st Param
>> [00000c30](05) e820fdffff call 00000955 // call H
>> [00000c35](03) 83c408 add esp,+08
>> [00000c38](02) 85c0 test eax,eax
>> [00000c3a](02) 7402 jz 00000c3e
>> [00000c3c](02) ebfe jmp 00000c3c
>> [00000c3e](01) 5d pop ebp
>> [00000c3f](01) c3 ret
>> Size in bytes:(0027) [00000c3f]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> Begin Local Halt Decider Simulation at Machine Address:c25
>> [00000c25][00211776][0021177a] 55 push ebp // P begins
>> [00000c26][00211776][0021177a] 8bec mov ebp,esp
>> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
>> [00000c2b][00211772][00000c25] 50 push eax // push P
>> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][0021176e][00000c25] 51 push ecx // push P
>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
>>
>> [00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
>> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
>> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
>> [00000c2b][0025c19a][00000c25] 50 push eax // push P
>> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
>> [00000c2f][0025c196][00000c25] 51 push ecx // push P
>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> If a person understands the x86 language and is not a liar they will
>> admit that the pure simulation of P(P) cannot possibly ever reach its
>> final state.
>
> As has been pointed out many times, this is an incorrect trace of the
> program.
>
> You seem to be insisting that it is correct to deceive. YOU ARE A LIAR.
>
(1) H does perform a pure simulation of its input until after it makes
its halt status decision.
(2) It can be verified that this is a pure simulation on the basis that
the execution trace does what the x86 source-code of P specifies.
(3) Because there are no control flow instructions in the execution
trace that can possibly escape the infinite recursion the execution
trace proves that a pure simulation of the above input cannot possibly
ever reach its final state.
(4) Therefore H was correct when it decided that its input never halts.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-24 11:39 -0700 |
| Subject | Re: How is H(P,P)==0 correct even though P(P) stops running? [focused until mutual agreement ] |
| Message-ID | <O7ZKI.8714$yU3.7194@fx05.iad> |
| In reply to | #36979 |
On 7/24/21 10:41 AM, olcott wrote:
> On 7/24/2021 11:33 AM, Richard Damon wrote:
>> On 7/24/21 7:23 AM, olcott wrote:
>>> On 7/23/2021 8:44 PM, André G. Isaak wrote:
>>>> On 2021-07-23 19:32, olcott wrote:
>>>>> On 7/23/2021 8:02 PM, André G. Isaak wrote:
>>>>>> On 2021-07-23 18:26, olcott wrote:
>>>>>>> On 7/23/2021 6:42 PM, André G. Isaak wrote:
>>>>>>>> On 2021-07-23 14:38, olcott wrote:
>>>>>>>>
>>>>>>>>> int main(){ P(P); } initially doesn't give H jack shit, that it
>>>>>>>>> the only reason why that P halts and this P never halts: int
>>>>>>>>> main(){ H(P,P); }
>>>>>>>>
>>>>>>>> Well, duh. Of course it doesn't 'give H jack shit' because H
>>>>>>>> *isn't being computed* in this case.
>>>>>>>
>>>>>>> Richard doesn't notice details like this.
>>>>>>
>>>>>> Richard gets it just fine. You're the one who is confused.
>>>>>>
>>>>>> int main(){ P(P); } is the only case we care about
>>>>>
>>>>> Then you are committed to deception.
>>>>
>>>> How so? the behaviour of int main(){ P(P); } is what int main(){
>>>> H(P,P); } is supposed to be deciding, so the behaviour of int main(){
>>>> P(P); } is the ultimate arbiter of the correct answer to the question.
>>>> AND IT HALTS.
>>>>
>>>
>>> I am going to stay focused on this one point until we have mutual
>>> agreement.
>>>
>>> _P()
>>> [00000c25](01) 55 push ebp
>>> [00000c26](02) 8bec mov ebp,esp
>>> [00000c28](03) 8b4508 mov eax,[ebp+08]
>>> [00000c2b](01) 50 push eax // 2nd Param
>>> [00000c2c](03) 8b4d08 mov ecx,[ebp+08]
>>> [00000c2f](01) 51 push ecx // 1st Param
>>> [00000c30](05) e820fdffff call 00000955 // call H
>>> [00000c35](03) 83c408 add esp,+08
>>> [00000c38](02) 85c0 test eax,eax
>>> [00000c3a](02) 7402 jz 00000c3e
>>> [00000c3c](02) ebfe jmp 00000c3c
>>> [00000c3e](01) 5d pop ebp
>>> [00000c3f](01) c3 ret
>>> Size in bytes:(0027) [00000c3f]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> Begin Local Halt Decider Simulation at Machine Address:c25
>>> [00000c25][00211776][0021177a] 55 push ebp // P begins
>>> [00000c26][00211776][0021177a] 8bec mov ebp,esp
>>> [00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
>>> [00000c2b][00211772][00000c25] 50 push eax // push P
>>> [00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
>>> [00000c2f][0021176e][00000c25] 51 push ecx // push P
>>> [00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
>>>
>>> [00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
>>> [00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
>>> [00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
>>> [00000c2b][0025c19a][00000c25] 50 push eax // push P
>>> [00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
>>> [00000c2f][0025c196][00000c25] 51 push ecx // push P
>>> [00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> If a person understands the x86 language and is not a liar they will
>>> admit that the pure simulation of P(P) cannot possibly ever reach its
>>> final state.
>>
>> As has been pointed out many times, this is an incorrect trace of the
>> program.
>>
>> You seem to be insisting that it is correct to deceive. YOU ARE A LIAR.
>>
>
> (1) H does perform a pure simulation of its input until after it makes
> its halt status decision.
Was ... Until ... does not mean IS.
Take a bowl of soup, prepare it in a totally clean environment.
Now crap on it.
Then eat it.
It was pure until... so by you logic it is pure. FAIL.
A Pure Simulation until ... is NOT a pure simulation.
>
> (2) It can be verified that this is a pure simulation on the basis that
> the execution trace does what the x86 source-code of P specifies.
WRONG, it doesn't show the tracd of the code of H, so it ISN'T a PURE
TRACE of the program P. Note, the H called by P is part of the program
P. You don't seem to understand this fundamental part of Software
Engineering, that the behavor of a program is the sum total of ALL of
the parts of the program.
>
> (3) Because there are no control flow instructions in the execution
> trace that can possibly escape the infinite recursion the execution
> trace proves that a pure simulation of the above input cannot possibly
> ever reach its final state.
Only because you have omitted them by a false trace.
UNSOUND Argument.
>
> (4) Therefore H was correct when it decided that its input never halts.
>
UNSOUND. FALSE.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-23 18:00 -0700 |
| Message-ID | <DCJKI.17614$_fgb.9133@fx01.iad> |
| In reply to | #36942 |
On 7/23/21 4:42 PM, André G. Isaak wrote:
> On 2021-07-23 14:38, olcott wrote:
>
>> int main(){ P(P); } initially doesn't give H jack shit, that it the
>> only reason why that P halts and this P never halts: int main(){
>> H(P,P); }
>
> Well, duh. Of course it doesn't 'give H jack shit' because H *isn't
> being computed* in this case.
>
> André
>
>
But the ALGORITHM of H IS being run, in the copy of it that has been put
into P.
This algorithm of H being passed the representation of P(P) will,
assuming that H actually is a computation as required, will give the
exact same value as the running of the Machine H given that same input.
It is not incorrect to describe this part of P as the sub-machine H,
which is basically a copy of H, with only slight modifications to the
terminal states to add the 'tail' code of P (really H^) to the machine.
This change is basically making the original qy of H into a non-halting
loop, but leaving qn to be a terminal state.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-23 22:12 +0100 |
| Message-ID | <87eebohgyx.fsf@bsb.me.uk> |
| In reply to | #36904 |
olcott <NoOne@NoWhere.com> writes:
> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>> compute the halting function. If it did, H(P, I) == 0 would be correct
>>>>>> only when P(I) does not stop running.
>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>> Seriously, go walk a shelter dog.
>>>>>
>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>> decided as not halting
>>>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>>>> does not compute the halting function because H(P, P) == 0. What else
>>>> do you have?
>>>
>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>> that its input cannot possibly reach its final state.
>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>> don't halt. You know this. H is not deciding halting, it's deciding
>> something else you refuse to give a name to.
> int main() { P(P); } only halts because H(P,P) correctly determines
> that its input cannot possibly reach its final state.
P(P) halts: agreed. H(P,P) == 0: agreed. For H to be a halt decider
H(P,I) == 0 only when P(I) does not halt: rejected by you. You reject
what a halt decider is, despite having quoted many authors on the
matter.
Do you think any amount of waffle can hide the fact that you are not
talking about what the world calls a halt decider?
>> (a) P(P) halts.
>> (b) H(P,P) == 0.
>> (c) H(P, I) == 0 is only correct if P(I) does not halt.
>> You don't accept (c). No amount of waffle about P(P) "only" halting
>> because reason, will alter what the right answer is.
>
> I understand that you have no problem with contradicting yourself as
> long as it supports your goal of staying focused on rebuttal no matter
I'll take it you don't disagree with this simple summary of why you are
wrong. If all you have left is claiming to misunderstand me you've come
to the end of the road. If you do disagree with this summary (that you
reject only fact (c)) you should say so. Only by agreeing to (c) can
you claim to have anything to say about halt deciders.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-23 16:49 -0500 |
| Message-ID | <teidnbRYSI_4pGb9nZ2dnUU7-V2dnZ2d@giganews.com> |
| In reply to | #36924 |
On 7/23/2021 4:12 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/22/2021 6:48 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/22/2021 6:04 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 7/22/2021 1:30 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> How is H(P,P)==0 correct even though P(P) stops running?
>>>>>>> Because H is not a halt decider. You've been clear that H does not
>>>>>>> compute the halting function. If it did, H(P, I) == 0 would be correct
>>>>>>> only when P(I) does not stop running.
>>>>>>> This is the pinnacle of your 17 years of "work" on halting?
>>>>>>> Seriously, go walk a shelter dog.
>>>>>>
>>>>>> The fact that P[0] Only halts because H(P[1],P[1]) was correctly
>>>>>> decided as not halting
>>>>> Stupid smoke and mirrors. P(P) halts. The reason does not matter. H
>>>>> does not compute the halting function because H(P, P) == 0. What else
>>>>> do you have?
>>>>
>>>> int main() { P(P); } only halts because H(P,P) correctly determines
>>>> that its input cannot possibly reach its final state.
>>> For H to be halt decider, H(P,I) == 0 only for computations P(I) that
>>> don't halt. You know this. H is not deciding halting, it's deciding
>>> something else you refuse to give a name to.
>
>> int main() { P(P); } only halts because H(P,P) correctly determines
>> that its input cannot possibly reach its final state.
>
> P(P) halts: agreed. H(P,P) == 0: agreed. For H to be a halt decider
> H(P,I) == 0 only when P(I) does not halt: rejected by you. You reject
> what a halt decider is, despite having quoted many authors on the
> matter.
>
> Do you think any amount of waffle can hide the fact that you are not
> talking about what the world calls a halt decider?
>
Because we know that the input to H(P,P) cannot possibly ever reach its
halt state while H remains a pure x86 emulator or not we know the its
input never halts.
That you fail to acknowledge this is dishonest.
I acknowledged that P of int main() { P(P); } halts once André pointed
out that the most definitive measure of halting is reaching a final state.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.theory
csiph-web