XPost: sci.logic

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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)();

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-17 17:46:29 +0000, olcott said:

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.

You need to repeat this because what you said is defective,
so it cannot be understood as you want and you don't know how
you could fix it so that you could say what you want to say.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/18/24 10:38 AM, olcott wrote:

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.

If you do not understand that a single valid counter-example is
the only correct refutation of my claim then you don't know enough
about proofs.

Which has been provided and ignored, proving you to be a liar.


The summary, and H that begins as

int H(ptr x, ptr y) {

static int flag = 0;
if(flag) return 0;
flag = 1;

/* code then continues as your simulator but disable the
non-simulation of the function H */
}


So, you are just proven to be a pathological lying idiot

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/18/24 10:55 AM, olcott wrote:

On 5/18/2024 8:30 AM, Mikko wrote:

On 2024-05-17 17:46:29 +0000, olcott said:

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.

You need to repeat this because what you said is defective,

*Try and show exactly how the following is defective*
*Try and show exactly how the following is defective*
*Try and show exactly how the following is defective*

so it cannot be understood as you want and you don't know how
you could fix it so that you could say what you want to say.

typedef int (*ptr)();  // ptr is pointer to int function
00 int H(ptr x, ptr y);
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.

Execution Trace
Line 11: main() invokes H(D,D);

keeps repeating (unless aborted)
Line 01:
Line 02:
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)

Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 03.

The key thing to note is that no D simulated correctly by any H of every
H/D pair specified by the above template ever reaches its own line 06
and halts.

PROVEN WRONG and that you are just a LIAR.

let H begin:

int H(ptr x, ptr y) {
static int flag = 0;
if (flag) return 0;
flag = 1;

/* Then you normal H with the skipping of the simualtion of H disabled */

}

Will be able to correct simulate D to the end at line 6.


Thus, you are proven to not have sufficient knowledge of the semantic properties of C, and to just be an ignorant pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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?

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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?

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-19 13:59:09 +0000, olcott said:

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}

More generally, everybody who knows what ∈ usually means,
thinks that {} ∈ X is true unless it is a syntax error.

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?

As this question seems unanswered I thing it is best to say that
you haven't proven that I am not a counter-example and therefore
that a counter-example does not exist.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/20/24 1:53 PM, olcott wrote:

On 5/20/2024 3:08 AM, Mikko wrote:

On 2024-05-19 13:59:09 +0000, olcott said:

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}

More generally, everybody who knows what ∈ usually means,
thinks that {} ∈ X is true unless it is a syntax error.

According to that reasoning everyone
thinks that {cats} ∈ {dogs} is true.

Why?

DO you think {} and {cats} are the same thing?

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?

As this question seems unanswered I thing it is best to say that
you haven't proven that I am not a counter-example and therefore
that a counter-example does not exist.

UNDER DEDUCTION (AKA PROOF)
The argument from authority is a logical fallacy[2] (also known as ad verecundiam fallacy), and obtaining knowledge in this way is fallible. https://en.wikipedia.org/wiki/Argument_from_authority

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-17 17:46:29 +0000, olcott said:

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.

Such casts are not permitted by the C standard. They may be
allowed by some compilers as an extension to C.

I got complaints about this.
It is simpler and easier to do this: typedef int (*ptr)();

The C standard does not permit reading the memory with a pointer
of this type nor a cast to another type that would permit such
reading. As simulation requires reading, this prevents all simulation
of the code. A compiler may allow casting to another type that
can be used for simulation as an extension to C. The C standard
is quite liberal about implementation specific extensions.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-20 17:53:59 +0000, olcott said:

On 5/20/2024 3:08 AM, Mikko wrote:

On 2024-05-19 13:59:09 +0000, olcott said:

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}

More generally, everybody who knows what ∈ usually means,
thinks that {} ∈ X is true unless it is a syntax error.

According to that reasoning everyone
thinks that {cats} ∈ {dogs} is true.

Apparently your interpretation of either "that reasoning" or
"everyone" is different from mine.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/05/24 11:39, Mikko wrote:

On 2024-05-20 17:53:59 +0000, olcott said:

On 5/20/2024 3:08 AM, Mikko wrote:

More generally, everybody who knows what ∈ usually means,
thinks that {} ∈ X is true unless it is a syntax error.

According to that reasoning everyone
thinks that {cats} ∈ {dogs} is true.

Apparently your interpretation of either "that reasoning" or
"everyone" is different from mine.

You meant the is-subset operator, ⊆
{} ⊆ X is true for every set X.
{} ∈ X is not true for every set X.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-05-21 09:54:48 +0000, immibis said:

On 21/05/24 11:39, Mikko wrote:

On 2024-05-20 17:53:59 +0000, olcott said:

On 5/20/2024 3:08 AM, Mikko wrote:

More generally, everybody who knows what ∈ usually means,
thinks that {} ∈ X is true unless it is a syntax error.

According to that reasoning everyone
thinks that {cats} ∈ {dogs} is true.

Apparently your interpretation of either "that reasoning" or
"everyone" is different from mine.

You meant the is-subset operator, ⊆
{} ⊆ X is true for every set X.
{} ∈ X is not true for every set X.

Something like that.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/21/24 9:41 AM, olcott wrote:

On 5/21/2024 4:39 AM, Mikko wrote:

Apparently your interpretation of either "that reasoning" or
"everyone" is different from mine.

Richard said that he didn't know he was supposed to provide
correct answers, he thought it was OK to intentionally provide
incorrect answers (AKA lie)

That isn't what I said, and so you are shown to be a LIAR.

I said that my H was just as accurate, as yours.

That means, you ADMIT that you have lied, that your machine was correct,
and know it.

After all, YOU argure that H is allowed to say that D(D) doesn't halt,
just because its simulaiton doesn't reach the end, even though you know
and admit that D(D) WILL HALT.

Thus, since the criteria allows the not reaching a final state to be
because the simulator didn't simulate long enough, my alternate machine
was JUST AS CORRECT.

On 5/19/2024 12:17 PM, Richard Damon wrote:

On 5/19/24 9:59 AM, olcott wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)