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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 22:52 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] |
| Message-ID | <e_dnK.35922$kaDc.28131@fx46.iad> |
| In reply to | #51981 |
On 6/5/22 10:37 PM, olcott wrote: > 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). By what definition of "Correct" are you using? That is like says I can be correct at saying 1+2 = 4 if I just redefine 1+2 to be 4. Note, if you correct deviates IN ANY WAY, from the UTM definition, you can't use it in your definiton of the Halting Problem. > > 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. Because that IS 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. Right, and the property is the Halting status of UTM(P,P). That is a FULLY DEFINED property. > > 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. Right, UTM simulation, and UTM simulation of its input is DEFINED to match the behavior of the machine its input represents. Thus BY DEFINITON UTM(<M>, w) matches the behavior of M(w). It isn't "computationall distinct" as you tried to claim above. So UTM(P,P) matches P(P), and you answer is proved incorrect, since P(P) Halts if H(P,P) returns 0, and thus UTM(P,P) will halt, and thus H(P,P) needed to accept (return 1), which it didn't so it is wrong. > > It has been completely proven that partial simulations do correctly > predict the behavior of some complete simulations. > yes, SOME, but not this one. FALLICY of proof by example. 1st grade error.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 22:03 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] |
| Message-ID | <oaWdna1jVqsT8wD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51984 |
On 6/5/2022 9:52 PM, Richard Damon wrote: > > On 6/5/22 10:37 PM, olcott wrote: >> 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). > > By what definition of "Correct" are you using? Ordinary software engineering proves that a correct and complete x86 emulation of the input to H(P,P) never reaches its "ret" instruction. _P() [00001352](01) 55 push ebp [00001353](02) 8bec mov ebp,esp [00001355](03) 8b4508 mov eax,[ebp+08] [00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08] [0000135c](01) 51 push ecx // push P [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 23:26 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ brand new computer science ] |
| Message-ID | <6uenK.7587$x7oc.45@fx01.iad> |
| In reply to | #51985 |
On 6/5/22 11:03 PM, olcott wrote: > On 6/5/2022 9:52 PM, Richard Damon wrote: >> >> On 6/5/22 10:37 PM, olcott wrote: >>> 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). >> >> By what definition of "Correct" are you using? > > > Ordinary software engineering proves that a correct and complete x86 > emulation of the input to H(P,P) never reaches its "ret" instruction. > So, I guess this just shows that you don't actually know a definition that shows this, so this is just another of your lies. Also, it is shown that P(P) Halts if H(P,P) returns 0, and even YOU have accepted that fact, so that also shows that you must be lying, since Ordinary Software Engineering doesn't 'prove' lies. Remember, correct and complete x86 emulation behaves exactly like the x86 program that is being emulated, in this case, P(P). Maybe YOUR knowledge of software engineering says that, but that says more about your (lack of) knowledge of real software engineering. > _P() > [00001352](01) 55 push ebp > [00001353](02) 8bec mov ebp,esp > [00001355](03) 8b4508 mov eax,[ebp+08] > [00001358](01) 50 push eax // push P > [00001359](03) 8b4d08 mov ecx,[ebp+08] > [0000135c](01) 51 push ecx // push P > [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] > >
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 22:41 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] |
| Message-ID | <zJednRViLZP46gD_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #51986 |
On 6/5/2022 10:26 PM, Richard Damon wrote: > On 6/5/22 11:03 PM, olcott wrote: >> On 6/5/2022 9:52 PM, Richard Damon wrote: >>> >>> On 6/5/22 10:37 PM, olcott wrote: >>>> 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). >>> >>> By what definition of "Correct" are you using? >> >> >> Ordinary software engineering proves that a correct and complete x86 >> emulation of the input to H(P,P) never reaches its "ret" instruction. >> > > So, I guess this just shows that you don't actually know a definition > that shows this, so this is just another of your lies. Ordinary software engineering proves that a correct and complete x86 emulation of the input to H(P,P) never reaches its "ret" instruction. _P() [00001352](01) 55 push ebp [00001353](02) 8bec mov ebp,esp [00001355](03) 8b4508 mov eax,[ebp+08] [00001358](01) 50 push eax // push P [00001359](03) 8b4d08 mov ecx,[ebp+08] [0000135c](01) 51 push ecx // push P [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] It is completely obvious that when H(P,P) correctly emulates its input that it must emulate the first seven instructions of P. Because the seventh instruction of P repeats this process we can know with complete certainty that the emulated P never reaches its final “ret” instruction, thus 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-06 00:17 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] |
| Message-ID | <ndfnK.2930$sW.2247@fx37.iad> |
| In reply to | #51987 |
On 6/5/22 11:41 PM, olcott wrote: > On 6/5/2022 10:26 PM, Richard Damon wrote: >> On 6/5/22 11:03 PM, olcott wrote: >>> On 6/5/2022 9:52 PM, Richard Damon wrote: >>>> >>>> On 6/5/22 10:37 PM, olcott wrote: >>>>> 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). >>>> >>>> By what definition of "Correct" are you using? >>> >>> >>> Ordinary software engineering proves that a correct and complete x86 >>> emulation of the input to H(P,P) never reaches its "ret" instruction. >>> >> >> So, I guess this just shows that you don't actually know a definition >> that shows this, so this is just another of your lies. > > Ordinary software engineering proves that a correct and complete x86 > emulation of the input to H(P,P) never reaches its "ret" instruction. Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P) returns 0 that P(P) will halt. Good engineering NEVER contradicts actual facts. > > _P() > [00001352](01) 55 push ebp > [00001353](02) 8bec mov ebp,esp > [00001355](03) 8b4508 mov eax,[ebp+08] > [00001358](01) 50 push eax // push P > [00001359](03) 8b4d08 mov ecx,[ebp+08] > [0000135c](01) 51 push ecx // push P > [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] > > It is completely obvious that when H(P,P) correctly emulates its input > that it must emulate the first seven instructions of P. Because the > seventh instruction of P repeats this process we can know with complete > certainty that the emulated P never reaches its final “ret” instruction, > thus never halts. > Maybe to you, but it is wrong (which might be why it is obvious to you). Let us start by assuming that H doesn't just abort its simulation until it has enough information to be obviously wrong. H(P,P) will first emulate the first 7 instructions of P as you say. Then it emulates the result of the call to H, so it emulates the start of the emulation of the input to this H, which is also P,P. That proceeds, as you almost say through the emulation of the emulaiton of the first 7 instructions of P. While doing this, the outer emulation will notice that the machine it has been emulating has been checking conditions along the way. We then get to the point that the emulation of the emulation reaches the 2nd level call to H, and the top level emulator will see that emulator it is emulating checking if things have recursed too far. At this point, the outer H has seen enough that it can see that if it has aborted its simulation as soon as it say P calling H(P,P) and matching that input to H to the input IT had, and calling that an infinite repeat pattern, it would have been wrong, as a correct emulation of that input would have continued and reached THIS point where the H it was emulating made that same decision. In fact, if the decider was smart enough, it could see that if it simulates N levels of calls, and decides that this was enough to call the input infinitely recursive, that at the N+1 call (that it won't get to but a CORRECT COMPLETE emulator would), the emulator it is emulating would reach N calls and do the same as it is, and thus showing that it was wrong to make that decision. The ONLY way that the correct emulation of the input never reaches the ret instruction is if H actually never aborts its emulation, and thus never actually gives the answer that the input is non-halting. So, the ONLY H that creates a non-halting input is the H that fails to give the answer that is only correct for that H. Your brain just doesn't seem to be able to keep enough information to handle the levels that happen in this problem.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-06 10:28 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] |
| Message-ID | <5ISdnatEmrelgAP_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51988 |
On 6/5/2022 11:17 PM, Richard Damon wrote:
>
> On 6/5/22 11:41 PM, olcott wrote:
>> On 6/5/2022 10:26 PM, Richard Damon wrote:
>>> On 6/5/22 11:03 PM, olcott wrote:
>>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>>> 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).
>>>>>
>>>>> By what definition of "Correct" are you using?
>>>>
>>>>
>>>> Ordinary software engineering proves that a correct and complete x86
>>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>>>
>>>
>>> So, I guess this just shows that you don't actually know a definition
>>> that shows this, so this is just another of your lies.
>>
>> Ordinary software engineering proves that a correct and complete x86
>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>
> Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
> returns 0 that P(P) will halt.
>
> Good engineering NEVER contradicts actual facts.
>
>>
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [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]
>>
>> It is completely obvious that when H(P,P) correctly emulates its input
>> that it must emulate the first seven instructions of P. Because the
>> seventh instruction of P repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>
> Maybe to you, but it is wrong (which might be why it is obvious to you).
>
Software engineers competent in C and the x86 language will verify that
when H(P,P) correctly emulates its input with an x86 emulator that this
emulation would never stop running. This provides the basis for H(P,P)
to correctly reject its input as 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
H determines the halt status of its input by watching the behavior of
this input when it is correctly simulated by H using an x86 emulator.
When H correctly matches an infinite behavior pattern it aborts the
emulation of this input and returns 0.
#include <stdint.h>
#define u32 uint32_t
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((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 // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[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]
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus 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-06 21:04 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers[ Ordinary software engineering ] |
| Message-ID | <CuxnK.8516$CBlb.3133@fx42.iad> |
| In reply to | #51992 |
On 6/6/22 11:28 AM, olcott wrote:
> On 6/5/2022 11:17 PM, Richard Damon wrote:
>>
>> On 6/5/22 11:41 PM, olcott wrote:
>>> On 6/5/2022 10:26 PM, Richard Damon wrote:
>>>> On 6/5/22 11:03 PM, olcott wrote:
>>>>> On 6/5/2022 9:52 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/5/22 10:37 PM, olcott wrote:
>>>>>>> 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).
>>>>>>
>>>>>> By what definition of "Correct" are you using?
>>>>>
>>>>>
>>>>> Ordinary software engineering proves that a correct and complete
>>>>> x86 emulation of the input to H(P,P) never reaches its "ret"
>>>>> instruction.
>>>>>
>>>>
>>>> So, I guess this just shows that you don't actually know a
>>>> definition that shows this, so this is just another of your lies.
>>>
>>> Ordinary software engineering proves that a correct and complete x86
>>> emulation of the input to H(P,P) never reaches its "ret" instruction.
>>
>> Nope. Not if H(P,P) returns 0, as simple facts show that if H(P,P)
>> returns 0 that P(P) will halt.
>>
>> Good engineering NEVER contradicts actual facts.
>>
>>>
>>> _P()
>>> [00001352](01) 55 push ebp
>>> [00001353](02) 8bec mov ebp,esp
>>> [00001355](03) 8b4508 mov eax,[ebp+08]
>>> [00001358](01) 50 push eax // push P
>>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>>> [0000135c](01) 51 push ecx // push P
>>> [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]
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its
>>> input that it must emulate the first seven instructions of P. Because
>>> the seventh instruction of P repeats this process we can know with
>>> complete certainty that the emulated P never reaches its final “ret”
>>> instruction, thus never halts.
>>>
>>
>> Maybe to you, but it is wrong (which might be why it is obvious to you).
>>
>
>
> Software engineers competent in C and the x86 language will verify that
> when H(P,P) correctly emulates its input with an x86 emulator that this
> emulation would never stop running. This provides the basis for H(P,P)
> to correctly reject its input as non-halting.
Yes, when H is actually defined to correctly emulate its input, which
means, BY DEFINITON, that it doesn't stop its emulation until it reaches
a final state, then it can be shown that this emulation never stops running.
This can NOT be used to show that any other H is correct to say that the
P built on that other H is non-halting, as it is a different program P,
as the program P includes the H that it is built on.
That you keep missing this fact speaks of your mental ability (or lack
thereof)
>
> > 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
>
> H determines the halt status of its input by watching the behavior of
> this input when it is correctly simulated by H using an x86 emulator.
> When H correctly matches an infinite behavior pattern it aborts the
> emulation of this input and returns 0.
Except that is can't see a full correctly simulation of its input, and
the partial simulation that it sees never shows an actual correctly
defined infinite behavior pattern, as can be proved by the fact that if
you include that in H, then P(P) for the P built on the H that includes
that pattern and returns 0 for H(P,P) will Halt, when the h that it
calls returns that answer.
You can't use the partial simulation that H used, as partial simulation
do not, by themselves, prove non-halting, and for a pattern to be
correctly determined to be non-halting, ALL programs that show that
pattern must be non-halting, but as described above ANY pattern that H
sees in its simulation of its input to H(P,P), if added to its list of
patterns to call non-halting, will produce a Halting P(P), and thus is
proved not to be correct.
>
> #include <stdint.h>
> #define u32 uint32_t
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((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 // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [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]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
It may be "obvious" to you, but "obvious" is the source of many errors.
You need to deal with PROVEN, not "obvious"
You apparently don't actually believe in your own rules, don't YOU say
that all Truths need to be proven, so since you can't actually PROVE
that rule, you can't claim it to be true.
The fact that it is proven FALSE, just shows your Hypocrisy.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 22:15 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <ordnK.144742$70j.37068@fx16.iad> |
| In reply to | #51974 |
On 6/5/22 9: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. The issue isn't partial simulation per-se, but that fact that he wants to define that if "No H" can simulate the input to a final state, then it is non-halting. The problem is that he means by this changing the definition of H in a way that changes the H that P is using. In more explicit terms, that if we define a series of Halt Deciders, Hi, that simulate for longer times with increasing i, and a series of "Contrary Inputs" Pi, such that Pi(x) calls Hi(X, X) and does the opposite, the fact that for all i, Hi(Pi,Pi) will never reach a final state, makes calling Pi(Pi) a non-halting computation correct, even if when we directly run Pi(Pi) it halts. Since he isn't using the right definition, he is working on his "other problem" that no one is particularly interested in.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 21:22 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <D-6dnTx7HvJ5-QD_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #51978 |
On 6/5/2022 9:15 PM, Richard Damon wrote: > On 6/5/22 9: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. > > The issue isn't partial simulation per-se, but that fact that he wants > to define that if "No H" can simulate the input to a final state, then > it is non-halting. No stupid that is not it. It is true that a partial simulation does correctly predict a complete simulation. I call you stupid for denying this because my examples very obviously prove that it is true. -- 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:38 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <vMdnK.144745$70j.26327@fx16.iad> |
| In reply to | #51980 |
On 6/5/22 10:22 PM, olcott wrote: > On 6/5/2022 9:15 PM, Richard Damon wrote: >> On 6/5/22 9: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. >> >> The issue isn't partial simulation per-se, but that fact that he wants >> to define that if "No H" can simulate the input to a final state, then >> it is non-halting. > > No stupid that is not it. > > It is true that a partial simulation does correctly predict a complete > simulation. I call you stupid for denying this because my examples very > obviously prove that it is true. > > It does? Then why does it predict that the correct complete simulation would be non-halting, when BY DEFINITION, the correct complete simulation needs to match the behavior of the machine the input represents, and even you agree that P(P) will Halt when H(P,P) returns 0, thus the CORRECT COMPLETE simulation of the input to H(P,P), i.e. UTM(P,P) will also halt. Your arguement is based on having two different machines call H that you confuse. One H that aborts its simulation of it input and a second one that doesn't. This can not exist. In a given proof, the definition of H as a machine must be consistant and always refer to the same machine. Your argument, if we lable the first machine Ha, and the second Hn (and the P's that use them Pa and Pn) that Ha(Pa, Pa) is correct to say non-halting becuase when Hn(Pn,Pn) simulates its input forever, it shows that Pn(Pn) is a non-halting computation, and somehow that behavior transfers over to the totally different machine Pa. You logic just fails.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 19:27 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] |
| Message-ID | <SfSdnQ0vIqRj1AD_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51966 |
On 6/5/2022 6: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...)
>
In other words when we make sure to conflate the program under test with
the test program as a single computation then the whole idea of a halt
decider becomes less coherent and
this can be used as an excuse to pretend that you don't already know
that H(P,P)==0 is correct and the H/P relationship matches the halting
problem counter example template.
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
return;
}
int main()
{
Output("Input_Halts = ", H((u32)P, (u32)P));
}
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
>>
>> 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!
It is required because my reviewers are making their best possible
effort to form rebuttals and the most persistent of the fake rebuttals
has been that the simulation is incorrect. It is very easy to verify
the correct x86 emulation on the basis of the x86 language.
> 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
My point exactly.
> 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
The foundation is simple software engineering that H(P,P)==0 on the
basis that a complete simulation of the input to H(P,P) by H would never
reach the "ret" instruction of P.
> here, especially with PO who couldn't understand the distinctions. ]
>
>
> Mike.
--
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 20:56 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] |
| Message-ID | <rhcnK.65120$ntj.43005@fx15.iad> |
| In reply to | #51968 |
On 6/5/22 8:27 PM, olcott wrote:
> On 6/5/2022 6: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...)
>>
>
> In other words when we make sure to conflate the program under test with
> the test program as a single computation then the whole idea of a halt
> decider becomes less coherent and
>
> this can be used as an excuse to pretend that you don't already know
> that H(P,P)==0 is correct and the H/P relationship matches the halting
> problem counter example template.
>
> void P(u32 x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> 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
>
>
>>>
>>> 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!
>
> It is required because my reviewers are making their best possible
> effort to form rebuttals and the most persistent of the fake rebuttals
> has been that the simulation is incorrect. It is very easy to verify
> the correct x86 emulation on the basis of the x86 language.
Except that it doesn't. By DEFINITION, a correct simulation needs show
the same behavior of the thing it is simulating.
Thus, since the input to H(P,P) represents the computation P(P) [at
least if H claims to be a Halt Decider], then a correct simulation of
that input needs to behave the same actual machine it represents.
Since P(P) Halts if H(P,P) returns 0, then H(P,P) returning 0 can not be
the correct answer for the behavior of P(P).
>
>> 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
>
> My point exactly.
You might be able to claim a correct partial simulation (excpet you
don't trace nesting right), but the partial d
>
>> 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
>
> The foundation is simple software engineering that H(P,P)==0 on the
> basis that a complete simulation of the input to H(P,P) by H would never
> reach the "ret" instruction of P.
The ONLY time that H does a COMPLETE SIMULATION, is if H never aborts
its simulation.
H must be a definite program.
If H IS that program that never aborts, then yes, P(P) is non-halting
and Halts(P,P) == 0 would be correct, but H can NEVER generate that
answer, as that behavior was derived from the assumption that H never
aborts its simulation. Thus any argument that breaks that assumption is
UNSOUND.
If H does abort its simulation, then it never did a COMPLETE SIMULATION,
and never will, and thus "the complete simulation by H" is a
non-existant entity, it is the liars paradox. You can't base a proof on
the properties of something that doesn't actually exist.
Any claims that these two possibilities for H can exist at the same time
is just an admission that H is not the required computation, as it
doesn;t always act the same way to the same input.
If you want to claim that it is possible for a computation to act
differently for different instances with the exact same input, then you
really need to PROVE that claim. If you can, that alone would make you
famous, but it seems you don't even know enough about the field to
understand the need to prove that claim, so I really doubt you have a
way to prove it. (Again, the proof that it always acts the same is so
foundationally simple, I can't imagine you having a way to actually
disprove it.
>
>> here, especially with PO who couldn't understand the distinctions. ]
>>
>>
>> Mike.
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-07 20:04 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ members of c/c++ ] |
| Message-ID | <YsWdnf84JLgBaAL_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51972 |
On 6/7/2022 7:05 PM, Mike Terry wrote: > On 07/06/2022 21:51, Mr Flibble wrote: >> On Tue, 7 Jun 2022 15:34:13 -0500 >> olcott <NoOne@NoWhere.com> wrote: >> > <..snip..> >>> >>> How many times do I have to say this before you notice that I said it >>> at least once? H (in the current process) always creates a new >>> process context to emulate its its input with an x86 emulator. >> >> I will have to take your word for it as you refuse to publish source >> code. Why not just stick your project on GitHub? Open source is de >> rigueur these days. What are you trying to hide? >> >> If a new process context is made then how is nested simulation >> detected? > > The code in x86utm.exe (his emulator) that emulates individual > instructions also updates a global trace table, making it accessible to > the emulated code. So every instruction and any (nested, nested(nested) > etc.) simulated instructions ALL get merged together in this one global > trace. > > I imagine the global trace table to be much like the printed traces that > PO posts over and over. If YOU can recognise some pattern in those > printed traces, then logically H can spot that same pattern in the > global trace, as the info in both cases is more or less the same. > When a UTM simulates TM description that invokes a UTM that simulates a TM description that invokes a UTM that simulates a TM description that invokes a UTM that simulates a TM description that invokes a UTM that simulates a TM description All of this whole process is data belongs to the first UTM, thus global data is not needed and the whole process is a computable function of the original inputs to the outermost UTM. > [Above is my best guess, based on previous PO answers before you were > interested.] > >> I assume the data segment of each process is private... > > PO said "new process context.." and that would imply each has its own > address space, and that is obviously how simulation is SUPPOSED to work > (like a TM would perform) - so your assumption is totally reasonable! My unlimited nested simulations could not function properly if I did not know all of the details of how to do this. > But you've made the basic mistake of assuming PO knows what a "process" > is - PO is not a software engineer or computer scientist, although he > does his utmost to give that impression! > > Anyhow, each PO-simulation is like a single-stepped thread within a > SINGLE shared address space, so any globals in his H are shared by all > his "independent" simulations. > > [Above is based on previous PO answers before you were interested.] > > Mike. -- 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-07 22:45 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ members of c/c++ ] |
| Message-ID | <V2UnK.13147$NAs.4573@fx04.iad> |
| In reply to | #52048 |
On 6/7/22 9:04 PM, olcott wrote: > On 6/7/2022 7:05 PM, Mike Terry wrote: >> On 07/06/2022 21:51, Mr Flibble wrote: >>> On Tue, 7 Jun 2022 15:34:13 -0500 >>> olcott <NoOne@NoWhere.com> wrote: >>> >> <..snip..> >>>> >>>> How many times do I have to say this before you notice that I said it >>>> at least once? H (in the current process) always creates a new >>>> process context to emulate its its input with an x86 emulator. >>> >>> I will have to take your word for it as you refuse to publish source >>> code. Why not just stick your project on GitHub? Open source is de >>> rigueur these days. What are you trying to hide? >>> >>> If a new process context is made then how is nested simulation >>> detected? >> >> The code in x86utm.exe (his emulator) that emulates individual >> instructions also updates a global trace table, making it accessible >> to the emulated code. So every instruction and any (nested, >> nested(nested) etc.) simulated instructions ALL get merged together in >> this one global trace. >> >> I imagine the global trace table to be much like the printed traces >> that PO posts over and over. If YOU can recognise some pattern in >> those printed traces, then logically H can spot that same pattern in >> the global trace, as the info in both cases is more or less the same. >> > > When a UTM simulates TM description > that invokes a UTM that simulates a TM description Nope, it invoke a copy of H that simulates its input and then abort is. > that invokes a UTM that simulates a TM description > that invokes a UTM that simulates a TM description > that invokes a UTM that simulates a TM description This appears to be a flaw in your whole system design, you P changes to call as H whatever you try to use to simulate it. P needs to call the H that this P is designed to refute, and no others. Remember, You need to pick *A* H that you are going to claim is a correct decider, then you make *A* P based on that one, and run the descion and test on THOSE SPECIIFIC machines. > > All of this whole process is data belongs to the first UTM, thus global > data is not needed and the whole process is a computable function of the > original inputs to the outermost UTM. ???? The input to the UTM is a description of a P that calls the H that you claim is correct in aborting its simulation of the P built on it. That UTM will simulate that input and generate the exact same results as running that P. That emulation will show the first 7 instructions of P, then the call to H, and then H doing its emulations and eventually aborting its emulaton and returning the 0 to P and P halting. If the H doesn't do this, then your H never answered H(P,P) as 0, and your whole premise is false, and shown to be a LIE. > >> [Above is my best guess, based on previous PO answers before you were >> interested.] >> >>> I assume the data segment of each process is private... >> >> PO said "new process context.." and that would imply each has its own >> address space, and that is obviously how simulation is SUPPOSED to >> work (like a TM would perform) - so your assumption is totally >> reasonable! > > My unlimited nested simulations could not function properly if I did not > know all of the details of how to do this. Then why do you think the UTM sees another UTM when it should see an H. Remember, your LIE that the test was to REPLACE H with a UTM has been discredited, or are you still claiming that is what needs to be done, even though it doesn't match the test you define? Or, do you not understand that the representation of P includes EVERYTHING needed to run it, and thus does include the copy of H that it calls, so it doesn't change when we give that input to the UTM? > >> But you've made the basic mistake of assuming PO knows what a >> "process" is - PO is not a software engineer or computer scientist, >> although he does his utmost to give that impression! >> >> Anyhow, each PO-simulation is like a single-stepped thread within a >> SINGLE shared address space, so any globals in his H are shared by all >> his "independent" simulations. >> >> [Above is based on previous PO answers before you were interested.] >> >> Mike. > >
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-06 17:49 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] |
| Message-ID | <20220606174952.00004643@reddwarf.jmc> |
| In reply to | #51968 |
On Sun, 5 Jun 2022 19:27:39 -0500 olcott <NoOne@NoWhere.com> wrote: > On 6/5/2022 6: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...) > > In other words when we make sure to conflate the program under test > with the test program as a single computation then the whole idea of > a halt decider becomes less coherent and I asserted that it is erroneous to conflate the decider with that which is being decided several months ago. No such conflation occurs in the HP proofs you are attempting to refute; it is your conflation which is erroneous. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-06 11:59 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Mike Terry ] |
| Message-ID | <ptmdnVtrKoXKrwP_nZ2dnUU7_839fwAA@giganews.com> |
| In reply to | #51998 |
On 6/6/2022 11:49 AM, Mr Flibble wrote: > On Sun, 5 Jun 2022 19:27:39 -0500 > olcott <NoOne@NoWhere.com> wrote: > >> On 6/5/2022 6: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...) >> >> In other words when we make sure to conflate the program under test >> with the test program as a single computation then the whole idea of >> a halt decider becomes less coherent and > > I asserted that it is erroneous to conflate the decider with that which > is being decided several months ago. No such conflation occurs in the > HP proofs you are attempting to refute; it is your conflation which is > erroneous. > > /Flibble > Did you notice that I was replying to Mike Terry? -- 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 | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 11:07 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <M6WdnbXOB-5RSQH_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51856 |
On 6/5/2022 9:46 AM, Mike Terry 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
>
> Regards,
> Mike.
>
That an aborted simulated has not reached a final state has not halted
is proven by the fact that your screwy reasoning would have to conclude
that an infinite loop halts.
*This is a Stipulative definition*
Computation that halts ... the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
A stipulative definition is a type of definition in which a new or
currently existing term is given a new specific meaning for the purposes
of argument or discussion in a given context.
https://en.wikipedia.org/wiki/Stipulative_definition
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]
--
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 17:12 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <20220605171210.00006bec@reddwarf.jmc> |
| In reply to | #51866 |
On Sun, 5 Jun 2022 11:07:38 -0500
olcott <NoOne@NoWhere.com> wrote:
> On 6/5/2022 9:46 AM, Mike Terry 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
> >
> > Regards,
> > Mike.
> >
>
> That an aborted simulated has not reached a final state has not
> halted is proven by the fact that your screwy reasoning would have to
> conclude that an infinite loop halts.
>
> *This is a Stipulative definition*
> Computation that halts ... the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> A stipulative definition is a type of definition in which a new or
> currently existing term is given a new specific meaning for the
> purposes of argument or discussion in a given context.
> https://en.wikipedia.org/wiki/Stipulative_definition
>
> 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]
You only call Infinite_Loop() if you detect a recursion
into your decider something that the proofs you are attempting to refute
do not do. What you have has nothing to do with the Halting Problem.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 11:15 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <H_adnUGxXfImSwH_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51868 |
On 6/5/2022 11:12 AM, Mr Flibble wrote:
> On Sun, 5 Jun 2022 11:07:38 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/5/2022 9:46 AM, Mike Terry 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
>>>
>>> Regards,
>>> Mike.
>>>
>>
>> That an aborted simulated has not reached a final state has not
>> halted is proven by the fact that your screwy reasoning would have to
>> conclude that an infinite loop halts.
>>
>> *This is a Stipulative definition*
>> Computation that halts ... the Turing machine will halt whenever it
>> enters a final state. (Linz:1990:234)
>>
>> A stipulative definition is a type of definition in which a new or
>> currently existing term is given a new specific meaning for the
>> purposes of argument or discussion in a given context.
>> https://en.wikipedia.org/wiki/Stipulative_definition
>>
>> 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]
>
> You only call Infinite_Loop() if you detect a recursion
> into your decider something that the proofs you are attempting to refute
> do not do. What you have has nothing to do with the Halting Problem.
>
> /Flibble
>
That you are simply not bright enough to see that the Linz proof does
specify infinitely nested simulation is really no actual rebuttal at all.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
When Ĥ is applied to ⟨Ĥ⟩ // subscripts indicate unique finite strings
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
Then these steps would keep repeating: (unless their simulation is aborted)
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
--
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 12:45 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <u45nK.65105$ntj.6416@fx15.iad> |
| In reply to | #51869 |
On 6/5/22 12:15 PM, olcott wrote:
> On 6/5/2022 11:12 AM, Mr Flibble wrote:
>> On Sun, 5 Jun 2022 11:07:38 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/5/2022 9:46 AM, Mike Terry 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
>>>>
>>>> Regards,
>>>> Mike.
>>>
>>> That an aborted simulated has not reached a final state has not
>>> halted is proven by the fact that your screwy reasoning would have to
>>> conclude that an infinite loop halts.
>>>
>>> *This is a Stipulative definition*
>>> Computation that halts ... the Turing machine will halt whenever it
>>> enters a final state. (Linz:1990:234)
>>>
>>> A stipulative definition is a type of definition in which a new or
>>> currently existing term is given a new specific meaning for the
>>> purposes of argument or discussion in a given context.
>>> https://en.wikipedia.org/wiki/Stipulative_definition
>>>
>>> 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]
>>
>> You only call Infinite_Loop() if you detect a recursion
>> into your decider something that the proofs you are attempting to refute
>> do not do. What you have has nothing to do with the Halting Problem.
>>
>> /Flibble
>>
>
> That you are simply not bright enough to see that the Linz proof does
> specify infinitely nested simulation is really no actual rebuttal at all.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
> state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
> When Ĥ is applied to ⟨Ĥ⟩ // subscripts indicate unique finite strings
> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>
> Then these steps would keep repeating: (unless their simulation is aborted)
> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...
>
>
And, if it DOES keep repeating as you claim, then H NEVER aborts its
simulation, and thus fails to answer.
If H does abort its simulation, then the pattern does NOT keep
repeating, because the H used by H^ will also abort its own simulation
and break the infinte chain.
The H simulating that input just doesn't get to that point before it
aborts it simulation.
You proof somewhat boils down to claiming there exists a N > N+5, which
just isn't true.
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.theory
csiph-web