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

Groups > sci.logic > #334205 > unrolled thread

Every D correctly simulated by H never reaches its final state and halts

Back to article view | Back to sci.logic

Contents

  Every D correctly simulated by H never reaches its final state and halts olcott <polcott333@gmail.com> - 2024-05-16 20:15 -0500
    Re: Every D correctly simulated by H never reaches its final state and halts Richard Damon <richard@damon-family.org> - 2024-05-16 22:29 -0400
      Re: Every D correctly simulated by H never reaches its final state and halts olcott <polcott333@gmail.com> - 2024-05-16 21:46 -0500
        Re: Every D correctly simulated by H never reaches its final state and halts Richard Damon <richard@damon-family.org> - 2024-05-16 22:59 -0400
    Re: Every D correctly simulated by H never reaches its final state and halts "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-17 09:25 +0200
      Re: Every D correctly simulated by H never reaches its final state and halts olcott <polcott333@gmail.com> - 2024-05-17 10:30 -0500
        Re: Every D correctly simulated by H never reaches its final state and halts Mikko <mikko.levanto@iki.fi> - 2024-05-17 19:00 +0300
          Re: Every D correctly simulated by H never reaches its final state and halts olcott <polcott333@gmail.com> - 2024-05-17 12:46 -0500
            Re: Every D correctly simulated by H never reaches its final state and halts Richard Damon <richard@damon-family.org> - 2024-05-17 21:06 -0400
            Re: Every D correctly simulated by H never reaches its final state and halts joes <noreply@example.com> - 2024-05-18 10:07 +0000
        Re: Every D correctly simulated by H never reaches its final state and halts Richard Damon <richard@damon-family.org> - 2024-05-17 21:06 -0400
      Re: Every D correctly simulated by H never reaches its final state and halts --- Admitted Liar olcott <polcott333@gmail.com> - 2024-05-19 14:07 -0500
        Re: Every D correctly simulated by H never reaches its final state and halts --- Olcott is an Admitted Liar Richard Damon <richard@damon-family.org> - 2024-05-19 15:20 -0400
    Re: Every D correctly simulated by H never reaches its final state and halts immibis <news@immibis.com> - 2024-05-18 10:56 +0200

#334205 — Every D correctly simulated by H never reaches its final state and halts

The following is self-evidently true on the basis of the
semantics of the C programming language.

typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr x, ptr x);
01 int D(ptr x)
02 {
03   int Halt_Status = H(x, x);
04   if (Halt_Status)
05     HERE: goto HERE;
06   return Halt_Status;
07 }
08
09 int main()
10 {
11   H(D,D);
12   return 0;
13 }

In the above case a simulator is an x86 emulator that correctly
emulates at least one of the x86 instructions of D in the order
specified by the x86 instructions of D.

This may include correctly emulating the x86 instructions of H
in the order specified by the x86 instructions of H thus calling
H(D,D) in recursive simulation.

Any H/D pair matching the above template where
D(D) is simulated by the same H(D,D) that it calls
cannot possibly reach its own line 06 and halt.

*This is a simple software engineering verified fact*

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

[toc] | [next] | [standalone]

#334217

On 5/16/24 9:15 PM, olcott wrote:
> The following is self-evidently true on the basis of the
> semantics of the C programming language.

Which proves that you don't understand that C programming language, or 
how logic work.

> 
> typedef int (*ptr)();  // ptr is pointer to int function
> 00 int H(ptr x, ptr x);
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12   return 0;
> 13 }
> 
> In the above case a simulator is an x86 emulator that correctly
> emulates at least one of the x86 instructions of D in the order
> specified by the x86 instructions of D.
> 
> This may include correctly emulating the x86 instructions of H
> in the order specified by the x86 instructions of H thus calling
> H(D,D) in recursive simulation.
> 
> Any H/D pair matching the above template where
> D(D) is simulated by the same H(D,D) that it calls
> cannot possibly reach its own line 06 and halt.
> 
> *This is a simple software engineering verified fact*
> 

No, THAT IS A OLCOTT LIE.

I proved it wrong in a post I made about two weeks ago, which you read, 
simce you replied to it, but didn't even attempt to refute the arguement 
I made.

You have REPEATEDLY lied and said I didn't make such a post, but don't 
beleive your own lie enough to take a small risk on it, so you are 
admitting that it might be possible, but you choose to LIE and ignore it 
and just continue to lie saying your statement is self-evidently true, 
which just proves that you don't understand what Truth actually is.

You are just proving that you are nothing but an ignorant pathological 
lying idiot.

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

#334220

On 5/16/2024 9:29 PM, Richard Damon wrote:
> On 5/16/24 9:15 PM, olcott wrote:
>> The following is self-evidently true on the basis of the
>> semantics of the C programming language.
> 
> Which proves that you don't understand that C programming language, or 
> how logic work.
> 
>>
>> typedef int (*ptr)();  // ptr is pointer to int function
>> 00 int H(ptr x, ptr x);
>> 01 int D(ptr x)
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11   H(D,D);
>> 12   return 0;
>> 13 }
>>
>> In the above case a simulator is an x86 emulator that correctly
>> emulates at least one of the x86 instructions of D in the order
>> specified by the x86 instructions of D.
>>
>> This may include correctly emulating the x86 instructions of H
>> in the order specified by the x86 instructions of H thus calling
>> H(D,D) in recursive simulation.
>>
>> Any H/D pair matching the above template where
>> D(D) is simulated by the same H(D,D) that it calls
>> cannot possibly reach its own line 06 and halt.
>>
>> *This is a simple software engineering verified fact*
>>
> 
> No, THAT IS A OLCOTT LIE.
> 
> I proved it wrong in a post I made about two weeks ago, which you read, 
> simce you replied to it, but didn't even attempt to refute the arguement 
> I made.

*Provide the message ID or YOUR ARE A LIAR*
*Provide the message ID or YOUR ARE A LIAR*
*Provide the message ID or YOUR ARE A LIAR*
*Provide the message ID or YOUR ARE A LIAR*

-- 
Copyright 2024 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]

#334222

On 5/16/24 10:46 PM, olcott wrote:
> On 5/16/2024 9:29 PM, Richard Damon wrote:
>> On 5/16/24 9:15 PM, olcott wrote:
>>> The following is self-evidently true on the basis of the
>>> semantics of the C programming language.
>>
>> Which proves that you don't understand that C programming language, or 
>> how logic work.
>>
>>>
>>> typedef int (*ptr)();  // ptr is pointer to int function
>>> 00 int H(ptr x, ptr x);
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12   return 0;
>>> 13 }
>>>
>>> In the above case a simulator is an x86 emulator that correctly
>>> emulates at least one of the x86 instructions of D in the order
>>> specified by the x86 instructions of D.
>>>
>>> This may include correctly emulating the x86 instructions of H
>>> in the order specified by the x86 instructions of H thus calling
>>> H(D,D) in recursive simulation.
>>>
>>> Any H/D pair matching the above template where
>>> D(D) is simulated by the same H(D,D) that it calls
>>> cannot possibly reach its own line 06 and halt.
>>>
>>> *This is a simple software engineering verified fact*
>>>
>>
>> No, THAT IS A OLCOTT LIE.
>>
>> I proved it wrong in a post I made about two weeks ago, which you 
>> read, simce you replied to it, but didn't even attempt to refute the 
>> arguement I made.
> 
> *Provide the message ID or YOUR ARE A LIAR*
> *Provide the message ID or YOUR ARE A LIAR*
> *Provide the message ID or YOUR ARE A LIAR*
> *Provide the message ID or YOUR ARE A LIAR*
> 


No, Make the commitment that if I show YOU have been the liar that you 
will give up the right to make similar statements that could be the same 
sort of lie.

Never again can you claim that no one has refuted what you said, because 
it is clear you are just too likely to have "overlooked" a rebutal.

You have the ability to search.

If you want to claim that you have searched to the best of your ability 
and can't find it, and thus we can point out your weak searching ability 
when you want to claim something obviously true, you can do that to.

I suppose that since the statement shows that your "verified facts" 
statement to be just a lie, I guess when I point out the message-id that 
means I can point out that your concept of "verified facts" means things 
not actually verified, so that claim from you is possible a lie.

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

#334229

Op 17.mei.2024 om 03:15 schreef olcott:
> The following is self-evidently true on the basis of the
> semantics of the C programming language.
> 
> typedef int (*ptr)();  // ptr is pointer to int function
> 00 int H(ptr x, ptr x);
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12   return 0;
> 13 }
> 
> In the above case a simulator is an x86 emulator that correctly
> emulates at least one of the x86 instructions of D in the order
> specified by the x86 instructions of D.
> 
> This may include correctly emulating the x86 instructions of H
> in the order specified by the x86 instructions of H thus calling
> H(D,D) in recursive simulation.
> 
> Any H/D pair matching the above template where
> D(D) is simulated by the same H(D,D) that it calls
> cannot possibly reach its own line 06 and halt.
> 
> *This is a simple software engineering verified fact*
> 

Note that olcott defines 'verified fact' as 'proven fact', but he is 
unable to show the proof. So, it must be read as 'my belief'.

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

#334237

On 5/17/2024 2:25 AM, Fred. Zwarts wrote:
> Op 17.mei.2024 om 03:15 schreef olcott:
>> The following is self-evidently true on the basis of the
>> semantics of the C programming language.
>>
>> typedef int (*ptr)();  // ptr is pointer to int function
>> 00 int H(ptr x, ptr x);
>> 01 int D(ptr x)
>> 02 {
>> 03   int Halt_Status = H(x, x);
>> 04   if (Halt_Status)
>> 05     HERE: goto HERE;
>> 06   return Halt_Status;
>> 07 }
>> 08
>> 09 int main()
>> 10 {
>> 11   H(D,D);
>> 12   return 0;
>> 13 }
>>
>> In the above case a simulator is an x86 emulator that correctly
>> emulates at least one of the x86 instructions of D in the order
>> specified by the x86 instructions of D.
>>
>> This may include correctly emulating the x86 instructions of H
>> in the order specified by the x86 instructions of H thus calling
>> H(D,D) in recursive simulation.
>>
>> Any H/D pair matching the above template where
>> D(D) is simulated by the same H(D,D) that it calls
>> cannot possibly reach its own line 06 and halt.
>>
>> *This is a simple software engineering verified fact*
>>
> 
> Note that olcott defines 'verified fact' as 'proven fact', but he is 
> unable to show the proof. So, it must be read as 'my belief'.

It is self-evidently true to anyone having sufficient knowledge
of the semantics of the C programming language.

-- 
Copyright 2024 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]

#334242

On 2024-05-17 15:30:01 +0000, olcott said:

> On 5/17/2024 2:25 AM, Fred. Zwarts wrote:
>> Op 17.mei.2024 om 03:15 schreef olcott:
>>> The following is self-evidently true on the basis of the
>>> semantics of the C programming language.
>>> 
>>> typedef int (*ptr)();  // ptr is pointer to int function
>>> 00 int H(ptr x, ptr x);
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12   return 0;
>>> 13 }
>>> 
>>> In the above case a simulator is an x86 emulator that correctly
>>> emulates at least one of the x86 instructions of D in the order
>>> specified by the x86 instructions of D.
>>> 
>>> This may include correctly emulating the x86 instructions of H
>>> in the order specified by the x86 instructions of H thus calling
>>> H(D,D) in recursive simulation.
>>> 
>>> Any H/D pair matching the above template where
>>> D(D) is simulated by the same H(D,D) that it calls
>>> cannot possibly reach its own line 06 and halt.
>>> 
>>> *This is a simple software engineering verified fact*
>>> 
>> 
>> Note that olcott defines 'verified fact' as 'proven fact', but he is 
>> unable to show the proof. So, it must be read as 'my belief'.
> 
> It is self-evidently true to anyone having sufficient knowledge
> of the semantics of the C programming language.

No, it isn't, because the C code of H is not shown. The actual
implementation of H as decribed in some earlier messages is
not fully encoded in standard C, so in order to understand the
behaviour of D one needs to know and understand something that
is not given as a C code and therefore not understandable from
mere knowing the C language definition.

-- 
Mikko

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

#334253

On 5/17/2024 11:00 AM, Mikko wrote:
> On 2024-05-17 15:30:01 +0000, olcott said:
> 
>> On 5/17/2024 2:25 AM, Fred. Zwarts wrote:
>>> Op 17.mei.2024 om 03:15 schreef olcott:
>>>> The following is self-evidently true on the basis of the
>>>> semantics of the C programming language.
>>>>
>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>> 00 int H(ptr x, ptr x);
>>>> 01 int D(ptr x)
>>>> 02 {
>>>> 03   int Halt_Status = H(x, x);
>>>> 04   if (Halt_Status)
>>>> 05     HERE: goto HERE;
>>>> 06   return Halt_Status;
>>>> 07 }
>>>> 08
>>>> 09 int main()
>>>> 10 {
>>>> 11   H(D,D);
>>>> 12   return 0;
>>>> 13 }
>>>>
>>>> In the above case a simulator is an x86 emulator that correctly
>>>> emulates at least one of the x86 instructions of D in the order
>>>> specified by the x86 instructions of D.
>>>>
>>>> This may include correctly emulating the x86 instructions of H
>>>> in the order specified by the x86 instructions of H thus calling
>>>> H(D,D) in recursive simulation.
>>>>
>>>> Any H/D pair matching the above template where
>>>> D(D) is simulated by the same H(D,D) that it calls
>>>> cannot possibly reach its own line 06 and halt.
>>>>
>>>> *This is a simple software engineering verified fact*
>>>>
>>>
>>> Note that olcott defines 'verified fact' as 'proven fact', but he is 
>>> unable to show the proof. So, it must be read as 'my belief'.
>>
>> It is self-evidently true to anyone having sufficient knowledge
>> of the semantics of the C programming language.
> 
> No, it isn't, because the C code of H is not shown. 

*I DON'T KNOW WHY I MUST REPEAT THIS HUNDREDS OF TIMES*
The C code that <is> shown provides the template for the
infinite set of every D correctly simulated by H.

> The actual
> implementation of H as decribed in some earlier messages is
> not fully encoded in standard C, so in order to understand the
> behaviour of D one needs to know and understand something that
> is not given as a C code and therefore not understandable from
> mere knowing the C language definition.
> 

*SUFFICIENTLY KNOWING THE SEMANTICS OF C*
*SUFFICIENTLY KNOWING THE SEMANTICS OF C*
*SUFFICIENTLY KNOWING THE SEMANTICS OF C*

I could cast uint32_t to and from the various function pointer
types yet this is more difficult for people to understand.
I got complaints about this.
It is simpler and easier to do this: typedef int (*ptr)();


-- 
Copyright 2024 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]

#334261

On 5/17/24 1:46 PM, olcott wrote:
> On 5/17/2024 11:00 AM, Mikko wrote:
>> On 2024-05-17 15:30:01 +0000, olcott said:
>>
>>> On 5/17/2024 2:25 AM, Fred. Zwarts wrote:
>>>> Op 17.mei.2024 om 03:15 schreef olcott:
>>>>> The following is self-evidently true on the basis of the
>>>>> semantics of the C programming language.
>>>>>
>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>> 00 int H(ptr x, ptr x);
>>>>> 01 int D(ptr x)
>>>>> 02 {
>>>>> 03   int Halt_Status = H(x, x);
>>>>> 04   if (Halt_Status)
>>>>> 05     HERE: goto HERE;
>>>>> 06   return Halt_Status;
>>>>> 07 }
>>>>> 08
>>>>> 09 int main()
>>>>> 10 {
>>>>> 11   H(D,D);
>>>>> 12   return 0;
>>>>> 13 }
>>>>>
>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>> emulates at least one of the x86 instructions of D in the order
>>>>> specified by the x86 instructions of D.
>>>>>
>>>>> This may include correctly emulating the x86 instructions of H
>>>>> in the order specified by the x86 instructions of H thus calling
>>>>> H(D,D) in recursive simulation.
>>>>>
>>>>> Any H/D pair matching the above template where
>>>>> D(D) is simulated by the same H(D,D) that it calls
>>>>> cannot possibly reach its own line 06 and halt.
>>>>>
>>>>> *This is a simple software engineering verified fact*
>>>>>
>>>>
>>>> Note that olcott defines 'verified fact' as 'proven fact', but he is 
>>>> unable to show the proof. So, it must be read as 'my belief'.
>>>
>>> It is self-evidently true to anyone having sufficient knowledge
>>> of the semantics of the C programming language.
>>
>> No, it isn't, because the C code of H is not shown. 
> 
> *I DON'T KNOW WHY I MUST REPEAT THIS HUNDREDS OF TIMES*
> The C code that <is> shown provides the template for the
> infinite set of every D correctly simulated by H.

But. I have shown how to right code for H that makes your claim false.

This means that you don't have the needed knowledge of the C programming 
language, or about what truth actually is.

And the fact that you refuse to take up any of my challenges to have me 
repost the link (because you clearly prefer to just lie rather that try 
to do some research) it is clear that you are not actually certain of 
your claim, so you know you may be lying, but you do it anyway.



> 
>> The actual
>> implementation of H as decribed in some earlier messages is
>> not fully encoded in standard C, so in order to understand the
>> behaviour of D one needs to know and understand something that
>> is not given as a C code and therefore not understandable from
>> mere knowing the C language definition.
>>
> 
> *SUFFICIENTLY KNOWING THE SEMANTICS OF C*
> *SUFFICIENTLY KNOWING THE SEMANTICS OF C*
> *SUFFICIENTLY KNOWING THE SEMANTICS OF C*

Which you don't seem to have, since you claim prove false statements 
about it.

> 
> I could cast uint32_t to and from the various function pointer
> types yet this is more difficult for people to understand.
> I got complaints about this.
> It is simpler and easier to do this: typedef int (*ptr)();
> 
> 

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

#334295

Am Fri, 17 May 2024 12:46:29 -0500 schrieb olcott:
> On 5/17/2024 11:00 AM, Mikko wrote:
>> On 2024-05-17 15:30:01 +0000, olcott said:
>>> On 5/17/2024 2:25 AM, Fred. Zwarts wrote:
>>>> Op 17.mei.2024 om 03:15 schreef olcott:

>>> It is self-evidently true to anyone having sufficient knowledge
>>> of the semantics of the C programming language.
>> 
>> No, it isn't, because the C code of H is not shown. 
> 
> *I DON'T KNOW WHY I MUST REPEAT THIS HUNDREDS OF TIMES*
> The C code that <is> shown provides the template for the
> infinite set of every D correctly simulated by H.
In music, repetition legitimises. This is not music. This is spam.
Maybe try something new. 

>> The actual
>> implementation of H as decribed in some earlier messages is
>> not fully encoded in standard C, so in order to understand the
>> behaviour of D one needs to know and understand something that
>> is not given as a C code and therefore not understandable from
>> mere knowing the C language definition.
-- 
joes

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

#334262

On 5/17/24 11:30 AM, olcott wrote:
> On 5/17/2024 2:25 AM, Fred. Zwarts wrote:
>> Op 17.mei.2024 om 03:15 schreef olcott:
>>> The following is self-evidently true on the basis of the
>>> semantics of the C programming language.
>>>
>>> typedef int (*ptr)();  // ptr is pointer to int function
>>> 00 int H(ptr x, ptr x);
>>> 01 int D(ptr x)
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 int main()
>>> 10 {
>>> 11   H(D,D);
>>> 12   return 0;
>>> 13 }
>>>
>>> In the above case a simulator is an x86 emulator that correctly
>>> emulates at least one of the x86 instructions of D in the order
>>> specified by the x86 instructions of D.
>>>
>>> This may include correctly emulating the x86 instructions of H
>>> in the order specified by the x86 instructions of H thus calling
>>> H(D,D) in recursive simulation.
>>>
>>> Any H/D pair matching the above template where
>>> D(D) is simulated by the same H(D,D) that it calls
>>> cannot possibly reach its own line 06 and halt.
>>>
>>> *This is a simple software engineering verified fact*
>>>
>>
>> Note that olcott defines 'verified fact' as 'proven fact', but he is 
>> unable to show the proof. So, it must be read as 'my belief'.
> 
> It is self-evidently true to anyone having sufficient knowledge
> of the semantics of the C programming language.
> 


Which, since I posted over two weeks ago how to do it in C, means that 
you don't have the needed knowledge of the C programming language, or 
about what truth actually is. THAT is now self-evidently true.

And the fact that you refuse to take up any of my challenges to have me 
repost the link (because you clearly prefer to just lie rather that try 
to do some research) it is clear that you are not actually certain of 
your claim, so you know you may be lying, but you do it anyway.

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

#334362 — Re: Every D correctly simulated by H never reaches its final state and halts --- Admitted Liar

On 5/19/2024 12:17 PM, Richard Damon wrote:
> On 5/19/24 9:59 AM, olcott wrote:
>> On 5/19/2024 8:43 AM, Mikko wrote:
>>> On 2024-05-19 12:36:08 +0000, olcott said:
>>>
>>>> On 5/19/2024 5:37 AM, Mikko wrote:
>>>>> On 2024-05-18 14:38:53 +0000, olcott said:
>>>>>
>>>>>> On 5/18/2024 4:45 AM, Mikko wrote:
>>>>>>> On 2024-05-17 15:55:03 +0000, olcott said:
>>>>>>>
>>>>>>>> On 5/17/2024 4:08 AM, Mikko wrote:
>>>>>>>>> On 2024-05-17 07:25:52 +0000, Fred. Zwarts said:
>>>>>>>>>
>>>>>>>>>> Op 17.mei.2024 om 03:15 schreef olcott:
>>>>>>>>>>> The following is self-evidently true on the basis of the
>>>>>>>>>>> semantics of the C programming language.
>>>>>>>>>>>
>>>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>>>>>>>> 00 int H(ptr x, ptr x);
>>>>>>>>>>> 01 int D(ptr x)
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>>>> 06   return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 int main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11   H(D,D);
>>>>>>>>>>> 12   return 0;
>>>>>>>>>>> 13 }
>>>>>>>>>>>
>>>>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>>>>
>>>>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>>>>> in the order specified by the x86 instructions of H thus calling
>>>>>>>>>>> H(D,D) in recursive simulation.
>>>>>>>>>>>
>>>>>>>>>>> Any H/D pair matching the above template where
>>>>>>>>>>> D(D) is simulated by the same H(D,D) that it calls
>>>>>>>>>>> cannot possibly reach its own line 06 and halt.
>>>>>>>>>>>
>>>>>>>>>>> *This is a simple software engineering verified fact*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note that olcott defines 'verified fact' as 'proven fact', but 
>>>>>>>>>> he is unable to show the proof. So, it must be read as 'my 
>>>>>>>>>> belief'.
>>>>>>>>>
>>>>>>>>> A "proven fact" without a proof is not worse than a "verified 
>>>>>>>>> fact"
>>>>>>>>> without a verification.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *I updated my wording*
>>>>>>>> It is self-evidently true to anyone having sufficient knowledge
>>>>>>>> of the semantics of the C programming language.
>>>>>>>
>>>>>>> No, it is not. I would know if it were.
>>>>>>>
>>>>>>
>>>>>> If you do not understand that a single valid counter-example
>>>>>> would refute my claim then you don't know enough about proofs.
>>>>>
>>>>> Your claim
>>>>>
>>>>
>>>> Most people to not know the difference between deductive proof
>>>> ]and inductive evidence.
>>>
>>> Most people don't read comp.theory so here we needn't care.
>>>
>>
>> If anyone is trying to prove me wrong they
>> must first understand what an actual proof is.
>>
>> Several people here seem to think that ad hominem personal
>> attacks and insults are the basis for a valid rebuttal.
>>
>> Richard has stated that he thinks that an example of
>> {D never simulated by H} ∈ {every D simulated by H}
> 
> No, the H that didn't simulate its input shows that once you allow H to 
> not be required to be correct, that we can then have a trivial function 
> that is "just as correct" (since wrong answers were allowed).
> 

*There you go, admitting that he is exactly the Liar that I claimed*
*There you go, admitting that he is exactly the Liar that I claimed*
*There you go, admitting that he is exactly the Liar that I claimed*


>>
>> On 5/1/2024 7:28 PM, Richard Damon wrote:
>> Message-ID: <v0ummt$2qov3$2@i2pn2.org>
>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv0ummt%242qov3%242%40i2pn2.org%3E
>>
>>>>>>>> It is self-evidently true to anyone having sufficient knowledge
>>>>>>>> of the semantics of the C programming language.
>>>>>
>>>>> is a little unclear about the meaning of "It" but I think it
>>>>> is false for any reasonable interpretation. Can I call myself
>>>>> a counter-example?
>>>
>>>
>>
> 

-- 
Copyright 2024 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]

#334364 — Re: Every D correctly simulated by H never reaches its final state and halts --- Olcott is an Admitted Liar

On 5/19/24 3:07 PM, olcott wrote:
> On 5/19/2024 12:17 PM, Richard Damon wrote:
>> On 5/19/24 9:59 AM, olcott wrote:
>>> On 5/19/2024 8:43 AM, Mikko wrote:
>>>> On 2024-05-19 12:36:08 +0000, olcott said:
>>>>
>>>>> On 5/19/2024 5:37 AM, Mikko wrote:
>>>>>> On 2024-05-18 14:38:53 +0000, olcott said:
>>>>>>
>>>>>>> On 5/18/2024 4:45 AM, Mikko wrote:
>>>>>>>> On 2024-05-17 15:55:03 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 5/17/2024 4:08 AM, Mikko wrote:
>>>>>>>>>> On 2024-05-17 07:25:52 +0000, Fred. Zwarts said:
>>>>>>>>>>
>>>>>>>>>>> Op 17.mei.2024 om 03:15 schreef olcott:
>>>>>>>>>>>> The following is self-evidently true on the basis of the
>>>>>>>>>>>> semantics of the C programming language.
>>>>>>>>>>>>
>>>>>>>>>>>> typedef int (*ptr)();  // ptr is pointer to int function
>>>>>>>>>>>> 00 int H(ptr x, ptr x);
>>>>>>>>>>>> 01 int D(ptr x)
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>>>>> 06   return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11   H(D,D);
>>>>>>>>>>>> 12   return 0;
>>>>>>>>>>>> 13 }
>>>>>>>>>>>>
>>>>>>>>>>>> In the above case a simulator is an x86 emulator that correctly
>>>>>>>>>>>> emulates at least one of the x86 instructions of D in the order
>>>>>>>>>>>> specified by the x86 instructions of D.
>>>>>>>>>>>>
>>>>>>>>>>>> This may include correctly emulating the x86 instructions of H
>>>>>>>>>>>> in the order specified by the x86 instructions of H thus 
>>>>>>>>>>>> calling
>>>>>>>>>>>> H(D,D) in recursive simulation.
>>>>>>>>>>>>
>>>>>>>>>>>> Any H/D pair matching the above template where
>>>>>>>>>>>> D(D) is simulated by the same H(D,D) that it calls
>>>>>>>>>>>> cannot possibly reach its own line 06 and halt.
>>>>>>>>>>>>
>>>>>>>>>>>> *This is a simple software engineering verified fact*
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Note that olcott defines 'verified fact' as 'proven fact', 
>>>>>>>>>>> but he is unable to show the proof. So, it must be read as 
>>>>>>>>>>> 'my belief'.
>>>>>>>>>>
>>>>>>>>>> A "proven fact" without a proof is not worse than a "verified 
>>>>>>>>>> fact"
>>>>>>>>>> without a verification.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *I updated my wording*
>>>>>>>>> It is self-evidently true to anyone having sufficient knowledge
>>>>>>>>> of the semantics of the C programming language.
>>>>>>>>
>>>>>>>> No, it is not. I would know if it were.
>>>>>>>>
>>>>>>>
>>>>>>> If you do not understand that a single valid counter-example
>>>>>>> would refute my claim then you don't know enough about proofs.
>>>>>>
>>>>>> Your claim
>>>>>>
>>>>>
>>>>> Most people to not know the difference between deductive proof
>>>>> ]and inductive evidence.
>>>>
>>>> Most people don't read comp.theory so here we needn't care.
>>>>
>>>
>>> If anyone is trying to prove me wrong they
>>> must first understand what an actual proof is.
>>>
>>> Several people here seem to think that ad hominem personal
>>> attacks and insults are the basis for a valid rebuttal.
>>>
>>> Richard has stated that he thinks that an example of
>>> {D never simulated by H} ∈ {every D simulated by H}
>>
>> No, the H that didn't simulate its input shows that once you allow H 
>> to not be required to be correct, that we can then have a trivial 
>> function that is "just as correct" (since wrong answers were allowed).
>>
> 
> *There you go, admitting that he is exactly the Liar that I claimed*
> *There you go, admitting that he is exactly the Liar that I claimed*
> *There you go, admitting that he is exactly the Liar that I claimed*

Since the not meeting specs was about YOUR H, I guess you are just 
admitting that you (Olcott) are a liar.

> 
> 
>>>
>>> On 5/1/2024 7:28 PM, Richard Damon wrote:
>>> Message-ID: <v0ummt$2qov3$2@i2pn2.org>
>>> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv0ummt%242qov3%242%40i2pn2.org%3E
>>>
>>>>>>>>> It is self-evidently true to anyone having sufficient knowledge
>>>>>>>>> of the semantics of the C programming language.
>>>>>>
>>>>>> is a little unclear about the meaning of "It" but I think it
>>>>>> is false for any reasonable interpretation. Can I call myself
>>>>>> a counter-example?
>>>>
>>>>
>>>
>>
> 

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

#334292

On 17/05/24 03:15, olcott wrote:
> The following is self-evidently true on the basis of the
> semantics of the C programming language.
> 
> typedef int (*ptr)();  // ptr is pointer to int function
> 00 int H(ptr x, ptr x);
> 01 int D(ptr x)
> 02 {
> 03   int Halt_Status = H(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   H(D,D);
> 12   return 0;
> 13 }
> 
> In the above case a simulator is an x86 emulator that correctly > emulates at least one of the x86 instructions of D in the order
> specified by the x86 instructions of D.

I don't see any simulator in the above case.

[toc] | [prev] | [standalone]

Back to top | Article view | sci.logic

csiph-web