Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #35634 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2021-07-03 10:19 -0500 |
| Last post | 2021-07-04 14:14 +0100 |
| Articles | 20 on this page of 130 — 13 participants |
Back to article view | Back to comp.theory
Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 10:19 -0500
Re: Could H correctly decide that P never halts? wij <wyniijj@gmail.com> - 2021-07-03 08:25 -0700
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 10:32 -0500
Re: Could H correctly decide that P never halts? Richard Damon <Richard@Damon-Family.org> - 2021-07-03 11:56 -0400
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 11:19 -0500
Re: Could H correctly decide that P never halts? Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 18:28 +0200
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 11:51 -0500
Re: Could H correctly decide that P never halts? Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 19:18 +0200
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 12:19 -0500
Re: Could H correctly decide that P never halts? Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-03 19:33 +0200
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-03 19:10 +0100
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 13:49 -0500
Re: Could H correctly decide that P never halts? Richard Damon <Richard@Damon-Family.org> - 2021-07-03 14:29 -0400
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-03 17:25 +0100
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 11:49 -0500
Re: Could H correctly decide that P never halts? Richard Damon <Richard@Damon-Family.org> - 2021-07-03 14:17 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ] olcott <NoOne@NoWhere.com> - 2021-07-03 14:08 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ] Richard Damon <Richard@Damon-Family.org> - 2021-07-03 15:43 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-03 15:37 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-03 17:58 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-03 17:20 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-03 18:55 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Mr Flibble <flibble@reddwarf.jmc> - 2021-07-03 23:57 +0100
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-03 18:13 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-03 19:04 -0400
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] olcott <NoOne@NoWhere.com> - 2021-07-03 18:34 -0500
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] Richard Damon <Richard@Damon-Family.org> - 2021-07-03 20:06 -0400
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] olcott <NoOne@NoWhere.com> - 2021-07-03 19:26 -0500
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] Richard Damon <Richard@Damon-Family.org> - 2021-07-03 21:21 -0400
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] olcott <NoOne@NoWhere.com> - 2021-07-03 20:41 -0500
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] Richard Damon <Richard@Damon-Family.org> - 2021-07-03 22:13 -0400
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] olcott <NoOne@NoWhere.com> - 2021-07-03 21:22 -0500
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] Richard Damon <Richard@Damon-Family.org> - 2021-07-03 23:24 -0400
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] olcott <NoOne@NoWhere.com> - 2021-07-03 22:32 -0500
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] Richard Damon <Richard@Damon-Family.org> - 2021-07-04 06:40 -0400
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] olcott <NoOne@NoWhere.com> - 2021-07-04 09:24 -0500
Re: Could H correctly decide that P never halts? [ prerequisites to understanding me] Richard Damon <Richard@Damon-Family.org> - 2021-07-04 14:50 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-03 19:14 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-03 20:38 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-03 22:14 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-03 22:18 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-03 23:18 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-04 00:50 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-04 09:15 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-04 10:31 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 08:07 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-04 11:24 -0700
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-04 13:00 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-04 15:09 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-04 13:30 -0700
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 08:23 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-07-05 07:18 -0700
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 09:31 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 11:10 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 10:18 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 11:29 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 12:53 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 12:13 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) André G. Isaak <agisaak@gm.invalid> - 2021-07-04 14:55 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) "dklei...@gmail.com" <dkleinecke@gmail.com> - 2021-07-04 18:03 -0700
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-04 20:42 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-04 22:31 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 08:05 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 08:40 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 12:13 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Jeff Barnett <jbb@notatt.com> - 2021-07-04 23:20 -0600
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-05 18:49 +0100
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Jeff Barnett <jbb@notatt.com> - 2021-07-05 15:17 -0600
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-05 17:38 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-04 23:52 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 10:36 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 09:51 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 11:36 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) olcott <NoOne@NoWhere.com> - 2021-07-05 08:18 -0500
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 12:11 -0400
Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) Richard Damon <Richard@Damon-Family.org> - 2021-07-04 15:02 -0400
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-03 21:20 +0100
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 16:21 -0500
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-04 01:23 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-03 19:30 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-04 17:46 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-04 12:00 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-05 02:04 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-04 20:57 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-05 03:14 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-04 21:28 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-04 22:33 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-04 22:09 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 07:33 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-05 08:38 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 10:57 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-05 09:59 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 11:34 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 13:16 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-05 12:48 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 14:36 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 12:18 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-05 23:58 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-05 19:54 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 21:29 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-06 03:35 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-05 22:30 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-06 06:47 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] Daniel Pehoushek <pehoushek1@gmail.com> - 2021-07-06 04:15 -0700
Re: Could H correctly decide that P never halts? [ already agreed ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-06 13:23 +0100
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 07:21 -0400
Re: Could H correctly decide that P never halts? [ halting criteria ] olcott <NoOne@NoWhere.com> - 2021-07-05 08:26 -0500
Re: Could H correctly decide that P never halts? [ halting criteria ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 10:50 -0400
Re: Could H correctly decide that P never halts? [ halting criteria ] olcott <NoOne@NoWhere.com> - 2021-07-05 09:56 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 10:30 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] olcott <NoOne@NoWhere.com> - 2021-07-05 09:33 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] Richard Damon <Richard@Damon-Family.org> - 2021-07-05 11:02 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] (correction) olcott <NoOne@NoWhere.com> - 2021-07-05 09:35 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] (correction) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 12:38 -0400
Re: Could H correctly decide that P never halts? [ already agreed ] (correction) olcott <NoOne@NoWhere.com> - 2021-07-05 12:10 -0500
Re: Could H correctly decide that P never halts? [ already agreed ] (correction) Richard Damon <Richard@Damon-Family.org> - 2021-07-05 13:43 -0400
Re: Could H correctly decide that P never halts? [ Richard's excellent summation ] olcott <NoOne@NoWhere.com> - 2021-07-05 19:12 -0500
Re: Could H correctly decide that P never halts? Siri Cruise <chine.bleu@yahoo.com> - 2021-07-03 11:01 -0700
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 13:15 -0500
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-03 21:09 +0100
Re: Could H correctly decide that P never halts? [ incorrect question ] olcott <NoOne@NoWhere.com> - 2021-07-03 16:06 -0500
Re: Could H correctly decide that P never halts? [ incorrect question ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-04 01:44 +0100
Re: Could H correctly decide that P never halts? [ incorrect question ] olcott <NoOne@NoWhere.com> - 2021-07-03 19:59 -0500
Re: Could H correctly decide that P never halts? [ incorrect question ] Mr Flibble <flibble@reddwarf.jmc> - 2021-07-04 02:34 +0100
Re: Could H correctly decide that P never halts? [ incorrect question ] olcott <NoOne@NoWhere.com> - 2021-07-03 20:46 -0500
Re: Could H correctly decide that P never halts? [ incorrect question ] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-04 17:45 +0100
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-03 19:15 +0100
Re: Could H correctly decide that P never halts? olcott <NoOne@NoWhere.com> - 2021-07-03 13:58 -0500
Re: Could H correctly decide that P never halts? Siri Cruise <chine.bleu@yahoo.com> - 2021-07-03 22:37 -0700
Re: Could H correctly decide that P never halts? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-04 14:14 +0100
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-04 20:42 -0500 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <K-mdnTaiYdQV_n_9nZ2dnUU7-fXNnZ2d@giganews.com> |
| In reply to | #35708 |
On 7/4/2021 8:03 PM, dklei...@gmail.com wrote:
> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>> On 2021-07-04 14:09, olcott wrote:
>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>
>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>> However it was stated that "halts" is a simulating decider. Therefore we
>>>>> have one call to halts. It then emulates another call to halts. But the
>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>> emulated.
>>>>>
>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>
>>>> I've tried to get Olcott to clarify exactly what he means by
>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>> what the rest of the world means, but I still am unclear about what he
>>>> actually means.
>>>>
>>>> André
>>>>
>>>
>>> Sure everyone knows that an x86 emulator can be anything from a vanilla
>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>> software that executes x86 machine language as if this software virtual
>>> machine was an actual x86 processor.
>> The problem is that you keep talking about 'nested simulations' but
>> there's absolutely nothing in your code or your traces to suggest more
>> than a single level of emulation is involved.
>>
>> If your H *emulates* P, it should not contain a call to P. It should
>> contain a call to some function EMULATE with some description of P
>> (either a file or a memory location) as an *argument* to that function.
>> If that P includes an H which also emulates its input, there should be a
>> second call to EMULATE, meaning we should have one instance of the
>> emulator running on the actual hardware, and a second instance of the
>> emulator being interpreted by the first emulator rather than being run
>> on the actual hardware, and with a second instance of P being
>> interpreted by that emulated emulator rather than either the hardware or
>> the emulator which is running directly on the hardware.
>>
>> But this is not what appears to be happening in either your traces or
>> your code fragments.
>> André
>
> I think everyone agrees that PO's x86 work will never be accepted by any
> scholarly journal. Shouldn't we be trying to avoid using it.
>
> For starters we need a clear statement as to what is being proved complete
> with all the definitions a journal will require.
>
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}
I have proved that H correctly decides that P is a non-halting
computation on the basis that P calls H in infinitely nested simulation.
Computer scientists might notice that H and P are in their proper
halting problem relation to each other.
--
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-04 22:31 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <%9uEI.28079$Vj7.9306@fx46.iad> |
| In reply to | #35711 |
On 7/4/21 9:42 PM, olcott wrote: > > I have proved that H correctly decides that P is a non-halting > computation on the basis that P calls H in infinitely nested simulation. > Computer scientists might notice that H and P are in their proper > halting problem relation to each other. No, you haven't, because the ONLY P that does this is the P built on an H that NEVER aborts its simulation, but those H don't need to be disproved, as they never return the answer to H(P,P). If P is built on an H that does abort its simulation, then your trace is incorrect, as it is built on a transformation that assumes that the simulator doesn't abort it simulation. When you take THAT fact into account, you see that H never had the sound proof that P was infinitely nested. Please show an ACTUAL proof that the transformations you are using are valid in the case of a simulator that can decide to terminate its simulation under some conditions. (Or at least a reference to someone reliable that agrees with your claim).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-05 08:05 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <BACEI.7297$mR.5884@fx33.iad> |
| In reply to | #35711 |
On 7/4/21 9:42 PM, olcott wrote:
> On 7/4/2021 8:03 PM, dklei...@gmail.com wrote:
>> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>>> On 2021-07-04 14:09, olcott wrote:
>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>
>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>> Therefore we
>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>> But the
>>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>>> emulated.
>>>>>>
>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>
>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>>> what the rest of the world means, but I still am unclear about what he
>>>>> actually means.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Sure everyone knows that an x86 emulator can be anything from a vanilla
>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>> software that executes x86 machine language as if this software virtual
>>>> machine was an actual x86 processor.
>>> The problem is that you keep talking about 'nested simulations' but
>>> there's absolutely nothing in your code or your traces to suggest more
>>> than a single level of emulation is involved.
>>>
>>> If your H *emulates* P, it should not contain a call to P. It should
>>> contain a call to some function EMULATE with some description of P
>>> (either a file or a memory location) as an *argument* to that function.
>>> If that P includes an H which also emulates its input, there should be a
>>> second call to EMULATE, meaning we should have one instance of the
>>> emulator running on the actual hardware, and a second instance of the
>>> emulator being interpreted by the first emulator rather than being run
>>> on the actual hardware, and with a second instance of P being
>>> interpreted by that emulated emulator rather than either the hardware or
>>> the emulator which is running directly on the hardware.
>>>
>>> But this is not what appears to be happening in either your traces or
>>> your code fragments.
>>> André
>> I think everyone agrees that PO's x86 work will never be accepted by
>> any
>> scholarly journal. Shouldn't we be trying to avoid using it.
>>
>> For starters we need a clear statement as to what is being proved
>> complete
>> with all the definitions a journal will require.
>>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> void P(u32 x)
> {
> u32 Input_Halts = H(x, x);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
> int main()
> {
> u32 Input_Halts = H((u32)P, (u32)P);
> Output("Input_Halts = ", Input_Halts);
> }
>
> I have proved that H correctly decides that P is a non-halting
> computation on the basis that P calls H in infinitely nested simulation.
> Computer scientists might notice that H and P are in their proper
> halting problem relation to each other.
>
No, you haven't, because the scenerio you describe only happes if H is
programmed never to abort the P that is built from it, in which case
H(P,P) never answers, and thus deosn't need to be disproved, it did a
good enough job at doing that itself.
When you consider that H can (and in fact will) abort P, the analysis
becomes clearly flawed.
Ultimately, the problem comes because you ignore that the behavior of P
is more that the code of the function P, but of the WHOLE PROGRAM P,
which includes a copy of H, and thus P changes when H changes.
This is perhaps a fundamental and fatal flaw in your analysis, you are
thinking that you can determine that halting behavior of the PROGRAM P
by just looking at the code of the C function P without taking into
account the code that it calls.
By that logic, you can tell me if this program halts or not:
void P(u32 I) {
while(1) {
if(foo(I)) return;
I = I + 1;
}
}
should be simple if you are able to handle the tough case of a recursive
call without looking at the function that was calling.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-05 08:40 -0500 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <mL-dnd7DlOpLln79nZ2dnUU7-IGdnZ2d@giganews.com> |
| In reply to | #35726 |
On 7/5/2021 7:05 AM, Richard Damon wrote:
> On 7/4/21 9:42 PM, olcott wrote:
>> On 7/4/2021 8:03 PM, dklei...@gmail.com wrote:
>>> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>>>> On 2021-07-04 14:09, olcott wrote:
>>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>>
>>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>>> Therefore we
>>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>>> But the
>>>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>>>> emulated.
>>>>>>>
>>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>>
>>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>>>> what the rest of the world means, but I still am unclear about what he
>>>>>> actually means.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Sure everyone knows that an x86 emulator can be anything from a vanilla
>>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>>> software that executes x86 machine language as if this software virtual
>>>>> machine was an actual x86 processor.
>>>> The problem is that you keep talking about 'nested simulations' but
>>>> there's absolutely nothing in your code or your traces to suggest more
>>>> than a single level of emulation is involved.
>>>>
>>>> If your H *emulates* P, it should not contain a call to P. It should
>>>> contain a call to some function EMULATE with some description of P
>>>> (either a file or a memory location) as an *argument* to that function.
>>>> If that P includes an H which also emulates its input, there should be a
>>>> second call to EMULATE, meaning we should have one instance of the
>>>> emulator running on the actual hardware, and a second instance of the
>>>> emulator being interpreted by the first emulator rather than being run
>>>> on the actual hardware, and with a second instance of P being
>>>> interpreted by that emulated emulator rather than either the hardware or
>>>> the emulator which is running directly on the hardware.
>>>>
>>>> But this is not what appears to be happening in either your traces or
>>>> your code fragments.
>>>> André
>>> I think everyone agrees that PO's x86 work will never be accepted by
>>> any
>>> scholarly journal. Shouldn't we be trying to avoid using it.
>>>
>>> For starters we need a clear statement as to what is being proved
>>> complete
>>> with all the definitions a journal will require.
>>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> u32 Input_Halts = H((u32)P, (u32)P);
>> Output("Input_Halts = ", Input_Halts);
>> }
>>
>> I have proved that H correctly decides that P is a non-halting
>> computation on the basis that P calls H in infinitely nested simulation.
>> Computer scientists might notice that H and P are in their proper
>> halting problem relation to each other.
>>
>
> No, you haven't, because the scenerio you describe only happes if H is
> programmed never to abort the P that is built from it, in which case
> H(P,P) never answers, and thus deosn't need to be disproved, it did a
> good enough job at doing that itself.
Every H only acts as a pure x86 emulator until some P has demonstrated
that it will never halt unless it is aborted.
Once it is fully understood that any computation that never halts unless
its simulation is aborted is the correct non-halting criteria then it
can be understood that H(P,P)==0 correct.
It can be easily verified that if no H ever aborts any P that P(P) will
never halt. If any H must abort any P then this H does correctly decide
that this P does not halt.
--
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-05 12:13 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <4dGEI.13232$SMMb.8826@fx17.iad> |
| In reply to | #35735 |
On 7/5/21 9:40 AM, olcott wrote:
> On 7/5/2021 7:05 AM, Richard Damon wrote:
>> On 7/4/21 9:42 PM, olcott wrote:
>>> On 7/4/2021 8:03 PM, dklei...@gmail.com wrote:
>>>> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>>>>> On 2021-07-04 14:09, olcott wrote:
>>>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>>>
>>>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>>>> Therefore we
>>>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>>>> But the
>>>>>>>> second call to "halts" shouldn't appear on the execution trace.
>>>>>>>> It's
>>>>>>>> emulated.
>>>>>>>>
>>>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>>>
>>>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't
>>>>>>> mean
>>>>>>> what the rest of the world means, but I still am unclear about
>>>>>>> what he
>>>>>>> actually means.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Sure everyone knows that an x86 emulator can be anything from a
>>>>>> vanilla
>>>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>>>> software that executes x86 machine language as if this software
>>>>>> virtual
>>>>>> machine was an actual x86 processor.
>>>>> The problem is that you keep talking about 'nested simulations' but
>>>>> there's absolutely nothing in your code or your traces to suggest more
>>>>> than a single level of emulation is involved.
>>>>>
>>>>> If your H *emulates* P, it should not contain a call to P. It should
>>>>> contain a call to some function EMULATE with some description of P
>>>>> (either a file or a memory location) as an *argument* to that
>>>>> function.
>>>>> If that P includes an H which also emulates its input, there should
>>>>> be a
>>>>> second call to EMULATE, meaning we should have one instance of the
>>>>> emulator running on the actual hardware, and a second instance of the
>>>>> emulator being interpreted by the first emulator rather than being run
>>>>> on the actual hardware, and with a second instance of P being
>>>>> interpreted by that emulated emulator rather than either the
>>>>> hardware or
>>>>> the emulator which is running directly on the hardware.
>>>>>
>>>>> But this is not what appears to be happening in either your traces or
>>>>> your code fragments.
>>>>> André
>>>> I think everyone agrees that PO's x86 work will never be accepted by
>>>> any
>>>> scholarly journal. Shouldn't we be trying to avoid using it.
>>>>
>>>> For starters we need a clear statement as to what is being proved
>>>> complete
>>>> with all the definitions a journal will require.
>>>>
>>>
>>> // Simplified Linz Ĥ (Linz:1990:319)
>>> void P(u32 x)
>>> {
>>> u32 Input_Halts = H(x, x);
>>> if (Input_Halts)
>>> HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>> u32 Input_Halts = H((u32)P, (u32)P);
>>> Output("Input_Halts = ", Input_Halts);
>>> }
>>>
>>> I have proved that H correctly decides that P is a non-halting
>>> computation on the basis that P calls H in infinitely nested simulation.
>>> Computer scientists might notice that H and P are in their proper
>>> halting problem relation to each other.
>>>
>>
>> No, you haven't, because the scenerio you describe only happes if H is
>> programmed never to abort the P that is built from it, in which case
>> H(P,P) never answers, and thus deosn't need to be disproved, it did a
>> good enough job at doing that itself.
>
> Every H only acts as a pure x86 emulator until some P has demonstrated
> that it will never halt unless it is aborted.
>
> Once it is fully understood that any computation that never halts unless
> its simulation is aborted is the correct non-halting criteria then it
> can be understood that H(P,P)==0 correct.
>
> It can be easily verified that if no H ever aborts any P that P(P) will
> never halt. If any H must abort any P then this H does correctly decide
> that this P does not halt.
>
>
False, as refuted elsewhere. You really need to work on your PROOF, and
come up with a REAL ANALYTICAL PROOF, rather than just keep on repeating
the same disproved assumptions.
It makes it seem like you really don't have an idea how to actaully try
to prove your statement.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2021-07-04 23:20 -0600 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <sbu4qm$qjt$1@dont-email.me> |
| In reply to | #35708 |
On 7/4/2021 7:03 PM, dklei...@gmail.com wrote: > On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote: >> On 2021-07-04 14:09, olcott wrote: >>> On 7/4/2021 2:00 PM, André G. Isaak wrote: >>>> On 2021-07-04 12:24, Malcolm McLean wrote: >>>> >>>>> The execution trace showed two calls to the "halts" subroutine. >>>>> However it was stated that "halts" is a simulating decider. Therefore we >>>>> have one call to halts. It then emulates another call to halts. But the >>>>> second call to "halts" shouldn't appear on the execution trace. It's >>>>> emulated. >>>>> >>>>> So exactly what the decider is doing remains a bit opaque. >>>> >>>> I've tried to get Olcott to clarify exactly what he means by >>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean >>>> what the rest of the world means, but I still am unclear about what he >>>> actually means. >>>> >>>> André >>>> >>> >>> Sure everyone knows that an x86 emulator can be anything from a vanilla >>> milkshake machine to a dump truck. What I mean by x86 emulator is >>> software that executes x86 machine language as if this software virtual >>> machine was an actual x86 processor. >> The problem is that you keep talking about 'nested simulations' but >> there's absolutely nothing in your code or your traces to suggest more >> than a single level of emulation is involved. >> >> If your H *emulates* P, it should not contain a call to P. It should >> contain a call to some function EMULATE with some description of P >> (either a file or a memory location) as an *argument* to that function. >> If that P includes an H which also emulates its input, there should be a >> second call to EMULATE, meaning we should have one instance of the >> emulator running on the actual hardware, and a second instance of the >> emulator being interpreted by the first emulator rather than being run >> on the actual hardware, and with a second instance of P being >> interpreted by that emulated emulator rather than either the hardware or >> the emulator which is running directly on the hardware. >> >> But this is not what appears to be happening in either your traces or >> your code fragments. >> André > > I think everyone agrees that PO's x86 work will never be accepted by any > scholarly journal. Shouldn't we be trying to avoid using it. > > For starters we need a clear statement as to what is being proved complete > with all the definitions a journal will require. And why in hell should we bother to try and get a clear statement. The idea that our ignoramus/troll will ever submit anything to a refereed journal is fatuous. He will never acquire the ability to clearly state, formulate, or prove any interesting conjecture. All he will ever do, all he wants to do is participate in these ridiculous dialogues; repeat, rewind, repeat again, and on and on. He enjoys defeating every one of us even when he "acknowledges a flaw". Then he rewinds, repeats and doesn't miss a beat never admitting the acknowledgement nor retracting it. You cannot win this game because he's in it for the game, not the outcome. -- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2021-07-05 18:49 +0100 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <Zp-dnfkyK8TV2379nZ2dnUU78fHNnZ2d@brightview.co.uk> |
| In reply to | #35721 |
On 05/07/2021 06:20, Jeff Barnett wrote: > On 7/4/2021 7:03 PM, dklei...@gmail.com wrote: >> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote: >>> On 2021-07-04 14:09, olcott wrote: >>>> On 7/4/2021 2:00 PM, André G. Isaak wrote: >>>>> On 2021-07-04 12:24, Malcolm McLean wrote: >>>>> >>>>>> The execution trace showed two calls to the "halts" subroutine. >>>>>> However it was stated that "halts" is a simulating decider. >>>>>> Therefore we >>>>>> have one call to halts. It then emulates another call to halts. >>>>>> But the >>>>>> second call to "halts" shouldn't appear on the execution trace. It's >>>>>> emulated. >>>>>> >>>>>> So exactly what the decider is doing remains a bit opaque. >>>>> >>>>> I've tried to get Olcott to clarify exactly what he means by >>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean >>>>> what the rest of the world means, but I still am unclear about what he >>>>> actually means. >>>>> >>>>> André >>>>> >>>> >>>> Sure everyone knows that an x86 emulator can be anything from a vanilla >>>> milkshake machine to a dump truck. What I mean by x86 emulator is >>>> software that executes x86 machine language as if this software virtual >>>> machine was an actual x86 processor. >>> The problem is that you keep talking about 'nested simulations' but >>> there's absolutely nothing in your code or your traces to suggest more >>> than a single level of emulation is involved. >>> >>> If your H *emulates* P, it should not contain a call to P. It should >>> contain a call to some function EMULATE with some description of P >>> (either a file or a memory location) as an *argument* to that function. >>> If that P includes an H which also emulates its input, there should be a >>> second call to EMULATE, meaning we should have one instance of the >>> emulator running on the actual hardware, and a second instance of the >>> emulator being interpreted by the first emulator rather than being run >>> on the actual hardware, and with a second instance of P being >>> interpreted by that emulated emulator rather than either the hardware or >>> the emulator which is running directly on the hardware. >>> >>> But this is not what appears to be happening in either your traces or >>> your code fragments. >>> André >> I think everyone agrees that PO's x86 work will never be accepted by any >> scholarly journal. Shouldn't we be trying to avoid using it. >> >> For starters we need a clear statement as to what is being proved >> complete >> with all the definitions a journal will require. > > And why in hell should we bother to try and get a clear statement. Personally, I wouldn't, for the reasons you say below. But I suspect DK is just saying that a clear statement is a pre-requisite for PO publishing, not that /we/ have some duty to try to get one from him, which would be quite fruitless. > The > idea that our ignoramus/troll will ever submit anything to a refereed > journal is fatuous. He will never acquire the ability to clearly state, > formulate, or prove any interesting conjecture. All he will ever do, all > he wants to do is participate in these ridiculous dialogues; repeat, > rewind, repeat again, and on and on. He enjoys defeating every one of us > even when he "acknowledges a flaw". Then he rewinds, repeats and doesn't > miss a beat never admitting the acknowledgement nor retracting it. You > cannot win this game because he's in it for the game, not the outcome. I think PO /wants/ to do more than just argue here, and convinces himself that one day he will do that. So he is not trolling (mostly), but is just severely Deluded. His statements seem a bit like confabulation, where patients invent fantastical stories to cover gaps in their memories. Those patients are not lying as such, they're just saying things which make sense to them. PO doesn't have a memory impairment as far as I can tell, but I wonder whether similar confabulation can occur when someone has an intellectual reasoning impairment: they invent "fantastical logic" to explain their unreasoned intuitions, without understanding that to other people those explanations are ridiculous. (E.g. PO convincing himself that a computation that demonstrably halts is correctly classified as non-halting, because that was his first intuition before he actually tried it, and he can't abandon that intuition, which trumps any logic from other people. (And apparently trumps reality in this case!)) Such a person simply wouldn't realise that other people are genuinely /reasoning logically/ about these abstract ideas, and that terms and phrases they use have precise technical meanings that the everyone else /understands/. To such a person, it would seem that other people are just doing the same as them: half understanding stuff and spouting vague words and magical phrases to "prove" things, which is exactly what the logically impaired person is doing - so why does everyone take other peoples' proofs seriously but not theirs? It must be quite frustrating! You're right that we can't "win" the PO "game", but that's alright - PO is harmless, and nobody should feel he needs to be "defeated". And it's simply not possible IMO to genuinely /help/ him, so what needs to be done? Er, nothing. :) Mike.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2021-07-05 15:17 -0600 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <sbvssq$6bb$1@dont-email.me> |
| In reply to | #35766 |
On 7/5/2021 11:49 AM, Mike Terry wrote: > On 05/07/2021 06:20, Jeff Barnett wrote: >> On 7/4/2021 7:03 PM, dklei...@gmail.com wrote: <SNIP-AGE> >> And why in hell should we bother to try and get a clear statement. > > Personally, I wouldn't, for the reasons you say below. But I suspect DK > is just saying that a clear statement is a pre-requisite for PO > publishing, not that /we/ have some duty to try to get one from him, > which would be quite fruitless. > >> The >> idea that our ignoramus/troll will ever submit anything to a refereed >> journal is fatuous. He will never acquire the ability to clearly >> state, formulate, or prove any interesting conjecture. All he will >> ever do, all he wants to do is participate in these ridiculous >> dialogues; repeat, rewind, repeat again, and on and on. He enjoys >> defeating every one of us even when he "acknowledges a flaw". Then he >> rewinds, repeats and doesn't miss a beat never admitting the >> acknowledgement nor retracting it. You cannot win this game because >> he's in it for the game, not the outcome. > > I think PO /wants/ to do more than just argue here, and convinces > himself that one day he will do that. So he is not trolling (mostly), > but is just severely Deluded. His statements seem a bit like > confabulation, where patients invent fantastical stories to cover gaps > in their memories. Those patients are not lying as such, they're just > saying things which make sense to them. You might be interested that what you say here mirrors very closely the speculations and writings of Frederic Bartlett, "Remembering", written around the beginning of the last century. His work was the idea-spring for Piaget's theory of cognitive development, e.g., how children create motor schemata for walking. The essence of Bartlett is that we do not store "rote records"; rather, we learn patterns that organize our thoughts over time: a Birthday frame for example. That frame brings mixes together threads of presents, party, aging, etc. When we recall a birthday party and describe it we use the frame to organize that description and fill in what's missing. Example: Last year you arrive very late for friend Joe's birthday celebration. Today, I ask you what kind of cake was served. You think about it a little and answer "chocolate", Joe's favorite. Since you arrived late last year you missed that Joe was on a diet so he was putting candles on a half watermelon instead of a cake. If I asked you next year you would probably give a similar wrong answer. Bartlett's contention was that these frames fill in obvious defaults and it's difficult or impossible for us to distinguish between real and generated memories. He came to his conclusions using longitudinal studies that collected and analyzed mistakes in recall. He did not (I repeat DID NOT) experiment with nonsense words and the like. He used stories or descriptions that should be familiar to his subjects, real world slice of life stuff. People remembered things they were not told or shown as well as those they were! So there had to be some organizing and defaulting mechanisms in our gray matter. The best reference to the experiments and theory developed is the book "Remembering, A Study in Experimental and Social Psychology", Sir Frederic C. Bartlett, Cambridge University Press 1961. The first addition was published in 1932 and journal articles appeared much before that. He wrote another book "Thinking" that took off from the same premises and tried to say that's how we think as well as remember but that book was far less readable and never caught the attention or stirred the imagination the way "Remembering" did. > PO doesn't have a memory impairment as far as I can tell, but I wonder > whether similar confabulation can occur when someone has an intellectual > reasoning impairment: they invent "fantastical logic" to explain their > unreasoned intuitions, without understanding that to other people those > explanations are ridiculous. (E.g. PO convincing himself that a > computation that demonstrably halts is correctly classified as > non-halting, because that was his first intuition before he actually > tried it, and he can't abandon that intuition, which trumps any logic > from other people. (And apparently trumps reality in this case!)) > > Such a person simply wouldn't realise that other people are genuinely > /reasoning logically/ about these abstract ideas, and that terms and > phrases they use have precise technical meanings that the everyone else > /understands/. To such a person, it would seem that other people are > just doing the same as them: half understanding stuff and spouting vague > words and magical phrases to "prove" things, which is exactly what the > logically impaired person is doing - so why does everyone take other > peoples' proofs seriously but not theirs? It must be quite frustrating! > > You're right that we can't "win" the PO "game", but that's alright - PO > is harmless, and nobody should feel he needs to be "defeated". And it's > simply not possible IMO to genuinely /help/ him, so what needs to be > done? Er, nothing. :) A little more "nothing" might return this group to normal. On the other hand, I guess it's fun to watch a lunatic get bounced around like a rubber ball. Happy 4th observed. -- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-05 17:38 -0500 |
| Message-ID | <jqWdnYcQk85gFH79nZ2dnUU7-T_NnZ2d@giganews.com> |
| In reply to | #35766 |
On 7/5/2021 12:49 PM, Mike Terry wrote:
> On 05/07/2021 06:20, Jeff Barnett wrote:
>> On 7/4/2021 7:03 PM, dklei...@gmail.com wrote:
>>> On Sunday, July 4, 2021 at 1:55:27 PM UTC-7, André G. Isaak wrote:
>>>> On 2021-07-04 14:09, olcott wrote:
>>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>>
>>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>>> Therefore we
>>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>>> But the
>>>>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>>>>> emulated.
>>>>>>>
>>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>>
>>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>>>>> what the rest of the world means, but I still am unclear about
>>>>>> what he
>>>>>> actually means.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Sure everyone knows that an x86 emulator can be anything from a
>>>>> vanilla
>>>>> milkshake machine to a dump truck. What I mean by x86 emulator is
>>>>> software that executes x86 machine language as if this software
>>>>> virtual
>>>>> machine was an actual x86 processor.
>>>> The problem is that you keep talking about 'nested simulations' but
>>>> there's absolutely nothing in your code or your traces to suggest more
>>>> than a single level of emulation is involved.
>>>>
>>>> If your H *emulates* P, it should not contain a call to P. It should
>>>> contain a call to some function EMULATE with some description of P
>>>> (either a file or a memory location) as an *argument* to that function.
>>>> If that P includes an H which also emulates its input, there should
>>>> be a
>>>> second call to EMULATE, meaning we should have one instance of the
>>>> emulator running on the actual hardware, and a second instance of the
>>>> emulator being interpreted by the first emulator rather than being run
>>>> on the actual hardware, and with a second instance of P being
>>>> interpreted by that emulated emulator rather than either the
>>>> hardware or
>>>> the emulator which is running directly on the hardware.
>>>>
>>>> But this is not what appears to be happening in either your traces or
>>>> your code fragments.
>>>> André
>>> I think everyone agrees that PO's x86 work will never be accepted by any
>>> scholarly journal. Shouldn't we be trying to avoid using it.
>>>
>>> For starters we need a clear statement as to what is being proved
>>> complete
>>> with all the definitions a journal will require.
>>
>> And why in hell should we bother to try and get a clear statement.
>
> Personally, I wouldn't, for the reasons you say below. But I suspect DK
> is just saying that a clear statement is a pre-requisite for PO
> publishing, not that /we/ have some duty to try to get one from him,
> which would be quite fruitless.
>
>> The
>> idea that our ignoramus/troll will ever submit anything to a refereed
>> journal is fatuous. He will never acquire the ability to clearly
>> state, formulate, or prove any interesting conjecture. All he will
>> ever do, all he wants to do is participate in these ridiculous
>> dialogues; repeat, rewind, repeat again, and on and on. He enjoys
>> defeating every one of us even when he "acknowledges a flaw". Then he
>> rewinds, repeats and doesn't miss a beat never admitting the
>> acknowledgement nor retracting it. You cannot win this game because
>> he's in it for the game, not the outcome.
>
> I think PO /wants/ to do more than just argue here, and convinces
> himself that one day he will do that. So he is not trolling (mostly),
> but is just severely Deluded. His statements seem a bit like
> confabulation, where patients invent fantastical stories to cover gaps
> in their memories. Those patients are not lying as such, they're just
> saying things which make sense to them.
>
> PO doesn't have a memory impairment as far as I can tell, but I wonder
> whether similar confabulation can occur when someone has an intellectual
> reasoning impairment: they invent "fantastical logic" to explain their
> unreasoned intuitions, without understanding that to other people those
> explanations are ridiculous. (E.g. PO convincing himself that a
> computation that demonstrably halts is correctly classified as
> non-halting, because that was his first intuition before he actually
> tried it, and he can't abandon that intuition, which trumps any logic
> from other people. (And apparently trumps reality in this case!))
>
void P(u32 x)
{
u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
P((u32)P);
}
If you weren't dumber than a box of rocks you would understand that the
above computation never halts unless it is aborted at some point.
The above statement assumes the context of this paper
(where H is a simulating halt decider based on an x86 emulator):
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> Such a person simply wouldn't realise that other people are genuinely
> /reasoning logically/ about these abstract ideas, and that terms and
> phrases they use have precise technical meanings that the everyone else
> /understands/. To such a person, it would seem that other people are
> just doing the same as them: half understanding stuff and spouting vague
> words and magical phrases to "prove" things, which is exactly what the
> logically impaired person is doing - so why does everyone take other
> peoples' proofs seriously but not theirs? It must be quite frustrating!
>
> You're right that we can't "win" the PO "game", but that's alright - PO
> is harmless, and nobody should feel he needs to be "defeated". And it's
> simply not possible IMO to genuinely /help/ him, so what needs to be
> done? Er, nothing. :)
>
>
> Mike.
>
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-04 23:52 -0500 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <ovOdnXA3d5iWDX_9nZ2dnUU7-ffNnZ2d@giganews.com> |
| In reply to | #35707 |
On 7/4/2021 3:55 PM, André G. Isaak wrote:
> On 2021-07-04 14:09, olcott wrote:
>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>
>>>> The execution trace showed two calls to the "halts" subroutine.
>>>> However it was stated that "halts" is a simulating decider.
>>>> Therefore we
>>>> have one call to halts. It then emulates another call to halts. But
>>>> the
>>>> second call to "halts" shouldn't appear on the execution trace. It's
>>>> emulated.
>>>>
>>>> So exactly what the decider is doing remains a bit opaque.
>>>
>>> I've tried to get Olcott to clarify exactly what he means by
>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't mean
>>> what the rest of the world means, but I still am unclear about what
>>> he actually means.
>>>
>>> André
>>>
>>
>> Sure everyone knows that an x86 emulator can be anything from a
>> vanilla milkshake machine to a dump truck. What I mean by x86
>> emulator is software that executes x86 machine language as if this
>> software virtual machine was an actual x86 processor.
>
> The problem is that you keep talking about 'nested simulations' but
> there's absolutely nothing in your code or your traces to suggest more
> than a single level of emulation is involved.
>
You must not know assembly x86 language at all.
// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{
u32 Input_Halts = H(x, x); // call H 2nd level of simulation
if (Input_Halts)
HERE: goto HERE;
}
int main()
{
u32 Input_Halts = H((u32)P, (u32)P); // call H 1st level of simulation
Output("Input_Halts = ", Input_Halts);
}
_P()
[00000b1a](01) 55 push ebp
[00000b1b](02) 8bec mov ebp,esp
[00000b1d](01) 51 push ecx
[00000b1e](03) 8b4508 mov eax,[ebp+08]
[00000b21](01) 50 push eax // 2nd Param
[00000b22](03) 8b4d08 mov ecx,[ebp+08]
[00000b25](01) 51 push ecx // 1st Param
[00000b26](05) e81ffeffff call 0000094a // call H
[00000b2b](03) 83c408 add esp,+08
[00000b2e](03) 8945fc mov [ebp-04],eax
[00000b31](04) 837dfc00 cmp dword [ebp-04],+00
[00000b35](02) 7402 jz 00000b39
[00000b37](02) ebfe jmp 00000b37
[00000b39](02) 8be5 mov esp,ebp
[00000b3b](01) 5d pop ebp
[00000b3c](01) c3 ret
Size in bytes:(0035) [00000b3c]
_main()
[00000bda](01) 55 push ebp
[00000bdb](02) 8bec mov ebp,esp
[00000bdd](01) 51 push ecx
[00000bde](05) 681a0b0000 push 00000b1a // push address of P
[00000be3](05) 681a0b0000 push 00000b1a // push address of P
[00000be8](05) e85dfdffff call 0000094a // call H
[00000bed](03) 83c408 add esp,+08
[00000bf0](03) 8945fc mov [ebp-04],eax
[00000bf3](03) 8b45fc mov eax,[ebp-04]
[00000bf6](01) 50 push eax
[00000bf7](05) 683b030000 push 0000033b
[00000bfc](05) e869f7ffff call 0000036a
[00000c01](03) 83c408 add esp,+08
[00000c04](02) 33c0 xor eax,eax
[00000c06](02) 8be5 mov esp,ebp
[00000c08](01) 5d pop ebp
[00000c09](01) c3 ret
Size in bytes:(0048) [00000c09]
Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Machine language bytes
(5) Assembly language text
===============================
...[00000bda][00101647][00000000](01) 55 push ebp
...[00000bdb][00101647][00000000](02) 8bec mov ebp,esp
...[00000bdd][00101643][00000000](01) 51 push ecx
...[00000bde][0010163f][00000b1a](05) 681a0b0000 push 00000b1a //
push P
...[00000be3][0010163b][00000b1a](05) 681a0b0000 push 00000b1a //
push P
...[00000be8][00101637][00000bed](05) e85dfdffff call 0000094a //
call H
Begin Local Halt Decider Simulation at Machine Address:b1a
...[00000b1a][002116e7][002116eb](01) 55 push ebp
...[00000b1b][002116e7][002116eb](02) 8bec mov ebp,esp
...[00000b1d][002116e3][002016b7](01) 51 push ecx
...[00000b1e][002116e3][002016b7](03) 8b4508 mov eax,[ebp+08]
...[00000b21][002116df][00000b1a](01) 50 push eax //
push P
...[00000b22][002116df][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
...[00000b25][002116db][00000b1a](01) 51 push ecx //
push P
...[00000b26][002116d7][00000b2b](05) e81ffeffff call 0000094a //
call H
...[00000b1a][0025c10f][0025c113](01) 55 push ebp
...[00000b1b][0025c10f][0025c113](02) 8bec mov ebp,esp
...[00000b1d][0025c10b][0024c0df](01) 51 push ecx
...[00000b1e][0025c10b][0024c0df](03) 8b4508 mov eax,[ebp+08]
...[00000b21][0025c107][00000b1a](01) 50 push eax //
push P
...[00000b22][0025c107][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
...[00000b25][0025c103][00000b1a](01) 51 push ecx //
push P
...[00000b26][0025c0ff][00000b2b](05) e81ffeffff call 0000094a //
call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
In the above 16 instructions of the simulation of P(P) we can see that
the first 8 instructions of P are repeated. The end of this sequence of
8 instructions P calls H with its own machine address as the parameters
to H: H(P,P). Because H only examines the behavior of its inputs and
ignores its own behavior when H(P,P) is called we only see the first
instruction of P being simulated.
Anyone knowing the x86 language well enough can see that none of these 8
simulated instructions of P have any escape from their infinitely
repeating behavior pattern. When H recognizes this infinitely repeating
pattern it aborts its simulation of P(P) and reports that its input:
(P,P) would never halt on its input.
> If your H *emulates* P, it should not contain a call to P. It should
> contain a call to some function EMULATE with some description of P
> (either a file or a memory location) as an *argument* to that function.
> If that P includes an H which also emulates its input, there should be a
> second call to EMULATE, meaning we should have one instance of the
> emulator running on the actual hardware, and a second instance of the
> emulator being interpreted by the first emulator rather than being run
> on the actual hardware, and with a second instance of P being
> interpreted by that emulated emulator rather than either the hardware or
> the emulator which is running directly on the hardware.
>
> But this is not what appears to be happening in either your traces or
> your code fragments.
>
> 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-05 10:36 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <dOEEI.7460$8b2.6990@fx24.iad> |
| In reply to | #35720 |
On 7/5/21 12:52 AM, olcott wrote:
> On 7/4/2021 3:55 PM, André G. Isaak wrote:
>> On 2021-07-04 14:09, olcott wrote:
>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>
>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>> However it was stated that "halts" is a simulating decider.
>>>>> Therefore we
>>>>> have one call to halts. It then emulates another call to halts.
>>>>> But the
>>>>> second call to "halts" shouldn't appear on the execution trace.
>>>>> It's emulated.
>>>>>
>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>
>>>> I've tried to get Olcott to clarify exactly what he means by
>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't
>>>> mean what the rest of the world means, but I still am unclear about
>>>> what he actually means.
>>>>
>>>> André
>>>>
>>>
>>> Sure everyone knows that an x86 emulator can be anything from a
>>> vanilla milkshake machine to a dump truck. What I mean by x86
>>> emulator is software that executes x86 machine language as if this
>>> software virtual machine was an actual x86 processor.
>>
>> The problem is that you keep talking about 'nested simulations' but
>> there's absolutely nothing in your code or your traces to suggest more
>> than a single level of emulation is involved.
>>
>
> You must not know assembly x86 language at all.
>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> void P(u32 x)
> {
> u32 Input_Halts = H(x, x); // call H 2nd level of simulation
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> u32 Input_Halts = H((u32)P, (u32)P); // call H 1st level of simulation
> Output("Input_Halts = ", Input_Halts);
> }
>
>
> _P()
> [00000b1a](01) 55 push ebp
> [00000b1b](02) 8bec mov ebp,esp
> [00000b1d](01) 51 push ecx
> [00000b1e](03) 8b4508 mov eax,[ebp+08]
> [00000b21](01) 50 push eax // 2nd Param
> [00000b22](03) 8b4d08 mov ecx,[ebp+08]
> [00000b25](01) 51 push ecx // 1st Param
> [00000b26](05) e81ffeffff call 0000094a // call H
> [00000b2b](03) 83c408 add esp,+08
> [00000b2e](03) 8945fc mov [ebp-04],eax
> [00000b31](04) 837dfc00 cmp dword [ebp-04],+00
> [00000b35](02) 7402 jz 00000b39
> [00000b37](02) ebfe jmp 00000b37
> [00000b39](02) 8be5 mov esp,ebp
> [00000b3b](01) 5d pop ebp
> [00000b3c](01) c3 ret
> Size in bytes:(0035) [00000b3c]
>
> _main()
> [00000bda](01) 55 push ebp
> [00000bdb](02) 8bec mov ebp,esp
> [00000bdd](01) 51 push ecx
> [00000bde](05) 681a0b0000 push 00000b1a // push address of P
> [00000be3](05) 681a0b0000 push 00000b1a // push address of P
> [00000be8](05) e85dfdffff call 0000094a // call H
> [00000bed](03) 83c408 add esp,+08
> [00000bf0](03) 8945fc mov [ebp-04],eax
> [00000bf3](03) 8b45fc mov eax,[ebp-04]
> [00000bf6](01) 50 push eax
> [00000bf7](05) 683b030000 push 0000033b
> [00000bfc](05) e869f7ffff call 0000036a
> [00000c01](03) 83c408 add esp,+08
> [00000c04](02) 33c0 xor eax,eax
> [00000c06](02) 8be5 mov esp,ebp
> [00000c08](01) 5d pop ebp
> [00000c09](01) c3 ret
> Size in bytes:(0048) [00000c09]
>
> Columns
> (1) Machine address of instruction
> (2) Machine address of top of stack
> (3) Value of top of stack after instruction executed
> (4) Machine language bytes
> (5) Assembly language text
> ===============================
> ...[00000bda][00101647][00000000](01) 55 push ebp
> ...[00000bdb][00101647][00000000](02) 8bec mov ebp,esp
> ...[00000bdd][00101643][00000000](01) 51 push ecx
> ...[00000bde][0010163f][00000b1a](05) 681a0b0000 push 00000b1a //
> push P
> ...[00000be3][0010163b][00000b1a](05) 681a0b0000 push 00000b1a //
> push P
> ...[00000be8][00101637][00000bed](05) e85dfdffff call 0000094a //
> call H
>
> Begin Local Halt Decider Simulation at Machine Address:b1a
> ...[00000b1a][002116e7][002116eb](01) 55 push ebp
> ...[00000b1b][002116e7][002116eb](02) 8bec mov ebp,esp
> ...[00000b1d][002116e3][002016b7](01) 51 push ecx
> ...[00000b1e][002116e3][002016b7](03) 8b4508 mov eax,[ebp+08]
> ...[00000b21][002116df][00000b1a](01) 50 push eax //
> push P
> ...[00000b22][002116df][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000b25][002116db][00000b1a](01) 51 push ecx //
> push P
> ...[00000b26][002116d7][00000b2b](05) e81ffeffff call 0000094a //
> call H
> ...[00000b1a][0025c10f][0025c113](01) 55 push ebp
> ...[00000b1b][0025c10f][0025c113](02) 8bec mov ebp,esp
> ...[00000b1d][0025c10b][0024c0df](01) 51 push ecx
> ...[00000b1e][0025c10b][0024c0df](03) 8b4508 mov eax,[ebp+08]
> ...[00000b21][0025c107][00000b1a](01) 50 push eax //
> push P
> ...[00000b22][0025c107][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000b25][0025c103][00000b1a](01) 51 push ecx //
> push P
> ...[00000b26][0025c0ff][00000b2b](05) e81ffeffff call 0000094a //
> call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> In the above 16 instructions of the simulation of P(P) we can see that
> the first 8 instructions of P are repeated. The end of this sequence of
> 8 instructions P calls H with its own machine address as the parameters
> to H: H(P,P). Because H only examines the behavior of its inputs and
> ignores its own behavior when H(P,P) is called we only see the first
> instruction of P being simulated.
>
> Anyone knowing the x86 language well enough can see that none of these 8
> simulated instructions of P have any escape from their infinitely
> repeating behavior pattern. When H recognizes this infinitely repeating
> pattern it aborts its simulation of P(P) and reports that its input:
> (P,P) would never halt on its input.
>
And anyone knowing x86 assemblh code knows that this is NOT what
actually happened.
The call to H as 00000B256 should be followed by the code at 00000B26
inside the function H. That fact that it is not, is a sign that this is
NOT an actual trace of the exectution path of P.
In fact, the folling trace of the code at 00000B1A is NOT a trace of the
actual code stream that was traced in the previous lines, but a trace of
a different level simulation, a change of level of simulation that is
absolutely NOT indicated in the trace. Thus it is a false trace.
You justify this based on some transformational rules that are valid in
certain condition, but you don't make that clear, in part because those
conditions are NOT satisfied, and thus are invalid so the logic is unsound.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-05 09:51 -0500 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <cvqdnaGCv_HogX79nZ2dnUU7-RGdnZ2d@giganews.com> |
| In reply to | #35741 |
On 7/5/2021 9:36 AM, Richard Damon wrote:
> On 7/5/21 12:52 AM, olcott wrote:
>> On 7/4/2021 3:55 PM, André G. Isaak wrote:
>>> On 2021-07-04 14:09, olcott wrote:
>>>> On 7/4/2021 2:00 PM, André G. Isaak wrote:
>>>>> On 2021-07-04 12:24, Malcolm McLean wrote:
>>>>>
>>>>>> The execution trace showed two calls to the "halts" subroutine.
>>>>>> However it was stated that "halts" is a simulating decider.
>>>>>> Therefore we
>>>>>> have one call to halts. It then emulates another call to halts.
>>>>>> But the
>>>>>> second call to "halts" shouldn't appear on the execution trace.
>>>>>> It's emulated.
>>>>>>
>>>>>> So exactly what the decider is doing remains a bit opaque.
>>>>>
>>>>> I've tried to get Olcott to clarify exactly what he means by
>>>>> 'emulate'/'simulate' but to no avail. I'm fairly sure he doesn't
>>>>> mean what the rest of the world means, but I still am unclear about
>>>>> what he actually means.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Sure everyone knows that an x86 emulator can be anything from a
>>>> vanilla milkshake machine to a dump truck. What I mean by x86
>>>> emulator is software that executes x86 machine language as if this
>>>> software virtual machine was an actual x86 processor.
>>>
>>> The problem is that you keep talking about 'nested simulations' but
>>> there's absolutely nothing in your code or your traces to suggest more
>>> than a single level of emulation is involved.
>>>
>>
>> You must not know assembly x86 language at all.
>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x); // call H 2nd level of simulation
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>>
>> int main()
>> {
>> u32 Input_Halts = H((u32)P, (u32)P); // call H 1st level of simulation
>> Output("Input_Halts = ", Input_Halts);
>> }
>>
>>
>> _P()
>> [00000b1a](01) 55 push ebp
>> [00000b1b](02) 8bec mov ebp,esp
>> [00000b1d](01) 51 push ecx
>> [00000b1e](03) 8b4508 mov eax,[ebp+08]
>> [00000b21](01) 50 push eax // 2nd Param
>> [00000b22](03) 8b4d08 mov ecx,[ebp+08]
>> [00000b25](01) 51 push ecx // 1st Param
>> [00000b26](05) e81ffeffff call 0000094a // call H
>> [00000b2b](03) 83c408 add esp,+08
>> [00000b2e](03) 8945fc mov [ebp-04],eax
>> [00000b31](04) 837dfc00 cmp dword [ebp-04],+00
>> [00000b35](02) 7402 jz 00000b39
>> [00000b37](02) ebfe jmp 00000b37
>> [00000b39](02) 8be5 mov esp,ebp
>> [00000b3b](01) 5d pop ebp
>> [00000b3c](01) c3 ret
>> Size in bytes:(0035) [00000b3c]
>>
>> _main()
>> [00000bda](01) 55 push ebp
>> [00000bdb](02) 8bec mov ebp,esp
>> [00000bdd](01) 51 push ecx
>> [00000bde](05) 681a0b0000 push 00000b1a // push address of P
>> [00000be3](05) 681a0b0000 push 00000b1a // push address of P
>> [00000be8](05) e85dfdffff call 0000094a // call H
>> [00000bed](03) 83c408 add esp,+08
>> [00000bf0](03) 8945fc mov [ebp-04],eax
>> [00000bf3](03) 8b45fc mov eax,[ebp-04]
>> [00000bf6](01) 50 push eax
>> [00000bf7](05) 683b030000 push 0000033b
>> [00000bfc](05) e869f7ffff call 0000036a
>> [00000c01](03) 83c408 add esp,+08
>> [00000c04](02) 33c0 xor eax,eax
>> [00000c06](02) 8be5 mov esp,ebp
>> [00000c08](01) 5d pop ebp
>> [00000c09](01) c3 ret
>> Size in bytes:(0048) [00000c09]
>>
>> Columns
>> (1) Machine address of instruction
>> (2) Machine address of top of stack
>> (3) Value of top of stack after instruction executed
>> (4) Machine language bytes
>> (5) Assembly language text
>> ===============================
>> ...[00000bda][00101647][00000000](01) 55 push ebp
>> ...[00000bdb][00101647][00000000](02) 8bec mov ebp,esp
>> ...[00000bdd][00101643][00000000](01) 51 push ecx
>> ...[00000bde][0010163f][00000b1a](05) 681a0b0000 push 00000b1a //
>> push P
>> ...[00000be3][0010163b][00000b1a](05) 681a0b0000 push 00000b1a //
>> push P
>> ...[00000be8][00101637][00000bed](05) e85dfdffff call 0000094a //
>> call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:b1a
>> ...[00000b1a][002116e7][002116eb](01) 55 push ebp
>> ...[00000b1b][002116e7][002116eb](02) 8bec mov ebp,esp
>> ...[00000b1d][002116e3][002016b7](01) 51 push ecx
>> ...[00000b1e][002116e3][002016b7](03) 8b4508 mov eax,[ebp+08]
>> ...[00000b21][002116df][00000b1a](01) 50 push eax //
>> push P
>> ...[00000b22][002116df][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
>> ...[00000b25][002116db][00000b1a](01) 51 push ecx //
>> push P
>> ...[00000b26][002116d7][00000b2b](05) e81ffeffff call 0000094a //
>> call H
>> ...[00000b1a][0025c10f][0025c113](01) 55 push ebp
>> ...[00000b1b][0025c10f][0025c113](02) 8bec mov ebp,esp
>> ...[00000b1d][0025c10b][0024c0df](01) 51 push ecx
>> ...[00000b1e][0025c10b][0024c0df](03) 8b4508 mov eax,[ebp+08]
>> ...[00000b21][0025c107][00000b1a](01) 50 push eax //
>> push P
>> ...[00000b22][0025c107][00000b1a](03) 8b4d08 mov ecx,[ebp+08]
>> ...[00000b25][0025c103][00000b1a](01) 51 push ecx //
>> push P
>> ...[00000b26][0025c0ff][00000b2b](05) e81ffeffff call 0000094a //
>> call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> In the above 16 instructions of the simulation of P(P) we can see that
>> the first 8 instructions of P are repeated. The end of this sequence of
>> 8 instructions P calls H with its own machine address as the parameters
>> to H: H(P,P). Because H only examines the behavior of its inputs and
>> ignores its own behavior when H(P,P) is called we only see the first
>> instruction of P being simulated.
>>
>> Anyone knowing the x86 language well enough can see that none of these 8
>> simulated instructions of P have any escape from their infinitely
>> repeating behavior pattern. When H recognizes this infinitely repeating
>> pattern it aborts its simulation of P(P) and reports that its input:
>> (P,P) would never halt on its input.
>>
>
> And anyone knowing x86 assemblh code knows that this is NOT what
> actually happened.
>
> The call to H as 00000B256 should be followed by the code at 00000B26
> inside the function H.
I explained why it does not and why it does not need to.
--
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-05 11:36 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <XFFEI.420$9p5.386@fx19.iad> |
| In reply to | #35743 |
On 7/5/21 10:51 AM, olcott wrote: > On 7/5/2021 9:36 AM, Richard Damon wrote: >> The call to H as 00000B256 should be followed by the code at 00000B26 >> inside the function H. > > I explained why it does not and why it does not need to. > You have explained why you (incorrectly) THINK it doesn't. You are wrong on that, Try to actually PROVE (REAL PROOF, not just Rhetorically) that you don't or show a reputable source that says you don't.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-05 08:18 -0500 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <_pOdnT5w15EGm379nZ2dnUU7-cfNnZ2d@giganews.com> |
| In reply to | #35701 |
On 7/4/2021 1:24 PM, Malcolm McLean wrote: > On Sunday, 4 July 2021 at 15:15:46 UTC+1, olcott wrote: >> On 7/4/2021 1:50 AM, André G. Isaak wrote: >>> On 2021-07-03 22:18, olcott wrote: >>>> On 7/3/2021 11:14 PM, André G. Isaak wrote: >>>>> On 2021-07-03 19:38, olcott wrote: >>>>>> On 7/3/2021 8:14 PM, André G. Isaak wrote: >>>>>>> On 2021-07-03 14:37, olcott wrote: >>>>>>> >>>>>>>> It can always ignore it own behavior and it can do this by >>>>>>>> screening out machine address ranges to be ignored. H ignores all >>>>>>>> of its own behavior and the behavior or every operating system >>>>>>>> function. >>>>>>> >>>>>>> And in what universe does it make sense to simply ignore operating >>>>>>> system functions? >>>>>> >>>>>> When making a halt deciding function it only makes sense to keep >>>>>> track of those aspects of computations that can cause the input to >>>>>> halt. >>>>> >>>>> And what on earth would lead you to believe that a system call could >>>>> have no impact on halting? >>>>> >>>>> (You conveniently skipped the example I gave.) >>>>> >>>>> André >>>>> >>>> >>>> I am the only author of the entire x86utm operating system and all of >>>> its functions. >>> >>> And we're just supposed to take your word for it that these can >>> legitimately be ignored? >>> >>> Given that you've claimed that the instance of H called from within P >>> doesn't affect halting when it clearly does, your word isn't going to >>> carry much weight here. >>> >> No instance of any H has any effect on any P until some P proves that it >> will never halt unless aborted. This has always been able to be directly >> verified by the assembly language execution trace of P relative to its >> assembly language source code. >> >> This has been available posted directly in this forum since >> On 3/14/2021 12:46 PM, olcott wrote: >> >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>> If it really were the case that these things didn't have any affect on >>> halting, then it would also be perfectly fine for your halt decider to >>> *not* skip this code in its analysis, and that would avoid objections >> Most importantly you can easily verify for yourself that P is accurately >> simulated by comparing its x86 source code to its x86 execution trace. >> >> That no one has bothered to do this since March 14 would seem to >> indicate that no one here knows assembly language besides me. >> >> I have proven that H has no effect on its input since March 13 and the >> 16 lines of execution trace of the input proved to be totally >> overwhelming for everyone here. Adding 26,000 lines of more code would >> not help. >> > The execution trace showed two calls to the "halts" subroutine. > However it was stated that "halts" is a simulating decider. Therefore we > have one call to halts. It then emulates another call to halts. But the > second call to "halts" shouldn't appear on the execution trace. It's emulated. > > So exactly what the decider is doing remains a bit opaque. > Software emulators have all of the details of subordinate emulations as their own data. H makes sure to ignore every address of itself and all operating system functions because neither OS functions nor itself have any effect on the behavior of the input while the input is being simulated. -- 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-05 12:11 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <zaGEI.13231$SMMb.5798@fx17.iad> |
| In reply to | #35731 |
On 7/5/21 9:18 AM, olcott wrote: > On 7/4/2021 1:24 PM, Malcolm McLean wrote: >> On Sunday, 4 July 2021 at 15:15:46 UTC+1, olcott wrote: >>> On 7/4/2021 1:50 AM, André G. Isaak wrote: >>>> On 2021-07-03 22:18, olcott wrote: >>>>> On 7/3/2021 11:14 PM, André G. Isaak wrote: >>>>>> On 2021-07-03 19:38, olcott wrote: >>>>>>> On 7/3/2021 8:14 PM, André G. Isaak wrote: >>>>>>>> On 2021-07-03 14:37, olcott wrote: >>>>>>>> >>>>>>>>> It can always ignore it own behavior and it can do this by >>>>>>>>> screening out machine address ranges to be ignored. H ignores all >>>>>>>>> of its own behavior and the behavior or every operating system >>>>>>>>> function. >>>>>>>> >>>>>>>> And in what universe does it make sense to simply ignore operating >>>>>>>> system functions? >>>>>>> >>>>>>> When making a halt deciding function it only makes sense to keep >>>>>>> track of those aspects of computations that can cause the input to >>>>>>> halt. >>>>>> >>>>>> And what on earth would lead you to believe that a system call could >>>>>> have no impact on halting? >>>>>> >>>>>> (You conveniently skipped the example I gave.) >>>>>> >>>>>> André >>>>>> >>>>> >>>>> I am the only author of the entire x86utm operating system and all of >>>>> its functions. >>>> >>>> And we're just supposed to take your word for it that these can >>>> legitimately be ignored? >>>> >>>> Given that you've claimed that the instance of H called from within P >>>> doesn't affect halting when it clearly does, your word isn't going to >>>> carry much weight here. >>>> >>> No instance of any H has any effect on any P until some P proves that it >>> will never halt unless aborted. This has always been able to be directly >>> verified by the assembly language execution trace of P relative to its >>> assembly language source code. >>> >>> This has been available posted directly in this forum since >>> On 3/14/2021 12:46 PM, olcott wrote: >>> >>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation >>> >>>> If it really were the case that these things didn't have any affect on >>>> halting, then it would also be perfectly fine for your halt decider to >>>> *not* skip this code in its analysis, and that would avoid objections >>> Most importantly you can easily verify for yourself that P is accurately >>> simulated by comparing its x86 source code to its x86 execution trace. >>> >>> That no one has bothered to do this since March 14 would seem to >>> indicate that no one here knows assembly language besides me. >>> >>> I have proven that H has no effect on its input since March 13 and the >>> 16 lines of execution trace of the input proved to be totally >>> overwhelming for everyone here. Adding 26,000 lines of more code would >>> not help. >>> >> The execution trace showed two calls to the "halts" subroutine. >> However it was stated that "halts" is a simulating decider. Therefore we >> have one call to halts. It then emulates another call to halts. But the >> second call to "halts" shouldn't appear on the execution trace. It's >> emulated. >> >> So exactly what the decider is doing remains a bit opaque. >> > > Software emulators have all of the details of subordinate emulations as > their own data. H makes sure to ignore every address of itself and all > operating system functions because neither OS functions nor itself have > any effect on the behavior of the input while the input is being simulated. > > And thus ignores important behavior of the machine it is simulating. Remember, the H inside P is PART of P, and its behavior is part of the behavior of P. That is how Turing Machines, Programs and even Sub-programs works, BY DEFINITION.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-07-04 15:02 -0400 |
| Subject | Re: Could H correctly decide that P never halts? [ Why can H ignore its own behavior? ](my thanks to Richard) |
| Message-ID | <eBnEI.82368$G11.44322@fx01.iad> |
| In reply to | #35695 |
On 7/4/21 10:15 AM, olcott wrote: > On 7/4/2021 1:50 AM, André G. Isaak wrote: >> On 2021-07-03 22:18, olcott wrote: >>> On 7/3/2021 11:14 PM, André G. Isaak wrote: >>>> On 2021-07-03 19:38, olcott wrote: >>>>> On 7/3/2021 8:14 PM, André G. Isaak wrote: >>>>>> On 2021-07-03 14:37, olcott wrote: >>>>>> >>>>>>> It can always ignore it own behavior and it can do this by >>>>>>> screening out machine address ranges to be ignored. H ignores all >>>>>>> of its own behavior and the behavior or every operating system >>>>>>> function. >>>>>> >>>>>> And in what universe does it make sense to simply ignore operating >>>>>> system functions? >>>>> >>>>> When making a halt deciding function it only makes sense to keep >>>>> track of those aspects of computations that can cause the input to >>>>> halt. >>>> >>>> And what on earth would lead you to believe that a system call could >>>> have no impact on halting? >>>> >>>> (You conveniently skipped the example I gave.) >>>> >>>> André >>>> >>> >>> I am the only author of the entire x86utm operating system and all of >>> its functions. >> >> And we're just supposed to take your word for it that these can >> legitimately be ignored? >> >> Given that you've claimed that the instance of H called from within P >> doesn't affect halting when it clearly does, your word isn't going to >> carry much weight here. >> > > No instance of any H has any effect on any P until some P proves that it > will never halt unless aborted. This has always been able to be directly > verified by the assembly language execution trace of P relative to its > assembly language source code. P was never PROVED to be non-halting. There was a faulty determination that it appears to be, but that determination makes the false assumption that no H will abort a simulation. Since H does abort the simulation, that is a false premise, thus the logic used to decide that P was non-halting is unsound. Thus H ERRED in deciding that P was non-halting and thus INCORRECTLY halted its simulation and returned the WRONG answer of non-halting. > > This has been available posted directly in this forum since > On 3/14/2021 12:46 PM, olcott wrote: > > https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation > > >> If it really were the case that these things didn't have any affect on >> halting, then it would also be perfectly fine for your halt decider to >> *not* skip this code in its analysis, and that would avoid objections > > Most importantly you can easily verify for yourself that P is accurately > simulated by comparing its x86 source code to its x86 execution trace. Right, and we see that the execution trace is improper as the execution trace does NOT include the code of H that P calls. Thus it is NOT a valid trace. You make an arguement that it is an 'equivalent' trace, but the limitations on this sort of transformation include: It is valid for a PURE simulator that doesn't ever abort its simulation. This is not true, H will abort its simulation, and thus the transform is incorrect. or It ia valid for a bounded number of substitutions for a proven finite machine. The claim is this forms an infinite execution, thus was NOT done just a bounded number of times, and because if we want to decide that the computation was infinite, that negates the right to use the transform in this way at all (but does not prove it to be infinite). > > That no one has bothered to do this since March 14 would seem to > indicate that no one here knows assembly language besides me. > It has been pointed out MANY times that the trace is logically WRONG. > I have proven that H has no effect on its input since March 13 and the > 16 lines of execution trace of the input proved to be totally > overwhelming for everyone here. Adding 26,000 lines of more code would > not help. WRONG. > >> along these lines. But if you did that you'd see that your assessment >> is wrong. >> >> André >> > >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-03 21:20 +0100 |
| Message-ID | <87im1rdu8s.fsf@bsb.me.uk> |
| In reply to | #35643 |
olcott <NoOne@NoWhere.com> writes:
> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> void P(u32 x)
>>> {
>>> u32 Input_Halts = H(x, x);
>>> if (Input_Halts)
>>> HERE: goto HERE;
>>> }
>> For H(P,P) to be correct one of these must apply:
>>
>> H(P,P) == 0 and P(P) does not halt, or
>> H(P,P) != 0 and P(P) halts.
>>
>> Neither is the case.
>
> Superficially it may seem that way until you realize (as you have
> already realized) that the halt criteria must be adapted for a
> simulating halt decider.
The two criteria I gave are for the halting problem. No one is
interested in your "other kind of halting". It seems you agree that H
is wrong about the input given above as far as the criterion of actual
halting goes.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-03 16:21 -0500 |
| Message-ID | <mL-dnUBUU5d7SX39nZ2dnUU7-U_NnZ2d@giganews.com> |
| In reply to | #35659 |
On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>> For H(P,P) to be correct one of these must apply:
>>>
>>> H(P,P) == 0 and P(P) does not halt, or
>>> H(P,P) != 0 and P(P) halts.
>>>
>>> Neither is the case.
>>
>> Superficially it may seem that way until you realize (as you have
>> already realized) that the halt criteria must be adapted for a
>> simulating halt decider.
>
> The two criteria I gave are for the halting problem. No one is
> interested in your "other kind of halting". It seems you agree that H
> is wrong about the input given above as far as the criterion of actual
> halting goes.
>
Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.
Does the input halt on its input?
must become
Does the input halt without having its simulation aborted?
This change is required because every input to a simulating halt decider
either halts on its own or halts because its simulation has been aborted.
Apparently only a simulating halt decider can correctly decide the
otherwise impossible inputs.
If you can significantly help me to get these ideas understood you can
be cited in my paper along with Kaz) as one of my two most important
reviewers. If you are the key to getting these ideas understood and
accepted you will be cited as my most important reviewer.
Whomever is the key to getting these ideas understood and accepted will
be cited as my most important reviewer.
Edsger W. Dijkstra merely wrote a letter to the editor of the CACM and
won the Turing award four years later.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-07-04 01:23 +0100 |
| Message-ID | <875yxrdj0o.fsf@bsb.me.uk> |
| In reply to | #35662 |
olcott <NoOne@NoWhere.com> writes:
> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> u32 Input_Halts = H(x, x);
>>>>> if (Input_Halts)
>>>>> HERE: goto HERE;
>>>>> }
>>>> For H(P,P) to be correct one of these must apply:
>>>>
>>>> H(P,P) == 0 and P(P) does not halt, or
>>>> H(P,P) != 0 and P(P) halts.
>>>>
>>>> Neither is the case.
>>>
>>> Superficially it may seem that way until you realize (as you have
>>> already realized) that the halt criteria must be adapted for a
>>> simulating halt decider.
>>>
>> The two criteria I gave are for the halting problem. No one is
>> interested in your "other kind of halting". It seems you agree that H
>> is wrong about the input given above as far as the criterion of actual
>> halting goes.
>
> Because a simulating halt decider must always abort the simulation of
> every input that never halts its halt deciding criteria must be
> adapted.
If you "adapted" the criterion for being a prime number you could
"refute" many more theorems.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2021-07-03 19:30 -0500 |
| Subject | Re: Could H correctly decide that P never halts? [ already agreed ] |
| Message-ID | <yf2dnc-On5-7nHz9nZ2dnUU7-ffNnZ2d@giganews.com> |
| In reply to | #35671 |
On 7/3/2021 7:23 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/3/2021 3:20 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/3/2021 11:25 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> u32 Input_Halts = H(x, x);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>> For H(P,P) to be correct one of these must apply:
>>>>>
>>>>> H(P,P) == 0 and P(P) does not halt, or
>>>>> H(P,P) != 0 and P(P) halts.
>>>>>
>>>>> Neither is the case.
>>>>
>>>> Superficially it may seem that way until you realize (as you have
>>>> already realized) that the halt criteria must be adapted for a
>>>> simulating halt decider.
>>>>
>>> The two criteria I gave are for the halting problem. No one is
>>> interested in your "other kind of halting". It seems you agree that H
>>> is wrong about the input given above as far as the criterion of actual
>>> halting goes.
>>
>> Because a simulating halt decider must always abort the simulation of
>> every input that never halts its halt deciding criteria must be
>> adapted.
>
> If you "adapted" the criterion for being a prime number you could
> "refute" many more theorems.
>
You already agreed that this adaptation of the halt status criteria is
correct:
On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.theory
csiph-web