| Deutsch English Français Italiano |
|
<29f5e2b5ff05046085fed0e88b40d083cdcd8ccc@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
to HHH(DD)
Date: Thu, 8 May 2025 22:11:22 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <29f5e2b5ff05046085fed0e88b40d083cdcd8ccc@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvgq6o$1acph$1@dont-email.me>
<vvgqgl$15i5e$27@dont-email.me> <vvgr22$1ag3a$2@dont-email.me>
<vvgt36$1auqp$2@dont-email.me> <vvgtbe$1b0li$1@dont-email.me>
<vvguot$1auqp$3@dont-email.me> <vvh0t2$1b939$1@dont-email.me>
<vvhap5$1hp80$1@dont-email.me> <vvhf20$1ihs9$1@dont-email.me>
<vvhfnd$1hvei$3@dont-email.me> <vvil99$1ugd5$1@dont-email.me>
<vvinvp$1vglb$1@dont-email.me> <vviv75$222r6$1@dont-email.me>
<vvj1fp$22a62$1@dont-email.me> <vvj2j6$23gk7$1@dont-email.me>
<as9TP.251456$lZjd.93653@fx05.ams4> <87msbmeo3b.fsf@nosuchdomain.example.com>
<vvjc9b$27753$1@dont-email.me> <87ecwyekg2.fsf@nosuchdomain.example.com>
<vvjg6a$28g5i$3@dont-email.me> <871psyejpl.fsf@nosuchdomain.example.com>
<vvjhcf$28g5i$6@dont-email.me>
<7b1e0f52cf7461400371c5809cf93df0460d0358@i2pn2.org>
<vvjm10$28g5i$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 9 May 2025 02:27:13 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="3737689"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vvjm10$28g5i$7@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
On 5/8/25 9:33 PM, olcott wrote:
> On 5/8/2025 8:07 PM, Richard Damon wrote:
>> On 5/8/25 8:14 PM, olcott wrote:
>>> On 5/8/2025 7:00 PM, Keith Thompson wrote:
>>>> olcott <polcott333@gmail.com> writes:
>>>>> On 5/8/2025 6:45 PM, Keith Thompson wrote:
>>>>>> olcott <polcott333@gmail.com> writes:
>>>>>>> On 5/8/2025 5:26 PM, Keith Thompson wrote:
>>>>>> [...]
>>>>>>>> I am more nearly an expert on C than on the Halting Problem.
>>>>>>>> Watching olcott base his arguments on C *and getting C so badly
>>>>>>>> wrong* leads me to think that he is largely ignorant of C (which is
>>>>>>>> fine, most people are) and is unwilling to admit it. Watching the
>>>>>>>> reactions of actual experts to his mathematical arguments leads me
>>>>>>>> to the same conclusion about his knowledge of the relevant fields
>>>>>>>> of mathematics.
>>>>>>>>
>>>>>>>
>>>>>>> If Halt7.c is not compiled with the Microsoft
>>>>>>> compiler then it will not produce the required
>>>>>>> object file type.
>>>>>>>
>>>>>>> The rest of the system has compiled under
>>>>>>> Linux. I haven't tried this in a few years.
>>>>>> [...]
>>>>>> So you normally compile your code using the 2017 version of
>>>>>> Microsoft
>>>>>> Visual Studio.
>>>>>> I have no particular problem with that, but your failure to correct
>>>>>> a number of C errors in your code is odd.
>>>>>
>>>>> As I already proved Microsoft reported no such errors.
>>>>
>>>> Microsoft's compiler did not report certain errors that any
>>>> conforming C
>>>> compiler is required by the standard to report.
>>>>
>>>> Microsoft's compiler *can* be invoked in a way that causes it to
>>>> diagnose such errors, though it may or may not become fully conforming.
>>>> I haven't used it lately, but a web search should tell you how to do
>>>> that.
>>>>
>>>>>> I've pointed out several
>>>>>> syntax errors and constraint violations; at least the syntax errors
>>>>>> would be trivial to fix (even if your compiler is lax enough to
>>>>>> fail to diagnose them). Richard Heathfield has pointed out code
>>>>>> that dereferences a null pointer.
>>>>>>
>>>>>
>>>>> Mike corrected Richard on this.
>>>>> Those are stub functions intercepted
>>>>> by x86utm the operating system.
>>>>>
>>>>>> You are using C, a language in which you appear to have little
>>>>>> apparent expertise or willingness to learn, to demonstrate claims
>>>>>> that, if true, would overturn ideas that have been generally accepted
>>>>>> for decades. Can you understand why I might decide that analyzing
>>>>>> your claims is not worth my time?
>>>>>>
>>>>>
>>>>> I learned C back when K & R was the standard.
>>>>
>>>> So did I. I've kept up with the language as it has changed.
>>>>
>>>>> void DDD()
>>>>> {
>>>>> HHH(DDD);
>>>>> return;
>>>>> }
>>>>>
>>>>> We don't need to look at any of my code for me
>>>>> to totally prove my point.
>>>>
>>>> Great. Then why do you keep posting code? Or is the above DDD()
>>>> function not included in "any of my code")?
>>>>
>>>>> For example when
>>>>> the above DDD is correctly simulated by HHH
>>>>> this simulated DDD cannot possibly reach its own
>>>>> "return" instruction.
>>>>
>>>> That's too vague for me to comment.
>>>>
>>>
>>> Do you know what a C language interpreter is?
>>> I actually do this at the x86 machine code level
>>> yet most people don't have a clue about that.
>>>
>>> _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]
>>>
>>> The above hypothetical HHH emulates the first four
>>> instructions of DDD. This sequence repeats until a
>>> OOM error.
>>>
>>
>> Which is INVALID as in input to a halt decider
>
> We aren't even talking about a halt decider yet.
Sure we are, as we are discussing the behavior of what you will make the
input to one.
It also is an invalid input to a correct emulator for exactly the same
reason,
>
> We are only testing to see if the idea of recursive
> simulation is understood to be equivalent to infinite
> recursion.
>
And how do you emulate something that doesn't define all its code?
Remember, the DEFINITION of the emulation of the call HHH instruciton
include next emulating the first instruction of HHH, which izn't in the
input, and thus your emulator also isn't a pure function.
Sorry, you deceptions just doesn't work, and all you are doing is
proving your ignorance of what you are talkking about.