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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> 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);

Please, don't post this repeated crap any more.

When I say "that makes no difference", I'm saying that it makes no
difference in the theory and therefore /must not/ make any difference
in your exploratory code.

You a must have the skill and know-how to write the key details of your
C code such that it is ensured that HHH1(P) and HHH(P) are 
interchangeable, equivalent expressions, such that substituting
one for the other.

Those details are not present in the code you are pasting here,
so it is absolutely pointless:

> 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.

So you basically lack the capacity for the abstract thinking
required to do computer science at the first year level.

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

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

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

On 11/24/2025 1:30 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> 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);
> 
> Please, don't post this repeated crap any more.
> 

As long as you keep lying I will keep repeating it.
If five people from comp.lang.c confirm that you
are lying and I am correct then I will quit posting it.

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]

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

On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> As long as you keep lying I will keep repeating it.

To lie is to knowing post something that is false.

But if you do that about an objectively verifiable fact that has nothing
to do with yourself, but some scientific matter, nobody in their right
mind will see you as a liar.

Rather than see you as a liar, they will just assume you are ignorant
and incompetent.

What makes you think I, or Mike, or anyone here would write something I
know to be false, which would be interpreted as ignorant, rather than
dishonest?

Maybe you don't understand that nobody would do that, since
you have no problem being casually wrong yourself.

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

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

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

On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> As long as you keep lying I will keep repeating it.
> 
> To lie is to knowing post something that is false.
> 
> But if you do that about an objectively verifiable fact that has nothing
> to do with yourself, but some scientific matter, nobody in their right
> mind will see you as a liar.
> 
> Rather than see you as a liar, they will just assume you are ignorant
> and incompetent.
> 
> What makes you think I, or Mike, or anyone here would write something I
> know to be false, which would be interpreted as ignorant, rather than
> dishonest?
> 
> Maybe you don't understand that nobody would do that, since
> you have no problem being casually wrong yourself.
> 

The people on comp.lang.c or comp.lang.c++
can always speak up.

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)...
that never stops running until aborted

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]

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

[Follow-ups set]

On 24/11/2025 23:23, olcott wrote:
> On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> As long as you keep lying I will keep repeating it.
>> 
>> To lie is to knowing post something that is false.
>> 
>> But if you do that about an objectively verifiable fact
>> that has nothing to do with yourself, but some scientific
>> matter, nobody in their right mind will see you as a liar.
>> 
>> Rather than see you as a liar, they will just assume you
>> are ignorant and incompetent.
>> 
>> What makes you think I, or Mike, or anyone here would
>> write something I know to be false, which would be
>> interpreted as ignorant, rather than dishonest?
>> 
>> Maybe you don't understand that nobody would do that, since 
>> you have no problem being casually wrong yourself.
>> 
> 
> The people on comp.lang.c or comp.lang.c++ can always speak
> up.

They have done so, many times. They have told you many times that
you are wrong. You don't care, of course.

> 
> 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

The rules of C offer no mechanism for HHH to be able to simulate 
any C function using nothing but a function pointer. The closest 
you can get is to dereference it, but you don't do that. Your 
'simulation' doesn't simulate any part of DD past the call in its 
first line, and you can only do that because of a 
platform-specific hack that breaks the rules of C.

You have been told this many times, but you're not interested in 
truth or competence., so (as Kaz rightly said) we all have to 
assume that you are ignorant and incompetent.

Followups set to comp.theory only, because nobody has anything to 
gain from your cross-posting to language experts whose expert 
opinions you invariably ignore.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

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

On 11/24/2025 1:30 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 12:12 PM, Mike Terry wrote:
>>> Right - in terms of their results when called.
>>
>> So stupidly incorrect that I can't believe
>> that Mike believes this.
> 
> Maybe the stupid one is you, and other people who are agree with each
> other are right?
> 
> Naaaah, that could not possibly be ...
> 
> You must have deep connections in the US Department of Defense;
> otherwise, how the hell did you get your hands on such a
> high weapons-grade Dunning Kruger ...
> 

That you only have mere empty rhetoric that
has no basis seems to prove that you know
that you are not telling the truth.

-- 
Copyright 2025 Olcott

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

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

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

On 11/24/2025 4:25 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 1:30 PM, Kaz Kylheku wrote:
>>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>>> On 11/24/2025 12:12 PM, Mike Terry wrote:
>>>>> Right - in terms of their results when called.
>>>>
>>>> So stupidly incorrect that I can't believe
>>>> that Mike believes this.
>>>
>>> Maybe the stupid one is you, and other people who are agree with each
>>> other are right?
>>>
>>> Naaaah, that could not possibly be ...
>>>
>>> You must have deep connections in the US Department of Defense;
>>> otherwise, how the hell did you get your hands on such a
>>> high weapons-grade Dunning Kruger ...
>>>
>>
>> That you only have mere empty rhetoric that
>> has no basis seems to prove that you know
>> that you are not telling the truth.
> 
> Are you saying you are disappointed that your relevant and
> substantial bit of rhetoric above, namely;
> 
>    "So stupidly incorrect that I can't believe mike believes this"
> 
> did not elicit an equally deep followup?
> 

I presented correct reasoning many thousands of times.

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)...
that never stops running until aborted

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]

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

On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>> On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
>>> On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>> On 24/11/2025 16:32, 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.
>>>>
>>>> Right - in terms of their results when called.
>>>>
>>>> But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
>>>> there's no reason that an emulator emulating the TM is required to identify such copies as being
>>>> copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
>>>> multiple copies of the same algorithm with different state labels...  Your point that the /results/
>>>> of those copied algorithms must be the same is spot on though.
>>>
>>> Olcott's simulator contains abort criteria which rely on comparing
>>> addresses pulled from the trace buffer.
>>>
>>> That logic concludes that when two addresses are not equal, they
>>> represent two different functions. I.e. if CALL X  and CALL Y occur in
>>> the trace buffer, without any intervening conditionals in between but X
>>> != Y, then it is not concluded that it is a loop.
>>>
>>
>> DD is calling HHH(DD) in recursive simulation
>> and DD is not calling HHH1(DD) in recursive
>> simulation.
> 
> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
> 
>> I do not believe that you do not
>> understand this.
> 
> Indeed, I do, of course. I'm just saying that it's an incorrect
> state of affairs.
> 

That wold be a lie.
It is like you are trying to get away with saying
that identical twins are one and the same person.


The identity of indiscernibles is an ontological principle
that states that there cannot be separate objects or entities
that have all their properties in common.
https://en.wikipedia.org/wiki/Identity_of_indiscernibles

Even if identical twins had every single atom that
was identical they these atoms differ in their x,y,z
coordinates relative to the center of the Earth.

> The fact that you keep reiterating about how things /are/ in your
> code, when I'm making effort to clarify that I'm talking about how
> they are /supposed/ to be, shows me you are not comprehending
> what you are reading.
> 
>> Anyone that even knows what
>> ordinary recursion is should get this
> 
> The point is that there isn't /supposed/ to be a difference
> between "DD is calls HHH" and "DD is calling HHH1".
> 

You keep thinking in mathematical terms that abstract
away (thus simply ignore) key differences.

> We (you, me, anyone else who runs the code) do see a difference.
> There is no denying that.
> 
>> HHH and HHH1 both see if the same function is
>> called from the same machine address with the
>> same arguments. This is true for HHH(DD) and
>> not true for HHH1(DD).
> 
> You believe that HHH1 is a different function from HHH because
> DDD calls HHH and does not call HHH1.
> 

You really can't be stupid enough to not see the
different execution trace.

> That, I'm saying, is not a valid concept.
> 
> The actual reason is that you are failing to identify HHH
> and HHH1 as equivalent by using address comparisons.
> 

That essentially prove that identical twins are not
one and the same person.

the comp.lang.c and comp.lang.c++ groups will
continue to be presented with your non-sense
until they call you out on it.

> The same function can be known under multiple addresses, just
> like under different names. That's an implementation detail you
> have to abstract away if you want to correctly model pure, recursive
> functions which behave like their mathematical counterparts in key ways.
> 


-- 
Copyright 2025 Olcott

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

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

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

On 11/24/2025 3:19 PM, olcott wrote:
> On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
>>>> On 2025-11-24, Mike Terry 
>>>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>>> On 24/11/2025 16:32, 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.
>>>>>
>>>>> Right - in terms of their results when called.
>>>>>
>>>>> But TM-descriptions can legitimately contain multiple distinct 
>>>>> copies of "the same algorithm", and
>>>>> there's no reason that an emulator emulating the TM is required to 
>>>>> identify such copies as being
>>>>> copies - an emulator just has to mimic what the TM would do and the 
>>>>> TM doesn't know that it has
>>>>> multiple copies of the same algorithm with different state 
>>>>> labels...  Your point that the /results/
>>>>> of those copied algorithms must be the same is spot on though.
>>>>
>>>> Olcott's simulator contains abort criteria which rely on comparing
>>>> addresses pulled from the trace buffer.
>>>>
>>>> That logic concludes that when two addresses are not equal, they
>>>> represent two different functions. I.e. if CALL X  and CALL Y occur in
>>>> the trace buffer, without any intervening conditionals in between but X
>>>> != Y, then it is not concluded that it is a loop.
>>>>
>>>
>>> DD is calling HHH(DD) in recursive simulation
>>> and DD is not calling HHH1(DD) in recursive
>>> simulation.
>>
>> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>>
>>> I do not believe that you do not
>>> understand this.
>>
>> Indeed, I do, of course. I'm just saying that it's an incorrect
>> state of affairs.
>>
> 
> That wold be a lie.
> It is like you are trying to get away with saying
> that identical twins are one and the same person.
> 
> 
> The identity of indiscernibles is an ontological principle
> that states that there cannot be separate objects or entities
> that have all their properties in common.
> https://en.wikipedia.org/wiki/Identity_of_indiscernibles
> 
> Even if identical twins had every single atom that
> was identical they these atoms differ in their x,y,z
> coordinates relative to the center of the Earth.
> 
>> The fact that you keep reiterating about how things /are/ in your
>> code, when I'm making effort to clarify that I'm talking about how
>> they are /supposed/ to be, shows me you are not comprehending
>> what you are reading.
>>
>>> Anyone that even knows what
>>> ordinary recursion is should get this
>>
>> The point is that there isn't /supposed/ to be a difference
>> between "DD is calls HHH" and "DD is calling HHH1".
>>
> 
> You keep thinking in mathematical terms that abstract
> away (thus simply ignore) key differences.
> 
>> We (you, me, anyone else who runs the code) do see a difference.
>> There is no denying that.
>>
>>> HHH and HHH1 both see if the same function is
>>> called from the same machine address with the
>>> same arguments. This is true for HHH(DD) and
>>> not true for HHH1(DD).
>>
>> You believe that HHH1 is a different function from HHH because
>> DDD calls HHH and does not call HHH1.
>>
> 
> You really can't be stupid enough to not see the
> different execution trace.
> 
>> That, I'm saying, is not a valid concept.
>>
>> The actual reason is that you are failing to identify HHH
>> and HHH1 as equivalent by using address comparisons.
>>
> 
> That essentially prove that identical twins are not
> one and the same person.

Are you an idiot, a moron, or both? Your twin is an idiotic moron 
instead of just a moron?


> 
> the comp.lang.c and comp.lang.c++ groups will
> continue to be presented with your non-sense
> until they call you out on it.
> 
>> The same function can be known under multiple addresses, just
>> like under different names. That's an implementation detail you
>> have to abstract away if you want to correctly model pure, recursive
>> functions which behave like their mathematical counterparts in key ways.
>>
> 
> 

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

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

On 11/24/2025 4:15 PM, Chris M. Thomasson wrote:
[...]

God damn it! Sorry.

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

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

On 2025-11-24, olcott <polcott333@gmail.com> wrote:
> On 11/24/2025 4:22 PM, Kaz Kylheku wrote:
>> On 2025-11-24, olcott <polcott333@gmail.com> wrote:
>>> On 11/24/2025 1:27 PM, Kaz Kylheku wrote:
>>>> On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>>> On 24/11/2025 16:32, 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.
>>>>>
>>>>> Right - in terms of their results when called.
>>>>>
>>>>> But TM-descriptions can legitimately contain multiple distinct copies of "the same algorithm", and
>>>>> there's no reason that an emulator emulating the TM is required to identify such copies as being
>>>>> copies - an emulator just has to mimic what the TM would do and the TM doesn't know that it has
>>>>> multiple copies of the same algorithm with different state labels...  Your point that the /results/
>>>>> of those copied algorithms must be the same is spot on though.
>>>>
>>>> Olcott's simulator contains abort criteria which rely on comparing
>>>> addresses pulled from the trace buffer.
>>>>
>>>> That logic concludes that when two addresses are not equal, they
>>>> represent two different functions. I.e. if CALL X  and CALL Y occur in
>>>> the trace buffer, without any intervening conditionals in between but X
>>>> != Y, then it is not concluded that it is a loop.
>>>>
>>>
>>> DD is calling HHH(DD) in recursive simulation
>>> and DD is not calling HHH1(DD) in recursive
>>> simulation.
>> 
>> Yes, clearly; yet HHH1 and HHH are the same. So how can that be?
>> 
>>> I do not believe that you do not
>>> understand this.
>> 
>> Indeed, I do, of course. I'm just saying that it's an incorrect
>> state of affairs.
>> 
>
> That wold be a lie.

I would not say anything that would be interpreted as wrong; nobody who
finds it wrong would think that I'm lying, only that I am misinformed
and ignorant. The last thing I want is to be misinformed and ignorant,
misinforming others.

> It is like you are trying to get away with saying
> that identical twins are one and the same person.

No, it's like I'm saying that Peter and Olcott, in the context of
comp.theory, are one person and not identical twins.

Twins is not a great analogy, but within that analogy that's
how it is.

If HHH and HHH1 have the same definition, they are supposed
to be the same function and not just identical twins.

Two people who are exactly the same down to the atom (not just
identical twins) are still different individuals bedcause
they have a separate mental state. If you were cloned in a
Star-Trek-like matter replicator, there would be two individuals.
They would share the same memories of the past, but forge new
experiences.

Functions in computation theory must not have state. Thus,
they are not like people. (There are ways to model state, as such,
with functions, but an individual function doesn't have state,
by definition.)

Two identical definitions, or nearly identical definitions that
have different names only, are of one function, not "twins".

Yes, your HHH1 and HHH do have state, like separate static
execution trace pointers pointing to different buffers when those
are allocated. That is one thing that is wrong.

If that were fixed, you would still have to make sure that
HHH1 and HHH compare as equal.

(At that point, it would be best to just drop HHH1 since
an additional name for the same function just adds potential
for confusion. The reason you maintain HHH1 is that you believe
it serves some purpose in your understanding, but the underpinnings
are flawed due to the above issues.)

> The identity of indiscernibles is an ontological principle
> that states that there cannot be separate objects or entities
> that have all their properties in common.
>
> https://en.wikipedia.org/wiki/Identity_of_indiscernibles

All the properties of a recursive function in computation theory
are encoded in its definition.

If HHH and HHH1 share the same definition, and are properly
pure functions, then they are indiscernible.

There is another principle in that there cannot be separate objects,
in some context, which have all their /relevant properties/
in common.

A recursive function modeled in C in two ways can result in
two instances that do not share an /irrelevant/ property,
such as address.

You must not bring in irrelevant properties and make them significant,
because then inappropriate details are leaking from the
implementation into the abstract model.

>> The point is that there isn't /supposed/ to be a difference
>> between "DD is calls HHH" and "DD is calling HHH1".
>> 
>
> You keep thinking in mathematical terms that abstract
> away (thus simply ignore) key differences.

No! I'm specifically pointing out differences in properties
that are not relevant and must not be allowed to make a difference.

Key differences must never be ignored, needless to say.

>
>> We (you, me, anyone else who runs the code) do see a difference.
>> There is no denying that.
>> 
>>> HHH and HHH1 both see if the same function is
>>> called from the same machine address with the
>>> same arguments. This is true for HHH(DD) and
>>> not true for HHH1(DD).
>> 
>> You believe that HHH1 is a different function from HHH because
>> DDD calls HHH and does not call HHH1.
>
> You really can't be stupid enough to not see the
> different execution trace.

Yes, but it's not supposed to be like that. You fudged things
incorrectly to make them different, in multiple ways.

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

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

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

On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
> On 2025-11-24, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>> For HHH/HHH1 the issue is different - they are clearly different algorithms since they give
>> different results, but it's not pointer comparison that is the problem - it's the use of mutable
>> global data:  HHH and HHH1 each use /their own/ global variable [viz their global trace tables]
>> within their algorithms.
> 
> Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
> functions since they react to this mutating state.
> 
> Multiplie instances of HHH share an execution trace buffer, allocated
> by the first call to HHH.
> 
> Multiple instances of HHH1 also share an execution trace buffer distinct
> from that one allocated by the first call to HHH1.
> 
> Simulations conducted by any level of HHH only feed HHH's buffer,
> and simulations conducted by any level of HHH1 only feed HHH1's buffer.
> 
> That is all gapingly incorrect; yet if these aspects were fixed, there
> would still be a problem if we evaluate HHH1 != HHH as dincating that
> they are different function.
> 
>> It so happens that in this case, the global data is a static variable, and
>> so it /appears/ at first glance as though they are the same - they have the same name in both
> 
> Olcott maintains that the only differenc ebetween HHH1 and HHH is
> that DD calls HHH and not HHH1. Obviously that is false.
> 

That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference
That is the key difference

>> One way to fix this [akin to my H/H1 fix], would be to make HHH1 processing match HHH, e.g. change
>> both HHH/HHH1 to use a common global-scope variable rather than a static-cope ones.  This leaves the
>> underlying problems of invalid global data use, but at least HHH/HHH1 are now equivalent.  The
>> proper way of fixing the problem would be to get rid of the improper use of global data in both
>> HHH/HHH1.  With either of these fixes HHH and HHH1 would produce the same result [neverhalts].
> 
> Olcott thinks that by moving the static data into the code space of the
> function, and using asssembly instructions and whatnot, such that the C
> keyword "static" does not appear, means that he has fixed the issue of
> relying on static data.
> 


-- 
Copyright 2025 Olcott

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

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

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

On 2025-11-24, olcott <NoOne@NoWhere.com> wrote:
> On 11/24/2025 4:45 PM, Kaz Kylheku wrote:
>> Olcott maintains that the only differenc ebetween HHH1 and HHH is
>> that DD calls HHH and not HHH1. Obviously that is false.
>> 
>
> That is the key difference

But that difference in the run-time of the system you have built is
propped up by bugs:

- relying on mutable static state, of which HHH and HHH1 have their own
  instance.

- comparing function addresses as the basis of equality and inequality

- ...

> That is the key difference

If you properly coded HHH1 and HHH as pure functions that are identical,
and compared equal even if they have different addresses, then there
would be no difference between HHH(DD) and HHH1(DD).

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

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

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

On 11/24/2025 5:33 PM, Mike Terry wrote:
> On 24/11/2025 19:27, Kaz Kylheku wrote:
>> On 2025-11-24, Mike Terry 
>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> On 24/11/2025 16:32, 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.
>>>
>>> Right - in terms of their results when called.
>>>
>>> But TM-descriptions can legitimately contain multiple distinct copies 
>>> of "the same algorithm", and
>>> there's no reason that an emulator emulating the TM is required to 
>>> identify such copies as being
>>> copies - an emulator just has to mimic what the TM would do and the 
>>> TM doesn't know that it has
>>> multiple copies of the same algorithm with different state labels...  
>>> Your point that the /results/
>>> of those copied algorithms must be the same is spot on though.
>>
>> Olcott's simulator contains abort criteria which rely on comparing
>> addresses pulled from the trace buffer.
> 
> Yep.  There are two such comparisons:
> -   the addresses of the CALL instructions are compared
> -   the targets of the CALL instructions are compared
> 
>>
>> That logic concludes that when two addresses are not equal, they
>> represent two different functions. I.e. if CALL X  and CALL Y occur in
>> the trace buffer, without any intervening conditionals in between but X
>> != Y, then it is not concluded that it is a loop.
> 
> Yep.  That's not actually a problem.  Possibly a genuine loop might be 
> overlooked, but the point is that if the addresses /do/ match that could 
> be a loop (subject to the other conditions matching).
> 
> Hmm, maybe you're thinking that HHH/HHH1 are comparing trace addresses 
> against /their own/ addresses?  They don't do that.  [H/H1 do that.]  
> All compared addresses (whether by HHH/HHH1) are trace addresses from 
> the DD() simulation, which is the same whether HHH or HHH1 is doing the 
> emulation [up to the point HHH aborts and HHH1 carries on].  So if you 
> were right, the behaviour would in any case be the same for HHH/HHH1 and 
> couldn't account for differing HHH/HHH1 results.
> 
>>
>> That is why HHH1 and HHH show different results, even though they are
>> identical.
>>
>> That comparison is the root cause why it matters that DD calls HHH
>> and not HHH1.
> 
> Not so, but I'll perform the test...
> 
> A complication:  there are TWO occasions where trace address comparisons 
> occur, as I listed above: the TARGETS of the two call instructions are 
> compared, and the ADDRESSES of the call instructions are compared.
> 
> You want to equate "equivalent" addresses.  For the TARGET addresses 
> this is easy-peasy as I will just check if they are both HHH/HHH1.  For 
> the CALL instruction addresses, these will not be HHH/HHH1, but 
> logically the CALL addresses in different (equivalent) routines should 
> be considered equivalent???  What would you like done here?  [Perhaps if 
> addresses are at the same offset within HHH/HHH1 they could be 
> considered equivalent.  That's a slight pain, but doable.]
> 
> You know what - I've just realised HHH/HHH1 are only called from DD, and 
> there's only one DD so this issue doesn't matter in our scenario!  The 
> CALL instruction addresses will always be the same when HHH/HHH1 are 
> called.  I'll just ignore the issue for now.  (I'll trace the 
> comparisons and results so we can check this in the logs.)
> 
>>
>> Olcott wrongly believes that the fact of DD calling HHH and not HHH1 is
>> the root cause of the difference.
> 
> Well that's PO for you!  It's simply that HHH/HHH1 are different 
> algorithms (each working off their own static trace table).
> 
>>
>> If addressees are compared with a CompareFunctions(X, Y) function
>> whch ensures that HHH and HHH1 are considered equal, then that
>> difference will disappear.
> 
> But there will still be the problem I explained with the HHH/HHH1 
> having /their own/ static trace tables...
> 
> 
> Mike.
> 

It is a matter of verified fact that

DD simulated by HHH does involve HHH simulating
an instance of itself simulating an instance of DD

and

DD simulated by HHH1 never involves HHH1 simulating
an instance of itself simulating an instance of DD

For people with great difficulty paying attention
For people with great difficulty paying attention
For people with great difficulty paying attention
For people with great difficulty paying attention

DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.
DOES INVOLVE and NEVER INVOLVES are not the same thing.

-- 
Copyright 2025 Olcott

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

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

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

On 11/25/2025 1:19 PM, Mike Terry wrote:
> On 24/11/2025 22:45, Kaz Kylheku wrote:
>> On 2025-11-24, Mike Terry 
>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>> For HHH/HHH1 the issue is different - they are clearly different 
>>> algorithms since they give
>>> different results, but it's not pointer comparison that is the 
>>> problem - it's the use of mutable
>>> global data:  HHH and HHH1 each use /their own/ global variable [viz 
>>> their global trace tables]
>>> within their algorithms.
>>
>> Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
>> functions since they react to this mutating state.
>>
>> Multiplie instances of HHH share an execution trace buffer, allocated
>> by the first call to HHH.
>>
>> Multiple instances of HHH1 also share an execution trace buffer distinct
>> from that one allocated by the first call to HHH1.
>>
>> Simulations conducted by any level of HHH only feed HHH's buffer,
>> and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
> 
> Exactly.  That explains why HHH and HHH1 are not proper clones of each 
> other [whatever PO claims], and hence why they produce different results.
> 

So you are really trying to get away with pretending
to be too stupid that you have no idea that recursive
simulation defines behavior that cannot terminate normally?

https://github.com/plolcott/x86utm/blob/master/Halt7.c
Simulating termination analyzer HHH and input DD
have been a fully operational software system for
more than three years.

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)...
that never stops running until aborted

HHH1 simulates DD that calls HHH(DD) that
returns to DD that returns to HHH1.
(when HHH(DD) sees the repeating pattern)



So HHH is still a Turing computable function?

Yes.

HHH with static data is still a Turing computable function.

**Reasoning:**

Turing machines fundamentally perform:
- Read from memory (tape)
- Write to memory (tape)
- Conditional logic based on memory contents

HHH using static data performs:
- Read from static memory
- Write to static memory
- Conditional logic based on static memory contents

These are the same basic operations.

**Key Point:**
Turing machines operate on infinite memory tape where the head reads 
symbols and writes symbols .

Static variables are simply named memory locations that persist across 
function calls.

Using static variables does not introduce any operation beyond what 
Turing machines can perform.

**Conclusion:**
HHH is Turing computable, just not a pure function.

Turing computability ≠ purity requirement.

https://claude.ai/share/214ba469-3f43-4407-b680-527ec9f7a05b

-- 
Copyright 2025 Olcott

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

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

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

On 2025-11-25, olcott <polcott333@gmail.com> wrote:
> On 11/25/2025 1:19 PM, Mike Terry wrote:
>> On 24/11/2025 22:45, Kaz Kylheku wrote:
>>> On 2025-11-24, Mike Terry 
>>> <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>> For HHH/HHH1 the issue is different - they are clearly different 
>>>> algorithms since they give
>>>> different results, but it's not pointer comparison that is the 
>>>> problem - it's the use of mutable
>>>> global data:  HHH and HHH1 each use /their own/ global variable [viz 
>>>> their global trace tables]
>>>> within their algorithms.
>>>
>>> Yes; this is an issue that I'm glossing over. HHH and HHH1 are not pure
>>> functions since they react to this mutating state.
>>>
>>> Multiplie instances of HHH share an execution trace buffer, allocated
>>> by the first call to HHH.
>>>
>>> Multiple instances of HHH1 also share an execution trace buffer distinct
>>> from that one allocated by the first call to HHH1.
>>>
>>> Simulations conducted by any level of HHH only feed HHH's buffer,
>>> and simulations conducted by any level of HHH1 only feed HHH1's buffer.a
>> 
>> Exactly.  That explains why HHH and HHH1 are not proper clones of each 
>> other [whatever PO claims], and hence why they produce different results.
>> 
>
> So you are really trying to get away with pretending
> to be too stupid that you have no idea that recursive
> simulation defines behavior that cannot terminate normally?

Rather, youa re adctually too stupid to realize that recursive
simulation doesn't require the particpating simulations
to be terminating.

I explained it using threads, but you don't understand those,
either:

 vod thread_func(void)
 {
    thread_start(thread_func);
    thread_exit(0);
 }

If we call this function from some mainline, it will start
a thread on itself. That thread against starts a thread and
so on, right? You follow that.

But each thread is terminating! It deos two things: start
a new thread, and terminate by returning thread_exit.

The "application" doesn't terminate, but the threads
are terminating.

The question "does thread_func terminate" is separate
from "does the application main() { thread_func(); }
temrinate".

You are tryng to apply the answer for one to the other.

There is no loop or recursion; in fact the application doesn't even
contain a conditional statement!  main unconditionally calls
thread_func, which unconditionally calls thread_start, and
unconditionally terminates.


> https://github.com/plolcott/x86utm/blob/master/Halt7.c
> Simulating termination analyzer HHH and input DD
> have been a fully operational software system for
> more than three years.

That does not operate in such a way that it corroborates
the rhetoric you've predicated on it.

The entities inside it do not correspond to the theory,
and so it doesn't meet the requirements for evaluating
the halting problem.

> **Conclusion:**
> HHH is Turing computable, just not a pure function.

That's a contradiction.

When we say something is Turing computable, we mean that we have
identified the manner in which we can model it as a pure function of
inputs.

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

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

#123093

Am 06.11.2025 um 21:48 schrieb olcott:
> D simulated by H cannot possibly reach its own
> simulated final halt state.
>
> I am not going to talk about any non-nonsense of
> resuming a simulation after we already have this
> final answer.
>
> We just proved that the input to H(D) specifies
> non-halting. Anything beyond this is flogging a
> dead horse.
>
>
> news://news.eternal-september.org/20251104183329.967@kylheku.com
>
> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
> > On 2025-11-05, olcott <polcott333@gmail.com> wrote:
> >>
> >> The whole point is that D simulated by H
> >> cannot possbly reach its own simulated
> >> "return" statement no matter what H does.
> >
> > Yes; this doesn't happen while H is running.
> >
> > So while H does /something/, no matter what H does,
> > that D simulation won't reach the return statement.
> >
>
What you do is like thinking in circles before falling asleep.
It never ends. You're gonna die with that for sure sooner or later.

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

#123094

On 11/25/2025 9:20 AM, Bonita Montero wrote:
> Am 06.11.2025 um 21:48 schrieb olcott:
>> D simulated by H cannot possibly reach its own
>> simulated final halt state.
>>
>> I am not going to talk about any non-nonsense of
>> resuming a simulation after we already have this
>> final answer.
>>
>> We just proved that the input to H(D) specifies
>> non-halting. Anything beyond this is flogging a
>> dead horse.
>>
>>
>> news://news.eternal-september.org/20251104183329.967@kylheku.com
>>
>> On 11/4/2025 8:43 PM, Kaz Kylheku wrote:
>> > On 2025-11-05, olcott <polcott333@gmail.com> wrote:
>> >>
>> >> The whole point is that D simulated by H
>> >> cannot possbly reach its own simulated
>> >> "return" statement no matter what H does.
>> >
>> > Yes; this doesn't happen while H is running.
>> >
>> > So while H does /something/, no matter what H does,
>> > that D simulation won't reach the return statement.
>> >
>>
> What you do is like thinking in circles before falling asleep.
> It never ends. You're gonna die with that for sure sooner or later.
> 

I now have four different LLM AI models that prove
that I am correct on the basis that they derive the
proof steps that prove that I am correct.

Even Kimi that was dead set against me now fully
understands my new formal foundation for correct
reasoning.

-- 
Copyright 2025 Olcott

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

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

#123095

Am 25.11.2025 um 16:47 schrieb olcott:
> On 11/25/2025 9:20 AM, Bonita Montero wrote:
>> What you do is like thinking in circles before falling asleep.
>> It never ends. You're gonna die with that for sure sooner or later.
>>
>
> I now have four different LLM AI models that prove
> that I am correct on the basis that they derive the
> proof steps that prove that I am correct.
It don't matters if you're correct. There's no benefit in discussing
such a theoretical topic for years. You won't even stop if everyone
tells you're right.
>
> Even Kimi that was dead set against me now fully
> understands my new formal foundation for correct
> reasoning.
>

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

#123096

On 11/25/2025 9:50 AM, Bonita Montero wrote:
> Am 25.11.2025 um 16:47 schrieb olcott:
>> On 11/25/2025 9:20 AM, Bonita Montero wrote:
>>> What you do is like thinking in circles before falling asleep.
>>> It never ends. You're gonna die with that for sure sooner or later.
>>>
>>
>> I now have four different LLM AI models that prove
>> that I am correct on the basis that they derive the
>> proof steps that prove that I am correct.

> It don't matters if you're correct. There's no benefit in discussing
> such a theoretical topic for years. You won't even stop if everyone
> tells you're right.

My whole purpose of this has been to establish a
new foundation for correct reasoning that gets rid
of Gödel Incompleteness and Tarski Undefinability
such that Boolean True(Language L Expression E) is
consistent and correct for the whole body of
knowledge that can be expressed in language.

The timing for such a system is perfect because it
could solve the LLM AI reliability issues. Once
it does that I will no longer need to talk about
it on conventional forums. At that point all of
my talks will be formal presentations at symposiums.

>>
>> Even Kimi that was dead set against me now fully
>> understands my new formal foundation for correct
>> reasoning.
>>
> 


-- 
Copyright 2025 Olcott

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

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

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

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

csiph-web