Re: Is Richard a Liar?

On 5/17/2024 11:24 AM, Fred. Zwarts wrote:

Op 17.mei.2024 om 17:31 schreef olcott:

On 5/17/2024 2:41 AM, Fred. Zwarts wrote:

Op 16.mei.2024 om 21:32 schreef olcott:

On 5/16/2024 1:55 PM, Fred. Zwarts wrote:

Op 16.mei.2024 om 18:04 schreef olcott:

On 5/16/2024 10:12 AM, Fred. Zwarts wrote:

Op 16.mei.2024 om 16:54 schreef olcott:

On 5/16/2024 5:36 AM, Fred. Zwarts wrote:

Op 15.mei.2024 om 22:10 schreef olcott:

On 5/15/2024 2:13 PM, Fred. Zwarts wrote:

Op 15.mei.2024 om 20:39 schreef olcott:

On 5/15/2024 1:19 PM, Fred. Zwarts wrote:

Op 15.mei.2024 om 18:27 schreef olcott:

On 5/15/2024 9:50 AM, Fred. Zwarts wrote:

Op 15.mei.2024 om 16:02 schreef olcott:

On 5/15/2024 1:21 AM, Fred. Zwarts wrote:

Op 14.mei.2024 om 22:13 schreef olcott:

On 5/14/2024 3:05 PM, Fred. Zwarts wrote:

Op 14.mei.2024 om 21:42 schreef olcott:

On 5/14/2024 2:36 PM, Fred. Zwarts wrote:

Op 14.mei.2024 om 20:40 schreef olcott:

On 5/14/2024 1:30 PM, Fred. Zwarts wrote:

Op 14.mei.2024 om 19:52 schreef olcott:

On 5/14/2024 12:49 PM, Fred. Zwarts wrote:

Op 14.mei.2024 om 19:14 schreef olcott:

On 5/14/2024 11:13 AM, Fred. Zwarts wrote:

Op 14.mei.2024 om 17:45 schreef olcott:

On 5/14/2024 10:42 AM, Fred. Zwarts wrote:

Op 14.mei.2024 om 17:30 schreef olcott:

On 5/14/2024 10:08 AM, Alan Mackenzie wrote:

[ Followup-To: set ]
>
In comp.theory olcott <polcott333@gmail.com> wrote:

On 5/14/2024 4:44 AM, Mikko wrote:

On 2024-05-12 15:58:02 +0000, olcott said:

>

On 5/12/2024 10:21 AM, Mikko wrote:

On 2024-05-12 11:34:17 +0000, Richard Damon said:

>

On 5/12/24 5:19 AM, Mikko wrote:

On 2024-05-11 16:26:30 +0000, olcott said:

>

I am working on providing an academic quality definition of this
term.

>

The definition in Wikipedia is good enough.

>
>

I think he means, he is working on a definition that redefines the
field to allow him to claim what he wants.

>

Here one can claim whatever one wants anysay.
In if one wants to present ones claims on some significant forum then
it is better to stick to usual definitions as much as possible.

>

Sort of like his new definition of H as an "unconventional" machine
that some how both returns an answer but also keeps on running.

>

There are systems where that is possible but unsolvable problems are
unsolvable even in those systems.

>
>

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

>

This notation does not work with machines that can, or have parts
that can, return a value without (or before) termination.

>
>
>

00 int H(ptr x, ptr x)  // ptr is pointer to int function
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 }

>

In any case you diverged away form the whole point of this thread.
Richard is wrong when he says that there exists an H/D pair such
that D simulated by H ever reaches past its own line 03.

>
Yes, in the same way that you are wrong. The above "C code" is garbage;
as already pointed out, it doesn't even compile. So any talk of
"reaching line 3" or "matching" that "code" is vacuous nonsense.
>

>
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 past its own
line 03. Simple software engineering verified fact.

>
Since nobody knows who has verified this fact en there have been counter examples,

>
*See if you can show that your claim of counter-examples is not a lie*
*See if you can show that your claim of counter-examples is not a lie*
*See if you can show that your claim of counter-examples is not a lie*
>

>

>
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
>
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
>
*YOU SKIPPED THE CHALLENGE TO YOUR ASSERTION*
IS THAT BECAUSE YOU KNOW IT IS FALSE?
>

Olcott is trying to stay at this point for several weeks now, but he does not succeed. The reason probably is, that it is already a few steps too far. First there must be agreement about the words and terms used in what he says. So, we should delay this subject and go back a few steps.
Before we can talk about this, first there must be 100% agreement about:
>
1) What is a "verified fact"? Who needs to do the verification before it can be said that it is a verified fact?

>
I am ONLY referring to expressions that are PROVEN
to be {true entirely on the basis of their meaning}.
>
*CONCRETE EXAMPLES*
How do we know that 2 + 3 = 5?

>
If needed we can write out the proof for this, starting from the axioms for natural numbers. That proof is well known.
>
But nobody here knows the proof for your assertion above, that it is a verified fact that it cannot reach past line 03. So, we would like to see that proof. Just the claim that it has been proven is not enough.
>

>
The "nobody here" you are referring to must be clueless
about the semantics of the C programming language.
>

>
Are you honest? Please, give the proof, instead of keeping away from it.

>
I have been an expert C/C++ programmer for decades.
If you knew C will enough yourself you would comprehend
that my claim about:
>
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 past its own line 03.
This is a simple software engineering verified fact.
>
My grandfather was a diagnostician and pathologist
said: "You can't argue with ignorance".

>
Again no trace of a proof. Only your authority and personal attacks about lack of knowledge and ignorance. So, the text below still stands:
>

>
*The only sufficient proof is being an expert in C yourself*

>
Again no trace of a proof. Do you understand what a proof is?
The proof of 2+3=5 is not 'Being a mathematician'.
You give the impression that you are clueless about how to prove it.
>

>
The proof of 2 + 3 = 5 is through comprehending arithmetic.

>
No, it follows with very simple reasoning from the axiomatic properties of natural numbers.
>

>
If you understand them then the proof is easy if you
do not understand them then the proof is impossible.
>

It cannot be proved to anyone failing to comprehend arithmetic.
>
Likewise my proof is through comprehending the semantics of C.
It cannot be proved to anyone failing to comprehend the semantics of C.

>
Since we understand C, that is not an excuse. It seems that you are looking for excuses to hide the fact that you have never seen such proof.
>

>
00 int H(ptr x, ptr x)  // ptr is pointer to int function
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 }
>
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 past its own line 03.
>
If you understand C and understand proofs then you
understand that a single counter-example would refute
my claim if one exists. You would also understand that
that when no such counter-example exists that would
prove that I am correct.
>
So I ask you to do one of three things:
(a) Admit that I am correct
(b) Provide a single counter example
(c) Admit that you simply don't understand this.
>
*Any other response will be construed as intentional deception*
Intentional deception certainly meets the requirement of
reckless disregard for the truth of defamation lawsuits.
>
https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html
>

>
Again no proof. Now with the excuse that olcott does not know a counter example.

>
Any claim that my statement is incorrect that does not have the
required single counter-example proving that my claim is incorrect
could be construed as the
>
https://dictionary.findlaw.com/definition/reckless-disregard-of-the-truth.html
>
of defamation. This is definitely defamation when people skilled in the
art of C programming understand that my claim is self-evidently true
and proved entirely on the basis of the semantics of the C programing
language.
>

It your claim, so you have the burden of a proof. Not knowing a counter example is not a proof. It seems you are using such excuses to hide the fact that you don't know how to prove it. Again, if there is a proof, show it. Otherwise stop saying that it is a verified fact, because it becomes more and more clear that nobody verified it.

>
*It is ONLY a verified fact to people*
*skilled in the art of C programming*
>
https://www.britannica.com/science/mole-chemistry
A mole in chemistry is only a verified fact to those
skilled in the art of chemistry. To everyone else it
is an animal that burrows in the ground.
>

>
Again no proof. The excuse, asking for a counter example,

>
People that claimed they provided (a valid) counter-example
are LIARS. They that know is was an invalid or non-existent
counter-example is a basis for winning a defamation suit.
>

is even weaker. If there is a proof, it would be so simple to show it here. As even olcott said that a verified fact is a proven fact, he cannot speak of a verified fact as long as there is no proof. I have 50 years of experience in programming, many years in C, so I am a very skilled C programmer. So, why do you hide the proof? I wonder what the next excuse will be to hide the fact that there is no proof.

>
*Then you know that valid counter-examples cannot possibly exist*
*and implication otherwise is a reckless disregard for the truth*
>

>
Again no proof. This time, instead of a proof, the claim that a counter

>
If I had 10,000 experts in C that are PhD computer scientists
that agreed with me this would not be proof. It is you that do
not understand what proof is.

>
Again an excuse to hide the proof. Now the prejudice that we would not understand it.
Further, it seems to be another indication that olcott does not understand how a proof in computation theory looks like. It is not like a juridical proof, where the number and expertise of witnesses play a role.
In computation theory a proof consists of a number of steps, starting with the definitions of the elements involved and of the axioms of the theory, resulting in a conclusion. Each of these steps can be explained from the definitions, axioms and results of previous steps.
Olcott, again, if you want to convince people, learn how to formulate a proof. Up to now, we have not seen more than your conviction, without evidence. Present the proof and we will see whether we understand it.

>
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 }
>
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 past its own line 03.
This is a simple software engineering verified fact.
>
It is true that the semantics of C does prove that
the above paragraph is true.
>
It is also true that you have proven that you are not
interested in an honest dialogue.
>
>

>
Again no proof. Again the excuse that we would not be interested in an honest dialogue. I am interested. That is why I ask for the proof.

>
Anyone that knows the semantics of the C language well enough
understands that a counter-example is categorically impossible.
(a) You know the semantics of C well enough and lie.
(b) You know the semantics of C well enough and fail to tell the truth.

>
Again no proof. Now with the excuse that we can find out ourselves.
Olcott is claiming, so olcott has the burden of the proof. Without a proof, it is not "verified fact", but "my belief".
(a) olcott knows that there is no such proof.
(b) olcott has no idea how to formulate a proof.
(c) olcott thinks he has a proof, but does not dare to show it, because he is afraid that someone will spot an error in it.
>

>
It seems that you are simply too ignorant to understand that 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 or 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 past its own line 03.
>
*This is a simple software engineering verified fact*
>
>

>
Again no proof. Now the excuse is that it is self-evidently true. A bad excuse, because it is self-evident only for olcott. That is what we call belief. It shows again that when olcott writes 'verified fact' we should read 'my belief'. Sorry, olcott, but with only your belief, your are not going to invalidate a proven theorem in computation theory. You will convince nobody if no proof can be supplied.

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

 Again no proof. Now the excuse is that it is self-evident.

The you want me to prove something to you in a language that you do not
sufficiently understand is an unreasonable request. I have improved the
words of my proof and put in some more details.
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.
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.
The above 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