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

Groups > comp.theory > #135704 > unrolled thread

Are the H(D) in main and the H(D) in D the same?

Back to article view | Back to comp.theory

Contents

  Are the H(D) in main and the H(D) in D the same? wij <wyniijj5@gmail.com> - 2025-11-16 03:57 +0800
    Re: Are the H(D) in main and the H(D) in D the same? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 20:36 +0000
      Re: Are the H(D) in main and the H(D) in D the same? wij <wyniijj5@gmail.com> - 2025-11-16 05:11 +0800
        Re: Are the H(D) in main and the H(D) in D the same? olcott <polcott333@gmail.com> - 2025-11-15 15:40 -0600
          Re: Are the H(D) in main and the H(D) in D the same? wij <wyniijj5@gmail.com> - 2025-11-16 06:10 +0800
            Re: Are the H(D) in main and the H(D) in D the same? olcott <polcott333@gmail.com> - 2025-11-15 16:20 -0600
              Re: Are the H(D) in main and the H(D) in D the same? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-15 14:35 -0800
                Re: Are the H(D) in main and the H(D) in D the same? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-11-15 14:38 -0800
      Re: Are the H(D) in main and the H(D) in D the same? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 22:35 +0000
        Re: Are the H(D) in main and the H(D) in D the same? olcott <polcott333@gmail.com> - 2025-11-15 17:14 -0600
          Re: Are the H(D) in main and the H(D) in D the same? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2025-11-15 23:15 +0000
            Re: Are the H(D) in main and the H(D) in D the same? olcott <polcott333@gmail.com> - 2025-11-15 17:30 -0600
              Re: Are the H(D) in main and the H(D) in D the same? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-11-15 23:39 +0000
                Re: Are the H(D) in main and the H(D) in D the same? olcott <polcott333@gmail.com> - 2025-11-15 17:58 -0600
    Re: Are the H(D) in main and the H(D) in D the same? Mikko <mikko.levanto@iki.fi> - 2025-11-16 11:05 +0200

#135704 — Are the H(D) in main and the H(D) in D the same?

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

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

int main()
{
   H(D);
}


Recently, olcott constantly pushes: "...the simulated D cannot reach its own simulated "return"
statement..."
But olcott cannot answer the question (very funny): Are the H(D) in main and the H(D) in D the same? 

[toc] | [next] | [standalone]

#135718

On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
> typedef int (*ptr)();
> int HHH(ptr P);
>
> int D()
> {
>    int Halt_Status = H(D);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
>
> int main()
> {
>    H(D);
> }
>
>
> Recently, olcott constantly pushes: "...the simulated D cannot reach its own simulated "return"
> statement..."
> But olcott cannot answer the question (very funny): Are the H(D) in main and the H(D) in D the same? 

Mathematically, they are the same and must be.

In his C code, he has put in hacks to try to make them different.

The first H invoked from main calls a routine to allocate and initialize
a new simulation, along with a trace buffer for execution traces.

That trace buffer is static/shared; it is allocated only once.

Hhen the trace buffer is allocated, that function returns 1 to the
caller, and is stored in a variable called Root.

Thus in the H(D) invoked from main, Root == 1.

H(D) simulates D, which calls H again. That H(D) executes with Root == 0.

Olcott rigged is so that the Root == 1 H will perform the termination
tests to abort the simulation loop, but Root == 0 just simulates
unconditionally.

That makes them different functions.

By doing this, he makes it true that the D simulated by H doesn't
terminate, whereas if you call D from main, it does terminate.

The underlying mathematics doesn't support that; the expression H(D)
denotes exactly the same computation and result wherever it appears.

If we know that H(D) produces false, we can replace all occurrences of
it with false.

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

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

#135725

On Sat, 2025-11-15 at 20:36 +0000, Kaz Kylheku wrote:
> On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
> > typedef int (*ptr)();
> > int HHH(ptr P);
> > 
> > int D()
> > {
> >    int Halt_Status = H(D);
> >    if (Halt_Status)
> >      HERE: goto HERE;
> >    return Halt_Status;
> > }
> > 
> > int main()
> > {
> >    H(D);
> > }
> > 
> > 
> > Recently, olcott constantly pushes: "...the simulated D cannot reach its own simulated "return"
> > statement..."
> > But olcott cannot answer the question (very funny): Are the H(D) in main and the H(D) in D the
> > same? 
> 
> Mathematically, they are the same and must be.
> 
> In his C code, he has put in hacks to try to make them different.
> 
> The first H invoked from main calls a routine to allocate and initialize
> a new simulation, along with a trace buffer for execution traces.
> 
> That trace buffer is static/shared; it is allocated only once.
> 
> Hhen the trace buffer is allocated, that function returns 1 to the
> caller, and is stored in a variable called Root.
> 
> Thus in the H(D) invoked from main, Root == 1.
> 
> H(D) simulates D, which calls H again. That H(D) executes with Root == 0.
> 
> Olcott rigged is so that the Root == 1 H will perform the termination
> tests to abort the simulation loop, but Root == 0 just simulates
> unconditionally.
> 
> That makes them different functions.
> 
> By doing this, he makes it true that the D simulated by H doesn't
> terminate, whereas if you call D from main, it does terminate.

Whatever, IMO, 'same function (call)' means the entrance address of the 
function is the same. The HP does not care what the inside, the implement of 
the decider is. But of course, being an 'correct' answer, 'the function' of
the decider HP requires to be deterministic and portable, i.e. reproducible.

> The underlying mathematics doesn't support that; the expression H(D)
> denotes exactly the same computation and result wherever it appears.
> 
> If we know that H(D) produces false, we can replace all occurrences of
> it with false.

The HP has nothing to do with any math or theories. 
Proving halt decider does not exist needs some 'logic'.
Proving halt decider exists needs to build one, at least a method.

Discussion of a problem have to first setup a criteria what is correct/wrong,
otherwise pointless.
I see no one precisely define what the halting problem being discussed is.
Can you? (except the tradition one defined on Turing Machine)

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

#135728

On 11/15/2025 3:11 PM, wij wrote:
> On Sat, 2025-11-15 at 20:36 +0000, Kaz Kylheku wrote:
>> On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
>>> typedef int (*ptr)();
>>> int HHH(ptr P);
>>>
>>> int D()
>>> {
>>>     int Halt_Status = H(D);
>>>     if (Halt_Status)
>>>       HERE: goto HERE;
>>>     return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>>     H(D);
>>> }
>>>
>>>
>>> Recently, olcott constantly pushes: "...the simulated D cannot reach its own simulated "return"
>>> statement..."
>>> But olcott cannot answer the question (very funny): Are the H(D) in main and the H(D) in D the
>>> same?
>>
>> Mathematically, they are the same and must be.
>>
>> In his C code, he has put in hacks to try to make them different.
>>
>> The first H invoked from main calls a routine to allocate and initialize
>> a new simulation, along with a trace buffer for execution traces.
>>
>> That trace buffer is static/shared; it is allocated only once.
>>
>> Hhen the trace buffer is allocated, that function returns 1 to the
>> caller, and is stored in a variable called Root.
>>
>> Thus in the H(D) invoked from main, Root == 1.
>>
>> H(D) simulates D, which calls H again. That H(D) executes with Root == 0.
>>
>> Olcott rigged is so that the Root == 1 H will perform the termination
>> tests to abort the simulation loop, but Root == 0 just simulates
>> unconditionally.
>>
>> That makes them different functions.
>>
>> By doing this, he makes it true that the D simulated by H doesn't
>> terminate, whereas if you call D from main, it does terminate.
> 
> Whatever, IMO, 'same function (call)' means the entrance address of the
> function is the same. The HP does not care what the inside, the implement of
> the decider is. But of course, being an 'correct' answer, 'the function' of
> the decider HP requires to be deterministic and portable, i.e. reproducible.
> 

The halting problem as Turing machines or as
C functions requires the halt decider to report
on the behavior of its own caller and no such
halt decider in C or in Turing machines can
possibly know what called it.

It people were not so damned sure that I must
be wrong they would have paid actual attention
to my words.

None of the rebuttals to anything that said
ever provided any reasoning showing any mistake.

Most of the rebuttals were either dishonest
dodges changing the subject the strawman
error of changing the words that I said and
then rebutting the changed words.

The strongest rebuttals ever made were of
the form: that is not how we learned it
in textbooks.



-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#135735

On Sat, 2025-11-15 at 15:40 -0600, olcott wrote:
> On 11/15/2025 3:11 PM, wij wrote:
> > On Sat, 2025-11-15 at 20:36 +0000, Kaz Kylheku wrote:
> > > On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
> > > > typedef int (*ptr)();
> > > > int HHH(ptr P);
> > > > 
> > > > int D()
> > > > {
> > > >     int Halt_Status = H(D);
> > > >     if (Halt_Status)
> > > >       HERE: goto HERE;
> > > >     return Halt_Status;
> > > > }
> > > > 
> > > > int main()
> > > > {
> > > >     H(D);
> > > > }
> > > > 
> > > > 
> > > > Recently, olcott constantly pushes: "...the simulated D cannot reach its own simulated
> > > > "return"
> > > > statement..."
> > > > But olcott cannot answer the question (very funny): Are the H(D) in main and the H(D) in D the
> > > > same?
> > > 
> > > Mathematically, they are the same and must be.
> > > 
> > > In his C code, he has put in hacks to try to make them different.
> > > 
> > > The first H invoked from main calls a routine to allocate and initialize
> > > a new simulation, along with a trace buffer for execution traces.
> > > 
> > > That trace buffer is static/shared; it is allocated only once.
> > > 
> > > Hhen the trace buffer is allocated, that function returns 1 to the
> > > caller, and is stored in a variable called Root.
> > > 
> > > Thus in the H(D) invoked from main, Root == 1.
> > > 
> > > H(D) simulates D, which calls H again. That H(D) executes with Root == 0.
> > > 
> > > Olcott rigged is so that the Root == 1 H will perform the termination
> > > tests to abort the simulation loop, but Root == 0 just simulates
> > > unconditionally.
> > > 
> > > That makes them different functions.
> > > 
> > > By doing this, he makes it true that the D simulated by H doesn't
> > > terminate, whereas if you call D from main, it does terminate.
> > 
> > Whatever, IMO, 'same function (call)' means the entrance address of the
> > function is the same. The HP does not care what the inside, the implement of
> > the decider is. But of course, being an 'correct' answer, 'the function' of
> > the decider HP requires to be deterministic and portable, i.e. reproducible.
> > 
> 
> The halting problem as Turing machines or as
> C functions requires the halt decider to report
> on the behavior of its own caller and no such
> halt decider in C or in Turing machines can
> possibly know what called it.
> 
> It people were not so damned sure that I must
> be wrong they would have paid actual attention
> to my words.
> 
> None of the rebuttals to anything that said
> ever provided any reasoning showing any mistake.
> 
> Most of the rebuttals were either dishonest
> dodges changing the subject the strawman
> error of changing the words that I said and
> then rebutting the changed words.
> 
> The strongest rebuttals ever made were of
> the form: that is not how we learned it
> in textbooks.

But how do you lean from text book? Ignore all exercises in the text books or
telling yourself they are something boring because none you cannot 
complete (Why I know is because you cannot answer many much simpler questions).

You have to complete the exercises in the text book to refute the theorems in it.
(I am 95% sure you cannot write a TM that computes the length of it input. 
prove me wrong)

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

#135738

On 11/15/2025 4:10 PM, wij wrote:
> On Sat, 2025-11-15 at 15:40 -0600, olcott wrote:
>> On 11/15/2025 3:11 PM, wij wrote:
>>> On Sat, 2025-11-15 at 20:36 +0000, Kaz Kylheku wrote:
>>>> On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
>>>>> typedef int (*ptr)();
>>>>> int HHH(ptr P);
>>>>>
>>>>> int D()
>>>>> {
>>>>>      int Halt_Status = H(D);
>>>>>      if (Halt_Status)
>>>>>        HERE: goto HERE;
>>>>>      return Halt_Status;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      H(D);
>>>>> }
>>>>>
>>>>>
>>>>> Recently, olcott constantly pushes: "...the simulated D cannot reach its own simulated
>>>>> "return"
>>>>> statement..."
>>>>> But olcott cannot answer the question (very funny): Are the H(D) in main and the H(D) in D the
>>>>> same?
>>>>
>>>> Mathematically, they are the same and must be.
>>>>
>>>> In his C code, he has put in hacks to try to make them different.
>>>>
>>>> The first H invoked from main calls a routine to allocate and initialize
>>>> a new simulation, along with a trace buffer for execution traces.
>>>>
>>>> That trace buffer is static/shared; it is allocated only once.
>>>>
>>>> Hhen the trace buffer is allocated, that function returns 1 to the
>>>> caller, and is stored in a variable called Root.
>>>>
>>>> Thus in the H(D) invoked from main, Root == 1.
>>>>
>>>> H(D) simulates D, which calls H again. That H(D) executes with Root == 0.
>>>>
>>>> Olcott rigged is so that the Root == 1 H will perform the termination
>>>> tests to abort the simulation loop, but Root == 0 just simulates
>>>> unconditionally.
>>>>
>>>> That makes them different functions.
>>>>
>>>> By doing this, he makes it true that the D simulated by H doesn't
>>>> terminate, whereas if you call D from main, it does terminate.
>>>
>>> Whatever, IMO, 'same function (call)' means the entrance address of the
>>> function is the same. The HP does not care what the inside, the implement of
>>> the decider is. But of course, being an 'correct' answer, 'the function' of
>>> the decider HP requires to be deterministic and portable, i.e. reproducible.
>>>
>>
>> The halting problem as Turing machines or as
>> C functions requires the halt decider to report
>> on the behavior of its own caller and no such
>> halt decider in C or in Turing machines can
>> possibly know what called it.
>>
>> It people were not so damned sure that I must
>> be wrong they would have paid actual attention
>> to my words.
>>
>> None of the rebuttals to anything that said
>> ever provided any reasoning showing any mistake.
>>
>> Most of the rebuttals were either dishonest
>> dodges changing the subject the strawman
>> error of changing the words that I said and
>> then rebutting the changed words.
>>
>> The strongest rebuttals ever made were of
>> the form: that is not how we learned it
>> in textbooks.
> 
> But how do you lean from text book? Ignore all exercises in the text books or
> telling yourself they are something boring because none you cannot
> complete (Why I know is because you cannot answer many much simpler questions).
> 
> You have to complete the exercises in the text book to refute the theorems in it.
> (I am 95% sure you cannot write a TM that computes the length of it input.
> prove me wrong)
> 

I have known for 28 years that if the halting
problem is correct then truth itself is broken.


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#135740

On 11/15/2025 2:20 PM, olcott wrote:
> On 11/15/2025 4:10 PM, wij wrote:
>> On Sat, 2025-11-15 at 15:40 -0600, olcott wrote:
>>> On 11/15/2025 3:11 PM, wij wrote:
>>>> On Sat, 2025-11-15 at 20:36 +0000, Kaz Kylheku wrote:
>>>>> On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
>>>>>> typedef int (*ptr)();
>>>>>> int HHH(ptr P);
>>>>>>
>>>>>> int D()
>>>>>> {
>>>>>>      int Halt_Status = H(D);
>>>>>>      if (Halt_Status)
>>>>>>        HERE: goto HERE;
>>>>>>      return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>      H(D);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Recently, olcott constantly pushes: "...the simulated D cannot 
>>>>>> reach its own simulated
>>>>>> "return"
>>>>>> statement..."
>>>>>> But olcott cannot answer the question (very funny): Are the H(D) 
>>>>>> in main and the H(D) in D the
>>>>>> same?
>>>>>
>>>>> Mathematically, they are the same and must be.
>>>>>
>>>>> In his C code, he has put in hacks to try to make them different.
>>>>>
>>>>> The first H invoked from main calls a routine to allocate and 
>>>>> initialize
>>>>> a new simulation, along with a trace buffer for execution traces.
>>>>>
>>>>> That trace buffer is static/shared; it is allocated only once.
>>>>>
>>>>> Hhen the trace buffer is allocated, that function returns 1 to the
>>>>> caller, and is stored in a variable called Root.
>>>>>
>>>>> Thus in the H(D) invoked from main, Root == 1.
>>>>>
>>>>> H(D) simulates D, which calls H again. That H(D) executes with Root 
>>>>> == 0.
>>>>>
>>>>> Olcott rigged is so that the Root == 1 H will perform the termination
>>>>> tests to abort the simulation loop, but Root == 0 just simulates
>>>>> unconditionally.
>>>>>
>>>>> That makes them different functions.
>>>>>
>>>>> By doing this, he makes it true that the D simulated by H doesn't
>>>>> terminate, whereas if you call D from main, it does terminate.
>>>>
>>>> Whatever, IMO, 'same function (call)' means the entrance address of the
>>>> function is the same. The HP does not care what the inside, the 
>>>> implement of
>>>> the decider is. But of course, being an 'correct' answer, 'the 
>>>> function' of
>>>> the decider HP requires to be deterministic and portable, i.e. 
>>>> reproducible.
>>>>
>>>
>>> The halting problem as Turing machines or as
>>> C functions requires the halt decider to report
>>> on the behavior of its own caller and no such
>>> halt decider in C or in Turing machines can
>>> possibly know what called it.
>>>
>>> It people were not so damned sure that I must
>>> be wrong they would have paid actual attention
>>> to my words.
>>>
>>> None of the rebuttals to anything that said
>>> ever provided any reasoning showing any mistake.
>>>
>>> Most of the rebuttals were either dishonest
>>> dodges changing the subject the strawman
>>> error of changing the words that I said and
>>> then rebutting the changed words.
>>>
>>> The strongest rebuttals ever made were of
>>> the form: that is not how we learned it
>>> in textbooks.
>>
>> But how do you lean from text book? Ignore all exercises in the text 
>> books or
>> telling yourself they are something boring because none you cannot
>> complete (Why I know is because you cannot answer many much simpler 
>> questions).
>>
>> You have to complete the exercises in the text book to refute the 
>> theorems in it.
>> (I am 95% sure you cannot write a TM that computes the length of it 
>> input.
>> prove me wrong)
>>
> 
> I have known for 28 years that if the halting
> problem is correct then truth itself is broken.
> 
> 

Why did you not it for 30 years?

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

#135741

On 11/15/2025 2:35 PM, Chris M. Thomasson wrote:
> On 11/15/2025 2:20 PM, olcott wrote:
>> On 11/15/2025 4:10 PM, wij wrote:
>>> On Sat, 2025-11-15 at 15:40 -0600, olcott wrote:
>>>> On 11/15/2025 3:11 PM, wij wrote:
>>>>> On Sat, 2025-11-15 at 20:36 +0000, Kaz Kylheku wrote:
>>>>>> On 2025-11-15, wij <wyniijj5@gmail.com> wrote:
>>>>>>> typedef int (*ptr)();
>>>>>>> int HHH(ptr P);
>>>>>>>
>>>>>>> int D()
>>>>>>> {
>>>>>>>      int Halt_Status = H(D);
>>>>>>>      if (Halt_Status)
>>>>>>>        HERE: goto HERE;
>>>>>>>      return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>      H(D);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Recently, olcott constantly pushes: "...the simulated D cannot 
>>>>>>> reach its own simulated
>>>>>>> "return"
>>>>>>> statement..."
>>>>>>> But olcott cannot answer the question (very funny): Are the H(D) 
>>>>>>> in main and the H(D) in D the
>>>>>>> same?
>>>>>>
>>>>>> Mathematically, they are the same and must be.
>>>>>>
>>>>>> In his C code, he has put in hacks to try to make them different.
>>>>>>
>>>>>> The first H invoked from main calls a routine to allocate and 
>>>>>> initialize
>>>>>> a new simulation, along with a trace buffer for execution traces.
>>>>>>
>>>>>> That trace buffer is static/shared; it is allocated only once.
>>>>>>
>>>>>> Hhen the trace buffer is allocated, that function returns 1 to the
>>>>>> caller, and is stored in a variable called Root.
>>>>>>
>>>>>> Thus in the H(D) invoked from main, Root == 1.
>>>>>>
>>>>>> H(D) simulates D, which calls H again. That H(D) executes with 
>>>>>> Root == 0.
>>>>>>
>>>>>> Olcott rigged is so that the Root == 1 H will perform the termination
>>>>>> tests to abort the simulation loop, but Root == 0 just simulates
>>>>>> unconditionally.
>>>>>>
>>>>>> That makes them different functions.
>>>>>>
>>>>>> By doing this, he makes it true that the D simulated by H doesn't
>>>>>> terminate, whereas if you call D from main, it does terminate.
>>>>>
>>>>> Whatever, IMO, 'same function (call)' means the entrance address of 
>>>>> the
>>>>> function is the same. The HP does not care what the inside, the 
>>>>> implement of
>>>>> the decider is. But of course, being an 'correct' answer, 'the 
>>>>> function' of
>>>>> the decider HP requires to be deterministic and portable, i.e. 
>>>>> reproducible.
>>>>>
>>>>
>>>> The halting problem as Turing machines or as
>>>> C functions requires the halt decider to report
>>>> on the behavior of its own caller and no such
>>>> halt decider in C or in Turing machines can
>>>> possibly know what called it.
>>>>
>>>> It people were not so damned sure that I must
>>>> be wrong they would have paid actual attention
>>>> to my words.
>>>>
>>>> None of the rebuttals to anything that said
>>>> ever provided any reasoning showing any mistake.
>>>>
>>>> Most of the rebuttals were either dishonest
>>>> dodges changing the subject the strawman
>>>> error of changing the words that I said and
>>>> then rebutting the changed words.
>>>>
>>>> The strongest rebuttals ever made were of
>>>> the form: that is not how we learned it
>>>> in textbooks.
>>>
>>> But how do you lean from text book? Ignore all exercises in the text 
>>> books or
>>> telling yourself they are something boring because none you cannot
>>> complete (Why I know is because you cannot answer many much simpler 
>>> questions).
>>>
>>> You have to complete the exercises in the text book to refute the 
>>> theorems in it.
>>> (I am 95% sure you cannot write a TM that computes the length of it 
>>> input.
>>> prove me wrong)
>>>
>>
>> I have known for 28 years that if the halting
>> problem is correct then truth itself is broken.

Heck. You should have known that in the womb, right?

> 
> Why did you not it for 30 years?

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

#135739

On 15/11/2025 20:36, Kaz Kylheku wrote:

> The underlying mathematics doesn't support that; the expression H(D)
> denotes exactly the same computation and result wherever it appears.

Is this in the problem where C semantics are specified? There the
underlying mathematics supports it because of the semantics of the C
programming language.

--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

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

#135743

On 11/15/2025 4:35 PM, Tristan Wibberley wrote:
> On 15/11/2025 20:36, Kaz Kylheku wrote:
> 
>> The underlying mathematics doesn't support that; the expression H(D)
>> denotes exactly the same computation and result wherever it appears.
> 
> Is this in the problem where C semantics are specified? There the
> underlying mathematics supports it because of the semantics of the C
> programming language.
> 

D simulated by H specifies that H simulates
D and then must simulate an instance of itself
simulating an instance of D.

D simulated by H1 does not specify that H1
simulate itself at all.

Any C programmer can instantly see this.

> --
> Tristan Wibberley
> 
> The message body is Copyright (C) 2025 Tristan Wibberley except
> citations and quotations noted. All Rights Reserved except that you may,
> of course, cite it academically giving credit to me, distribute it
> verbatim as part of a usenet system or its archives, and use it to
> promote my greatness and general superiority without misrepresentation
> of my opinions other than my opinion of my greatness and general
> superiority which you _may_ misrepresent. You definitely MAY NOT train
> any production AI system with it but you may train experimental AI that
> will only be used for evaluation of the AI methods it implements.
> 


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#135744

On 15/11/2025 23:14, olcott wrote:
> On 11/15/2025 4:35 PM, Tristan Wibberley wrote:
>> On 15/11/2025 20:36, Kaz Kylheku wrote:
>>
>>> The underlying mathematics doesn't support that; the expression H(D)
>>> denotes exactly the same computation and result wherever it appears.
>>
>> Is this in the problem where C semantics are specified? There the
>> underlying mathematics supports it because of the semantics of the C
>> programming language.
>>
> 
> D simulated by H specifies that H simulates
> D and then must simulate an instance of itself
> simulating an instance of D.
> 
> D simulated by H1 does not specify that H1
> simulate itself at all.
> 
> Any C programmer can instantly see this.

Thanks it doesn't help.

--
Tristan Wibberley

The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.

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

#135748

On 11/15/2025 5:15 PM, Tristan Wibberley wrote:
> On 15/11/2025 23:14, olcott wrote:
>> On 11/15/2025 4:35 PM, Tristan Wibberley wrote:
>>> On 15/11/2025 20:36, Kaz Kylheku wrote:
>>>
>>>> The underlying mathematics doesn't support that; the expression H(D)
>>>> denotes exactly the same computation and result wherever it appears.
>>>
>>> Is this in the problem where C semantics are specified? There the
>>> underlying mathematics supports it because of the semantics of the C
>>> programming language.
>>>
>>
>> D simulated by H specifies that H simulates
>> D and then must simulate an instance of itself
>> simulating an instance of D.
>>
>> D simulated by H1 does not specify that H1
>> simulate itself at all.
>>
>> Any C programmer can instantly see this.
> 
> Thanks it doesn't help.
> 

C is essentially its own formal mathematical
language with its own semantics thus what I
just said applies to C as a formal language.

> --
> Tristan Wibberley
> 
> The message body is Copyright (C) 2025 Tristan Wibberley except
> citations and quotations noted. All Rights Reserved except that you may,
> of course, cite it academically giving credit to me, distribute it
> verbatim as part of a usenet system or its archives, and use it to
> promote my greatness and general superiority without misrepresentation
> of my opinions other than my opinion of my greatness and general
> superiority which you _may_ misrepresent. You definitely MAY NOT train
> any production AI system with it but you may train experimental AI that
> will only be used for evaluation of the AI methods it implements.
> 


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#135750

On 2025-11-15, olcott <polcott333@gmail.com> wrote:
> On 11/15/2025 5:15 PM, Tristan Wibberley wrote:
>> On 15/11/2025 23:14, olcott wrote:
>>> On 11/15/2025 4:35 PM, Tristan Wibberley wrote:
>>>> On 15/11/2025 20:36, Kaz Kylheku wrote:
>>>>
>>>>> The underlying mathematics doesn't support that; the expression H(D)
>>>>> denotes exactly the same computation and result wherever it appears.
>>>>
>>>> Is this in the problem where C semantics are specified? There the
>>>> underlying mathematics supports it because of the semantics of the C
>>>> programming language.
>>>>
>>>
>>> D simulated by H specifies that H simulates
>>> D and then must simulate an instance of itself
>>> simulating an instance of D.
>>>
>>> D simulated by H1 does not specify that H1
>>> simulate itself at all.
>>>
>>> Any C programmer can instantly see this.
>> 
>> Thanks it doesn't help.
>> 
>
> C is essentially its own formal mathematical
> language with its own semantics thus what I
> just said applies to C as a formal language.

The problem, you idiot, is that same-named entities between
mathematics and C like "variable" and "function" do not correspond.

Yes, I know you like to assume that the same words refer to "isomorphic"
entities (another word you don't understand) but that simpy isn't so.

Even if we can build a formal model of C, that model cannot
turn a C function into a math function.

And, no, C is not formally specified. It is informally specified, in a
plain language description which leaves many details "unspecified",
"implementation-defined" and "undefined".  Every revision of the ISO C
standard has been the target of defect reports.

There are projects out there to do formal verification on C programs;
those have to construct their own formal model; you don't get one
from ISO C.

If you want certain functions in a C file to model math
functions (like functions from the theory of computation)
you have to tread very carefully.

You cannot pull bullshit like have to identical functions be
treated as different because one of them is called by
a certain function and the other isn't.

If you have two idnetical functions, you have to ensure that
everything in your system behaves as if they were just two
different /names/ for a single function.

Your functions cannot have any side effects, like reacting to
different values of a shared, static variable; they have to be pure.

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

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

#135751

On 11/15/2025 5:39 PM, Kaz Kylheku wrote:
> On 2025-11-15, olcott <polcott333@gmail.com> wrote:
>> On 11/15/2025 5:15 PM, Tristan Wibberley wrote:
>>> On 15/11/2025 23:14, olcott wrote:
>>>> On 11/15/2025 4:35 PM, Tristan Wibberley wrote:
>>>>> On 15/11/2025 20:36, Kaz Kylheku wrote:
>>>>>
>>>>>> The underlying mathematics doesn't support that; the expression H(D)
>>>>>> denotes exactly the same computation and result wherever it appears.
>>>>>
>>>>> Is this in the problem where C semantics are specified? There the
>>>>> underlying mathematics supports it because of the semantics of the C
>>>>> programming language.
>>>>>
>>>>
>>>> D simulated by H specifies that H simulates
>>>> D and then must simulate an instance of itself
>>>> simulating an instance of D.
>>>>
>>>> D simulated by H1 does not specify that H1
>>>> simulate itself at all.
>>>>
>>>> Any C programmer can instantly see this.
>>>
>>> Thanks it doesn't help.
>>>
>>
>> C is essentially its own formal mathematical
>> language with its own semantics thus what I
>> just said applies to C as a formal language.
> 
> The problem, you idiot, is that same-named entities between
> mathematics and C like "variable" and "function" do not correspond.
> 

Computable functions of C maps to x86
that maps to RASP machines that maps
to Turing machines

*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state

D simulated by H maps to ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H

That you only have rhetoric and insults as your basis
fools all of the gullible people in this group.




> Yes, I know you like to assume that the same words refer to "isomorphic"
> entities (another word you don't understand) but that simpy isn't so.
> 
> Even if we can build a formal model of C, that model cannot
> turn a C function into a math function.
> 
> And, no, C is not formally specified. It is informally specified, in a
> plain language description which leaves many details "unspecified",
> "implementation-defined" and "undefined".  Every revision of the ISO C
> standard has been the target of defect reports.
> 
> There are projects out there to do formal verification on C programs;
> those have to construct their own formal model; you don't get one
> from ISO C.
> 
> If you want certain functions in a C file to model math
> functions (like functions from the theory of computation)
> you have to tread very carefully.
> 
> You cannot pull bullshit like have to identical functions be
> treated as different because one of them is called by
> a certain function and the other isn't.
> 
> If you have two idnetical functions, you have to ensure that
> everything in your system behaves as if they were just two
> different /names/ for a single function.
> 
> Your functions cannot have any side effects, like reacting to
> different values of a shared, static variable; they have to be pure.
> 


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

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

#135775

On 2025-11-15 19:57:35 +0000, wij said:

> typedef int (*ptr)();
> int HHH(ptr P);
> 
> int D()
> {
>    int Halt_Status = H(D);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> int main()
> {
>    H(D);
> }
> 
> 
> Recently, olcott constantly pushes: "...the simulated D cannot reach 
> its own simulated "return"
> statement..."
> But olcott cannot answer the question (very funny): Are the H(D) in 
> main and the H(D) in D the same?

They must be except when the intent is to deceive with equivocation.

-- 
Mikko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.theory

csiph-web