Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #122954 > unrolled thread

D simulated by H cannot possibly reach its own simulated final halt state

Back to article view | Back to comp.lang.c++

Contents

  D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-06 14:48 -0600
    How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 19:38 -0600
      Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 02:13 +0000
        Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 20:33 -0600
        Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 21:05 -0600
          Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 21:45 -0600
            Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 05:52 +0000
              Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-11 23:59 -0600
                Re: How pathological self-reference is confused with undecidability Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-12 06:13 +0000
                  Re: How pathological self-reference is confused with undecidability olcott <polcott333@gmail.com> - 2025-11-12 06:50 -0600
    Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-11 20:41 -0600
      Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 09:11 -0600
      Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-12 20:30 -0600
        Re: D simulated by H cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-12 21:35 -0500
      Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-13 14:22 -0600
    Weasel word double talk excuses =--- AKA Liars olcott <polcott333@gmail.com> - 2025-11-18 15:57 -0600
    Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 21:07 -0600
      Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:30 +0000
      DDD simulated by HHH cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 22:45 -0600
        Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 04:52 +0000
        Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-18 23:08 -0600
          Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state dbush <dbush.mobile@gmail.com> - 2025-11-19 00:14 -0500
          Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-19 05:23 +0000
      Glossary of names of my simulating termination analyzer HHH(DD) olcott <polcott333@gmail.com> - 2025-11-23 16:29 -0600
    polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 07:22 -0600
      Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 17:51 +0000
        Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 12:06 -0600
    polcott agrees the Kaz is a damned liar --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 07:33 -0600
      Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-22 17:56 +0000
        Dangerous Precipice that could end all life --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 13:29 -0600
          Re: Dangerous Precipice that could end all life --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-22 23:02 -0600
            Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-23 05:23 +0000
            Re: Dangerous Precipice that could end all life --- DD simulated by HHH olcott <polcott333@gmail.com> - 2025-11-23 14:53 -0600
              Re: Dangerous Precipice that could end all life --- DD simulated by HHH "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-23 13:32 -0800
              Re: Dangerous Precipice that could end all life --- DD simulated by HHH Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 02:44 +0000
            DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-23 21:15 -0600
              Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 16:32 +0000
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 10:45 -0600
                Re: DD simulated by HHH and DD simulated by HHH1 tTh <tth@none.invalid> - 2025-11-24 19:45 +0100
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 12:08 -0600
                Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 19:22 +0000
                Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 14:20 -0600
                  Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-24 22:31 +0000
                  Re: DD simulated by HHH and DD simulated by HHH1 olcott <NoOne@NoWhere.com> - 2025-11-24 17:23 -0600
                    Re: DD simulated by HHH and DD simulated by HHH1 Richard Heathfield <rjh@cpax.org.uk> - 2025-11-25 05:10 +0000
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 14:15 -0600
                Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 17:21 -0600
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 17:19 -0600
                Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-24 16:15 -0800
                  Re: DD simulated by HHH and DD simulated by HHH1 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-24 16:25 -0800
                Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 01:39 +0000
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <NoOne@NoWhere.com> - 2025-11-24 17:24 -0600
                Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 01:42 +0000
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-24 18:33 -0600
              Re: DD simulated by HHH and DD simulated by HHH1 olcott <polcott333@gmail.com> - 2025-11-25 13:35 -0600
                Re: DD simulated by HHH and DD simulated by HHH1 Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 20:27 +0000
    Re: D simulated by H cannot possibly reach its own simulated final halt state Bonita Montero <Bonita.Montero@gmail.com> - 2025-11-25 16:20 +0100
      Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 09:47 -0600
        Re: D simulated by H cannot possibly reach its own simulated final halt state Bonita Montero <Bonita.Montero@gmail.com> - 2025-11-25 16:50 +0100
          Re: D simulated by H cannot possibly reach its own simulated final halt state olcott <polcott333@gmail.com> - 2025-11-25 10:09 -0600
            Re: D simulated by H cannot possibly reach its own simulated final halt state Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-25 17:33 +0000
        Re: D simulated by H cannot possibly reach its own simulated final halt state Richard Damon <Richard@Damon-Family.org> - 2025-11-25 11:37 -0500
    Olcott is provably correct --- no one can correctly refute this olcott <polcott333@gmail.com> - 2025-12-03 19:54 -0600

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#123019 — Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state

On 11/18/2025 10:52 PM, Kaz Kylheku wrote:
> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>> On 11/18/2025 10:31 PM, Kaz Kylheku wrote:
>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>> On 11/18/2025 8:53 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>>>> On 11/18/2025 7:01 PM, Kaz Kylheku wrote:
>>>>>>> On 2025-11-18, olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 11/18/2025 3:21 PM, Kaz Kylheku wrote:
>>>>>>>>> On 2025-11-18, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>> If you ask a decider to determine if my
>>>>>>>>>> sister's name is "Sally" and I don't tell
>>>>>>>>>> it who I am then the information contained
>>>>>>>>>> in the input is insufficient. This does not
>>>>>>>>>> in any way limit computation itself.
>>>>>>>>>
>>>>>>>>> The problem is that UTM(D) can work out the fact that
>>>>>>>>> D halts. Why is it that UTM knows that D's sister's
>>>>>>>>> name is Sally, but H does not?
>>>>>>>>>
>>>>>>>>
>>>>>>>> UTM(D) is answering a different question.
>>>>>>>> (a) It is not providing any answer at all.
>>>>>>>
>>>>>>> Well, of course, by "UTM" we mean a /decider/ that purely simulates:
>>>>>>>
>>>>>>>      bool UTM(ptr P) {
>>>>>>>        sim S = sim_create(P);
>>>>>>>        sim_step_exhaustively(S);
>>>>>>>        return true;
>>>>>>>      }
>>>>>>>
>>>>>>> All deciders applied to D are tasked with answering exactly the same
>>>>>>> question.
>>>>>>>
>>>>>>> Pretending that a different question was asked is nonproductive;
>>>>>>> the answer will be interpreted to the original question.
>>>>>>>
>>>>>>> All the information needed to answer is positively contained in D.
>>>>>>>
>>>>>>> It is just too complex relative to H.
>>>>>>>
>>>>>>
>>>>>> What The F does UTM decide when DD calls UTM(DD)?
>>>>>
>>>>> That doesn't happen; DD calls HHH(DD).
>>>>>
>>>>> A diagonal functon set against UTM, call it DDUTM,
>>>>> cannot be decided by UTM(DDUTM).
>>>>>
>>>>> That call simply does not return.
>>>>>
>>>>
>>>> Yes, and the other one does return proving the
>>>> whole point that I have been making for three
>>>> years that everyone (besides Ben) was too damned
>>>> dishonest to acknowledge has been true all along.
>>>
>>> What "other one"? Is that referring to HHH(DD)?
>>>
>>> HHH(DD) returns; UTM(DDUTM) does not return.
>>>
>>> That's four functions; HHH isn't UTM; DD isn't DDUTM.
>>>
>>> HHH and DDUTM are unrelated; UTM and DD are unrelated.
>>>
>>
>> void DDD()
>> {
>>     HHH(DDD);
>>     return;
>> }
>>
>> A simulating termination analyzer that must
>> abort the interpretation of the above ASCII
>> string to prevent its own non-termination
>> has different behavior than a simulating
>> termination analyzer that need not abort
>> its interpretation of the above exact same
>> ASCII string.
> 
> 1. Up to that abort point, UTM(DDD) and HHH(DDD) conduct an
> absolutely identical simulation. The only difference is
> that the simulation continues under UTM, and is abandoned
> under HHH.
> 

No that is counter-factual please try again.

> 2. This is not a difference attributable to DDD.  DDD is the same in
> both cases. Not continuing the simulation fo DDD doesn't redefine what
> DDD is. It is not possible to redefine what DDD is; it is the
> agreed-upon procedure above.
> 


-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123020 — Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state

On 11/19/2025 12:08 AM, olcott wrote:
> On 11/18/2025 10:52 PM, Kaz Kylheku wrote:
>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>> On 11/18/2025 10:31 PM, Kaz Kylheku wrote:
>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/18/2025 8:53 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/18/2025 7:01 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-18, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 11/18/2025 3:21 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-18, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> If you ask a decider to determine if my
>>>>>>>>>>> sister's name is "Sally" and I don't tell
>>>>>>>>>>> it who I am then the information contained
>>>>>>>>>>> in the input is insufficient. This does not
>>>>>>>>>>> in any way limit computation itself.
>>>>>>>>>>
>>>>>>>>>> The problem is that UTM(D) can work out the fact that
>>>>>>>>>> D halts. Why is it that UTM knows that D's sister's
>>>>>>>>>> name is Sally, but H does not?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> UTM(D) is answering a different question.
>>>>>>>>> (a) It is not providing any answer at all.
>>>>>>>>
>>>>>>>> Well, of course, by "UTM" we mean a /decider/ that purely 
>>>>>>>> simulates:
>>>>>>>>
>>>>>>>>      bool UTM(ptr P) {
>>>>>>>>        sim S = sim_create(P);
>>>>>>>>        sim_step_exhaustively(S);
>>>>>>>>        return true;
>>>>>>>>      }
>>>>>>>>
>>>>>>>> All deciders applied to D are tasked with answering exactly the 
>>>>>>>> same
>>>>>>>> question.
>>>>>>>>
>>>>>>>> Pretending that a different question was asked is nonproductive;
>>>>>>>> the answer will be interpreted to the original question.
>>>>>>>>
>>>>>>>> All the information needed to answer is positively contained in D.
>>>>>>>>
>>>>>>>> It is just too complex relative to H.
>>>>>>>>
>>>>>>>
>>>>>>> What The F does UTM decide when DD calls UTM(DD)?
>>>>>>
>>>>>> That doesn't happen; DD calls HHH(DD).
>>>>>>
>>>>>> A diagonal functon set against UTM, call it DDUTM,
>>>>>> cannot be decided by UTM(DDUTM).
>>>>>>
>>>>>> That call simply does not return.
>>>>>>
>>>>>
>>>>> Yes, and the other one does return proving the
>>>>> whole point that I have been making for three
>>>>> years that everyone (besides Ben) was too damned
>>>>> dishonest to acknowledge has been true all along.
>>>>
>>>> What "other one"? Is that referring to HHH(DD)?
>>>>
>>>> HHH(DD) returns; UTM(DDUTM) does not return.
>>>>
>>>> That's four functions; HHH isn't UTM; DD isn't DDUTM.
>>>>
>>>> HHH and DDUTM are unrelated; UTM and DD are unrelated.
>>>>
>>>
>>> void DDD()
>>> {
>>>     HHH(DDD);
>>>     return;
>>> }
>>>
>>> A simulating termination analyzer that must
>>> abort the interpretation of the above ASCII
>>> string to prevent its own non-termination
>>> has different behavior than a simulating
>>> termination analyzer that need not abort
>>> its interpretation of the above exact same
>>> ASCII string.
>>
>> 1. Up to that abort point, UTM(DDD) and HHH(DDD) conduct an
>> absolutely identical simulation. The only difference is
>> that the simulation continues under UTM, and is abandoned
>> under HHH.
>>
> 
> No that is counter-factual please try again.

On 6/16/2025 12:58 PM, olcott wrote:
 > Baseless dogmatic statements that are utterly bereft of any
 > supporting reasoning at all DO NOT COUNT AS REBUTTALS.

It is factual as proven by Kaz's code, *and* the side by side trace 
posted by Mike, *and* by your repeated failure to show which x86 
instruction is emulated differently by HHH and UTM.

> 
>> 2. This is not a difference attributable to DDD.  DDD is the same in
>> both cases. Not continuing the simulation fo DDD doesn't redefine what
>> DDD is. It is not possible to redefine what DDD is; it is the
>> agreed-upon procedure above.
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#123021 — Re: DDD simulated by HHH cannot possibly reach its own simulated final halt state

On 2025-11-19, olcott <polcott333@gmail.com> wrote:
> On 11/18/2025 10:52 PM, Kaz Kylheku wrote:
>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>> On 11/18/2025 10:31 PM, Kaz Kylheku wrote:
>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/18/2025 8:53 PM, Kaz Kylheku wrote:
>>>>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
>>>>>>> On 11/18/2025 7:01 PM, Kaz Kylheku wrote:
>>>>>>>> On 2025-11-18, olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 11/18/2025 3:21 PM, Kaz Kylheku wrote:
>>>>>>>>>> On 2025-11-18, olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>> If you ask a decider to determine if my
>>>>>>>>>>> sister's name is "Sally" and I don't tell
>>>>>>>>>>> it who I am then the information contained
>>>>>>>>>>> in the input is insufficient. This does not
>>>>>>>>>>> in any way limit computation itself.
>>>>>>>>>>
>>>>>>>>>> The problem is that UTM(D) can work out the fact that
>>>>>>>>>> D halts. Why is it that UTM knows that D's sister's
>>>>>>>>>> name is Sally, but H does not?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> UTM(D) is answering a different question.
>>>>>>>>> (a) It is not providing any answer at all.
>>>>>>>>
>>>>>>>> Well, of course, by "UTM" we mean a /decider/ that purely simulates:
>>>>>>>>
>>>>>>>>      bool UTM(ptr P) {
>>>>>>>>        sim S = sim_create(P);
>>>>>>>>        sim_step_exhaustively(S);
>>>>>>>>        return true;
>>>>>>>>      }
>>>>>>>>
>>>>>>>> All deciders applied to D are tasked with answering exactly the same
>>>>>>>> question.
>>>>>>>>
>>>>>>>> Pretending that a different question was asked is nonproductive;
>>>>>>>> the answer will be interpreted to the original question.
>>>>>>>>
>>>>>>>> All the information needed to answer is positively contained in D.
>>>>>>>>
>>>>>>>> It is just too complex relative to H.
>>>>>>>>
>>>>>>>
>>>>>>> What The F does UTM decide when DD calls UTM(DD)?
>>>>>>
>>>>>> That doesn't happen; DD calls HHH(DD).
>>>>>>
>>>>>> A diagonal functon set against UTM, call it DDUTM,
>>>>>> cannot be decided by UTM(DDUTM).
>>>>>>
>>>>>> That call simply does not return.
>>>>>>
>>>>>
>>>>> Yes, and the other one does return proving the
>>>>> whole point that I have been making for three
>>>>> years that everyone (besides Ben) was too damned
>>>>> dishonest to acknowledge has been true all along.
>>>>
>>>> What "other one"? Is that referring to HHH(DD)?
>>>>
>>>> HHH(DD) returns; UTM(DDUTM) does not return.
>>>>
>>>> That's four functions; HHH isn't UTM; DD isn't DDUTM.
>>>>
>>>> HHH and DDUTM are unrelated; UTM and DD are unrelated.
>>>>
>>>
>>> void DDD()
>>> {
>>>     HHH(DDD);
>>>     return;
>>> }
>>>
>>> A simulating termination analyzer that must
>>> abort the interpretation of the above ASCII
>>> string to prevent its own non-termination
>>> has different behavior than a simulating
>>> termination analyzer that need not abort
>>> its interpretation of the above exact same
>>> ASCII string.
>> 
>> 1. Up to that abort point, UTM(DDD) and HHH(DDD) conduct an
>> absolutely identical simulation. The only difference is
>> that the simulation continues under UTM, and is abandoned
>> under HHH.
>> 
>
> No that is counter-factual please try again.

Iron-clad, unvarnished truth.

I mean that the simulaton states are identicdal, not that absolutely
all calculations in the scenario are the same.

You may be thinking that the internals of the simulation are different
because at every step HHH tests some conditions whch UTM does not.
However, this has no effect on the simulation state.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#123061 — Glossary of names of my simulating termination analyzer HHH(DD)

On 11/23/2025 3:20 PM, joes wrote:
> Am Tue, 18 Nov 2025 21:07:35 -0600 schrieb olcott:
>> On 11/18/2025 8:53 PM, Kaz Kylheku wrote:
>>> On 2025-11-19, olcott <polcott333@gmail.com> wrote:
> 
>>>> What The F does UTM decide when DD calls UTM(DD)?
>>>
>>> That doesn't happen; DD calls HHH(DD).
>>> A diagonal functon set against UTM, call it DDUTM, cannot be decided by
>>> UTM(DDUTM).
>>> That call simply does not return.
>>>
>> Yes, and the other one does return […]
> 
> The other what? DDUTM is not DD.
> 

*Just stick with these names and no other names*
*Just stick with these names and no other names*
*Just stick with these names and no other names*

template for hypothetical H and D
<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 words10/13/2022>

https://github.com/plolcott/x86utm/blob/master/Halt7.c

HHH is a fully operational termination analyzer anchored
in the x86 language yet can be construed as simulating C
functions according to the semantics of the C programming
language because the x86 was code translated from C.

HHH1 exactly the same as HHH except that DD does not
call HHH. DD simulated by HHH1 has the exact same
behavior as DD executed from main().

typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   HHH(DD);
}

HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...

HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.

The behavior of DD simulated by HHH1 is the
same as the behavior of DD() executed from main.

The sound basis of this reasoning is the
semantics of the C programming language.


-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123047 — polcott agrees the Kaz is a damned liar --- DD simulated by HHH

On 11/22/2025 12:49 AM, Kaz Kylheku wrote:
> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>> On 11/21/2025 3:58 PM, Kaz Kylheku wrote:
>>> On 2025-11-21, olcott <polcott333@gmail.com> wrote:
>>>>> Irrelevant to the question wheter H is designed to ask "Does D halt
>>>>> if fully executed?" when D is the input to H.
>>>>
>>>> It turns out that question is the same as
>>>> predict who the next president of the United
>>>> States will be entirely on the basis of the
>>>> square root of two. That information is not
>>>> contained in the input.
>>>
>>> Yes it is. It is just too complex for H to use, though.
>>>
>>> H has to trace through its own complexity and then some.
>>>
>>> The incomptuability of halting is hinged to the problem that programs
>>> cannot completely model their own complexity inside of themselves.
>>
>> The details of the behavior of D() executed
>> from main are not in the input to H(D).
> 
> Why are they in the input to UTM(D) but not in
> the input of H(D)? The argument passing is identical.
> 

Because D calls H(D) in recursive simulation
this H/D pair has different behavior than H
with any other input and D with any other decider.

I guy that can create this would have understood
that years ago. I do believe that you did create this.
https://www.nongnu.org/txr/txr-manpage.html#N-CF27E2FE

> You are just bat shit crazy.
> 
> It could be of parasitic origin; maybe you have picked up some
> sort of rare fungal infection that is producing psychedelics.
> 


-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123049 — Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH

On 2025-11-22, olcott <polcott333@gmail.com> wrote:
> On 11/22/2025 12:49 AM, Kaz Kylheku wrote:
>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>> On 11/21/2025 3:58 PM, Kaz Kylheku wrote:
>>>> On 2025-11-21, olcott <polcott333@gmail.com> wrote:
>>>>>> Irrelevant to the question wheter H is designed to ask "Does D halt
>>>>>> if fully executed?" when D is the input to H.
>>>>>
>>>>> It turns out that question is the same as
>>>>> predict who the next president of the United
>>>>> States will be entirely on the basis of the
>>>>> square root of two. That information is not
>>>>> contained in the input.
>>>>
>>>> Yes it is. It is just too complex for H to use, though.
>>>>
>>>> H has to trace through its own complexity and then some.
>>>>
>>>> The incomptuability of halting is hinged to the problem that programs
>>>> cannot completely model their own complexity inside of themselves.
>>>
>>> The details of the behavior of D() executed
>>> from main are not in the input to H(D).
>> 
>> Why are they in the input to UTM(D) but not in
>> the input of H(D)? The argument passing is identical.
>> 
>
> Because D calls H(D) in recursive simulation
> this H/D pair has different behavior than H
> with any other input and D with any other decider.

We are concerned only with the behavior of D; the behavior of D does not
depend on the choice of decider that we apply to D.

The behavior of D is based on the H/D pair.

As you correctly note above, other decider/input pairs have other
behaviors; but /D does not call any of those combinations/. D calls
H(D), thereby bolting its behavior to that of the H/D pair.

No matter which decider is looking at D, they all have to
agree that it calls H(D), which determines its behavior.

H is one thing. D is one thing.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#123051 — Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH

On 11/22/2025 11:51 AM, Kaz Kylheku wrote:
> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>> On 11/22/2025 12:49 AM, Kaz Kylheku wrote:
>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>> On 11/21/2025 3:58 PM, Kaz Kylheku wrote:
>>>>> On 2025-11-21, olcott <polcott333@gmail.com> wrote:
>>>>>>> Irrelevant to the question wheter H is designed to ask "Does D halt
>>>>>>> if fully executed?" when D is the input to H.
>>>>>>
>>>>>> It turns out that question is the same as
>>>>>> predict who the next president of the United
>>>>>> States will be entirely on the basis of the
>>>>>> square root of two. That information is not
>>>>>> contained in the input.
>>>>>
>>>>> Yes it is. It is just too complex for H to use, though.
>>>>>
>>>>> H has to trace through its own complexity and then some.
>>>>>
>>>>> The incomptuability of halting is hinged to the problem that programs
>>>>> cannot completely model their own complexity inside of themselves.
>>>>
>>>> The details of the behavior of D() executed
>>>> from main are not in the input to H(D).
>>>
>>> Why are they in the input to UTM(D) but not in
>>> the input of H(D)? The argument passing is identical.
>>>
>>
>> Because D calls H(D) in recursive simulation
>> this H/D pair has different behavior than H
>> with any other input and D with any other decider.
> 
> We are concerned only with the behavior of D; the behavior of D does not
> depend on the choice of decider that we apply to D.
> 
> The behavior of D is based on the H/D pair.
> 

You have proven that you are smart
https://www.nongnu.org/txr/

Thus certainly not so stupid to believe that D
simulated by H has the same behavior as D simulated
by H1 that is identical to H except that D does not
call H1(D) in recursive simulation.

int D()
{
   int Halt_Status = H(D);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}




-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123048 — polcott agrees the Kaz is a damned liar --- DD simulated by HHH

On 11/22/2025 1:03 AM, Kaz Kylheku wrote:
> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>> On 11/21/2025 3:58 PM, Kaz Kylheku wrote:
>>> On 2025-11-21, olcott <polcott333@gmail.com> wrote:
>>>>> Irrelevant to the question wheter H is designed to ask "Does D halt
>>>>> if fully executed?" when D is the input to H.
>>>>
>>>> It turns out that question is the same as
>>>> predict who the next president of the United
>>>> States will be entirely on the basis of the
>>>> square root of two. That information is not
>>>> contained in the input.
>>>
>>> Yes it is. It is just too complex for H to use, though.
>>>
>>> H has to trace through its own complexity and then some.
>>>
>>> The incomptuability of halting is hinged to the problem that programs
>>> cannot completely model their own complexity inside of themselves.
>>>
>>
>> The details of the behavior of D() executed
>> from main are not in the input to H(D).
> 
> That directly contradicts:
> 
>> The combination of the semantics of C
>> and the source of the function DD provide
>> all the information needed to specify all
>> of the details of the steps of DD simulated
>> by HHH.
> 
> Under the imaginary C simulation system, a function pointer DD is
> source-code based, since it is inside a simulation framwork in whch the
> current executing position is tracked to the syntax tree.
> 
> HHH(DD) receives the DD code, and has access to the simulation
> API to step it according to the correct semantics.
> 
> What is lacking?
> 

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

A guy that is smart enough to do this
https://www.nongnu.org/txr/txr-manpage.html#N-CF27E2FE

is smart enough to know that DD simulated by HHH has
different behavior than DD simulated by HHH1. HHH1
is exactly the same as HHH except that DD does not
call HHH1(DD) in recursive simulation.

A guy that is smart enough to do this
https://www.nongnu.org/txr/txr-manpage.html#N-CF27E2FE
and says that he does not understand the above is a liar.

-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123050 — Re: polcott agrees the Kaz is a damned liar --- DD simulated by HHH

On 2025-11-22, olcott <polcott333@gmail.com> wrote:
> is exactly the same as HHH except that DD does not
> call HHH1(DD) in recursive simulation.

I already pointed out the massive problem with this.

If HHH1 is identical to HHH, it means that HHH1 and HHH
are only different names for exactly the same function.

Functions do not have differences in behavior based
on what name is being used to refer to them.

You have a bug there.

> A guy that is smart enough to do this
> https://www.nongnu.org/txr/txr-manpage.html#N-CF27E2FE

... is not you, even by a long shot.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#123052 — Dangerous Precipice that could end all life --- DD simulated by HHH

On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>> is exactly the same as HHH except that DD does not
>> call HHH1(DD) in recursive simulation.
> 
> I already pointed out the massive problem with this.
> 
> If HHH1 is identical to HHH, it means that HHH1 and HHH
> are only different names for exactly the same function.
> 

In the mathematical abstraction that simply pretends
the behavioral details don't exist the math itself is
also a damned liar.

That you are trying to get away with ignoring these
details from the stipulated perspective of the execution
trace in C according to the semantics of C makes you
a damned liar even when referring to the mathematical
abstraction.

The reason that I call you a damned liar and not
just an ordinary liar is that damned lies against
my reasoning keep postponing making truth computable.

This continues to let dangerous liars get away with
their dangerous lies. Thus your silly trollish head
games might actually result in the end of life on Earth.

The world may be plunged in nuclear Winter just
because people believe that Putin's land grab is
not mere theft. If truth would have been computable
five years ago we might not even be on this
dangerous precipice.

> Functions do not have differences in behavior based
> on what name is being used to refer to them.
> 
> You have a bug there.
> 
>> A guy that is smart enough to do this
>> https://www.nongnu.org/txr/txr-manpage.html#N-CF27E2FE
> 
> ... is not you, even by a long shot.
> 


-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123054 — Re: Dangerous Precipice that could end all life --- DD simulated by HHH

On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>> On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>> is exactly the same as HHH except that DD does not
>>>> call HHH1(DD) in recursive simulation.
>>>
>>> I already pointed out the massive problem with this.
>>>
>>> If HHH1 is identical to HHH, it means that HHH1 and HHH
>>> are only different names for exactly the same function.
>>>
>>
>> In the mathematical abstraction that simply pretends
>> the behavioral details don't exist the math itself is
>> also a damned liar.
> 
> The fact that two different names are used to refer to exactly the same
> function does not constitute a "behavior detail" of that function.
> 
>> That you are trying to get away with ignoring these
>> details from the stipulated perspective of the execution
>> trace in C according to the semantics of C makes you
>> a damned liar even when referring to the mathematical
>> abstraction.
> 
> If you want your C functions to correspond to recursive
> functions in computation theory, you have to code them
> according to certain rules.
> 
> One of those is that you may not conclude that if f1 != f2 (pointer
> comparison) then they are different functions.
> 

HHH1 is at line  589 -  665
HHH  is at line 1081 - 1156

https://github.com/plolcott/x86utm/blob/master/Halt7.c
When DD calls HHH through of C interpreter
it does not call HHH1 because HHH1 has a
different name and is at a different location.

When you show that you know this
https://www.nongnu.org/txr/
no one is going to think you are too stupid
to know how C interpreters work.

-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123055 — Re: Dangerous Precipice that could end all life --- DD simulated by HHH

On 2025-11-23, olcott <polcott333@gmail.com> wrote:
> On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>> On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
>>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>>> is exactly the same as HHH except that DD does not
>>>>> call HHH1(DD) in recursive simulation.
>>>>
>>>> I already pointed out the massive problem with this.
>>>>
>>>> If HHH1 is identical to HHH, it means that HHH1 and HHH
>>>> are only different names for exactly the same function.
>>>>
>>>
>>> In the mathematical abstraction that simply pretends
>>> the behavioral details don't exist the math itself is
>>> also a damned liar.
>> 
>> The fact that two different names are used to refer to exactly the same
>> function does not constitute a "behavior detail" of that function.
>> 
>>> That you are trying to get away with ignoring these
>>> details from the stipulated perspective of the execution
>>> trace in C according to the semantics of C makes you
>>> a damned liar even when referring to the mathematical
>>> abstraction.
>> 
>> If you want your C functions to correspond to recursive
>> functions in computation theory, you have to code them
>> according to certain rules.
>> 
>> One of those is that you may not conclude that if f1 != f2 (pointer
>> comparison) then they are different functions.
>> 
>
> HHH1 is at line  589 -  665
> HHH  is at line 1081 - 1156
>
> https://github.com/plolcott/x86utm/blob/master/Halt7.c
> When DD calls HHH through of C interpreter
> it does not call HHH1 because HHH1 has a
> different name and is at a different location.

That's just the thing! If this were correctly implemented then in fact
DD /wold be/ calling HHH1, using the name HHH.

Just like if I call you Peter, I'm addressing Olcott.

There is no such thing as HHH1 being the same as HHH, except that it's
not called by DD.

The situation can occur among the procedures of a procedural program,
whch are not modeling recursive functions in computation theory.

> When you show that you know this
> https://www.nongnu.org/txr/
> no one is going to think you are too stupid
> to know how C interpreters work.

The problem is that a collection of C functions don't correspond to the
recursive primtive functions in computation theory, unless you take very
careful measures.

Those measures are not required in software development in C,
though some aspects of them can be helpful in that endeavor.

It's not simply a problem of knowing C or not.

You've more or less correctly implemented incorrect /requirements/.

The requirements don't come from the semantics of C.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#123059 — Re: Dangerous Precipice that could end all life --- DD simulated by HHH

On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
> On 2025-11-23, olcott <polcott333@gmail.com> wrote:
>> On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>> On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
>>>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>>>> is exactly the same as HHH except that DD does not
>>>>>> call HHH1(DD) in recursive simulation.
>>>>>
>>>>> I already pointed out the massive problem with this.
>>>>>
>>>>> If HHH1 is identical to HHH, it means that HHH1 and HHH
>>>>> are only different names for exactly the same function.
>>>>>
>>>>
>>>> In the mathematical abstraction that simply pretends
>>>> the behavioral details don't exist the math itself is
>>>> also a damned liar.
>>>
>>> The fact that two different names are used to refer to exactly the same
>>> function does not constitute a "behavior detail" of that function.
>>>
>>>> That you are trying to get away with ignoring these
>>>> details from the stipulated perspective of the execution
>>>> trace in C according to the semantics of C makes you
>>>> a damned liar even when referring to the mathematical
>>>> abstraction.
>>>
>>> If you want your C functions to correspond to recursive
>>> functions in computation theory, you have to code them
>>> according to certain rules.
>>>
>>> One of those is that you may not conclude that if f1 != f2 (pointer
>>> comparison) then they are different functions.
>>>
>>
>> HHH1 is at line  589 -  665
>> HHH  is at line 1081 - 1156
>>
>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>> When DD calls HHH through of C interpreter
>> it does not call HHH1 because HHH1 has a
>> different name and is at a different location.
> 
> That's just the thing! If this were correctly implemented then in fact
> DD /wold be/ calling HHH1, using the name HHH.
> 

*You (and everyone in the comp.lang.c group) that*
*you are a damned liar about this*

Because this and other such liars prevent truth
from becoming computable and that this can have
very dire consequences this might get you
condemned to actual Hell if such a place exists.

-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123060 — Re: Dangerous Precipice that could end all life --- DD simulated by HHH

On 11/23/2025 12:53 PM, olcott wrote:
> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>> On 2025-11-23, olcott <polcott333@gmail.com> wrote:
>>> On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
>>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>>> On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
>>>>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>>>>> is exactly the same as HHH except that DD does not
>>>>>>> call HHH1(DD) in recursive simulation.
>>>>>>
>>>>>> I already pointed out the massive problem with this.
>>>>>>
>>>>>> If HHH1 is identical to HHH, it means that HHH1 and HHH
>>>>>> are only different names for exactly the same function.
>>>>>>
>>>>>
>>>>> In the mathematical abstraction that simply pretends
>>>>> the behavioral details don't exist the math itself is
>>>>> also a damned liar.
>>>>
>>>> The fact that two different names are used to refer to exactly the same
>>>> function does not constitute a "behavior detail" of that function.
>>>>
>>>>> That you are trying to get away with ignoring these
>>>>> details from the stipulated perspective of the execution
>>>>> trace in C according to the semantics of C makes you
>>>>> a damned liar even when referring to the mathematical
>>>>> abstraction.
>>>>
>>>> If you want your C functions to correspond to recursive
>>>> functions in computation theory, you have to code them
>>>> according to certain rules.
>>>>
>>>> One of those is that you may not conclude that if f1 != f2 (pointer
>>>> comparison) then they are different functions.
>>>>
>>>
>>> HHH1 is at line  589 -  665
>>> HHH  is at line 1081 - 1156
>>>
>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>> When DD calls HHH through of C interpreter
>>> it does not call HHH1 because HHH1 has a
>>> different name and is at a different location.
>>
>> That's just the thing! If this were correctly implemented then in fact
>> DD /wold be/ calling HHH1, using the name HHH.
>>
> 
> *You (and everyone in the comp.lang.c group) that*
> *you are a damned liar about this*
> 
> Because this and other such liars prevent truth
> from becoming computable and that this can have
> very dire consequences this might get you
> condemned to actual Hell if such a place exists.
> 

Look in the mirror, and say liar. You would be correct?

[toc] | [prev] | [next] | [standalone]

#123062 — Re: Dangerous Precipice that could end all life --- DD simulated by HHH

On 2025-11-23, olcott <polcott333@gmail.com> wrote:
> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>> That's just the thing! If this were correctly implemented then in fact
>> DD /wold be/ calling HHH1, using the name HHH.
>
> *You (and everyone in the comp.lang.c group) that*
> *you are a damned liar about this*

Your posturing about liars makes you look like an even bigger
moron. Everything in this area is verifiable.

It is not a matter of trust.

I'm conveying ideas (and sometimes code), which anyone can check for
themselves. I'm not asking anyone take it on my word and just believe
me. (That's more or less how you operate; don't project that onto me).

If you don't understand it, so that you have to rely on trust,
that's just your lack of ability.

> Because this and other such liars prevent truth
> from becoming computable and that this can have
> very dire consequences this might get you
> condemned to actual Hell if such a place exists.

Bat shit lunacy; go see someone who is qualified
and licensed to prescribe the right meds.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#123063 — DD simulated by HHH and DD simulated by HHH1

On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
> On 2025-11-23, olcott <polcott333@gmail.com> wrote:
>> On 11/22/2025 10:00 PM, Kaz Kylheku wrote:
>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>> On 11/22/2025 11:56 AM, Kaz Kylheku wrote:
>>>>> On 2025-11-22, olcott <polcott333@gmail.com> wrote:
>>>>>> is exactly the same as HHH except that DD does not
>>>>>> call HHH1(DD) in recursive simulation.
>>>>>
>>>>> I already pointed out the massive problem with this.
>>>>>
>>>>> If HHH1 is identical to HHH, it means that HHH1 and HHH
>>>>> are only different names for exactly the same function.
>>>>>
>>>>
>>>> In the mathematical abstraction that simply pretends
>>>> the behavioral details don't exist the math itself is
>>>> also a damned liar.
>>>
>>> The fact that two different names are used to refer to exactly the same
>>> function does not constitute a "behavior detail" of that function.
>>>
>>>> That you are trying to get away with ignoring these
>>>> details from the stipulated perspective of the execution
>>>> trace in C according to the semantics of C makes you
>>>> a damned liar even when referring to the mathematical
>>>> abstraction.
>>>
>>> If you want your C functions to correspond to recursive
>>> functions in computation theory, you have to code them
>>> according to certain rules.
>>>
>>> One of those is that you may not conclude that if f1 != f2 (pointer
>>> comparison) then they are different functions.
>>>
>>
>> HHH1 is at line  589 -  665
>> HHH  is at line 1081 - 1156
>>
>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>> When DD calls HHH through of C interpreter
>> it does not call HHH1 because HHH1 has a
>> different name and is at a different location.
> 
> That's just the thing! If this were correctly implemented then in fact
> DD /wold be/ calling HHH1, using the name HHH.
> 

You are trying to get away with this lie
about the semantics of C?

int main()
{
   HHH(DD);
   HHH1(DD);
   return 0;
}

_main()
[000022c4] 55             push ebp
[000022c5] 8bec           mov ebp,esp
[000022c7] 6834220000     push 00002234 ; push DD
[000022cc] e833f3ffff     call 00001604 ; call HHH
[000022d1] 83c404         add esp,+04
[000022d4] 6834220000     push 00002234 ; push DD
[000022d9] e856f2ffff     call 00001534 ; call HHH1
[000022de] 83c404         add esp,+04
[000022e1] 33c0           xor eax,eax
[000022e3] 5d             pop ebp
[000022e4] c3             ret
Size in bytes:(0033) [000022e4]



-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123070 — Re: DD simulated by HHH and DD simulated by HHH1

On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>> That's just the thing! If this were correctly implemented then in fact
>> DD /wold be/ calling HHH1, using the name HHH.
>> 
>
> You are trying to get away with this lie
> about the semantics of C?
>
> int main()
> {
>    HHH(DD);
>    HHH1(DD);
>    return 0;
> }
>
> _main()
> [000022c4] 55             push ebp
> [000022c5] 8bec           mov ebp,esp
> [000022c7] 6834220000     push 00002234 ; push DD
> [000022cc] e833f3ffff     call 00001604 ; call HHH
> [000022d1] 83c404         add esp,+04
> [000022d4] 6834220000     push 00002234 ; push DD
> [000022d9] e856f2ffff     call 00001534 ; call HHH1
> [000022de] 83c404         add esp,+04
> [000022e1] 33c0           xor eax,eax
> [000022e3] 5d             pop ebp
> [000022e4] c3             ret
> Size in bytes:(0033) [000022e4]

That's right; even if HHH and HHH1 are separately realized and given
different adddresses, not recognized as identical by the compiler and
not folded into one copy, in a correct implementation of your software,
HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
interchangeable operations.

The problem is that you have logic which concludes that HHH1 != HHH (low
level pointer comparison), they are different functions.

If it helps, you can think about it by analogy to strings. Suppose
you had code:

  puts("Hello"):
  puts("Hello"):

and suppose that the compiler did not fold the two strings to one
object (maybe it does that, but optimization is turned off). Suppose
you see this code:

   push 0001230 ; push "Hello"
   call 0432180 ; call puts
   push 0001240 ; push "Hello"
   call 0432180 ; call puts

Do you conclude form that that "Hello" and "Hello" are different
strings, so that your program is correct in using str! != str2
for string comparison?

Think about the differences between:

- pointer equivalence

- strng equivalence

- procedure equvalence

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#123071 — Re: DD simulated by HHH and DD simulated by HHH1

On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>> That's just the thing! If this were correctly implemented then in fact
>>> DD /wold be/ calling HHH1, using the name HHH.
>>>
>>
>> You are trying to get away with this lie
>> about the semantics of C?
>>
>> int main()
>> {
>>     HHH(DD);
>>     HHH1(DD);
>>     return 0;
>> }
>>
>> _main()
>> [000022c4] 55             push ebp
>> [000022c5] 8bec           mov ebp,esp
>> [000022c7] 6834220000     push 00002234 ; push DD
>> [000022cc] e833f3ffff     call 00001604 ; call HHH
>> [000022d1] 83c404         add esp,+04
>> [000022d4] 6834220000     push 00002234 ; push DD
>> [000022d9] e856f2ffff     call 00001534 ; call HHH1
>> [000022de] 83c404         add esp,+04
>> [000022e1] 33c0           xor eax,eax
>> [000022e3] 5d             pop ebp
>> [000022e4] c3             ret
>> Size in bytes:(0033) [000022e4]
> 
> That's right; even if HHH and HHH1 are separately realized and given
> different adddresses, not recognized as identical by the compiler and
> not folded into one copy, in a correct implementation of your software,
> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
> interchangeable operations.
> 

Except when their input calls themself.
In this case they must simulate themselves
simulating their input, not just simulate
their input.


-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

#123077 — Re: DD simulated by HHH and DD simulated by HHH1

On 11/24/25 17:45, olcott wrote:

>>> [000022e1] 33c0           xor eax,eax
>>> [000022e3] 5d             pop ebp
>>> [000022e4] c3             ret
>>> Size in bytes:(0033) [000022e4]
>>
>> That's right; even if HHH and HHH1 are separately realized and given
>> different adddresses, not recognized as identical by the compiler and
>> not folded into one copy, in a correct implementation of your software,
>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>> interchangeable operations.

> Except when their input calls themself.
> In this case they must simulate themselves
> simulating their input, not just simulate
> their input.

    I've got a Sun U5, with a Sparc64 CPU, and I'm thinking
    about running your ultimate proof about the end of the
    universe.

    How portable is your software in this alternate universe?
    And (this is just an absurd hypothesis, don't take it as a
    personnal attack) can this famous proof of the end of the
    world run on other deviant processors such as the z80 or
    the ipax432 ?

-- 
**                                                            **
*                      tTh des Bourtoulots                     *
*                  http://maison.tth.netlib.re/                *
**                                                            **

[toc] | [prev] | [next] | [standalone]

#123076 — Re: DD simulated by HHH and DD simulated by HHH1

On 11/24/2025 11:55 AM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 10:32 AM, Kaz Kylheku wrote:
>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>> On 11/22/2025 11:24 PM, Kaz Kylheku wrote:
>>>>> That's just the thing! If this were correctly implemented then in fact
>>>>> DD /wold be/ calling HHH1, using the name HHH.
>>>>>
>>>>
>>>> You are trying to get away with this lie
>>>> about the semantics of C?
>>>>
>>>> int main()
>>>> {
>>>>      HHH(DD);
>>>>      HHH1(DD);
>>>>      return 0;
>>>> }
>>>>
>>>> _main()
>>>> [000022c4] 55             push ebp
>>>> [000022c5] 8bec           mov ebp,esp
>>>> [000022c7] 6834220000     push 00002234 ; push DD
>>>> [000022cc] e833f3ffff     call 00001604 ; call HHH
>>>> [000022d1] 83c404         add esp,+04
>>>> [000022d4] 6834220000     push 00002234 ; push DD
>>>> [000022d9] e856f2ffff     call 00001534 ; call HHH1
>>>> [000022de] 83c404         add esp,+04
>>>> [000022e1] 33c0           xor eax,eax
>>>> [000022e3] 5d             pop ebp
>>>> [000022e4] c3             ret
>>>> Size in bytes:(0033) [000022e4]
>>>
>>> That's right; even if HHH and HHH1 are separately realized and given
>>> different adddresses, not recognized as identical by the compiler and
>>> not folded into one copy, in a correct implementation of your software,
>>> HHH(DD) and HHH1(DD) would behave as indistinguishable, mutually
>>> interchangeable operations.
>>>
>>> The problem is that you have logic which concludes that HHH1 != HHH (low
>>> level pointer comparison), they are different functions.
>>>
>>
>> Except when their input calls themself.
> 
> That makes no difference.
> 

typedef int (*ptr)();
int HHH(ptr P);
int HHH1(ptr P);

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   HHH(DD);
   HHH1(DD);
}

HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...

HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.


-- 
Copyright 2025 Olcott

My 28 year goal has been to make
"true on the basis of meaning" computable.

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c++

csiph-web