| Deutsch English Français Italiano |
|
<87o6w2czvd.fsf@nosuchdomain.example.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)
Date: Thu, 08 May 2025 18:54:46 -0700
Organization: None to speak of
Lines: 118
Message-ID: <87o6w2czvd.fsf@nosuchdomain.example.com>
References: <vv97ft$3fg66$1@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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 09 May 2025 03:54:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="302a6dd640940106301f9e87fdade96e";
logging-data="2450542"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4Lr1BDfhXmLVUZkF3DYFf"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:ZqxvAX1vjWFTK2bRBt16Jl/7Dqo=
sha1:gUIxpCD3rsmX+s8mgoCIUqMRviM=
olcott <polcott333@gmail.com> writes:
> 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?
Yes. Do you? I don't read most of your posts, but I've never seen you
post anything that could reasonably be called a C language interpreter.
Perhaps if you explain what you mean someone could suggest a more
accurate term for it.
> I actually do this at the x86 machine code level
> yet most people don't have a clue about that.
My knowledge of x86 machine code is minimal. I thought you were saying
someone only needs to be "sufficiently competent C programmer" was
enough to understand your arguments.
> _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]
I see no interpretation of C code. All I see is a mix of x86 machine
code (in hexadecimal) and x86 assembly code.
> The above hypothetical HHH emulates the first four
> instructions of DDD. This sequence repeats until a
> OOM error.
If you say so.
A "C language interpreter" would take C *source code* as input and
execute it, presumably without first compiling it to machine code.
Let me warn you again that I expect I will tire of this discussion
very soon, so I suggest you make any coherent points quickly.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */