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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-04 13:37 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] |
| Message-ID | <KeadnTPlxbPwOwb_nZ2dnUU7_8zNnZ2d@giganews.com> |
| In reply to | #51817 |
On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>
>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>
> [ .... ]
>
>>> You've got nested simulations.
>>> If H detects them as infinitely nested, and aborts, they are no longer
>>> infinitely nested, so it gets the wrong answer (as happens here).
>
>> I can't understand how you can be so wrong about this. It is like you
>> make sure to never read anything that I say before spouting off a canned
>> rebuttal.
>
> I frequently read what you say. It's dull and repetitive. And wrong.
>
>> 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]
>
>> In the same way that H0 detects .....
>
> We don't know what H0 detects, since its code is secret, and probably
> doesn't exist.
>
That software engineering confirms that such an H0 could exist is
sufficient proof that H0 does exist whether or not it is encoded.
It is encoded.
>> .... that the complete x86 emulation of _Infinite_Loop() would never
>> reach its final "ret" instruction H(P,P) on the basis of a partial
>> simulation H(P,P) detects that the complete x86 emulation of its input
>> would never reach its final "ret" instruction.
>
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>
> Yes. It's dull and repetitive and wrong. If it were correct, you would
> only need to say it once, and it would be accepted and acknowledged by
> the experts in this group.
Not with the damned liars on this forum that are only interested in
rebuttal and don't give a rat's ass about the truth.
>
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>
> In this context, it does.
>
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>
> A turing machine runs until it halts. Terminated "normally" has no
> meaning.
So you are saying that the term "terminated normally" is complete
gibberish to every software engineer? Why do you lie about this?
> That is one reason you avoid turing machines. They make things
> too clear and well defined, leaving you no room to argue stupidities like
> "halting doesn't mean stops running".
Computation that halts ... 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.
--
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-04 14:54 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] |
| Message-ID | <BTNmK.47061$X_i.40601@fx18.iad> |
| In reply to | #51823 |
On 6/4/22 2:37 PM, olcott wrote:
> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>>
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>
>> [ .... ]
>>
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no longer
>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a canned
>>> rebuttal.
>>
>> I frequently read what you say. It's dull and repetitive. And wrong.
>>
>>> 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]
>>
>>> In the same way that H0 detects .....
>>
>> We don't know what H0 detects, since its code is secret, and probably
>> doesn't exist.
>>
>
> That software engineering confirms that such an H0 could exist is
> sufficient proof that H0 does exist whether or not it is encoded.
> It is encoded.
And it is well know that a limited halt decider to detect programs like
that can exist. But that doesn't show that the needed H to decide P does.
>
>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>> would never reach its final "ret" instruction.
>>
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>
>> Yes. It's dull and repetitive and wrong. If it were correct, you would
>> only need to say it once, and it would be accepted and acknowledged by
>> the experts in this group.
>
> Not with the damned liars on this forum that are only interested in
> rebuttal and don't give a rat's ass about the truth.
You mean the one named Peter Olcott?
He is the biggest liar on the forum.
>
>>
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>
>> In this context, it does.
>>
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>
>> A turing machine runs until it halts. Terminated "normally" has no
>> meaning.
>
> So you are saying that the term "terminated normally" is complete
> gibberish to every software engineer? Why do you lie about this?
>
>> That is one reason you avoid turing machines. They make things
>> too clear and well defined, leaving you no room to argue stupidities like
>> "halting doesn't mean stops running".
>
> Computation that halts ... 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.
>
>
Right, so to show non-halting, you need to show that if you run the
machine for an unbounded number of steps, it will not reach a final state.
P(P), the machine in question, reaches its final state in a finite
number of steps if H(P,P) returns 0, so that H is wrong.
If H(P,P) doesn't return 0, it fails to be a decider.
THus, you have proved that you method can't create an H that correctly
decides the P built on it.
All you have shown is that your H can't actually prove this either, but
always gets it wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-04 14:01 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] |
| Message-ID | <PoqdnWk6MOqXMQb_nZ2dnUU7_8xh4p2d@giganews.com> |
| In reply to | #51827 |
On 6/4/2022 1:54 PM, Richard Damon wrote:
> On 6/4/22 2:37 PM, olcott wrote:
>> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>>> [ Followup-To: set ]
>>>
>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>
>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>
>>> [ .... ]
>>>
>>>>> You've got nested simulations.
>>>>> If H detects them as infinitely nested, and aborts, they are no longer
>>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>>
>>>> I can't understand how you can be so wrong about this. It is like you
>>>> make sure to never read anything that I say before spouting off a
>>>> canned
>>>> rebuttal.
>>>
>>> I frequently read what you say. It's dull and repetitive. And wrong.
>>>
>>>> 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]
>>>
>>>> In the same way that H0 detects .....
>>>
>>> We don't know what H0 detects, since its code is secret, and probably
>>> doesn't exist.
>>>
>>
>> That software engineering confirms that such an H0 could exist is
>> sufficient proof that H0 does exist whether or not it is encoded.
>> It is encoded.
>
> And it is well know that a limited halt decider to detect programs like
> that can exist. But that doesn't show that the needed H to decide P does.
>
>>
>>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>>> would never reach its final "ret" instruction.
>>>
>>>> Did you notice that I said this 500 times already?
>>>> Did you notice that I said this 500 times already?
>>>> Did you notice that I said this 500 times already?
>>>
>>> Yes. It's dull and repetitive and wrong. If it were correct, you would
>>> only need to say it once, and it would be accepted and acknowledged by
>>> the experts in this group.
>>
>> Not with the damned liars on this forum that are only interested in
>> rebuttal and don't give a rat's ass about the truth.
>
> You mean the one named Peter Olcott?
>
> He is the biggest liar on the forum.
>>
>>>
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>
>>> In this context, it does.
>>>
>>>> HALTING MEANS TERMINATED NORMALLY
>>>> HALTING MEANS TERMINATED NORMALLY
>>>> HALTING MEANS TERMINATED NORMALLY
>>>
>>> A turing machine runs until it halts. Terminated "normally" has no
>>> meaning.
>>
>> So you are saying that the term "terminated normally" is complete
>> gibberish to every software engineer? Why do you lie about this?
>>
>>> That is one reason you avoid turing machines. They make things
>>> too clear and well defined, leaving you no room to argue stupidities
>>> like
>>> "halting doesn't mean stops running".
>>
>> Computation that halts ... 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.
>>
>>
>
> Right, so to show non-halting, you need to show that if you run the
> machine for an unbounded number of steps, it will not reach a final state.
THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
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 x86 emulation of this input by H.
--
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-04 15:57 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] |
| Message-ID | <2POmK.42943$elob.36450@fx43.iad> |
| In reply to | #51828 |
On 6/4/22 3:01 PM, olcott wrote:
> On 6/4/2022 1:54 PM, Richard Damon wrote:
>> On 6/4/22 2:37 PM, olcott wrote:
>>> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>>>> [ Followup-To: set ]
>>>>
>>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>
>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>
>>>> [ .... ]
>>>>
>>>>>> You've got nested simulations.
>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>> longer
>>>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>>>
>>>>> I can't understand how you can be so wrong about this. It is like you
>>>>> make sure to never read anything that I say before spouting off a
>>>>> canned
>>>>> rebuttal.
>>>>
>>>> I frequently read what you say. It's dull and repetitive. And wrong.
>>>>
>>>>> 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]
>>>>
>>>>> In the same way that H0 detects .....
>>>>
>>>> We don't know what H0 detects, since its code is secret, and probably
>>>> doesn't exist.
>>>>
>>>
>>> That software engineering confirms that such an H0 could exist is
>>> sufficient proof that H0 does exist whether or not it is encoded.
>>> It is encoded.
>>
>> And it is well know that a limited halt decider to detect programs
>> like that can exist. But that doesn't show that the needed H to decide
>> P does.
>>
>>>
>>>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>>>> would never reach its final "ret" instruction.
>>>>
>>>>> Did you notice that I said this 500 times already?
>>>>> Did you notice that I said this 500 times already?
>>>>> Did you notice that I said this 500 times already?
>>>>
>>>> Yes. It's dull and repetitive and wrong. If it were correct, you
>>>> would
>>>> only need to say it once, and it would be accepted and acknowledged by
>>>> the experts in this group.
>>>
>>> Not with the damned liars on this forum that are only interested in
>>> rebuttal and don't give a rat's ass about the truth.
>>
>> You mean the one named Peter Olcott?
>>
>> He is the biggest liar on the forum.
>>>
>>>>
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>
>>>> In this context, it does.
>>>>
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>
>>>> A turing machine runs until it halts. Terminated "normally" has no
>>>> meaning.
>>>
>>> So you are saying that the term "terminated normally" is complete
>>> gibberish to every software engineer? Why do you lie about this?
>>>
>>>> That is one reason you avoid turing machines. They make things
>>>> too clear and well defined, leaving you no room to argue stupidities
>>>> like
>>>> "halting doesn't mean stops running".
>>>
>>> Computation that halts ... 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.
>>>
>>>
>>
>> Right, so to show non-halting, you need to show that if you run the
>> machine for an unbounded number of steps, it will not reach a final
>> state.
>
> THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
> 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 x86 emulation of this input by H.
>
So, since you say "the actual behavior specifed by the actual input
measured by the correct x86 emulation of this input by H", do you mean
that it must actually match the ACTUAL correct x86 behavior of the
machine the input specifies (independent of what H does?, what else does
the first actual behavior clause refer to) or are you putting a
restrirction on H that its emulation must match the actual behavior of
the input based on the actual behaviof specified by an x86 processor
running that input? or are you adding "escape" clauses to mean that
"correct" doesn't need to be actually "correct'?
You have a few too many "correct"s.
As has been shown, P(P), which is what the ACTUAL BEHAVIOR of the input
would be if correctly emulated, will Halt if H(P,P) returns 0.
This means that the ONLY correct answer for H(P,P), if H(P,P) actually
returns 0 would be 1, so it is wrong.
Of course, since you aren't quoting the ACTUAL definition of the Halting
Problem, you also need to prove that you version is equivalent, which is
ultimately your problem, because you actually REJECT that actual
definition, but can't say that as you can't refute what you aren't
working on.
The fact that you are adding a bunch of extraneous words to the
statement is just your attempt to hide the fact that you aren't actually
wanting to look at the actual definition of the halting problem, but
trying to replace the actual behavior specified by the input (which is
the behavior of the machine described as itself) with a PARTIAL
simulation by H, which fails to meet the "correct" requriement.
YOU FAIL.
[toc] | [prev] | [next] | [standalone]
| From | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2022-06-04 19:02 +0000 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Alan Mackenzie ] |
| Message-ID | <t7ga8l$142m$2@news.muc.de> |
| In reply to | #51823 |
[ Newsgroups: trimmed. ]
In comp.theory olcott <NoOne@nowhere.com> wrote:
> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>> [ .... ]
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no
>>>> longer infinitely nested, so it gets the wrong answer (as happens
>>>> here).
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a
>>> canned rebuttal.
>> I frequently read what you say. It's dull and repetitive. And wrong.
>>> 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]
>>> In the same way that H0 detects .....
>> We don't know what H0 detects, since its code is secret, and probably
>> doesn't exist.
> That software engineering confirms that such an H0 could exist is
> sufficient proof that H0 does exist whether or not it is encoded.
> It is encoded.
"Such" an H0 has not been defined. You don't say what you mean by H0.
Whatever it is, even if it "could" exist is no proof that it does exist.
Given your propensity for being poetic with the truth, I (like everybody
else here) am sceptical about its existence. Even if it does exist, it
is likely you misunderstand its implications.
>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>> simulation H(P,P) detects that the complete x86 emulation of its
>>> input would never reach its final "ret" instruction.
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>> Yes. It's dull and repetitive and wrong. If it were correct, you
>> would only need to say it once, and it would be accepted and
>> acknowledged by the experts in this group.
> Not with the damned liars on this forum that are only interested in
> rebuttal and don't give a rat's ass about the truth.
They are profoundly interested in the truth, and that is the only
motivation for them having to tolerate your dullness, your falsehoods and
your abuse.
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>> In this context, it does.
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>> A turing machine runs until it halts. Terminated "normally" has no
>> meaning.
> So you are saying that the term "terminated normally" is complete
> gibberish to every software engineer?
Kindly read what I write if you want to know what I am saying. In the
context of turing machines, "terminated normally" has no meaning.
> Why do you lie about this?
Get this straight, I don't lie on Usenet. Neither do I get poetic with
the truth. I can make mistakes. The above is not one of these mistakes.
>> That is one reason you avoid turing machines. They make things
>> too clear and well defined, leaving you no room to argue stupidities like
>> "halting doesn't mean stops running".
[ .... ]
> --
> Copyright 2022 Pete Olcott
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer
--
Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-04 14:28 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <RaadnXFvdY_OLwb_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51817 |
On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>
>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>
> [ .... ]
>
>>> You've got nested simulations.
>>> If H detects them as infinitely nested, and aborts, they are no longer
>>> infinitely nested, so it gets the wrong answer (as happens here).
>
>> I can't understand how you can be so wrong about this. It is like you
>> make sure to never read anything that I say before spouting off a canned
>> rebuttal.
>
> I frequently read what you say. It's dull and repetitive. And wrong.
>
>> 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]
>
>> In the same way that H0 detects .....
>
> We don't know what H0 detects, since its code is secret, and probably
> doesn't exist.
>
>> .... that the complete x86 emulation of _Infinite_Loop() would never
>> reach its final "ret" instruction H(P,P) on the basis of a partial
>> simulation H(P,P) detects that the complete x86 emulation of its input
>> would never reach its final "ret" instruction.
>
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>
> Yes. It's dull and repetitive and wrong. If it were correct, you would
> only need to say it once, and it would be accepted and acknowledged by
> the experts in this group.
>
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>
> In this context, it does.
>
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>
> A turing machine runs until it halts. Terminated "normally" has no
> meaning.
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.
> That is one reason you avoid turing machines. They make things
> too clear and well defined, leaving you no room to argue stupidities like
> "halting doesn't mean stops running".
The reason that I avoid Turing machines is that 99% of the most
important details cannot be fully expressed or analyzed. After all of
these details are fully understood then it is very easy to apply the
same reasoning to the Linz proof as I have done in my paper.
Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
--
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-04 16:05 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <mWOmK.107946$JVi.1087@fx17.iad> |
| In reply to | #51831 |
On 6/4/22 3:28 PM, olcott wrote:
> On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
>> [ Followup-To: set ]
>>
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>
>> [ .... ]
>>
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no longer
>>>> infinitely nested, so it gets the wrong answer (as happens here).
>>
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a canned
>>> rebuttal.
>>
>> I frequently read what you say. It's dull and repetitive. And wrong.
>>
>>> 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]
>>
>>> In the same way that H0 detects .....
>>
>> We don't know what H0 detects, since its code is secret, and probably
>> doesn't exist.
>>
>>> .... that the complete x86 emulation of _Infinite_Loop() would never
>>> reach its final "ret" instruction H(P,P) on the basis of a partial
>>> simulation H(P,P) detects that the complete x86 emulation of its input
>>> would never reach its final "ret" instruction.
>>
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>
>> Yes. It's dull and repetitive and wrong. If it were correct, you would
>> only need to say it once, and it would be accepted and acknowledged by
>> the experts in this group.
>>
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>
>> In this context, it does.
>>
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>
>> A turing machine runs until it halts. Terminated "normally" has no
>> meaning.
>
> 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.
>
Yes, it appears that Linz is using the notation that any unspecified
transition is the signal that the machine halts where it is, as opposed
to the notation with a defined set of final states (which have no
transitions specified, and all other states have ALL transitions
specified). These are "equivalent" descriptions in terms of computing
power unless you are playing Turing Golf and scoring based on the "size"
of the Turing Machine.
> When translated into ordinary software engineering terms this means
> terminated normally. In a C function this means reaching the "ret"
> instruction.
>
>> That is one reason you avoid turing machines. They make things
>> too clear and well defined, leaving you no room to argue stupidities like
>> "halting doesn't mean stops running".
>
> The reason that I avoid Turing machines is that 99% of the most
> important details cannot be fully expressed or analyzed. After all of
> these details are fully understood then it is very easy to apply the
> same reasoning to the Linz proof as I have done in my paper.
No, you avoid them because you can't pull the shenanagians with them
that you do with your x86 code. The key here is that a Turing Machine,
by its very nature, can only be a computation, while x86 code fragments
can easily be non-computations. By all appearances, you decider H is NOT
actually a computation, and the only way for you to actually prove it is
would be to let others inspect your code, but that would let the cat out
of the bag (which you will probably call a dog).
I suspect that also, you just don't understand how a Turing Machine
actually works, because you are such a poor programmer you can't deal
with a machine that won't take your dirty tricks. Maybe the issue is you
have tried to code your trick as a Turing Machine, and because you can't
make a non-computation out of one, you just failed and don't want to
admit that you are just being a cheater.
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Jeff Barnett <jbb@notatt.com> |
|---|---|
| Date | 2022-06-04 17:30 -0600 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] [OT] |
| Message-ID | <t7gpvi$gn5$1@dont-email.me> |
| In reply to | #51834 |
On 6/4/2022 2:05 PM, Richard Damon wrote:
<SNIP>
> Yes, it appears that Linz is using the notation that any unspecified
> transition is the signal that the machine halts where it is, as opposed
> to the notation with a defined set of final states (which have no
> transitions specified, and all other states have ALL transitions
> specified). These are "equivalent" descriptions in terms of computing
> power unless you are playing Turing Golf and scoring based on the "size"
> of the Turing Machine.
The normal game is scored by the product of the number of states and the
size of the tape (as opposed to the input) alphabet.
--
Jeff Barnett
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2022-06-05 13:14 +0300 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7hvlv$5e5$1@dont-email.me> |
| In reply to | #51831 |
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
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 05:34 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <rcSdncOuUMYvGwH_nZ2dnUU7_81g4p2d@giganews.com> |
| In reply to | #51848 |
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. -- 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 | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2022-06-05 11:12 +0000 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <t7i32v$j5n$1@news.muc.de> |
| In reply to | #51849 |
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? It can only be the TM having halted. So a TM final state is equivalent to a C program's termination, whether by a ret instruction or a halt instruction or anything else. > -- > Copyright 2022 Pete Olcott > "Talent hits a target no one else can hit; > Genius hits a target no one else can see." > Arthur Schopenhauer -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <NoOne@NoWhere.com> |
|---|---|
| Date | 2022-06-05 06:21 -0500 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <V4qdnY-VjKcsDAH_nZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #51850 |
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.
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.
Therefore H(P,P)==0 is correct.
> It can only be the TM having halted. So a TM final
> state is equivalent to a C program's termination, whether by a ret
> instruction or a halt instruction or anything else.
>
>> --
>> Copyright 2022 Pete Olcott
>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
--
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 07:58 -0400 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <TT0nK.107168$45E8.72348@fx47.iad> |
| In reply to | #51851 |
On 6/5/22 7:21 AM, olcott 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.
No, you have things backwards. Turing Machine behavior is NOT based on
simulating the machines, but on just running them. Simulation is a way
to see what a given machine would do if you don't actually have the
machine available.
Turing Machine NEVER stop running until they reach their final state,
and thus, the ONLY way they "terminate" is what you call "normally
terminate", so the term normally is extraneous.
Any other form of "termination" that a simulator creates is just proof
that the simulation wasn't accurate, or in simpler terems WRONG.
Part of your problem seems to be an inability to handle abstractions.
Turing Machines are DEFINED by abstract properties. You can't actually
"build" a physical Turing Machine, only a model of one. But to
mathematics, they exist. Sort of like how the number Pi has an exact
value, but you can never actually express it (because it takes an
infinite number of digits).
>
> 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.
But what happens when the simulation never matches a pattern that is
actually infinite behavior?
Your simulator will just run forever (and fail to be a decider) as
appears to happen with your H.
If it allows itself to abort the simulation (and thus its simulation is
no longer actually accurate) on a pattern that it just THINKS shows
infinite behavior it can be wrong. Note, when we give the input to a
"better" simulator, one that doesn't try to that pattern, it WILL run to
completion and halt.
(Note, P still calls the original H, not this better simulator)
>
> #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.
No, since H is DEFINED to abort its simulation, it is DEFINED to NOT do
a CORRECT emulation of its input.
That is like saying it is obvious that your dog is a cat.
Note also, the seventh instruction is being misinterpreted. It does NOT
"Just repeat the process", that would be it actually CALLED P(P) instead
of calling H(P,P).
Conditional simulation is NOT the equivalent of direct execution (and if
the simulation isn't conditional, they you can't talk about it doing
things like aborting its simulation on some condition).
The CORRECT emulation of this input would emulate the emulator, and the
trace needs to be showing that, and all the aspects related to that.
Working from wrong data gives wrong answers.
>
> Therefore H(P,P)==0 is correct.
Nope. That statement shows your stupiditiy.
THat fact that YOU AGREE that P(P) halts when H(P,P) returns 0, means
that you KNOW that, if H actually is defined to be a Halt Decider, this
answer is wrong.
The fact that you persist in making the claim shows that either you are
a pathological liar, or suffer from a mental deficiency that allows you
to ignore the cognitive dissonance of your statement, or you are so
ignorant you don't understand anything about what you are talking.
The Non-Halting answer can not be right for an input you know Halts.
>
>> It can only be the TM having halted. So a TM final
>> state is equivalent to a C program's termination, whether by a ret
>> instruction or a halt instruction or anything else.
>>
>>> --
>>> 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 14:47 +0100 |
| Subject | Re: Refuting the HP proofs (adapted for software engineers)[ Andy Walker ] |
| Message-ID | <20220605144720.0000277a@reddwarf.jmc> |
| In reply to | #51852 |
On Sun, 5 Jun 2022 07:58:42 -0400 Richard Damon <Richard@Damon-Family.org> wrote: > On 6/5/22 7:21 AM, olcott 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. > > No, you have things backwards. Turing Machine behavior is NOT based > on simulating the machines, but on just running them. Simulation is a > way to see what a given machine would do if you don't actually have > the machine available. > > Turing Machine NEVER stop running until they reach their final state, > and thus, the ONLY way they "terminate" is what you call "normally > terminate", so the term normally is extraneous. > > Any other form of "termination" that a simulator creates is just > proof that the simulation wasn't accurate, or in simpler terems WRONG. > > Part of your problem seems to be an inability to handle abstractions. > Turing Machines are DEFINED by abstract properties. You can't > actually "build" a physical Turing Machine, only a model of one. But > to mathematics, they exist. Sort of like how the number Pi has an > exact value, but you can never actually express it (because it takes > an infinite number of digits). PI does not have an exact value; no irrational number has an exact value. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Andy Walker <anw@cuboid.co.uk> |
|---|---|
| Date | 2022-06-05 16:28 +0100 |
| Message-ID | <t7ii25$1ohb$1@gioia.aioe.org> |
| In reply to | #51855 |
On 05/06/2022 14:47, Mr Flibble wrote:
> On Sun, 5 Jun 2022 07:58:42 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>> [...] Sort of like how the number Pi has an
>> exact value, but you can never actually express it (because it takes
>> an infinite number of digits).
> PI does not have an exact value; no irrational number has an exact
> value.
Of course "pi" has an exact value; as do [eg] "sqrt(2)", "e", and all
the other computable real [and complex] numbers. Whether that value can be
expressed in finite terms in some particular representation is quite another
matter. That in turn depends on the representation; standard decimals is
merely one [common] choice. Note that in symbolic computer systems, those
computable reals are typically written "pi" [or whatever], and the computer
works with that exactly, so that [eg] "sin^2 (pi/3) == 3/4", not 0.7499...;
and also that in decimal-type notations most rationals equally have no
terminating expansion. Numbers such as "pi" and "sqrt(2)" are not defined
as decimal expansions but via their properties [eg that "sqrt(2)" is the
unique positive real whose square is 2, or equivalently that it is the
ratio of the diagonal of a square to its side, and "pi" is the least
positive real whose sine is zero]. Those properties are exact, and tell
you all you ever need to know about those numbers.
[I have removed my name from the "Subject:"; I don't know why
anyone saw fit to attach it to this debate, such as it is, on the HP.]
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Palmgren
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-05 16:34 +0100 |
| Message-ID | <20220605163408.00005e3f@reddwarf.jmc> |
| In reply to | #51860 |
On Sun, 5 Jun 2022 16:28:05 +0100 Andy Walker <anw@cuboid.co.uk> wrote: > On 05/06/2022 14:47, Mr Flibble wrote: > > On Sun, 5 Jun 2022 07:58:42 -0400 > > Richard Damon <Richard@Damon-Family.org> wrote: > >> [...] Sort of like how the number Pi has an > >> exact value, but you can never actually express it (because it > >> takes an infinite number of digits). > > PI does not have an exact value; no irrational number has an exact > > value. > > Of course "pi" has an exact value; as do [eg] "sqrt(2)", > "e", and all the other computable real [and complex] numbers. > Whether that value can be expressed in finite terms in some > particular representation is quite another matter. That in turn > depends on the representation; standard decimals is merely one > [common] choice. Note that in symbolic computer systems, those > computable reals are typically written "pi" [or whatever], and the > computer works with that exactly, so that [eg] "sin^2 (pi/3) == 3/4", > not 0.7499...; and also that in decimal-type notations most rationals > equally have no terminating expansion. Numbers such as "pi" and > "sqrt(2)" are not defined as decimal expansions but via their > properties [eg that "sqrt(2)" is the unique positive real whose > square is 2, or equivalently that it is the ratio of the diagonal of > a square to its side, and "pi" is the least positive real whose sine > is zero]. Those properties are exact, and tell you all you ever need > to know about those numbers. > > [I have removed my name from the "Subject:"; I don't know why > anyone saw fit to attach it to this debate, such as it is, on the HP.] What has decimal (base 10) expansion got to do with anything? An irrational number has a non-terminating sequence in ANY base. I am sorry but you are simply mistaken: irrational numbers do NOT have an exact value; this is obvious to anyone who understands logic and uses a sane definition for infinity. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2022-06-05 15:44 +0000 |
| Message-ID | <t7ij10$1qaq$2@news.muc.de> |
| In reply to | #51861 |
Mr Flibble <flibble@reddwarf.jmc> wrote: > On Sun, 5 Jun 2022 16:28:05 +0100 > Andy Walker <anw@cuboid.co.uk> wrote: >> On 05/06/2022 14:47, Mr Flibble wrote: >> > On Sun, 5 Jun 2022 07:58:42 -0400 >> > Richard Damon <Richard@Damon-Family.org> wrote: >> >> [...] Sort of like how the number Pi has an >> >> exact value, but you can never actually express it (because it >> >> takes an infinite number of digits). >> > PI does not have an exact value; no irrational number has an exact >> > value. >> Of course "pi" has an exact value; as do [eg] "sqrt(2)", >> "e", and all the other computable real [and complex] numbers. >> Whether that value can be expressed in finite terms in some >> particular representation is quite another matter. That in turn >> depends on the representation; standard decimals is merely one >> [common] choice. Note that in symbolic computer systems, those >> computable reals are typically written "pi" [or whatever], and the >> computer works with that exactly, so that [eg] "sin^2 (pi/3) == 3/4", >> not 0.7499...; and also that in decimal-type notations most rationals >> equally have no terminating expansion. Numbers such as "pi" and >> "sqrt(2)" are not defined as decimal expansions but via their >> properties [eg that "sqrt(2)" is the unique positive real whose >> square is 2, or equivalently that it is the ratio of the diagonal of >> a square to its side, and "pi" is the least positive real whose sine >> is zero]. Those properties are exact, and tell you all you ever need >> to know about those numbers. [ .... ] > What has decimal (base 10) expansion got to do with anything? An > irrational number has a non-terminating sequence in ANY base. I am > sorry but you are simply mistaken: irrational numbers do NOT have an > exact value; this is obvious to anyone who understands logic and uses > a sane definition for infinity. That irrational numbers are exact values is clear to anybody with a degree in maths. Definitions of "infinity" (of which there are many) have nothing to do with this. > /Flibble -- Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-05 16:49 +0100 |
| Message-ID | <20220605164927.0000148a@reddwarf.jmc> |
| In reply to | #51862 |
On Sun, 5 Jun 2022 15:44:32 -0000 (UTC)
Alan Mackenzie <acm@muc.de> wrote:
> Mr Flibble <flibble@reddwarf.jmc> wrote:
> > On Sun, 5 Jun 2022 16:28:05 +0100
> > Andy Walker <anw@cuboid.co.uk> wrote:
>
> >> On 05/06/2022 14:47, Mr Flibble wrote:
> >> > On Sun, 5 Jun 2022 07:58:42 -0400
> >> > Richard Damon <Richard@Damon-Family.org> wrote:
> >> >> [...] Sort of like how the number Pi has an
> >> >> exact value, but you can never actually express it (because it
> >> >> takes an infinite number of digits).
> >> > PI does not have an exact value; no irrational number has an
> >> > exact value.
>
> >> Of course "pi" has an exact value; as do [eg] "sqrt(2)",
> >> "e", and all the other computable real [and complex] numbers.
> >> Whether that value can be expressed in finite terms in some
> >> particular representation is quite another matter. That in turn
> >> depends on the representation; standard decimals is merely one
> >> [common] choice. Note that in symbolic computer systems, those
> >> computable reals are typically written "pi" [or whatever], and the
> >> computer works with that exactly, so that [eg] "sin^2 (pi/3) ==
> >> 3/4", not 0.7499...; and also that in decimal-type notations most
> >> rationals equally have no terminating expansion. Numbers such as
> >> "pi" and "sqrt(2)" are not defined as decimal expansions but via
> >> their properties [eg that "sqrt(2)" is the unique positive real
> >> whose square is 2, or equivalently that it is the ratio of the
> >> diagonal of a square to its side, and "pi" is the least positive
> >> real whose sine is zero]. Those properties are exact, and tell
> >> you all you ever need to know about those numbers.
>
> [ .... ]
>
> > What has decimal (base 10) expansion got to do with anything? An
> > irrational number has a non-terminating sequence in ANY base. I am
> > sorry but you are simply mistaken: irrational numbers do NOT have an
> > exact value; this is obvious to anyone who understands logic and
> > uses a sane definition for infinity.
>
> That irrational numbers are exact values is clear to anybody with a
> degree in maths. Definitions of "infinity" (of which there are many)
> have nothing to do with this.
You are wrong and fractally so so your degree in maths appears to be
worthless. An irrational number's sequence is statistically random,
has no fixed point on the number line ergo has no exact representation.
Any number with no exact representation has, by definition, no exact
value, only an approximation. Infinity has everything to do with this
as an irrational's sequence ("digits") never terminates (i.e. it is an
INFINITELY long sequence).
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-06-05 12:22 -0400 |
| Message-ID | <qL4nK.40210$ssF.18716@fx14.iad> |
| In reply to | #51863 |
On 6/5/22 11:49 AM, Mr Flibble wrote:
> On Sun, 5 Jun 2022 15:44:32 -0000 (UTC)
> Alan Mackenzie <acm@muc.de> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>> On Sun, 5 Jun 2022 16:28:05 +0100
>>> Andy Walker <anw@cuboid.co.uk> wrote:
>>
>>>> On 05/06/2022 14:47, Mr Flibble wrote:
>>>>> On Sun, 5 Jun 2022 07:58:42 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>> [...] Sort of like how the number Pi has an
>>>>>> exact value, but you can never actually express it (because it
>>>>>> takes an infinite number of digits).
>>>>> PI does not have an exact value; no irrational number has an
>>>>> exact value.
>>
>>>> Of course "pi" has an exact value; as do [eg] "sqrt(2)",
>>>> "e", and all the other computable real [and complex] numbers.
>>>> Whether that value can be expressed in finite terms in some
>>>> particular representation is quite another matter. That in turn
>>>> depends on the representation; standard decimals is merely one
>>>> [common] choice. Note that in symbolic computer systems, those
>>>> computable reals are typically written "pi" [or whatever], and the
>>>> computer works with that exactly, so that [eg] "sin^2 (pi/3) ==
>>>> 3/4", not 0.7499...; and also that in decimal-type notations most
>>>> rationals equally have no terminating expansion. Numbers such as
>>>> "pi" and "sqrt(2)" are not defined as decimal expansions but via
>>>> their properties [eg that "sqrt(2)" is the unique positive real
>>>> whose square is 2, or equivalently that it is the ratio of the
>>>> diagonal of a square to its side, and "pi" is the least positive
>>>> real whose sine is zero]. Those properties are exact, and tell
>>>> you all you ever need to know about those numbers.
>>
>> [ .... ]
>>
>>> What has decimal (base 10) expansion got to do with anything? An
>>> irrational number has a non-terminating sequence in ANY base. I am
>>> sorry but you are simply mistaken: irrational numbers do NOT have an
>>> exact value; this is obvious to anyone who understands logic and
>>> uses a sane definition for infinity.
>>
>> That irrational numbers are exact values is clear to anybody with a
>> degree in maths. Definitions of "infinity" (of which there are many)
>> have nothing to do with this.
>
> You are wrong and fractally so so your degree in maths appears to be
> worthless. An irrational number's sequence is statistically random,
> has no fixed point on the number line ergo has no exact representation.
> Any number with no exact representation has, by definition, no exact
> value, only an approximation. Infinity has everything to do with this
> as an irrational's sequence ("digits") never terminates (i.e. it is an
> INFINITELY long sequence).
>
> /Flibble
>
Nope. Irrational numbers DO have exact points on the number line.
And what does representation have to do with exact value?
Also, irrational numbers sequence of digits are not necessarily
statistically random, in some representations, they can be VERY
predictible for some numbers.
One simple construction to show exact position, draw a box with sides
exactly 1.
Draw a line though opposite corners and make one point the value 0.
The other corner will be EXACTLY at the point sqrt(2), so that
irrational number has an exact point on the number line.
You just don't understand what an exact value means, likely because you
can't understand things that are somewhat abstract.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Date | 2022-06-05 17:28 +0100 |
| Message-ID | <20220605172829.000011ad@reddwarf.jmc> |
| In reply to | #51871 |
On Sun, 5 Jun 2022 12:22:45 -0400
Richard Damon <Richard@Damon-Family.org> wrote:
> On 6/5/22 11:49 AM, Mr Flibble wrote:
> > On Sun, 5 Jun 2022 15:44:32 -0000 (UTC)
> > Alan Mackenzie <acm@muc.de> wrote:
> >
> >> Mr Flibble <flibble@reddwarf.jmc> wrote:
> >>> On Sun, 5 Jun 2022 16:28:05 +0100
> >>> Andy Walker <anw@cuboid.co.uk> wrote:
> >>
> >>>> On 05/06/2022 14:47, Mr Flibble wrote:
> >>>>> On Sun, 5 Jun 2022 07:58:42 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>> [...] Sort of like how the number Pi has an
> >>>>>> exact value, but you can never actually express it (because it
> >>>>>> takes an infinite number of digits).
> >>>>> PI does not have an exact value; no irrational number has an
> >>>>> exact value.
> >>
> >>>> Of course "pi" has an exact value; as do [eg] "sqrt(2)",
> >>>> "e", and all the other computable real [and complex] numbers.
> >>>> Whether that value can be expressed in finite terms in some
> >>>> particular representation is quite another matter. That in turn
> >>>> depends on the representation; standard decimals is merely one
> >>>> [common] choice. Note that in symbolic computer systems, those
> >>>> computable reals are typically written "pi" [or whatever], and
> >>>> the computer works with that exactly, so that [eg] "sin^2 (pi/3)
> >>>> == 3/4", not 0.7499...; and also that in decimal-type notations
> >>>> most rationals equally have no terminating expansion. Numbers
> >>>> such as "pi" and "sqrt(2)" are not defined as decimal expansions
> >>>> but via their properties [eg that "sqrt(2)" is the unique
> >>>> positive real whose square is 2, or equivalently that it is the
> >>>> ratio of the diagonal of a square to its side, and "pi" is the
> >>>> least positive real whose sine is zero]. Those properties are
> >>>> exact, and tell you all you ever need to know about those
> >>>> numbers.
> >>
> >> [ .... ]
> >>
> >>> What has decimal (base 10) expansion got to do with anything? An
> >>> irrational number has a non-terminating sequence in ANY base. I
> >>> am sorry but you are simply mistaken: irrational numbers do NOT
> >>> have an exact value; this is obvious to anyone who understands
> >>> logic and uses a sane definition for infinity.
> >>
> >> That irrational numbers are exact values is clear to anybody with a
> >> degree in maths. Definitions of "infinity" (of which there are
> >> many) have nothing to do with this.
> >
> > You are wrong and fractally so so your degree in maths appears to be
> > worthless. An irrational number's sequence is statistically random,
> > has no fixed point on the number line ergo has no exact
> > representation. Any number with no exact representation has, by
> > definition, no exact value, only an approximation. Infinity has
> > everything to do with this as an irrational's sequence ("digits")
> > never terminates (i.e. it is an INFINITELY long sequence).
> >
> > /Flibble
> >
>
> Nope. Irrational numbers DO have exact points on the number line.
>
> And what does representation have to do with exact value?
>
> Also, irrational numbers sequence of digits are not necessarily
> statistically random, in some representations, they can be VERY
> predictible for some numbers.
>
> One simple construction to show exact position, draw a box with sides
> exactly 1.
>
> Draw a line though opposite corners and make one point the value 0.
>
> The other corner will be EXACTLY at the point sqrt(2), so that
> irrational number has an exact point on the number line.
>
> You just don't understand what an exact value means, likely because
> you can't understand things that are somewhat abstract.
An irrational number does not have an exact point on the number line as
it will move about as you "zoom in", you can keep "zooming in" forever
(i.e. infinitely) and it will keep moving about because the number
never terminates.
If I couldn't understand things that are somewhat abstract then I
wouldn't have a computer science degree (BSc Hons) and 30 years of
industry experience.
/Flibble
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web