Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #51785 > unrolled thread
| Started by | olcott <NoOne@NoWhere.com> |
|---|---|
| First post | 2022-06-03 17:17 -0500 |
| Last post | 2022-06-04 00:36 +0100 |
| Articles | 20 on this page of 165 — 11 participants |
Back to article view | Back to comp.theory
Refuting the HP proofs (adapted for software engineers) olcott <NoOne@NoWhere.com> - 2022-06-03 17:17 -0500
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-03 18:50 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-06-04 00:35 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-03 18:56 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-03 20:20 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-03 22:51 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-06-04 03:01 -0700
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-04 10:11 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 11:38 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] olcott <NoOne@NoWhere.com> - 2022-06-04 10:51 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 12:11 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] olcott <NoOne@NoWhere.com> - 2022-06-04 11:25 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 13:15 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] olcott <NoOne@NoWhere.com> - 2022-06-04 12:23 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 14:09 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] olcott <NoOne@NoWhere.com> - 2022-06-04 13:14 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 14:31 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] olcott <NoOne@NoWhere.com> - 2022-06-04 13:39 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ BRAIN DEAD MORON ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 14:49 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Alan Mackenzie <acm@muc.de> - 2022-06-04 18:17 +0000
Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] olcott <NoOne@NoWhere.com> - 2022-06-04 13:37 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 14:54 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] olcott <NoOne@NoWhere.com> - 2022-06-04 14:01 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 15:57 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] Alan Mackenzie <acm@muc.de> - 2022-06-04 19:02 +0000
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-04 14:28 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 16:05 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] [OT] Jeff Barnett <jbb@notatt.com> - 2022-06-04 17:30 -0600
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mikko <mikko.levanto@iki.fi> - 2022-06-05 13:14 +0300
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 05:34 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Alan Mackenzie <acm@muc.de> - 2022-06-05 11:12 +0000
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 06:21 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 07:58 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 14:47 +0100
Re: Refuting the HP proofs (adapted for software engineers) Andy Walker <anw@cuboid.co.uk> - 2022-06-05 16:28 +0100
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 16:34 +0100
Re: Refuting the HP proofs (adapted for software engineers) Alan Mackenzie <acm@muc.de> - 2022-06-05 15:44 +0000
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 16:49 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:22 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:28 +0100
Re: Refuting the HP proofs (adapted for software engineers) olcott <NoOne@NoWhere.com> - 2022-06-05 11:35 -0500
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:50 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:56 +0100
Re: Refuting the HP proofs (adapted for software engineers) olcott <NoOne@NoWhere.com> - 2022-06-05 12:01 -0500
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:19 +0100
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:27 +0100
Re: Refuting the HP proofs (adapted for software engineers) olcott <NoOne@NoWhere.com> - 2022-06-05 12:58 -0500
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:13 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:14 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 17:46 -0400
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 13:05 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:22 +0100
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:26 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:17 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:17 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:30 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:33 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:47 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:56 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 16:09 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 21:23 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 16:32 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mikko <mikko.levanto@iki.fi> - 2022-06-06 16:10 +0300
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-06 17:47 +0100
Re: Refuting the HP proofs (adapted for software engineers) Andy Walker <anw@cuboid.co.uk> - 2022-06-05 18:44 +0100
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:48 +0100
Re: Refuting the HP proofs (adapted for software engineers) olcott <NoOne@NoWhere.com> - 2022-06-05 11:29 -0500
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:53 -0400
Re: Refuting the HP proofs (adapted for software engineers) Alan Mackenzie <acm@muc.de> - 2022-06-05 16:34 +0000
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:38 +0100
Re: Refuting the HP proofs (adapted for software engineers) olcott <NoOne@NoWhere.com> - 2022-06-05 11:41 -0500
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:42 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:54 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:58 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 13:07 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:23 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:20 -0400
Re: Refuting the HP proofs (adapted for software engineers) Alan Mackenzie <acm@muc.de> - 2022-06-05 17:04 +0000
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:17 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:37 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:57 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 18:17 +0100
Re: Refuting the HP proofs (adapted for software engineers) Alan Mackenzie <acm@muc.de> - 2022-06-05 18:07 +0000
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:19 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:32 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:34 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:49 -0400
Re: Refuting the HP proofs (adapted for software engineers) Alan Mackenzie <acm@muc.de> - 2022-06-05 19:42 +0000
Re: Refuting the HP proofs (adapted for software engineers) Mikko <mikko.levanto@iki.fi> - 2022-06-06 16:03 +0300
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:24 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:18 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:38 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 20:44 +0100
Re: Refuting the HP proofs (adapted for software engineers) Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:54 -0400
Re: Refuting the HP proofs (adapted for software engineers) Ben <ben.usenet@bsb.me.uk> - 2022-06-05 18:56 +0100
Re: Refuting the HP proofs (adapted for software engineers) [ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 13:07 -0500
Re: Refuting the HP proofs (adapted for software engineers) [ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:29 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Alan Mackenzie <acm@muc.de> - 2022-06-05 12:14 +0000
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Ben <ben.usenet@bsb.me.uk> - 2022-06-05 13:38 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Ben <ben.usenet@bsb.me.uk> - 2022-06-05 16:17 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 10:59 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:29 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 10:57 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:31 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 11:39 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:59 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 12:02 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:31 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 13:35 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 14:54 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 13:57 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 14:09 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:25 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 14:33 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 15:43 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 11:24 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-05 15:46 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Alan Mackenzie <acm@muc.de> - 2022-06-05 15:16 +0000
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 11:10 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-05 21:07 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 15:15 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 21:28 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 15:36 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 16:44 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 16:38 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 15:41 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 16:57 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Jeff Barnett <jbb@notatt.com> - 2022-06-05 15:59 -0600
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-06 00:59 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Jeff Barnett <jbb@notatt.com> - 2022-06-05 18:24 -0600
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Ben <ben.usenet@bsb.me.uk> - 2022-06-06 01:40 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Jeff Barnett <jbb@notatt.com> - 2022-06-05 18:44 -0600
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 20:03 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 21:59 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 21:14 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 22:44 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-06-06 02:58 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 21:11 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 22:20 -0400
Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] olcott <NoOne@NoWhere.com> - 2022-06-05 21:37 -0500
Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 22:52 -0400
Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] olcott <NoOne@NoWhere.com> - 2022-06-05 22:03 -0500
Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 23:26 -0400
Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] olcott <NoOne@NoWhere.com> - 2022-06-05 22:41 -0500
Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] Richard Damon <Richard@Damon-Family.org> - 2022-06-06 00:17 -0400
Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] olcott <NoOne@NoWhere.com> - 2022-06-06 10:28 -0500
Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] Richard Damon <Richard@Damon-Family.org> - 2022-06-06 21:04 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 22:15 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 21:22 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 22:38 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] olcott <NoOne@NoWhere.com> - 2022-06-05 19:27 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 20:56 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ members of c/c++ ] olcott <NoOne@NoWhere.com> - 2022-06-07 20:04 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ members of c/c++ ] Richard Damon <Richard@Damon-Family.org> - 2022-06-07 22:45 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-06 17:49 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] olcott <NoOne@NoWhere.com> - 2022-06-06 11:59 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 11:07 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Mr Flibble <flibble@reddwarf.jmc> - 2022-06-05 17:12 +0100
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-05 11:15 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:45 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-05 12:41 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 06:27 -0400
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] olcott <NoOne@NoWhere.com> - 2022-06-04 10:28 -0500
Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] Richard Damon <Richard@Damon-Family.org> - 2022-06-04 11:51 -0400
Re: Refuting the HP proofs (adapted for software engineers) Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-06-04 00:36 +0100
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 15:15 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <jNudnR8OsYickgD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51943 |
On 6/5/2022 3:07 PM, Mike Terry wrote:
> On 05/06/2022 16:16, Alan Mackenzie wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> On 05/06/2022 13:14, Alan Mackenzie wrote:
>>>> olcott <NoOne@nowhere.com> wrote:
>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>
>>>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>>>> configuration for which δ is not defined; this is possible because
>>>>>>>>> δ is a partial function. In fact, we will assume that no
>>>>>>>>> transitions are defined for any final state so the Turing machine
>>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234)
>>
>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>> Automata.
>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>
>>>>>>>>> When translated into ordinary software engineering terms this
>>>>>>>>> means
>>>>>>>>> terminated normally. In a C function this means reaching the "ret"
>>>>>>>>> instruction.
>>
>>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>>>>>> defined" should include at least:
>>>>>>>> - HLT or any other instruction that means 'halt'
>>>>>>>> - any undefined op code
>>>>>>>> - any return or pop instruction if the stack is empty
>>>>>>>> - an instruction fetch from a location that is not specifiec by the
>>>>>>>> program
>>>>>>>> That way the analogy to Linz' definition is much better.
>>
>>>>>>>> Mikko
>>
>>>>>>> Reaching a final state is merely the Turing machine way of saying
>>>>>>> terminated normally. "ret" is the C way of saying the same thing.
>>
>>>>>> Sophistry. What would be the turing machine equivalent of an
>>>>>> "abnormal termination" in C?
>>
>>>>> An aborted simulation.
>>
>>>> There's no such thing on a turing machine. It either runs and halts,
>>>> or it runs forever.
>>
>>>> Your aborted simulation is just one final state of a turing machine,
>>>> which has thus halted.
>>
>>> A TM "aborting" a simulation is just the TM ceasing to calculate
>>> computation steps for some computation, and going on to calculate
>>> something else instead. It does not mean:
>>> a) that the TM (doing the simulation) has halted
>>> b) that the simulated computation halts
>>> c) that the simulated computation never halts
>>
>> OK. I've a feeling we're talking more about nice shades of words than
>> computer science here, but ....
>>
>> If the simulation is the entire turing machine, aborting it will bring
>> the TM to a halt state. If that simulation is merely part of the TM,
>> then the word "halt" has a different meaning when applied to that
>> simulation part from when applied to the entire TM. I'm not even sure
>> what you mean when you say a part of a TM has halted or not halted.
>
> We are clearly talking at cross purposes - I never talked about /part/
> of a TM halting, and like you, I can't work out what that would mean! I
> used "halt" only with respect to a computation, meaning that the
> computation halts [there is an n such that computation step n is a TM
> final state].
>
> Reading what you say very carefully, I think that by your definition of
> simulation, the simulating TM must be a "pure" simulator that does
> nothing but simulate computation steps until the simulation halts, at
> which point the simulating TM halts (like a UTM). I get that with that
> interpretation what you said:
>
> <copied from above>
> >>> Your aborted simulation is just one final state of a turing machine,
> >>> which has thus halted.
>
> makes sense and is correct. I'd just say I don't think that usage of
> "simulation" is very useful, and is DEFINITELY not what PO is talking
> about (so it would be wrong if applied PO's posts...)
>
> My use of "simulation" is broader: it's simply the activity performed by
> a TM which consists of calculating computation steps of some given
> computation. As such it's just a part of the TM logic. A TM's typical
> use of simulation might be something like "..the TM simulates the
> computation for n steps, and if the simulation halts during those n
> steps, the TM [blah blah], /otherwise/ the TM [blah blah blah]...".
> Just about every reference in the literature I can recall is something
> like that.
>
> So... to be 100% clear on what I said:
>
> <copied from above>
> >> A TM "aborting" a simulation is just the TM ceasing to calculate
> >> computation steps for some computation, and going on to calculate
> >> something else instead.
>
> E.g. in PO's P, after P aborts its simulation of P(P), the TM either
> halts or enters an infinite loop. (That logic is not part of the
> simulation, IMO.)
>
> >> It does *NOT* mean:
> >> a) that the TM (doing the simulation) has halted
>
> obviously, because now P has gone on to something else...
>
> >> b) that the simulated computation halts
> >> c) that the simulated computation never halts
>
> obviously - in general different exacmples of a simulated computation
> P(I) might halt or never halt, and this is unaffected by a simulator's
> decision to simulate no further computation steps. [The TM may have
> spotted some pattern in the simulated computation which implies P(I)
> never halts - that is a separate matter, but for sure the mere act of
> "aborting" the simulation doesn't imply P(I) never halts, or imply that
> it halts...
>
> Put yet another way, when a TM stops calculating TM steps (aka aborts
> its simulation), NOTHING HALTS: not the simulating TM, not the simulated
> computation, and NOT ANY PART OF EITHER OF THOSE. (Like you say, what
> would part of a TM halting mean?)
>
>
> Mike.
THIS IS EXACTLY WHAT I MEAN.
H0(Infinite_Loop) correctly determines that its input never halts.
If we really want to get totally tediously precise (tedium utterly
freaks me out) we can say that the finite string machine code specified
as an input parameter to the C function H0 specifies a sequence of
instructions that would never reach their "ret" instruction.
void Infinite_Loop()
{
HERE: goto HERE;
}
int main()
{
Output("Input_Halts = ", H0(Infinite_Loop));
}
_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]
_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6842130000 push 00001342
[0000137a](05) e833fdffff call 000010b2
[0000137f](03) 83c404 add esp,+04
[00001382](01) 50 push eax
[00001383](05) 6823040000 push 00000423
[00001388](05) e8e5f0ffff call 00000472
[0000138d](03) 83c408 add esp,+08
[00001390](02) 33c0 xor eax,eax
[00001392](01) 5d pop ebp
[00001393](01) c3 ret
Size in bytes:(0034) [00001393]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001372][0010228f][00000000] 55 push ebp
[00001373][0010228f][00000000] 8bec mov ebp,esp
[00001375][0010228b][00001342] 6842130000 push 00001342 // push
_Infinite_Loop
[0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped
[0000137f][0010228f][00000000] 83c404 add esp,+04
[00001382][0010228b][00000000] 50 push eax
[00001383][00102287][00000423] 6823040000 push 00000423
[00001388][00102287][00000423] e8e5f0ffff call 00000472
Input_Halts = 0
[0000138d][0010228f][00000000] 83c408 add esp,+08
[00001390][0010228f][00000000] 33c0 xor eax,eax
[00001392][00102293][00100000] 5d pop ebp
[00001393][00102297][00000004] c3 ret
Number of Instructions Executed(680)
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-05 21:28 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <20220605212800.00003eae@reddwarf.jmc> |
| In reply to | #51945 |
On Sun, 5 Jun 2022 15:15:59 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/5/2022 3:07 PM, Mike Terry wrote:
> > On 05/06/2022 16:16, Alan Mackenzie wrote:
> >> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> >>> On 05/06/2022 13:14, Alan Mackenzie wrote:
> >>>> olcott <NoOne@nowhere.com> wrote:
> >>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
> >>>>>> olcott <NoOne@nowhere.com> wrote:
> >>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
> >>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
> >>
> >>>>>>>>> A Turing machine is said to halt whenever it reaches a
> >>>>>>>>> configuration for which δ is not defined; this is possible
> >>>>>>>>> because δ is a partial function. In fact, we will assume
> >>>>>>>>> that no transitions are defined for any final state so the
> >>>>>>>>> Turing machine will halt whenever it enters a final state.
> >>>>>>>>> (Linz:1990:234)
> >>
> >>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
> >>>>>>>>> Automata.
> >>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
> >>
> >>>>>>>>> When translated into ordinary software engineering terms
> >>>>>>>>> this means
> >>>>>>>>> terminated normally. In a C function this means reaching
> >>>>>>>>> the "ret" instruction.
> >>
> >>>>>>>> The best equivalent to "not defined" is not "ret". Instead,
> >>>>>>>> "not defined" should include at least:
> >>>>>>>> - HLT or any other instruction that means 'halt'
> >>>>>>>> - any undefined op code
> >>>>>>>> - any return or pop instruction if the stack is empty
> >>>>>>>> - an instruction fetch from a location that is not specifiec
> >>>>>>>> by the program
> >>>>>>>> That way the analogy to Linz' definition is much better.
> >>
> >>>>>>>> Mikko
> >>
> >>>>>>> Reaching a final state is merely the Turing machine way of
> >>>>>>> saying terminated normally. "ret" is the C way of saying the
> >>>>>>> same thing.
> >>
> >>>>>> Sophistry. What would be the turing machine equivalent of an
> >>>>>> "abnormal termination" in C?
> >>
> >>>>> An aborted simulation.
> >>
> >>>> There's no such thing on a turing machine. It either runs and
> >>>> halts, or it runs forever.
> >>
> >>>> Your aborted simulation is just one final state of a turing
> >>>> machine, which has thus halted.
> >>
> >>> A TM "aborting" a simulation is just the TM ceasing to calculate
> >>> computation steps for some computation, and going on to calculate
> >>> something else instead. It does not mean:
> >>> a) that the TM (doing the simulation) has halted
> >>> b) that the simulated computation halts
> >>> c) that the simulated computation never halts
> >>
> >> OK. I've a feeling we're talking more about nice shades of words
> >> than computer science here, but ....
> >>
> >> If the simulation is the entire turing machine, aborting it will
> >> bring the TM to a halt state. If that simulation is merely part
> >> of the TM, then the word "halt" has a different meaning when
> >> applied to that simulation part from when applied to the entire
> >> TM. I'm not even sure what you mean when you say a part of a TM
> >> has halted or not halted.
> >
> > We are clearly talking at cross purposes - I never talked about
> > /part/ of a TM halting, and like you, I can't work out what that
> > would mean! I used "halt" only with respect to a computation,
> > meaning that the computation halts [there is an n such that
> > computation step n is a TM final state].
> >
> > Reading what you say very carefully, I think that by your
> > definition of simulation, the simulating TM must be a "pure"
> > simulator that does nothing but simulate computation steps until
> > the simulation halts, at which point the simulating TM halts (like
> > a UTM). I get that with that interpretation what you said:
> >
> > <copied from above>
> > >>> Your aborted simulation is just one final state of a turing
> > >>> machine, which has thus halted.
> >
> > makes sense and is correct. I'd just say I don't think that
> > usage of "simulation" is very useful, and is DEFINITELY not what PO
> > is talking about (so it would be wrong if applied PO's posts...)
> >
> > My use of "simulation" is broader: it's simply the activity
> > performed by a TM which consists of calculating computation steps
> > of some given computation. As such it's just a part of the TM
> > logic. A TM's typical use of simulation might be something like
> > "..the TM simulates the computation for n steps, and if the
> > simulation halts during those n steps, the TM [blah blah],
> > /otherwise/ the TM [blah blah blah]...". Just about every reference
> > in the literature I can recall is something like that.
> >
> > So... to be 100% clear on what I said:
> >
> > <copied from above>
> > >> A TM "aborting" a simulation is just the TM ceasing to calculate
> > >> computation steps for some computation, and going on to
> > >> calculate something else instead.
> >
> > E.g. in PO's P, after P aborts its simulation of P(P), the TM
> > either halts or enters an infinite loop. (That logic is not part
> > of the simulation, IMO.)
> >
> > >> It does *NOT* mean:
> > >> a) that the TM (doing the simulation) has halted
> >
> > obviously, because now P has gone on to something else...
> >
> > >> b) that the simulated computation halts
> > >> c) that the simulated computation never halts
> >
> > obviously - in general different exacmples of a simulated
> > computation P(I) might halt or never halt, and this is unaffected
> > by a simulator's decision to simulate no further computation steps.
> > [The TM may have spotted some pattern in the simulated computation
> > which implies P(I) never halts - that is a separate matter, but for
> > sure the mere act of "aborting" the simulation doesn't imply P(I)
> > never halts, or imply that it halts...
> >
> > Put yet another way, when a TM stops calculating TM steps (aka
> > aborts its simulation), NOTHING HALTS: not the simulating TM, not
> > the simulated computation, and NOT ANY PART OF EITHER OF THOSE.
> > (Like you say, what would part of a TM halting mean?)
> >
> >
> > Mike.
>
> THIS IS EXACTLY WHAT I MEAN.
> H0(Infinite_Loop) correctly determines that its input never halts.
>
> If we really want to get totally tediously precise (tedium utterly
> freaks me out) we can say that the finite string machine code
> specified as an input parameter to the C function H0 specifies a
> sequence of instructions that would never reach their "ret"
> instruction.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01) 55 push ebp
> [00001343](02) 8bec mov ebp,esp
> [00001345](02) ebfe jmp 00001345
> [00001347](01) 5d pop ebp
> [00001348](01) c3 ret
> Size in bytes:(0007) [00001348]
>
> _main()
> [00001372](01) 55 push ebp
> [00001373](02) 8bec mov ebp,esp
> [00001375](05) 6842130000 push 00001342
> [0000137a](05) e833fdffff call 000010b2
> [0000137f](03) 83c404 add esp,+04
> [00001382](01) 50 push eax
> [00001383](05) 6823040000 push 00000423
> [00001388](05) e8e5f0ffff call 00000472
> [0000138d](03) 83c408 add esp,+08
> [00001390](02) 33c0 xor eax,eax
> [00001392](01) 5d pop ebp
> [00001393](01) c3 ret
> Size in bytes:(0034) [00001393]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001372][0010228f][00000000] 55 push ebp
> [00001373][0010228f][00000000] 8bec mov ebp,esp
> [00001375][0010228b][00001342] 6842130000 push 00001342 // push
> _Infinite_Loop
> [0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
> [00001342][00212333][00212337] 55 push ebp
> [00001343][00212333][00212337] 8bec mov ebp,esp
> [00001345][00212333][00212337] ebfe jmp 00001345
> [00001345][00212333][00212337] ebfe jmp 00001345
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> [0000137f][0010228f][00000000] 83c404 add esp,+04
> [00001382][0010228b][00000000] 50 push eax
> [00001383][00102287][00000423] 6823040000 push 00000423
> [00001388][00102287][00000423] e8e5f0ffff call 00000472
> Input_Halts = 0
> [0000138d][0010228f][00000000] 83c408 add esp,+08
> [00001390][0010228f][00000000] 33c0 xor eax,eax
> [00001392][00102293][00100000] 5d pop ebp
> [00001393][00102297][00000004] c3 ret
> Number of Instructions Executed(680)
Why have you removed/hidden the branching logic upon which the call to
Infinite_Loop() is decided to be made? It is because it reveals that you
are not refuting the HP proofs and that your wrongness is fractal in
nature?
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 15:36 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <WYydnS4g7px1jgD_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #51947 |
On 6/5/2022 3:28 PM, Mr Flibble wrote:
> On Sun, 5 Jun 2022 15:15:59 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/5/2022 3:07 PM, Mike Terry wrote:
>>> On 05/06/2022 16:16, Alan Mackenzie wrote:
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>>> On 05/06/2022 13:14, Alan Mackenzie wrote:
>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>>>
>>>>>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>> configuration for which δ is not defined; this is possible
>>>>>>>>>>> because δ is a partial function. In fact, we will assume
>>>>>>>>>>> that no transitions are defined for any final state so the
>>>>>>>>>>> Turing machine will halt whenever it enters a final state.
>>>>>>>>>>> (Linz:1990:234)
>>>>
>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>> Automata.
>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>
>>>>>>>>>>> When translated into ordinary software engineering terms
>>>>>>>>>>> this means
>>>>>>>>>>> terminated normally. In a C function this means reaching
>>>>>>>>>>> the "ret" instruction.
>>>>
>>>>>>>>>> The best equivalent to "not defined" is not "ret". Instead,
>>>>>>>>>> "not defined" should include at least:
>>>>>>>>>> - HLT or any other instruction that means 'halt'
>>>>>>>>>> - any undefined op code
>>>>>>>>>> - any return or pop instruction if the stack is empty
>>>>>>>>>> - an instruction fetch from a location that is not specifiec
>>>>>>>>>> by the program
>>>>>>>>>> That way the analogy to Linz' definition is much better.
>>>>
>>>>>>>>>> Mikko
>>>>
>>>>>>>>> Reaching a final state is merely the Turing machine way of
>>>>>>>>> saying terminated normally. "ret" is the C way of saying the
>>>>>>>>> same thing.
>>>>
>>>>>>>> Sophistry. What would be the turing machine equivalent of an
>>>>>>>> "abnormal termination" in C?
>>>>
>>>>>>> An aborted simulation.
>>>>
>>>>>> There's no such thing on a turing machine. It either runs and
>>>>>> halts, or it runs forever.
>>>>
>>>>>> Your aborted simulation is just one final state of a turing
>>>>>> machine, which has thus halted.
>>>>
>>>>> A TM "aborting" a simulation is just the TM ceasing to calculate
>>>>> computation steps for some computation, and going on to calculate
>>>>> something else instead. It does not mean:
>>>>> a) that the TM (doing the simulation) has halted
>>>>> b) that the simulated computation halts
>>>>> c) that the simulated computation never halts
>>>>
>>>> OK. I've a feeling we're talking more about nice shades of words
>>>> than computer science here, but ....
>>>>
>>>> If the simulation is the entire turing machine, aborting it will
>>>> bring the TM to a halt state. If that simulation is merely part
>>>> of the TM, then the word "halt" has a different meaning when
>>>> applied to that simulation part from when applied to the entire
>>>> TM. I'm not even sure what you mean when you say a part of a TM
>>>> has halted or not halted.
>>>
>>> We are clearly talking at cross purposes - I never talked about
>>> /part/ of a TM halting, and like you, I can't work out what that
>>> would mean! I used "halt" only with respect to a computation,
>>> meaning that the computation halts [there is an n such that
>>> computation step n is a TM final state].
>>>
>>> Reading what you say very carefully, I think that by your
>>> definition of simulation, the simulating TM must be a "pure"
>>> simulator that does nothing but simulate computation steps until
>>> the simulation halts, at which point the simulating TM halts (like
>>> a UTM). I get that with that interpretation what you said:
>>>
>>> <copied from above>
>>> >>> Your aborted simulation is just one final state of a turing
>>> >>> machine, which has thus halted.
>>>
>>> makes sense and is correct. I'd just say I don't think that
>>> usage of "simulation" is very useful, and is DEFINITELY not what PO
>>> is talking about (so it would be wrong if applied PO's posts...)
>>>
>>> My use of "simulation" is broader: it's simply the activity
>>> performed by a TM which consists of calculating computation steps
>>> of some given computation. As such it's just a part of the TM
>>> logic. A TM's typical use of simulation might be something like
>>> "..the TM simulates the computation for n steps, and if the
>>> simulation halts during those n steps, the TM [blah blah],
>>> /otherwise/ the TM [blah blah blah]...". Just about every reference
>>> in the literature I can recall is something like that.
>>>
>>> So... to be 100% clear on what I said:
>>>
>>> <copied from above>
>>> >> A TM "aborting" a simulation is just the TM ceasing to calculate
>>> >> computation steps for some computation, and going on to
>>> >> calculate something else instead.
>>>
>>> E.g. in PO's P, after P aborts its simulation of P(P), the TM
>>> either halts or enters an infinite loop. (That logic is not part
>>> of the simulation, IMO.)
>>>
>>> >> It does *NOT* mean:
>>> >> a) that the TM (doing the simulation) has halted
>>>
>>> obviously, because now P has gone on to something else...
>>>
>>> >> b) that the simulated computation halts
>>> >> c) that the simulated computation never halts
>>>
>>> obviously - in general different exacmples of a simulated
>>> computation P(I) might halt or never halt, and this is unaffected
>>> by a simulator's decision to simulate no further computation steps.
>>> [The TM may have spotted some pattern in the simulated computation
>>> which implies P(I) never halts - that is a separate matter, but for
>>> sure the mere act of "aborting" the simulation doesn't imply P(I)
>>> never halts, or imply that it halts...
>>>
>>> Put yet another way, when a TM stops calculating TM steps (aka
>>> aborts its simulation), NOTHING HALTS: not the simulating TM, not
>>> the simulated computation, and NOT ANY PART OF EITHER OF THOSE.
>>> (Like you say, what would part of a TM halting mean?)
>>>
>>>
>>> Mike.
>>
>> THIS IS EXACTLY WHAT I MEAN.
>> H0(Infinite_Loop) correctly determines that its input never halts.
>>
>> If we really want to get totally tediously precise (tedium utterly
>> freaks me out) we can say that the finite string machine code
>> specified as an input parameter to the C function H0 specifies a
>> sequence of instructions that would never reach their "ret"
>> instruction.
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H0(Infinite_Loop));
>> }
>>
>> _Infinite_Loop()
>> [00001342](01) 55 push ebp
>> [00001343](02) 8bec mov ebp,esp
>> [00001345](02) ebfe jmp 00001345
>> [00001347](01) 5d pop ebp
>> [00001348](01) c3 ret
>> Size in bytes:(0007) [00001348]
>>
>> _main()
>> [00001372](01) 55 push ebp
>> [00001373](02) 8bec mov ebp,esp
>> [00001375](05) 6842130000 push 00001342
>> [0000137a](05) e833fdffff call 000010b2
>> [0000137f](03) 83c404 add esp,+04
>> [00001382](01) 50 push eax
>> [00001383](05) 6823040000 push 00000423
>> [00001388](05) e8e5f0ffff call 00000472
>> [0000138d](03) 83c408 add esp,+08
>> [00001390](02) 33c0 xor eax,eax
>> [00001392](01) 5d pop ebp
>> [00001393](01) c3 ret
>> Size in bytes:(0034) [00001393]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [00001372][0010228f][00000000] 55 push ebp
>> [00001373][0010228f][00000000] 8bec mov ebp,esp
>> [00001375][0010228b][00001342] 6842130000 push 00001342 // push
>> _Infinite_Loop
>> [0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
>> [00001342][00212333][00212337] 55 push ebp
>> [00001343][00212333][00212337] 8bec mov ebp,esp
>> [00001345][00212333][00212337] ebfe jmp 00001345
>> [00001345][00212333][00212337] ebfe jmp 00001345
>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>
>> [0000137f][0010228f][00000000] 83c404 add esp,+04
>> [00001382][0010228b][00000000] 50 push eax
>> [00001383][00102287][00000423] 6823040000 push 00000423
>> [00001388][00102287][00000423] e8e5f0ffff call 00000472
>> Input_Halts = 0
>> [0000138d][0010228f][00000000] 83c408 add esp,+08
>> [00001390][0010228f][00000000] 33c0 xor eax,eax
>> [00001392][00102293][00100000] 5d pop ebp
>> [00001393][00102297][00000004] c3 ret
>> Number of Instructions Executed(680)
>
> Why have you removed/hidden the branching logic upon which the call to
> Infinite_Loop() is decided to be made? It is because it reveals that you
> are not refuting the HP proofs and that your wrongness is fractal in
> nature?
>
> /Flibble
>
You can't understand that an infinite loop never halts?
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 16:44 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <XA8nK.36832$tLd9.15347@fx98.iad> |
| In reply to | #51949 |
On 6/5/22 4:36 PM, olcott wrote:
> On 6/5/2022 3:28 PM, Mr Flibble wrote:
>> On Sun, 5 Jun 2022 15:15:59 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/5/2022 3:07 PM, Mike Terry wrote:
>>>> On 05/06/2022 16:16, Alan Mackenzie wrote:
>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>>>> On 05/06/2022 13:14, Alan Mackenzie wrote:
>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>>>>>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>>>>>>> configuration for which δ is not defined; this is possible
>>>>>>>>>>>> because δ is a partial function. In fact, we will assume
>>>>>>>>>>>> that no transitions are defined for any final state so the
>>>>>>>>>>>> Turing machine will halt whenever it enters a final state.
>>>>>>>>>>>> (Linz:1990:234)
>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>> Automata.
>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>>>>>>>>>> When translated into ordinary software engineering terms
>>>>>>>>>>>> this means
>>>>>>>>>>>> terminated normally. In a C function this means reaching
>>>>>>>>>>>> the "ret" instruction.
>>>>>>>>>>> The best equivalent to "not defined" is not "ret". Instead,
>>>>>>>>>>> "not defined" should include at least:
>>>>>>>>>>> - HLT or any other instruction that means 'halt'
>>>>>>>>>>> - any undefined op code
>>>>>>>>>>> - any return or pop instruction if the stack is empty
>>>>>>>>>>> - an instruction fetch from a location that is not specifiec
>>>>>>>>>>> by the program
>>>>>>>>>>> That way the analogy to Linz' definition is much better.
>>>>>>>>>>> Mikko
>>>>>>>>>> Reaching a final state is merely the Turing machine way of
>>>>>>>>>> saying terminated normally. "ret" is the C way of saying the
>>>>>>>>>> same thing.
>>>>>>>>> Sophistry. What would be the turing machine equivalent of an
>>>>>>>>> "abnormal termination" in C?
>>>>>>>> An aborted simulation.
>>>>>>> There's no such thing on a turing machine. It either runs and
>>>>>>> halts, or it runs forever.
>>>>>>> Your aborted simulation is just one final state of a turing
>>>>>>> machine, which has thus halted.
>>>>>> A TM "aborting" a simulation is just the TM ceasing to calculate
>>>>>> computation steps for some computation, and going on to calculate
>>>>>> something else instead. It does not mean:
>>>>>> a) that the TM (doing the simulation) has halted
>>>>>> b) that the simulated computation halts
>>>>>> c) that the simulated computation never halts
>>>>>
>>>>> OK. I've a feeling we're talking more about nice shades of words
>>>>> than computer science here, but ....
>>>>>
>>>>> If the simulation is the entire turing machine, aborting it will
>>>>> bring the TM to a halt state. If that simulation is merely part
>>>>> of the TM, then the word "halt" has a different meaning when
>>>>> applied to that simulation part from when applied to the entire
>>>>> TM. I'm not even sure what you mean when you say a part of a TM
>>>>> has halted or not halted.
>>>>
>>>> We are clearly talking at cross purposes - I never talked about
>>>> /part/ of a TM halting, and like you, I can't work out what that
>>>> would mean! I used "halt" only with respect to a computation,
>>>> meaning that the computation halts [there is an n such that
>>>> computation step n is a TM final state].
>>>>
>>>> Reading what you say very carefully, I think that by your
>>>> definition of simulation, the simulating TM must be a "pure"
>>>> simulator that does nothing but simulate computation steps until
>>>> the simulation halts, at which point the simulating TM halts (like
>>>> a UTM). I get that with that interpretation what you said:
>>>>
>>>> <copied from above>
>>>> >>> Your aborted simulation is just one final state of a turing
>>>> >>> machine, which has thus halted.
>>>>
>>>> makes sense and is correct. I'd just say I don't think that
>>>> usage of "simulation" is very useful, and is DEFINITELY not what PO
>>>> is talking about (so it would be wrong if applied PO's posts...)
>>>>
>>>> My use of "simulation" is broader: it's simply the activity
>>>> performed by a TM which consists of calculating computation steps
>>>> of some given computation. As such it's just a part of the TM
>>>> logic. A TM's typical use of simulation might be something like
>>>> "..the TM simulates the computation for n steps, and if the
>>>> simulation halts during those n steps, the TM [blah blah],
>>>> /otherwise/ the TM [blah blah blah]...". Just about every reference
>>>> in the literature I can recall is something like that.
>>>>
>>>> So... to be 100% clear on what I said:
>>>>
>>>> <copied from above>
>>>> >> A TM "aborting" a simulation is just the TM ceasing to calculate
>>>> >> computation steps for some computation, and going on to
>>>> >> calculate something else instead.
>>>>
>>>> E.g. in PO's P, after P aborts its simulation of P(P), the TM
>>>> either halts or enters an infinite loop. (That logic is not part
>>>> of the simulation, IMO.)
>>>> >> It does *NOT* mean:
>>>> >> a) that the TM (doing the simulation) has halted
>>>>
>>>> obviously, because now P has gone on to something else...
>>>> >> b) that the simulated computation halts
>>>> >> c) that the simulated computation never halts
>>>>
>>>> obviously - in general different exacmples of a simulated
>>>> computation P(I) might halt or never halt, and this is unaffected
>>>> by a simulator's decision to simulate no further computation steps.
>>>> [The TM may have spotted some pattern in the simulated computation
>>>> which implies P(I) never halts - that is a separate matter, but for
>>>> sure the mere act of "aborting" the simulation doesn't imply P(I)
>>>> never halts, or imply that it halts...
>>>>
>>>> Put yet another way, when a TM stops calculating TM steps (aka
>>>> aborts its simulation), NOTHING HALTS: not the simulating TM, not
>>>> the simulated computation, and NOT ANY PART OF EITHER OF THOSE.
>>>> (Like you say, what would part of a TM halting mean?)
>>>>
>>>>
>>>> Mike.
>>>
>>> THIS IS EXACTLY WHAT I MEAN.
>>> H0(Infinite_Loop) correctly determines that its input never halts.
>>>
>>> If we really want to get totally tediously precise (tedium utterly
>>> freaks me out) we can say that the finite string machine code
>>> specified as an input parameter to the C function H0 specifies a
>>> sequence of instructions that would never reach their "ret"
>>> instruction.
>>>
>>> void Infinite_Loop()
>>> {
>>> HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H0(Infinite_Loop));
>>> }
>>>
>>> _Infinite_Loop()
>>> [00001342](01) 55 push ebp
>>> [00001343](02) 8bec mov ebp,esp
>>> [00001345](02) ebfe jmp 00001345
>>> [00001347](01) 5d pop ebp
>>> [00001348](01) c3 ret
>>> Size in bytes:(0007) [00001348]
>>>
>>> _main()
>>> [00001372](01) 55 push ebp
>>> [00001373](02) 8bec mov ebp,esp
>>> [00001375](05) 6842130000 push 00001342
>>> [0000137a](05) e833fdffff call 000010b2
>>> [0000137f](03) 83c404 add esp,+04
>>> [00001382](01) 50 push eax
>>> [00001383](05) 6823040000 push 00000423
>>> [00001388](05) e8e5f0ffff call 00000472
>>> [0000138d](03) 83c408 add esp,+08
>>> [00001390](02) 33c0 xor eax,eax
>>> [00001392](01) 5d pop ebp
>>> [00001393](01) c3 ret
>>> Size in bytes:(0034) [00001393]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [00001372][0010228f][00000000] 55 push ebp
>>> [00001373][0010228f][00000000] 8bec mov ebp,esp
>>> [00001375][0010228b][00001342] 6842130000 push 00001342 // push
>>> _Infinite_Loop
>>> [0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
>>>
>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
>>> [00001342][00212333][00212337] 55 push ebp
>>> [00001343][00212333][00212337] 8bec mov ebp,esp
>>> [00001345][00212333][00212337] ebfe jmp 00001345
>>> [00001345][00212333][00212337] ebfe jmp 00001345
>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>
>>> [0000137f][0010228f][00000000] 83c404 add esp,+04
>>> [00001382][0010228b][00000000] 50 push eax
>>> [00001383][00102287][00000423] 6823040000 push 00000423
>>> [00001388][00102287][00000423] e8e5f0ffff call 00000472
>>> Input_Halts = 0
>>> [0000138d][0010228f][00000000] 83c408 add esp,+08
>>> [00001390][0010228f][00000000] 33c0 xor eax,eax
>>> [00001392][00102293][00100000] 5d pop ebp
>>> [00001393][00102297][00000004] c3 ret
>>> Number of Instructions Executed(680)
>>
>> Why have you removed/hidden the branching logic upon which the call to
>> Infinite_Loop() is decided to be made? It is because it reveals that you
>> are not refuting the HP proofs and that your wrongness is fractal in
>> nature?
>>
>> /Flibble
>>
>
> You can't understand that an infinite loop never halts?
>
Bad logic will sometimes get the right answer by accident.
The logic is still unsound/invalid.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 16:38 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <Yu8nK.39543$Fikb.17277@fx33.iad> |
| In reply to | #51945 |
On 6/5/22 4:15 PM, olcott wrote:
> On 6/5/2022 3:07 PM, Mike Terry wrote:
>> On 05/06/2022 16:16, Alan Mackenzie wrote:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>> On 05/06/2022 13:14, Alan Mackenzie wrote:
>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote:
>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote:
>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said:
>>>
>>>>>>>>>> A Turing machine is said to halt whenever it reaches a
>>>>>>>>>> configuration for which δ is not defined; this is possible
>>>>>>>>>> because
>>>>>>>>>> δ is a partial function. In fact, we will assume that no
>>>>>>>>>> transitions are defined for any final state so the Turing machine
>>>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234)
>>>
>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>> Automata.
>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company.
>>>
>>>>>>>>>> When translated into ordinary software engineering terms this
>>>>>>>>>> means
>>>>>>>>>> terminated normally. In a C function this means reaching the
>>>>>>>>>> "ret"
>>>>>>>>>> instruction.
>>>
>>>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not
>>>>>>>>> defined" should include at least:
>>>>>>>>> - HLT or any other instruction that means 'halt'
>>>>>>>>> - any undefined op code
>>>>>>>>> - any return or pop instruction if the stack is empty
>>>>>>>>> - an instruction fetch from a location that is not specifiec by
>>>>>>>>> the
>>>>>>>>> program
>>>>>>>>> That way the analogy to Linz' definition is much better.
>>>
>>>>>>>>> Mikko
>>>
>>>>>>>> Reaching a final state is merely the Turing machine way of saying
>>>>>>>> terminated normally. "ret" is the C way of saying the same thing.
>>>
>>>>>>> Sophistry. What would be the turing machine equivalent of an
>>>>>>> "abnormal termination" in C?
>>>
>>>>>> An aborted simulation.
>>>
>>>>> There's no such thing on a turing machine. It either runs and halts,
>>>>> or it runs forever.
>>>
>>>>> Your aborted simulation is just one final state of a turing machine,
>>>>> which has thus halted.
>>>
>>>> A TM "aborting" a simulation is just the TM ceasing to calculate
>>>> computation steps for some computation, and going on to calculate
>>>> something else instead. It does not mean:
>>>> a) that the TM (doing the simulation) has halted
>>>> b) that the simulated computation halts
>>>> c) that the simulated computation never halts
>>>
>>> OK. I've a feeling we're talking more about nice shades of words than
>>> computer science here, but ....
>>>
>>> If the simulation is the entire turing machine, aborting it will bring
>>> the TM to a halt state. If that simulation is merely part of the TM,
>>> then the word "halt" has a different meaning when applied to that
>>> simulation part from when applied to the entire TM. I'm not even sure
>>> what you mean when you say a part of a TM has halted or not halted.
>>
>> We are clearly talking at cross purposes - I never talked about /part/
>> of a TM halting, and like you, I can't work out what that would mean!
>> I used "halt" only with respect to a computation, meaning that the
>> computation halts [there is an n such that computation step n is a TM
>> final state].
>>
>> Reading what you say very carefully, I think that by your definition
>> of simulation, the simulating TM must be a "pure" simulator that does
>> nothing but simulate computation steps until the simulation halts, at
>> which point the simulating TM halts (like a UTM). I get that with
>> that interpretation what you said:
>>
>> <copied from above>
>> >>> Your aborted simulation is just one final state of a turing machine,
>> >>> which has thus halted.
>>
>> makes sense and is correct. I'd just say I don't think that usage
>> of "simulation" is very useful, and is DEFINITELY not what PO is
>> talking about (so it would be wrong if applied PO's posts...)
>>
>> My use of "simulation" is broader: it's simply the activity performed
>> by a TM which consists of calculating computation steps of some given
>> computation. As such it's just a part of the TM logic. A TM's typical
>> use of simulation might be something like "..the TM simulates the
>> computation for n steps, and if the simulation halts during those n
>> steps, the TM [blah blah], /otherwise/ the TM [blah blah blah]...".
>> Just about every reference in the literature I can recall is something
>> like that.
>>
>> So... to be 100% clear on what I said:
>>
>> <copied from above>
>> >> A TM "aborting" a simulation is just the TM ceasing to calculate
>> >> computation steps for some computation, and going on to calculate
>> >> something else instead.
>>
>> E.g. in PO's P, after P aborts its simulation of P(P), the TM either
>> halts or enters an infinite loop. (That logic is not part of the
>> simulation, IMO.)
>>
>> >> It does *NOT* mean:
>> >> a) that the TM (doing the simulation) has halted
>>
>> obviously, because now P has gone on to something else...
>>
>> >> b) that the simulated computation halts
>> >> c) that the simulated computation never halts
>>
>> obviously - in general different exacmples of a simulated computation
>> P(I) might halt or never halt, and this is unaffected by a simulator's
>> decision to simulate no further computation steps. [The TM may have
>> spotted some pattern in the simulated computation which implies P(I)
>> never halts - that is a separate matter, but for sure the mere act of
>> "aborting" the simulation doesn't imply P(I) never halts, or imply
>> that it halts...
>>
>> Put yet another way, when a TM stops calculating TM steps (aka aborts
>> its simulation), NOTHING HALTS: not the simulating TM, not the
>> simulated computation, and NOT ANY PART OF EITHER OF THOSE. (Like you
>> say, what would part of a TM halting mean?)
>>
>>
>> Mike.
>
> THIS IS EXACTLY WHAT I MEAN.
> H0(Infinite_Loop) correctly determines that its input never halts.
>
> If we really want to get totally tediously precise (tedium utterly
> freaks me out) we can say that the finite string machine code specified
> as an input parameter to the C function H0 specifies a sequence of
> instructions that would never reach their "ret" instruction.
Right, so H can decide on Infinite_Loop being non-halting even if it
doesn't actually create a correct simulation of the input.
But, change Infinite_Loop to P, then we can show that the C funciton P
called with the parameter P WILL reach its return instruction if H(P,P)
returns 0, so that CAN'T be the correct answer.
Halting naturally refers to the ACTUAL PROGRAM, so H needs to try to
figure out what THAT will do, but fails.
It doesn't matter that no H can be created that can simulate the input
of an H that refers to it to the return instruction. What matters is
that for THIS H, the P built from it will halt if it returns 0, and in
fact, alternate deciders that run longer, when given this P refering to
the original H, can simulate to this point to.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01) 55 push ebp
> [00001343](02) 8bec mov ebp,esp
> [00001345](02) ebfe jmp 00001345
> [00001347](01) 5d pop ebp
> [00001348](01) c3 ret
> Size in bytes:(0007) [00001348]
>
> _main()
> [00001372](01) 55 push ebp
> [00001373](02) 8bec mov ebp,esp
> [00001375](05) 6842130000 push 00001342
> [0000137a](05) e833fdffff call 000010b2
> [0000137f](03) 83c404 add esp,+04
> [00001382](01) 50 push eax
> [00001383](05) 6823040000 push 00000423
> [00001388](05) e8e5f0ffff call 00000472
> [0000138d](03) 83c408 add esp,+08
> [00001390](02) 33c0 xor eax,eax
> [00001392](01) 5d pop ebp
> [00001393](01) c3 ret
> Size in bytes:(0034) [00001393]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [00001372][0010228f][00000000] 55 push ebp
> [00001373][0010228f][00000000] 8bec mov ebp,esp
> [00001375][0010228b][00001342] 6842130000 push 00001342 // push
> _Infinite_Loop
> [0000137a][00102287][0000137f] e833fdffff call 000010b2 // call H0
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
> [00001342][00212333][00212337] 55 push ebp
> [00001343][00212333][00212337] 8bec mov ebp,esp
> [00001345][00212333][00212337] ebfe jmp 00001345
> [00001345][00212333][00212337] ebfe jmp 00001345
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> [0000137f][0010228f][00000000] 83c404 add esp,+04
> [00001382][0010228b][00000000] 50 push eax
> [00001383][00102287][00000423] 6823040000 push 00000423
> [00001388][00102287][00000423] e8e5f0ffff call 00000472
> Input_Halts = 0
> [0000138d][0010228f][00000000] 83c408 add esp,+08
> [00001390][0010228f][00000000] 33c0 xor eax,eax
> [00001392][00102293][00100000] 5d pop ebp
> [00001393][00102297][00000004] c3 ret
> Number of Instructions Executed(680)
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 15:41 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <WYydnSkg7pxhiQD_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #51950 |
On 6/5/2022 3:38 PM, Richard Damon wrote: > On 6/5/22 4:15 PM, olcott wrote: >> On 6/5/2022 3:07 PM, Mike Terry wrote: >>> On 05/06/2022 16:16, Alan Mackenzie wrote: >>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>>> On 05/06/2022 13:14, Alan Mackenzie wrote: >>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote: >>>>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote: >>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said: >>>> >>>>>>>>>>> A Turing machine is said to halt whenever it reaches a >>>>>>>>>>> configuration for which δ is not defined; this is possible >>>>>>>>>>> because >>>>>>>>>>> δ is a partial function. In fact, we will assume that no >>>>>>>>>>> transitions are defined for any final state so the Turing >>>>>>>>>>> machine >>>>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234) >>>> >>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and >>>>>>>>>>> Automata. >>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. >>>> >>>>>>>>>>> When translated into ordinary software engineering terms this >>>>>>>>>>> means >>>>>>>>>>> terminated normally. In a C function this means reaching the >>>>>>>>>>> "ret" >>>>>>>>>>> instruction. >>>> >>>>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not >>>>>>>>>> defined" should include at least: >>>>>>>>>> - HLT or any other instruction that means 'halt' >>>>>>>>>> - any undefined op code >>>>>>>>>> - any return or pop instruction if the stack is empty >>>>>>>>>> - an instruction fetch from a location that is not specifiec >>>>>>>>>> by the >>>>>>>>>> program >>>>>>>>>> That way the analogy to Linz' definition is much better. >>>> >>>>>>>>>> Mikko >>>> >>>>>>>>> Reaching a final state is merely the Turing machine way of saying >>>>>>>>> terminated normally. "ret" is the C way of saying the same thing. >>>> >>>>>>>> Sophistry. What would be the turing machine equivalent of an >>>>>>>> "abnormal termination" in C? >>>> >>>>>>> An aborted simulation. >>>> >>>>>> There's no such thing on a turing machine. It either runs and halts, >>>>>> or it runs forever. >>>> >>>>>> Your aborted simulation is just one final state of a turing machine, >>>>>> which has thus halted. >>>> >>>>> A TM "aborting" a simulation is just the TM ceasing to calculate >>>>> computation steps for some computation, and going on to calculate >>>>> something else instead. It does not mean: >>>>> a) that the TM (doing the simulation) has halted >>>>> b) that the simulated computation halts >>>>> c) that the simulated computation never halts >>>> >>>> OK. I've a feeling we're talking more about nice shades of words than >>>> computer science here, but .... >>>> >>>> If the simulation is the entire turing machine, aborting it will bring >>>> the TM to a halt state. If that simulation is merely part of the TM, >>>> then the word "halt" has a different meaning when applied to that >>>> simulation part from when applied to the entire TM. I'm not even sure >>>> what you mean when you say a part of a TM has halted or not halted. >>> >>> We are clearly talking at cross purposes - I never talked about >>> /part/ of a TM halting, and like you, I can't work out what that >>> would mean! I used "halt" only with respect to a computation, meaning >>> that the computation halts [there is an n such that computation step >>> n is a TM final state]. >>> >>> Reading what you say very carefully, I think that by your definition >>> of simulation, the simulating TM must be a "pure" simulator that does >>> nothing but simulate computation steps until the simulation halts, at >>> which point the simulating TM halts (like a UTM). I get that with >>> that interpretation what you said: >>> >>> <copied from above> >>> >>> Your aborted simulation is just one final state of a turing >>> machine, >>> >>> which has thus halted. >>> >>> makes sense and is correct. I'd just say I don't think that usage >>> of "simulation" is very useful, and is DEFINITELY not what PO is >>> talking about (so it would be wrong if applied PO's posts...) >>> >>> My use of "simulation" is broader: it's simply the activity performed >>> by a TM which consists of calculating computation steps of some given >>> computation. As such it's just a part of the TM logic. A TM's >>> typical use of simulation might be something like "..the TM simulates >>> the computation for n steps, and if the simulation halts during those >>> n steps, the TM [blah blah], /otherwise/ the TM [blah blah blah]...". >>> Just about every reference in the literature I can recall is >>> something like that. >>> >>> So... to be 100% clear on what I said: >>> >>> <copied from above> >>> >> A TM "aborting" a simulation is just the TM ceasing to calculate >>> >> computation steps for some computation, and going on to calculate >>> >> something else instead. >>> >>> E.g. in PO's P, after P aborts its simulation of P(P), the TM either >>> halts or enters an infinite loop. (That logic is not part of the >>> simulation, IMO.) >>> >>> >> It does *NOT* mean: >>> >> a) that the TM (doing the simulation) has halted >>> >>> obviously, because now P has gone on to something else... >>> >>> >> b) that the simulated computation halts >>> >> c) that the simulated computation never halts >>> >>> obviously - in general different exacmples of a simulated computation >>> P(I) might halt or never halt, and this is unaffected by a >>> simulator's decision to simulate no further computation steps. [The >>> TM may have spotted some pattern in the simulated computation which >>> implies P(I) never halts - that is a separate matter, but for sure >>> the mere act of "aborting" the simulation doesn't imply P(I) never >>> halts, or imply that it halts... >>> >>> Put yet another way, when a TM stops calculating TM steps (aka aborts >>> its simulation), NOTHING HALTS: not the simulating TM, not the >>> simulated computation, and NOT ANY PART OF EITHER OF THOSE. (Like you >>> say, what would part of a TM halting mean?) >>> >>> >>> Mike. >> >> THIS IS EXACTLY WHAT I MEAN. >> H0(Infinite_Loop) correctly determines that its input never halts. >> >> If we really want to get totally tediously precise (tedium utterly >> freaks me out) we can say that the finite string machine code >> specified as an input parameter to the C function H0 specifies a >> sequence of instructions that would never reach their "ret" instruction. > > Right, so H can decide on Infinite_Loop being non-halting even if it > doesn't actually create a correct simulation of the input. You are quite the total jackass. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 16:57 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <EM8nK.43256$lut9.24595@fx99.iad> |
| In reply to | #51951 |
On 6/5/22 4:41 PM, olcott wrote: > On 6/5/2022 3:38 PM, Richard Damon wrote: >> On 6/5/22 4:15 PM, olcott wrote: >>> On 6/5/2022 3:07 PM, Mike Terry wrote: >>>> On 05/06/2022 16:16, Alan Mackenzie wrote: >>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>>>> On 05/06/2022 13:14, Alan Mackenzie wrote: >>>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote: >>>>>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote: >>>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said: >>>>> >>>>>>>>>>>> A Turing machine is said to halt whenever it reaches a >>>>>>>>>>>> configuration for which δ is not defined; this is possible >>>>>>>>>>>> because >>>>>>>>>>>> δ is a partial function. In fact, we will assume that no >>>>>>>>>>>> transitions are defined for any final state so the Turing >>>>>>>>>>>> machine >>>>>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234) >>>>> >>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and >>>>>>>>>>>> Automata. >>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. >>>>> >>>>>>>>>>>> When translated into ordinary software engineering terms >>>>>>>>>>>> this means >>>>>>>>>>>> terminated normally. In a C function this means reaching the >>>>>>>>>>>> "ret" >>>>>>>>>>>> instruction. >>>>> >>>>>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not >>>>>>>>>>> defined" should include at least: >>>>>>>>>>> - HLT or any other instruction that means 'halt' >>>>>>>>>>> - any undefined op code >>>>>>>>>>> - any return or pop instruction if the stack is empty >>>>>>>>>>> - an instruction fetch from a location that is not specifiec >>>>>>>>>>> by the >>>>>>>>>>> program >>>>>>>>>>> That way the analogy to Linz' definition is much better. >>>>> >>>>>>>>>>> Mikko >>>>> >>>>>>>>>> Reaching a final state is merely the Turing machine way of saying >>>>>>>>>> terminated normally. "ret" is the C way of saying the same thing. >>>>> >>>>>>>>> Sophistry. What would be the turing machine equivalent of an >>>>>>>>> "abnormal termination" in C? >>>>> >>>>>>>> An aborted simulation. >>>>> >>>>>>> There's no such thing on a turing machine. It either runs and >>>>>>> halts, >>>>>>> or it runs forever. >>>>> >>>>>>> Your aborted simulation is just one final state of a turing machine, >>>>>>> which has thus halted. >>>>> >>>>>> A TM "aborting" a simulation is just the TM ceasing to calculate >>>>>> computation steps for some computation, and going on to calculate >>>>>> something else instead. It does not mean: >>>>>> a) that the TM (doing the simulation) has halted >>>>>> b) that the simulated computation halts >>>>>> c) that the simulated computation never halts >>>>> >>>>> OK. I've a feeling we're talking more about nice shades of words than >>>>> computer science here, but .... >>>>> >>>>> If the simulation is the entire turing machine, aborting it will bring >>>>> the TM to a halt state. If that simulation is merely part of the TM, >>>>> then the word "halt" has a different meaning when applied to that >>>>> simulation part from when applied to the entire TM. I'm not even sure >>>>> what you mean when you say a part of a TM has halted or not halted. >>>> >>>> We are clearly talking at cross purposes - I never talked about >>>> /part/ of a TM halting, and like you, I can't work out what that >>>> would mean! I used "halt" only with respect to a computation, >>>> meaning that the computation halts [there is an n such that >>>> computation step n is a TM final state]. >>>> >>>> Reading what you say very carefully, I think that by your definition >>>> of simulation, the simulating TM must be a "pure" simulator that >>>> does nothing but simulate computation steps until the simulation >>>> halts, at which point the simulating TM halts (like a UTM). I get >>>> that with that interpretation what you said: >>>> >>>> <copied from above> >>>> >>> Your aborted simulation is just one final state of a turing >>>> machine, >>>> >>> which has thus halted. >>>> >>>> makes sense and is correct. I'd just say I don't think that usage >>>> of "simulation" is very useful, and is DEFINITELY not what PO is >>>> talking about (so it would be wrong if applied PO's posts...) >>>> >>>> My use of "simulation" is broader: it's simply the activity >>>> performed by a TM which consists of calculating computation steps of >>>> some given computation. As such it's just a part of the TM logic. A >>>> TM's typical use of simulation might be something like "..the TM >>>> simulates the computation for n steps, and if the simulation halts >>>> during those n steps, the TM [blah blah], /otherwise/ the TM [blah >>>> blah blah]...". Just about every reference in the literature I can >>>> recall is something like that. >>>> >>>> So... to be 100% clear on what I said: >>>> >>>> <copied from above> >>>> >> A TM "aborting" a simulation is just the TM ceasing to calculate >>>> >> computation steps for some computation, and going on to calculate >>>> >> something else instead. >>>> >>>> E.g. in PO's P, after P aborts its simulation of P(P), the TM either >>>> halts or enters an infinite loop. (That logic is not part of the >>>> simulation, IMO.) >>>> >>>> >> It does *NOT* mean: >>>> >> a) that the TM (doing the simulation) has halted >>>> >>>> obviously, because now P has gone on to something else... >>>> >>>> >> b) that the simulated computation halts >>>> >> c) that the simulated computation never halts >>>> >>>> obviously - in general different exacmples of a simulated >>>> computation P(I) might halt or never halt, and this is unaffected by >>>> a simulator's decision to simulate no further computation steps. >>>> [The TM may have spotted some pattern in the simulated computation >>>> which implies P(I) never halts - that is a separate matter, but for >>>> sure the mere act of "aborting" the simulation doesn't imply P(I) >>>> never halts, or imply that it halts... >>>> >>>> Put yet another way, when a TM stops calculating TM steps (aka >>>> aborts its simulation), NOTHING HALTS: not the simulating TM, not >>>> the simulated computation, and NOT ANY PART OF EITHER OF THOSE. >>>> (Like you say, what would part of a TM halting mean?) >>>> >>>> >>>> Mike. >>> >>> THIS IS EXACTLY WHAT I MEAN. >>> H0(Infinite_Loop) correctly determines that its input never halts. >>> >>> If we really want to get totally tediously precise (tedium utterly >>> freaks me out) we can say that the finite string machine code >>> specified as an input parameter to the C function H0 specifies a >>> sequence of instructions that would never reach their "ret" instruction. >> >> Right, so H can decide on Infinite_Loop being non-halting even if it >> doesn't actually create a correct simulation of the input. > > You are quite the total jackass. > Your the one doing fault logic. What have I said that is actually incorrect?
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2022-06-05 15:59 -0600 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7j8vh$2i1$1@dont-email.me> |
| In reply to | #51943 |
On 6/5/2022 2:07 PM, Mike Terry wrote: > On 05/06/2022 16:16, Alan Mackenzie wrote: >> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>> On 05/06/2022 13:14, Alan Mackenzie wrote: >>>> olcott <NoOne@nowhere.com> wrote: >>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote: >>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>> On 6/5/2022 5:14 AM, Mikko wrote: >>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said: >> >>>>>>>>> A Turing machine is said to halt whenever it reaches a >>>>>>>>> configuration for which δ is not defined; this is possible because >>>>>>>>> δ is a partial function. In fact, we will assume that no >>>>>>>>> transitions are defined for any final state so the Turing machine >>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234) >> >>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and >>>>>>>>> Automata. >>>>>>>>> Lexington/Toronto: D. C. Heath and Company. >> >>>>>>>>> When translated into ordinary software engineering terms this >>>>>>>>> means >>>>>>>>> terminated normally. In a C function this means reaching the "ret" >>>>>>>>> instruction. >> >>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not >>>>>>>> defined" should include at least: >>>>>>>> - HLT or any other instruction that means 'halt' >>>>>>>> - any undefined op code >>>>>>>> - any return or pop instruction if the stack is empty >>>>>>>> - an instruction fetch from a location that is not specifiec by the >>>>>>>> program >>>>>>>> That way the analogy to Linz' definition is much better. >> >>>>>>>> Mikko >> >>>>>>> Reaching a final state is merely the Turing machine way of saying >>>>>>> terminated normally. "ret" is the C way of saying the same thing. >> >>>>>> Sophistry. What would be the turing machine equivalent of an >>>>>> "abnormal termination" in C? >> >>>>> An aborted simulation. >> >>>> There's no such thing on a turing machine. It either runs and halts, >>>> or it runs forever. >> >>>> Your aborted simulation is just one final state of a turing machine, >>>> which has thus halted. >> >>> A TM "aborting" a simulation is just the TM ceasing to calculate >>> computation steps for some computation, and going on to calculate >>> something else instead. It does not mean: >>> a) that the TM (doing the simulation) has halted >>> b) that the simulated computation halts >>> c) that the simulated computation never halts >> >> OK. I've a feeling we're talking more about nice shades of words than >> computer science here, but .... >> >> If the simulation is the entire turing machine, aborting it will bring >> the TM to a halt state. If that simulation is merely part of the TM, >> then the word "halt" has a different meaning when applied to that >> simulation part from when applied to the entire TM. I'm not even sure >> what you mean when you say a part of a TM has halted or not halted. > > We are clearly talking at cross purposes - I never talked about /part/ > of a TM halting, and like you, I can't work out what that would mean! I > used "halt" only with respect to a computation, meaning that the > computation halts [there is an n such that computation step n is a TM > final state]. > > Reading what you say very carefully, I think that by your definition of > simulation, the simulating TM must be a "pure" simulator that does > nothing but simulate computation steps until the simulation halts, at > which point the simulating TM halts (like a UTM). I get that with that > interpretation what you said: > > <copied from above> > >>> Your aborted simulation is just one final state of a turing machine, > >>> which has thus halted. > > makes sense and is correct. I'd just say I don't think that usage of > "simulation" is very useful, and is DEFINITELY not what PO is talking > about (so it would be wrong if applied PO's posts...) > > My use of "simulation" is broader: it's simply the activity performed by > a TM which consists of calculating computation steps of some given > computation. As such it's just a part of the TM logic. A TM's typical > use of simulation might be something like "..the TM simulates the > computation for n steps, and if the simulation halts during those n > steps, the TM [blah blah], /otherwise/ the TM [blah blah blah]...". > Just about every reference in the literature I can recall is something > like that. > > So... to be 100% clear on what I said: > > <copied from above> > >> A TM "aborting" a simulation is just the TM ceasing to calculate > >> computation steps for some computation, and going on to calculate > >> something else instead. > > E.g. in PO's P, after P aborts its simulation of P(P), the TM either > halts or enters an infinite loop. (That logic is not part of the > simulation, IMO.) > > >> It does *NOT* mean: > >> a) that the TM (doing the simulation) has halted > > obviously, because now P has gone on to something else... > > >> b) that the simulated computation halts > >> c) that the simulated computation never halts > > obviously - in general different exacmples of a simulated computation > P(I) might halt or never halt, and this is unaffected by a simulator's > decision to simulate no further computation steps. [The TM may have > spotted some pattern in the simulated computation which implies P(I) > never halts - that is a separate matter, but for sure the mere act of > "aborting" the simulation doesn't imply P(I) never halts, or imply that > it halts... > > Put yet another way, when a TM stops calculating TM steps (aka aborts > its simulation), NOTHING HALTS: not the simulating TM, not the simulated > computation, and NOT ANY PART OF EITHER OF THOSE. (Like you say, what > would part of a TM halting mean?) I think of a TM and an input string as defining a sequence (an ordered list). The elements of the sequence are pairs of a TM state name and a string representing the "tape" contents when the state was entered. Note that this view has no character of animation in it and makes the definition of the halt predicate (H) trivial: H(TM,STRING) = If length of TM(STRING) is finite then TRUE else FALSE. A simulator animates the production of the sequence and that causes some difficulties in the same way that elaborating an infinite sum or sequence does in math classes. An (ultimate) value only exists if there is some notation of convergence or limit which typically is the case with examples used in a math class. There is no definition of convergence or limit with the sequence defined by TM(STRING); rather, we simply ask about the last pair if the sequence is finite. -- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2022-06-06 00:59 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7jg0k$1qko$1@gioia.aioe.org> |
| In reply to | #51958 |
On 05/06/2022 22:59, Jeff Barnett wrote: > On 6/5/2022 2:07 PM, Mike Terry wrote: >> On 05/06/2022 16:16, Alan Mackenzie wrote: >>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>> On 05/06/2022 13:14, Alan Mackenzie wrote: >>>>> olcott <NoOne@nowhere.com> wrote: >>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote: >>>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote: >>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said: >>> >>>>>>>>>> A Turing machine is said to halt whenever it reaches a >>>>>>>>>> configuration for which δ is not defined; this is possible because >>>>>>>>>> δ is a partial function. In fact, we will assume that no >>>>>>>>>> transitions are defined for any final state so the Turing machine >>>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234) >>> >>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata. >>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. >>> >>>>>>>>>> When translated into ordinary software engineering terms this means >>>>>>>>>> terminated normally. In a C function this means reaching the "ret" >>>>>>>>>> instruction. >>> >>>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not >>>>>>>>> defined" should include at least: >>>>>>>>> - HLT or any other instruction that means 'halt' >>>>>>>>> - any undefined op code >>>>>>>>> - any return or pop instruction if the stack is empty >>>>>>>>> - an instruction fetch from a location that is not specifiec by the >>>>>>>>> program >>>>>>>>> That way the analogy to Linz' definition is much better. >>> >>>>>>>>> Mikko >>> >>>>>>>> Reaching a final state is merely the Turing machine way of saying >>>>>>>> terminated normally. "ret" is the C way of saying the same thing. >>> >>>>>>> Sophistry. What would be the turing machine equivalent of an >>>>>>> "abnormal termination" in C? >>> >>>>>> An aborted simulation. >>> >>>>> There's no such thing on a turing machine. It either runs and halts, >>>>> or it runs forever. >>> >>>>> Your aborted simulation is just one final state of a turing machine, >>>>> which has thus halted. >>> >>>> A TM "aborting" a simulation is just the TM ceasing to calculate >>>> computation steps for some computation, and going on to calculate >>>> something else instead. It does not mean: >>>> a) that the TM (doing the simulation) has halted >>>> b) that the simulated computation halts >>>> c) that the simulated computation never halts >>> >>> OK. I've a feeling we're talking more about nice shades of words than >>> computer science here, but .... >>> >>> If the simulation is the entire turing machine, aborting it will bring >>> the TM to a halt state. If that simulation is merely part of the TM, >>> then the word "halt" has a different meaning when applied to that >>> simulation part from when applied to the entire TM. I'm not even sure >>> what you mean when you say a part of a TM has halted or not halted. >> >> We are clearly talking at cross purposes - I never talked about /part/ of a TM halting, and like >> you, I can't work out what that would mean! I used "halt" only with respect to a computation, >> meaning that the computation halts [there is an n such that computation step n is a TM final state]. >> >> Reading what you say very carefully, I think that by your definition of simulation, the simulating >> TM must be a "pure" simulator that does nothing but simulate computation steps until the >> simulation halts, at which point the simulating TM halts (like a UTM). I get that with that >> interpretation what you said: >> >> <copied from above> >> >>> Your aborted simulation is just one final state of a turing machine, >> >>> which has thus halted. >> >> makes sense and is correct. I'd just say I don't think that usage of "simulation" is very >> useful, and is DEFINITELY not what PO is talking about (so it would be wrong if applied PO's >> posts...) >> >> My use of "simulation" is broader: it's simply the activity performed by a TM which consists of >> calculating computation steps of some given computation. As such it's just a part of the TM >> logic. A TM's typical use of simulation might be something like "..the TM simulates the >> computation for n steps, and if the simulation halts during those n steps, the TM [blah blah], >> /otherwise/ the TM [blah blah blah]...". Just about every reference in the literature I can recall >> is something like that. >> >> So... to be 100% clear on what I said: >> >> <copied from above> >> >> A TM "aborting" a simulation is just the TM ceasing to calculate >> >> computation steps for some computation, and going on to calculate >> >> something else instead. >> >> E.g. in PO's P, after P aborts its simulation of P(P), the TM either halts or enters an infinite >> loop. (That logic is not part of the simulation, IMO.) >> >> >> It does *NOT* mean: >> >> a) that the TM (doing the simulation) has halted >> >> obviously, because now P has gone on to something else... >> >> >> b) that the simulated computation halts >> >> c) that the simulated computation never halts >> >> obviously - in general different exacmples of a simulated computation P(I) might halt or never >> halt, and this is unaffected by a simulator's decision to simulate no further computation steps. >> [The TM may have spotted some pattern in the simulated computation which implies P(I) never halts >> - that is a separate matter, but for sure the mere act of "aborting" the simulation doesn't imply >> P(I) never halts, or imply that it halts... >> >> Put yet another way, when a TM stops calculating TM steps (aka aborts its simulation), NOTHING >> HALTS: not the simulating TM, not the simulated computation, and NOT ANY PART OF EITHER OF THOSE. >> (Like you say, what would part of a TM halting mean?) > > I think of a TM and an input string as defining a sequence (an ordered list). The elements of the > sequence are pairs of a TM state name and a string representing the "tape" contents when the state > was entered. Note that this view has no character of animation in it and makes the definition of the > halt predicate (H) trivial: > > H(TM,STRING) = If length of TM(STRING) is finite then TRUE else FALSE. Yes, that's equivalent to what I said (or at least meant). Your sequence is my computation steps. Formally, these would be defined inductively via the rule to go from step n to step n+1. (Not an animation, but the induction gives some /sense/ of step-by-step calculation, and a simulator will follow this, starting at step 1, then calculate step 2 and so on. Still, I agree the entire sequence [the "computation"] exists as one timeless structure. Too abstract for PO...) > > A simulator animates the production of the sequence and that causes some difficulties in the same > way that elaborating an infinite sum or sequence does in math classes. An (ultimate) value only > exists if there is some notation of convergence or limit which typically is the case with examples > used in a math class. There is no definition of convergence or limit with the sequence defined by > TM(STRING); rather, we simply ask about the last pair if the sequence is finite. Sure. The question right now is what you would call a TM which evaluates the first 10 steps of a computation, and then does something else. What is it doing while evaluating those 10 steps? tl;dr : who cares :) My terminology would be that it's "simulating" the computation (just for 10 steps) - then it stops simulating and does something else. Obviously I wouldn't describe it as "correctly" simulating, because nobody considers incorrect simulations, so the word would be redundant! Others have referred to that as an "incorrect simulation" because it stops calculating computation steps before a final state is reached. [Or maybe it's "incorrect" because after it aborts the simulation, H proceeds to return the wrong result? ..which is considered part of the simulation?" ... Well, there are loads of ok ways to analyse and phrase what's going on I guess, as long as we're consistent. But nobody is going to put in all the work required to achieve a consensus on this here, especially with PO who couldn't understand the distinctions. ] Mike.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2022-06-05 18:24 -0600 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7jhfn$kfc$1@dont-email.me> |
| In reply to | #51966 |
On 6/5/2022 5:59 PM, Mike Terry wrote: > On 05/06/2022 22:59, Jeff Barnett wrote: >> On 6/5/2022 2:07 PM, Mike Terry wrote: >>> On 05/06/2022 16:16, Alan Mackenzie wrote: >>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: >>>>> On 05/06/2022 13:14, Alan Mackenzie wrote: >>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>> On 6/5/2022 6:12 AM, Alan Mackenzie wrote: >>>>>>>> olcott <NoOne@nowhere.com> wrote: >>>>>>>>> On 6/5/2022 5:14 AM, Mikko wrote: >>>>>>>>>> On 2022-06-04 19:28:19 +0000, olcott said: >>>> >>>>>>>>>>> A Turing machine is said to halt whenever it reaches a >>>>>>>>>>> configuration for which δ is not defined; this is possible >>>>>>>>>>> because >>>>>>>>>>> δ is a partial function. In fact, we will assume that no >>>>>>>>>>> transitions are defined for any final state so the Turing >>>>>>>>>>> machine >>>>>>>>>>> will halt whenever it enters a final state. (Linz:1990:234) >>>> >>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and >>>>>>>>>>> Automata. >>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. >>>> >>>>>>>>>>> When translated into ordinary software engineering terms this >>>>>>>>>>> means >>>>>>>>>>> terminated normally. In a C function this means reaching the >>>>>>>>>>> "ret" >>>>>>>>>>> instruction. >>>> >>>>>>>>>> The best equivalent to "not defined" is not "ret". Instead, "not >>>>>>>>>> defined" should include at least: >>>>>>>>>> - HLT or any other instruction that means 'halt' >>>>>>>>>> - any undefined op code >>>>>>>>>> - any return or pop instruction if the stack is empty >>>>>>>>>> - an instruction fetch from a location that is not specifiec >>>>>>>>>> by the >>>>>>>>>> program >>>>>>>>>> That way the analogy to Linz' definition is much better. >>>> >>>>>>>>>> Mikko >>>> >>>>>>>>> Reaching a final state is merely the Turing machine way of saying >>>>>>>>> terminated normally. "ret" is the C way of saying the same thing. >>>> >>>>>>>> Sophistry. What would be the turing machine equivalent of an >>>>>>>> "abnormal termination" in C? >>>> >>>>>>> An aborted simulation. >>>> >>>>>> There's no such thing on a turing machine. It either runs and halts, >>>>>> or it runs forever. >>>> >>>>>> Your aborted simulation is just one final state of a turing machine, >>>>>> which has thus halted. >>>> >>>>> A TM "aborting" a simulation is just the TM ceasing to calculate >>>>> computation steps for some computation, and going on to calculate >>>>> something else instead. It does not mean: >>>>> a) that the TM (doing the simulation) has halted >>>>> b) that the simulated computation halts >>>>> c) that the simulated computation never halts >>>> >>>> OK. I've a feeling we're talking more about nice shades of words than >>>> computer science here, but .... >>>> >>>> If the simulation is the entire turing machine, aborting it will bring >>>> the TM to a halt state. If that simulation is merely part of the TM, >>>> then the word "halt" has a different meaning when applied to that >>>> simulation part from when applied to the entire TM. I'm not even sure >>>> what you mean when you say a part of a TM has halted or not halted. >>> >>> We are clearly talking at cross purposes - I never talked about >>> /part/ of a TM halting, and like you, I can't work out what that >>> would mean! I used "halt" only with respect to a computation, >>> meaning that the computation halts [there is an n such that >>> computation step n is a TM final state]. >>> >>> Reading what you say very carefully, I think that by your definition >>> of simulation, the simulating TM must be a "pure" simulator that does >>> nothing but simulate computation steps until the simulation halts, at >>> which point the simulating TM halts (like a UTM). I get that with >>> that interpretation what you said: >>> >>> <copied from above> >>> >>> Your aborted simulation is just one final state of a turing >>> machine, >>> >>> which has thus halted. >>> >>> makes sense and is correct. I'd just say I don't think that usage >>> of "simulation" is very useful, and is DEFINITELY not what PO is >>> talking about (so it would be wrong if applied PO's posts...) >>> >>> My use of "simulation" is broader: it's simply the activity performed >>> by a TM which consists of calculating computation steps of some given >>> computation. As such it's just a part of the TM logic. A TM's >>> typical use of simulation might be something like "..the TM simulates >>> the computation for n steps, and if the simulation halts during those >>> n steps, the TM [blah blah], /otherwise/ the TM [blah blah blah]...". >>> Just about every reference in the literature I can recall is >>> something like that. >>> >>> So... to be 100% clear on what I said: >>> >>> <copied from above> >>> >> A TM "aborting" a simulation is just the TM ceasing to calculate >>> >> computation steps for some computation, and going on to calculate >>> >> something else instead. >>> >>> E.g. in PO's P, after P aborts its simulation of P(P), the TM either >>> halts or enters an infinite loop. (That logic is not part of the >>> simulation, IMO.) >>> >>> >> It does *NOT* mean: >>> >> a) that the TM (doing the simulation) has halted >>> >>> obviously, because now P has gone on to something else... >>> >>> >> b) that the simulated computation halts >>> >> c) that the simulated computation never halts >>> >>> obviously - in general different exacmples of a simulated computation >>> P(I) might halt or never halt, and this is unaffected by a >>> simulator's decision to simulate no further computation steps. [The >>> TM may have spotted some pattern in the simulated computation which >>> implies P(I) never halts - that is a separate matter, but for sure >>> the mere act of "aborting" the simulation doesn't imply P(I) never >>> halts, or imply that it halts... >>> >>> Put yet another way, when a TM stops calculating TM steps (aka aborts >>> its simulation), NOTHING HALTS: not the simulating TM, not the >>> simulated computation, and NOT ANY PART OF EITHER OF THOSE. (Like you >>> say, what would part of a TM halting mean?) >> >> I think of a TM and an input string as defining a sequence (an ordered >> list). The elements of the sequence are pairs of a TM state name and a >> string representing the "tape" contents when the state was entered. >> Note that this view has no character of animation in it and makes the >> definition of the halt predicate (H) trivial: >> >> H(TM,STRING) = If length of TM(STRING) is finite then TRUE else FALSE. > > Yes, that's equivalent to what I said (or at least meant). Your > sequence is my computation steps. Formally, these would be defined > inductively via the rule to go from step n to step n+1. (Not an > animation, but the induction gives some /sense/ of step-by-step > calculation, and a simulator will follow this, starting at step 1, then > calculate step 2 and so on. Still, I agree the entire sequence [the > "computation"] exists as one timeless structure. Too abstract for PO...) > >> >> A simulator animates the production of the sequence and that causes >> some difficulties in the same way that elaborating an infinite sum or >> sequence does in math classes. An (ultimate) value only exists if >> there is some notation of convergence or limit which typically is the >> case with examples used in a math class. There is no definition of >> convergence or limit with the sequence defined by TM(STRING); rather, >> we simply ask about the last pair if the sequence is finite. > > Sure. > The question right now is what you would call a TM which evaluates the > first 10 steps of a computation, and then does something else. What is > it doing while evaluating those 10 steps? What would I call it? POOP! It just goes to show the accuracy and flexibility of Ben's acronym for any Peter-related concept. > tl;dr : who cares :) > > My terminology would be that it's "simulating" the computation (just for > 10 steps) - then it stops simulating and does something else. Obviously > I wouldn't describe it as "correctly" simulating, because nobody > considers incorrect simulations, so the word would be redundant! Others > have referred to that as an "incorrect simulation" because it stops > calculating computation steps before a final state is reached. [Or > maybe it's "incorrect" because after it aborts the simulation, H > proceeds to return the wrong result? ..which is considered part of the > simulation?" ... Well, there are loads of ok ways to analyse and > phrase what's going on I guess, as long as we're consistent. But nobody > is going to put in all the work required to achieve a consensus on this > here, especially with PO who couldn't understand the distinctions. ] I'm not looking for consensus with this group. While I think that animating concepts in math is a good pedagogical method to awaken understanding, it is essential to note that infinite ordered things exist, to the extent that they do exist, all at once and do not develop in time as some sequence of events. If one does not separate the "as if" teaching method from "this is the definition", you get genuine misunderstanding as well as the half ass stuff you read in this news group. Of course, the animation method suggests some interesting "proofs" of ideas (such as the Hilbert Hotel) and sometimes some ways of visualizing results that are hard to come by otherwise. -- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | Ben <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-06-06 01:40 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <87mteqlj44.fsf@bsb.me.uk> |
| In reply to | #51967 |
Jeff Barnett <jbb@notatt.com> writes: > On 6/5/2022 5:59 PM, Mike Terry wrote: >> The question right now is what you would call a TM which evaluates >> the first 10 steps of a computation, and then does something else. >> What is it doing while evaluating those 10 steps? > > What would I call it? POOP! It just goes to show the accuracy and > flexibility of Ben's acronym for any Peter-related concept. Credit where it's due... POOP is Richard's. Mine was not as good. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2022-06-05 18:44 -0600 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7jili$pnf$1@dont-email.me> |
| In reply to | #51970 |
On 6/5/2022 6:40 PM, Ben wrote: > Jeff Barnett <jbb@notatt.com> writes: > >> On 6/5/2022 5:59 PM, Mike Terry wrote: > >>> The question right now is what you would call a TM which evaluates >>> the first 10 steps of a computation, and then does something else. >>> What is it doing while evaluating those 10 steps? >> >> What would I call it? POOP! It just goes to show the accuracy and >> flexibility of Ben's acronym for any Peter-related concept. > > Credit where it's due... POOP is Richard's. Mine was not as good. Then a thousand apologies and kudos to Richard! -- Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 20:03 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <WtCdnUN8arLrzwD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51970 |
On 6/5/2022 7:40 PM, Ben wrote: > Jeff Barnett <jbb@notatt.com> writes: > >> On 6/5/2022 5:59 PM, Mike Terry wrote: > >>> The question right now is what you would call a TM which evaluates >>> the first 10 steps of a computation, and then does something else. >>> What is it doing while evaluating those 10 steps? >> >> What would I call it? POOP! It just goes to show the accuracy and >> flexibility of Ben's acronym for any Peter-related concept. > > Credit where it's due... POOP is Richard's. Mine was not as good. > That was the initial incorrect rebuttal that claimed the concept of a simulating halt decider is inherently invalid. When a simulating halt decider H correctly predicts that its complete simulation of its input finite string would never reach the final state of this machine description then H has correctly rejected this input as non-halting. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 21:59 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <_bdnK.109334$JVi.7568@fx17.iad> |
| In reply to | #51973 |
On 6/5/22 9:03 PM, olcott wrote: > On 6/5/2022 7:40 PM, Ben wrote: >> Jeff Barnett <jbb@notatt.com> writes: >> >>> On 6/5/2022 5:59 PM, Mike Terry wrote: >> >>>> The question right now is what you would call a TM which evaluates >>>> the first 10 steps of a computation, and then does something else. >>>> What is it doing while evaluating those 10 steps? >>> >>> What would I call it? POOP! It just goes to show the accuracy and >>> flexibility of Ben's acronym for any Peter-related concept. >> >> Credit where it's due... POOP is Richard's. Mine was not as good. >> > > That was the initial incorrect rebuttal that claimed the concept of a > simulating halt decider is inherently invalid. > > When a simulating halt decider H correctly predicts that its complete > simulation of its input finite string would never reach the final state > of this machine description then H has correctly rejected this input as > non-halting. > No, its based on the fact that you are trying to define the "correct" answer for H to be something different than what the Halting Problem Requires. The DEFINITION of the Halting Problem is that H applied to <M> w needs to accept the input if M applied to w Halts and reject if M applied to w never halts. You want to change that to being based on "The correct simulation of its input by H reaching a final state", which is not equivalent. The key point is that by the classical definition of what a "correct simulation" would be that actually shows non-halting, a simulator that does that CAN'T answer non-halting, because the definition of a correct simulation of a non-halting machine is a non-halting simulation. (i.e. the behavior of a UTM). If your definition was based on "The correct simulation of its input by a UTM", then it would be ok, but since that isn't what you mean, your definition is different than the original, so it is your "Other Problem". It isn't that a simulating Halt Deicder is inherently invalid, but even a simulating halt decider needs to use the original definition of Halting, which means either looking that the behavior of the original machine, or the UTM simulation of the representation of it. Yes, this gives the decider an inherent problem, that it, like ALL Halt Deciders, needs to decide in finite time something that takes unbounded time to directly prove, but that is the nature of the Halting Problem, and what made it interesting. The hope initially was that there might be some "trick" that could be done to analyise the machine/input and be able to determine halting without needing to actually run the machine to the halting state (or a point it was clear that it would never halt). Turing showed that there could not be such a trick. You keep on erring because you start with assumptions that implicitly assume that a machine to give the answer is possible, when it isn't, and this leads you to a false conclusion and an inconsistent logic system. Many of your arguments actually boil down to, If I had a routine that solved the Halting Problem, I could wrap it up in code to transform the input into a somewhat different problem but with the same answer, and ask that routine about this new problem.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 21:14 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <j_idnQkuqviR_gD_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #51975 |
On 6/5/2022 8:59 PM, Richard Damon wrote:
> On 6/5/22 9:03 PM, olcott wrote:
>> On 6/5/2022 7:40 PM, Ben wrote:
>>> Jeff Barnett <jbb@notatt.com> writes:
>>>
>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>
>>>>> The question right now is what you would call a TM which evaluates
>>>>> the first 10 steps of a computation, and then does something else.
>>>>> What is it doing while evaluating those 10 steps?
>>>>
>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>
>>> Credit where it's due... POOP is Richard's. Mine was not as good.
>>>
>>
>> That was the initial incorrect rebuttal that claimed the concept of a
>> simulating halt decider is inherently invalid.
>>
>> When a simulating halt decider H correctly predicts that its complete
>> simulation of its input finite string would never reach the final
>> state of this machine description then H has correctly rejected this
>> input as non-halting.
>>
>
> No, its based on the fact that you are trying to define the "correct"
> answer for H to be something different than what the Halting Problem
> Requires.
If that was true then one of these facts wold not be verified:
(1) The relationship between H and P matches the pattern specified below:
(2) H does correctly compute the mapping from the x86 machine code to
its reject state on the basis
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H1((u32)P, (u32)P));
}
_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 22:44 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <hSdnK.10426$Vxw.2879@fx07.iad> |
| In reply to | #51977 |
On 6/5/22 10:14 PM, olcott wrote:
> On 6/5/2022 8:59 PM, Richard Damon wrote:
>> On 6/5/22 9:03 PM, olcott wrote:
>>> On 6/5/2022 7:40 PM, Ben wrote:
>>>> Jeff Barnett <jbb@notatt.com> writes:
>>>>
>>>>> On 6/5/2022 5:59 PM, Mike Terry wrote:
>>>>
>>>>>> The question right now is what you would call a TM which evaluates
>>>>>> the first 10 steps of a computation, and then does something else.
>>>>>> What is it doing while evaluating those 10 steps?
>>>>>
>>>>> What would I call it? POOP! It just goes to show the accuracy and
>>>>> flexibility of Ben's acronym for any Peter-related concept.
>>>>
>>>> Credit where it's due... POOP is Richard's. Mine was not as good.
>>>>
>>>
>>> That was the initial incorrect rebuttal that claimed the concept of a
>>> simulating halt decider is inherently invalid.
>>>
>>> When a simulating halt decider H correctly predicts that its complete
>>> simulation of its input finite string would never reach the final
>>> state of this machine description then H has correctly rejected this
>>> input as non-halting.
>>>
>>
>> No, its based on the fact that you are trying to define the "correct"
>> answer for H to be something different than what the Halting Problem
>> Requires.
>
> If that was true then one of these facts wold not be verified:
> (1) The relationship between H and P matches the pattern specified below:
>
> (2) H does correctly compute the mapping from the x86 machine code to
> its reject state on the basis
No definition of what "Correct computes the mapping"
Remember the MAPPING that H needs to compute is that
H(<M>, w) accepts if M(w) Halts, and rejects if M(w) doesn't halt.
No mention of "simulations" here.
Since P(P) is shown to Halt if H(P,P) returns 0 (reject), that mapping
is NOT correctly computed.
>
> For any program H that might determine if programs halt, a
> "pathological" > program P, called with some input, can pass its own source and its
> input to
> H and then specifically do the opposite of what H predicts P will
> do. No H
> can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
Since you H didn't handle the case, because H(P,P) results in a
rejection, while P(P) Halts, you haven't show correctly computing of the
Halting Map.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
>
>
Not even your broken trace?
Your slipping.
FAIL.
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2022-06-06 02:58 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7jmvi$1ukh$1@gioia.aioe.org> |
| In reply to | #51967 |
On 06/06/2022 01:24, Jeff Barnett wrote: > On 6/5/2022 5:59 PM, Mike Terry wrote: <..snip..>>> >> Sure. >> The question right now is what you would call a TM which evaluates the first 10 steps of a >> computation, and then does something else. What is it doing while evaluating those 10 steps? > > What would I call it? POOP! It just goes to show the accuracy and flexibility of Ben's acronym for > any Peter-related concept. > But PO didn't invent the concept of (partially) simulating a computation in order to compute certain properties of that computation! It's been around since Turing's days, and is very useful. Mike.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 21:11 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <j_idnQ4uqvj8_wD_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #51974 |
On 6/5/2022 8:58 PM, Mike Terry wrote:
> On 06/06/2022 01:24, Jeff Barnett wrote:
>> On 6/5/2022 5:59 PM, Mike Terry wrote:
> <..snip..>>>
>>> Sure.
>>> The question right now is what you would call a TM which evaluates
>>> the first 10 steps of a computation, and then does something else.
>>> What is it doing while evaluating those 10 steps?
>>
>> What would I call it? POOP! It just goes to show the accuracy and
>> flexibility of Ben's acronym for any Peter-related concept.
>>
>
> But PO didn't invent the concept of (partially) simulating a computation
> in order to compute certain properties of that computation! It's been
> around since Turing's days, and is very useful.
>
> Mike.
That is true. I am apparently the first one that ever thought this
through well enough so that machine descriptions matching the following
pattern could be correctly determined to be non-halting:
For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own source and its
input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
In that a partial simulation does correctly predict the behavior of a
complete simulation it can be used to recognize infinite behavior patterns.
--
Copyright 2022 Pete Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 22:20 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <tvdnK.53503$X_i.15539@fx18.iad> |
| In reply to | #51976 |
On 6/5/22 10:11 PM, olcott wrote: > On 6/5/2022 8:58 PM, Mike Terry wrote: >> On 06/06/2022 01:24, Jeff Barnett wrote: >>> On 6/5/2022 5:59 PM, Mike Terry wrote: >> <..snip..>>> >>>> Sure. >>>> The question right now is what you would call a TM which evaluates >>>> the first 10 steps of a computation, and then does something else. >>>> What is it doing while evaluating those 10 steps? >>> >>> What would I call it? POOP! It just goes to show the accuracy and >>> flexibility of Ben's acronym for any Peter-related concept. >>> >> >> But PO didn't invent the concept of (partially) simulating a >> computation in order to compute certain properties of that >> computation! It's been around since Turing's days, and is very useful. >> >> Mike. > > That is true. I am apparently the first one that ever thought this > through well enough so that machine descriptions matching the following > pattern could be correctly determined to be non-halting: > > For any program H that might determine if programs halt, a > "pathological" > program P, called with some input, can pass its own source and its > input to > H and then specifically do the opposite of what H predicts P will > do. No H > can exist that handles this case. > https://en.wikipedia.org/wiki/Halting_problem > > In that a partial simulation does correctly predict the behavior of a > complete simulation it can be used to recognize infinite behavior patterns. > Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by the DEFINITION of the requirements of the Halting Problem, H(P,P) needs to accept (return 1) if P(P) Halts, thus H was incorrect for a Halting Decider. You just try to use twisted words to try and describe what H actually did decide on to be close to words that could be used to descirbe the Halting Problem. But the slight difference is important, even if you don't think so. That just shows your level (or lack thereof) of knowledge of the field.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 21:37 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] |
| Message-ID | <CZWdnQh_NLwe9QD_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #51979 |
On 6/5/2022 9:20 PM, Richard Damon wrote: > On 6/5/22 10:11 PM, olcott wrote: >> On 6/5/2022 8:58 PM, Mike Terry wrote: >>> On 06/06/2022 01:24, Jeff Barnett wrote: >>>> On 6/5/2022 5:59 PM, Mike Terry wrote: >>> <..snip..>>> >>>>> Sure. >>>>> The question right now is what you would call a TM which evaluates >>>>> the first 10 steps of a computation, and then does something else. >>>>> What is it doing while evaluating those 10 steps? >>>> >>>> What would I call it? POOP! It just goes to show the accuracy and >>>> flexibility of Ben's acronym for any Peter-related concept. >>>> >>> >>> But PO didn't invent the concept of (partially) simulating a >>> computation in order to compute certain properties of that >>> computation! It's been around since Turing's days, and is very useful. >>> >>> Mike. >> >> That is true. I am apparently the first one that ever thought this >> through well enough so that machine descriptions matching the >> following pattern could be correctly determined to be non-halting: >> >> For any program H that might determine if programs halt, a >> "pathological" >> program P, called with some input, can pass its own source and >> its input to >> H and then specifically do the opposite of what H predicts P >> will do. No H >> can exist that handles this case. >> https://en.wikipedia.org/wiki/Halting_problem >> >> In that a partial simulation does correctly predict the behavior of a >> complete simulation it can be used to recognize infinite behavior >> patterns. >> > > Except that it doesn't since P(P) Halts if H(P,P) returns 0, which, by > the DEFINITION of the requirements of the Halting Problem, H(P,P) needs > to accept (return 1) if P(P) Halts, This seems to be brand new computer science that I just discovered. Previously no one understood that it was possible for the correct simulation of the input to H(P,P) to be computationally distinct (thus not equivalent) to the direct execution of P(P). Because of this all of the computer science textbooks refer to the halting behavior of P(P) as what must be decided by the halt decider. This same computer science also knows that a decider must compute the mapping of its input finite string to an accept or reject state on the basis of a property of this input encoded in this finite string. THE FOLLOWING CRITERIA ALWAYS WORKS H computes the mapping from its input finite strings to its accept or reject state on the basis of the actual behavior specified by the actual input as measured by the correct UTM simulation of this input by H. It has been completely proven that partial simulations do correctly predict the behavior of some complete simulations. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web