On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
PO's D(D) halts, as illustrated in various traces that have been
posted here.
PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various
traces.
i.e. exactly as the Linz proof claims. PO has acknowledged both these
results. Same for the HH/DD variants.
You might imagine that's the end of the matter - PO failed. :)
That's right, but PO just carries on anyway!
He has quite explicitly stated that false (0) is the correct result for
H(D,D) "even though D(D) halts". I am mystified why anyone continues to
discuss the matter until he equally explicitly repudiates that claim.
Deciders only compute the mapping *from their inputs* to their own
accept or reject state. The correct emulation of the machine code input
to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction
of the x86 machine code of DD correctly and in the correct order.
*The input to HH(DD,DD) specifies non-halting behavior*
On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
PO's D(D) halts, as illustrated in various traces that have been posted here.
PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces.
i.e. exactly as the Linz proof claims. PO has acknowledged both these
results. Same for the HH/DD variants.
You might imagine that's the end of the matter - PO failed. :)
That's right, but PO just carries on anyway!
He has quite explicitly stated that false (0) is the correct result for
H(D,D) "even though D(D) halts". I am mystified why anyone continues to
discuss the matter until he equally explicitly repudiates that claim.
Deciders only compute the mapping *from their inputs* to their own
accept or reject state.
On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
PO's D(D) halts, as illustrated in various traces that have been
posted here.
PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various
traces.
i.e. exactly as the Linz proof claims. PO has acknowledged both these
results. Same for the HH/DD variants.
You might imagine that's the end of the matter - PO failed. :)
That's right, but PO just carries on anyway!
He has quite explicitly stated that false (0) is the correct result for
H(D,D) "even though D(D) halts". I am mystified why anyone continues to
discuss the matter until he equally explicitly repudiates that claim.
Deciders only compute the mapping *from their inputs* to their own
accept or reject state. The correct emulation of the machine code input
to H(DD,DD) requires DD emulated by HH to emulate each x86 instruction
of the x86 machine code of DD correctly and in the correct order.
*The input to HH(DD,DD) specifies non-halting behavior*
The only way to cause DD emulated by HH to have the same behavior as
the directly executed (non input) DD(DD) is to emulate the instructions specified by the machine code of DD incorrectly or in the incorrect
order. *This is not the behavior that the input to HH(DD,DD) specifies*
The behavior of the directly executed DD(DD) has different behavior
than DD correctly emulated by HH. This is because the behavior of DD(DD) reaps the benefits of HH having already aborted its simulation.
No one ever noticed that these two behaviors could ever diverge before because everyone rejected the notion of a simulating halt decider out- of-hand without review.
Two PhD computer science professors that I have communicated with
agree with me that there is something wrong with the halting problem.
Bill Stoddart. *The Halting Paradox*
20 December 2017
https://arxiv.org/abs/1906.05340
arXiv:1906.05340 [cs.LO]
E C R Hehner. *Problems with the Halting Problem*, COMPUTING2011
Symposium on 75 years of Turing Machine and Lambda-Calculus, Karlsruhe Germany, invited, 2011 October 20-21; Advances in Computer Science and Engineering v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf
E C R Hehner. *Objective and Subjective Specifications*
WST Workshop on Termination, Oxford. 2018 July 18.
See https://www.cs.toronto.edu/~hehner/OSS.pdf
*Introduction to the Theory of Computation, by Michael Sipser* https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
On 10/13/2022 11:29:23 AM
MIT Professor Michael Sipser agreed this verbatim paragraph is correct
(He has neither reviewed nor agreed to anything else in this paper)
<Professor Sipser agreed>
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.
</Professor Sipser agreed>
*DD correctly simulated by HH would never stop running unless aborted*
*We can see that the following DD cannot possibly halt when*
*correctly simulated by every HH that can possibly exist*
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int HH(ptr p, ptr i);
01 int DD(ptr p)
02 {
03 int Halt_Status = HH(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
_DD()
[00001c22] 55 push ebp
[00001c23] 8bec mov ebp,esp
[00001c25] 51 push ecx
[00001c26] 8b4508 mov eax,[ebp+08]
[00001c29] 50 push eax ; push DD 1c22 [00001c2a] 8b4d08 mov ecx,[ebp+08]
[00001c2d] 51 push ecx ; push DD 1c22 [00001c2e] e80ff7ffff call 00001342 ; call HH
[00001c33] 83c408 add esp,+08
[00001c36] 8945fc mov [ebp-04],eax
[00001c39] 837dfc00 cmp dword [ebp-04],+00
[00001c3d] 7402 jz 00001c41
[00001c3f] ebfe jmp 00001c3f
[00001c41] 8b45fc mov eax,[ebp-04]
[00001c44] 8be5 mov esp,ebp
[00001c46] 5d pop ebp
[00001c47] c3 ret
Size in bytes:(0038) [00001c47]
So really, there's no /need/ to "refute" everything he says - the end
result will be exactly the same as just ignoring him, BUT WITH THE
LATTER
ONLY NEEDING 0.1% OF THE EFFORT and eliminating 99.9% of the posting
clutter in these newsgroups. [ok, comp.theory will die pretty
quickly, but
it is not discussing anything useful, so that's ok for most people...
(with
some reluctance)]
Do we know that? There's the start of a discussion of quines on
comp.lang.c that probably belongs here, but no will dare come here to
discuss it because of all the junk.
You cannot show any mistake in what I said above because all you
have is bluster and dogma. What I am saying is just not the way
that you memorized it !
On 6/3/2024 9:27 AM, Mikko wrote:
On 2024-06-03 12:20:01 +0000, olcott said:
On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
PO's D(D) halts, as illustrated in various traces that have been
posted here.
PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
various traces.
i.e. exactly as the Linz proof claims. PO has acknowledged both these >>>>> results. Same for the HH/DD variants.
You might imagine that's the end of the matter - PO failed. :)
That's right, but PO just carries on anyway!
He has quite explicitly stated that false (0) is the correct result for >>>> H(D,D) "even though D(D) halts". I am mystified why anyone
continues to
discuss the matter until he equally explicitly repudiates that claim.
Deciders only compute the mapping *from their inputs* to their own
accept or reject state.
That does not restrict what a problem statement can specify.
If the computed mapping differs from the specified one the
decider does not solve the problem.
int sum(int x, int y) { return x + y; }
sum(2,3) cannot return the sum of 5 + 6.
DD correctly simulated by HH does have provably
different behavior than DD(DD) so HH is is not
allowed to report on the behavior of DD(DD).
On 6/3/2024 9:27 AM, Mikko wrote:
On 2024-06-03 12:20:01 +0000, olcott said:
On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
PO's D(D) halts, as illustrated in various traces that have been posted here.
PO's H(D,D) returns 0 : [NOT halting] also as illustrated in various traces.
i.e. exactly as the Linz proof claims. PO has acknowledged both these >>>>> results. Same for the HH/DD variants.
You might imagine that's the end of the matter - PO failed. :)
That's right, but PO just carries on anyway!
He has quite explicitly stated that false (0) is the correct result for >>>> H(D,D) "even though D(D) halts". I am mystified why anyone continues to >>>> discuss the matter until he equally explicitly repudiates that claim.
Deciders only compute the mapping *from their inputs* to their own
accept or reject state.
That does not restrict what a problem statement can specify.
If the computed mapping differs from the specified one the
decider does not solve the problem.
int sum(int x, int y) { return x + y; }
sum(2,3) cannot return the sum of 5 + 6.
On 6/3/2024 9:27 AM, Mikko wrote:Huh? Then HH is not a correct simulator if it produces different
On 2024-06-03 12:20:01 +0000, olcott said:int sum(int x, int y) { return x + y; } sum(2,3) cannot return the sum
On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:Deciders only compute the mapping *from their inputs* to their own
He has quite explicitly stated that false (0) is the correct result
for H(D,D) "even though D(D) halts". I am mystified why anyone
continues to discuss the matter until he equally explicitly
repudiates that claim.
accept or reject state.
That does not restrict what a problem statement can specify.
If the computed mapping differs from the specified one the decider does
not solve the problem.
of 5 + 6.
DD correctly simulated by HH does have provably different behavior than DD(DD) so HH is is not allowed to report on the behavior of DD(DD).
On 6/3/2024 9:27 AM, Mikko wrote:
On 2024-06-03 12:20:01 +0000, olcott said:
On 6/3/2024 4:42 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
PO's D(D) halts, as illustrated in various traces that have been
posted here.
PO's H(D,D) returns 0 : [NOT halting] also as illustrated in
various traces.
i.e. exactly as the Linz proof claims. PO has acknowledged both these >>>>> results. Same for the HH/DD variants.
You might imagine that's the end of the matter - PO failed. :)
That's right, but PO just carries on anyway!
He has quite explicitly stated that false (0) is the correct result for >>>> H(D,D) "even though D(D) halts". I am mystified why anyone
continues to
discuss the matter until he equally explicitly repudiates that claim.
Deciders only compute the mapping *from their inputs* to their own
accept or reject state.
That does not restrict what a problem statement can specify.
If the computed mapping differs from the specified one the
decider does not solve the problem.
int sum(int x, int y) { return x + y; }
sum(2,3) cannot return the sum of 5 + 6.
DD correctly simulated by HH does have provably
different behavior than DD(DD) so HH is is not
allowed to report on the behavior of DD(DD).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 498 |
| Nodes: | 16 (4 / 12) |
| Uptime: | 14:22:21 |
| Calls: | 9,825 |
| Calls today: | 4 |
| Files: | 13,761 |
| Messages: | 6,191,076 |