Re: Proof that DDD specifies non-halting behavior --- Mike is not paying attention

Liste des GroupesRevenir à c theory 
Sujet : Re: Proof that DDD specifies non-halting behavior --- Mike is not paying attention
De : mikko.levanto (at) *nospam* iki.fi (Mikko)
Groupes : comp.theory
Date : 19. Aug 2024, 10:34:45
Autres entêtes
Organisation : -
Message-ID : <v9v3jl$2qmp2$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
User-Agent : Unison/2.2
On 2024-08-18 12:58:00 +0000, olcott said:

On 8/18/2024 3:23 AM, Mikko wrote:
On 2024-08-17 16:33:05 +0000, Richard Damon said:
 
On 8/17/24 12:27 PM, olcott wrote:
On 8/17/2024 11:17 AM, Mike Terry wrote:
If I post here these days it is generally for the possible benefit of others conversing with PO - e.g. perhaps it seems to me that weeks of time are being wasted /through some simple miscommunication/ with PO. I've been around longer than the current (relative) newcommers [not as long as you and Ben I think], so I have more context for what PO is trying to say,
 *Yet you persistently fail to agree with Ben on this*
  Because you just don't understand what Ben said here, because you are just too stupid.
 
 
 
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game.  PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
...
But H determines (correctly) that D would not halt if it
were not halted.  That much is a truism.
 
  *This is a simpler version that*
*defines correctly simulated in*
*a way that has no correct rebuttal*
 void DDD()
{
  HHH(DDD);
}
 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 *It is a basic fact that DDD emulated by HHH according to*
*the semantics of the x86 language cannot possibly stop*
*running unless aborted* (out of memory error excluded)
 <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D
    until H correctly determines that its simulated D would never
    stop running unless aborted then
     H can abort its simulation of D and correctly report that D
    specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
 
 Which is just a repeating of the lies that have been disproven, showing that you don't understand the words you say,
 The input DDD can't be just those bytes, or it is just a category error.
 One problem in these discussion is that the term "input" has no formal
definition and its informal meaning is vague, like informal meanings
usually are.
 
 The input to HHH is its parameter of the machine address of
DDD in the shared memory space of Halt7.obj loaded into memory.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
That is one meaning of the word "input" thata can be used in certain
situations. A more (but still not fully) general meaning is that an
input is anything used in a computation that is not a part of the
algrithm or a reuslt by an aleady executed part of the computation.
It may also mean the content of any memory location or register that
is read before it is written. Sometimes it is useful to have separate
terms for different kinds of inputs such as "permitted input" and
"formal input" and "actual input", or whatever one happens to need.
--
Mikko

Date Sujet#  Auteur
15 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal