| Deutsch English Français Italiano |
|
<tL-dnQNGiOhnABz1nZ2dnZfqlJydnZ2d@giganews.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!border-1.nntp.ord.giganews.com!nntp.giganews.com!local-3.nntp.ord.giganews.com!Xl.tags.giganews.com!local-4.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 24 Jul 2025 02:44:10 +0000
Date: Wed, 23 Jul 2025 21:44:10 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Title: A Structural Analysis of the Standard Halting Problem
Proof --- Alan Mackenzie
Newsgroups: comp.theory,comp.ai.philosophy
References: <105ht1n$36s20$1@dont-email.me>
<eed26ffea811a639a76d0184321c57eafba746cd@i2pn2.org>
<pI4fQ.147044$gKRf.71824@fx12.ams4> <105kvub$2q17h$1@dont-email.me>
<105lg9k$3v8t8$6@dont-email.me> <105ljhk$9si$1@news.muc.de>
<105lkj4$3v8t8$13@dont-email.me> <105lnn2$2srt$1@news.muc.de>
<105lpsd$1mvr$1@dont-email.me> <105m9me$2phf$1@news.muc.de>
<w7WcnXmKtNz9E-L1nZ2dnZfqlJ-dnZ2d@giganews.com> <105oqht$2puc$1@news.muc.de>
Content-Language: en-US
From: olcott <NoOne@NoWhere.com>
In-Reply-To: <105oqht$2puc$1@news.muc.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: Norton (VPS 250723-4, 7/23/2025), Outbound message
X-Antivirus-Status: Clean
Message-ID: <tL-dnQNGiOhnABz1nZ2dnZfqlJydnZ2d@giganews.com>
Lines: 124
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-dRtIFRvWxMJsBpabJiubqymnAQpCogCwcU6M3J4493Iiz8YrgrmZ8ekr5pxvcdQWK4+L/75RJnLPXdE!jY5CGeE9s4r+lcUZTgmfuLqqQtaLzWtqYeAb61DfSPhEdiG0epaCBwUxWXAwI718pyzVu6E+vZSL!gQ==
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
On 7/22/2025 2:58 PM, Alan Mackenzie wrote:
> olcott <NoOne@nowhere.com> wrote:
>> On 7/21/2025 3:58 PM, Alan Mackenzie wrote:
>>> [ Followup-To: set ]
>
>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>> On 7/21/2025 10:52 AM, Alan Mackenzie wrote:
>
> [ .... ]
>
>>>>> You will have a get out clause from the vagueness of your language, which
>>>>> could be construed to mean practically anything.
>
>>>> typedef void (*ptr)();
>>>> int HHH(ptr P);
>
>>>> void DDD()
>>>> {
>>>> HHH(DDD);
>>>> return;
>>>> }
>
>>>> int main()
>>>> {
>>>> HHH(DDD);
>>>> }
>
>>>> Not at all. HHH does emulate the x86 machine code
>>>> of DDD pointed to by P. That is does this according
>>>> to the semantics of the x86 language conclusively
>>>> proves that this emulation is correct.
>
>>> That's nauseatingly overstretching things into another lie. Whatever HHH
>>> might do is far short of sufficient "conclusively to prove" that the
>>> emulation is correct. To prove that is likely impossible in principle,
>>> that's even assuming you could define "correct" coherently.
>
>
>> [00002192] 55 push ebp
>> [00002193] 8bec mov ebp,esp
>> [00002195] 6892210000 push 00002192
>> [0000219a] e833f4ffff call 000015d2 // call HHH
>> [0000219f] 83c404 add esp,+04
>> [000021a2] 5d pop ebp
>> [000021a3] c3 ret
>> Size in bytes:(0018) [000021a3]
>
>> x86utm is a multi-tasking operating system (that I wrote)
>> that allows any C function to execute any other C function
>> in debug step mode. HHH and DDD have their own virtual
>> registers and stack.
>
>> When HHH emulates the first instruction of DDD it
>> emulates pushing the DDD ebp base pointer onto the
>> DDD stack.
>
>> *That is a 100% concrete example of correct emulation*
>
> Which appears to be beside the point.
>
>> Exactly how is it that you could have construed this
>> as impossible in principle?
>
> You seem to be "proving" the correctness of your emulation by giving one
> example of its execution and saying "because it works for this particular
> case, it works in general".
>
> It is as though you are testing a multiplication program and give it the
> inputs 3.0 and 1.5, you get the answer 4.5 "therefore" it works properly.
> Actually, what you were testing turned out to be an addition program.
>
> You can never prove a program is correct just by getting correct results
> from a single run of it, or even correct results from several or many
> runs. This is impossible in principle. And as I wrote earlier, that
> even supposes that you can define "correct" coherently and usefully.
>
It is certainly not impossible in principle
to prove that DDD is correctly emulated by HHH.
I claim that it is proved that DDD is correctly
emulated by HHH and your rebuttal totally changes
the subject. This strawman deception is the primary
form of every fake rebuttal of my work.
There have been zero correct rebuttals of any
detail of the essence of my work. Not one person
can point to any correct rebuttal of the essence
of my work in the last three years.
The fact that HHH(DD) rejects its input as non-halting
never was contradicted by the fact that the directly
executed DD() halts. It only seemed that way because
no one ever bothered to notice:
(a) Turing machine deciders only take finite
string inputs they never take directly executing
Turing machines as inputs.
(b) Turing machine deciders only compute the mapping
from their inputs on the basis of the behavior
specified by these inputs.
(c) When the input to a Turing machine decider
calls this same decider then the behavior of the
direct execution and the correct simulation diverge.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH(DD)==0 even though DD() halts.
--
Copyright 2024 Olcott
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer