XPost: sci.logic

On 5/16/24 10:48 AM, olcott wrote:

On 5/16/2024 5:42 AM, Mikko wrote:

On 2024-05-15 15:06:26 +0000, olcott said:

On 5/15/2024 3:06 AM, Mikko wrote:

On 2024-05-14 14:32:26 +0000, olcott said:

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 }

That notation is not any better for the purpose.

I refer to transitioning through a specific state to indicate
a specific halt status value, for Turing Machines.

That does not satisfy the usual definition of "halt decider".

Yet it <is> an incremental improvement over both YES and NO are
the wrong answer for input D. YES <is> the correct answer and H
can not SAY this answer in the conventional way.

However, we could accept that as a solution to the halting problem
if one could prove that there is a Turing machine that can indicate
halting or non-halting that way for all computations.

Refuting the HP pathological program/input pair is the the full scope
of my theory of computation work. Even without my POD24 diagnosis I
would have no time to verify this against an infinite set of programs.

And you don't even get that one right.

Validation of POD24 as a robust early clinical end point of poor
survival in FL from 5225 patients on 13 clinical trials https://pubmed.ncbi.nlm.nih.gov/34614146/

Yep, perhaps some day soon we will be rid of your lies.

However, it is possible to prove that every Turing machine that
indicates halting that way fails to indicate correctly at least
some computations.

Once I conquer the HP pathological program/input pair and
apply to to the foundation of {true on the basis of meaning}
expressed as finite strings, then I am done.

But since you can't conquer the Halting Problem, except by just lying
and calling your Poop Halting, you aren't going to get anywhere.

True on the basis of meaning, needs to start with using words according
to their meaning, which means that Halting IS what Halting was defined
to be.

Your trying to "redefine" it just shows you don't know that that
actually means.

"a sentence may fail to make a statement if it is paradoxical or
ungrounded."
*Outline of a Theory of Truth --- Saul Kripke* https://www.impan.pl/~kz/truthseminar/Kripke_Outline.pdf

How to define a True(L, x) predicate that refutes Tarski Undefinability:
*AKA The grounding of a truth-bearer to its truthmaker*

True(L,x) returns true when x is derived from a set of truth preserving operations from finite string expressions of language that have been stipulated to have the semantic value of Boolean true. False(L,x) is
defined as True(L,~x).   Copyright 2022 PL Olcott

And thus True(L, x) with x in L defined as ~True(L, x) show that us that True(L, x) must be false, but is also must be true as if True(L, x) is
false, then x is ~false, or true.

So either true is false, or ~ doesn't work, or there doesn't exist a
True predicate.

So, your logic system is just broken, but you are too dumb to understand
that.


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

XPost: sci.logic

Am Thu, 16 May 2024 22:29:14 -0400 schrieb Richard Damon:

On 5/16/24 10:48 AM, olcott wrote:

On 5/16/2024 5:42 AM, Mikko wrote:

On 2024-05-15 15:06:26 +0000, olcott said:

On 5/15/2024 3:06 AM, Mikko wrote:

On 2024-05-14 14:32:26 +0000, olcott said:

I refer to transitioning through a specific state to indicate a
specific halt status value, for Turing Machines.

That does not satisfy the usual definition of "halt decider".

Yet it <is> an incremental improvement over both YES and NO are the
wrong answer for input D. YES <is> the correct answer and H can not SAY
this answer in the conventional way.

However, we could accept that as a solution to the halting problem if
one could prove that there is a Turing machine that can indicate
halting or non-halting that way for all computations.

Refuting the HP pathological program/input pair is the the full scope
of my theory of computation work. Even without my POD24 diagnosis I
would have no time to verify this against an infinite set of programs.

And you don't even get that one right.

Validation of POD24 as a robust early clinical end point of poor
survival in FL from 5225 patients on 13 clinical trials
https://pubmed.ncbi.nlm.nih.gov/34614146/

Yep, perhaps some day soon we will be rid of your lies.

That’s low.
Your continuous cries of „liar” aren’t any better than Peter’s spam.

--
joes

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

On 2024-05-16 14:48:21 +0000, olcott said:

On 5/16/2024 5:42 AM, Mikko wrote:

On 2024-05-15 15:06:26 +0000, olcott said:

On 5/15/2024 3:06 AM, Mikko wrote:

On 2024-05-14 14:32:26 +0000, olcott said:

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 }

That notation is not any better for the purpose.

I refer to transitioning through a specific state to indicate
a specific halt status value, for Turing Machines.

That does not satisfy the usual definition of "halt decider".

Yet it <is> an incremental improvement over both YES and NO are
the wrong answer for input D. YES <is> the correct answer and H
can not SAY this answer in the conventional way.

For every computation "yes" is the correct answer if and only if one can construct a finite sequence of configurations so that the first one is the initial configuration, each other one follows from the previous one by a transition rule, and no possible configuration follows from the last one
by any transition rule. If "yes" is not the correct answer then "no" is. Therefore there is no D where neither "yes" and "no" is wrong for the
same input.

None of this is of course relevant to the topics of my comments quoted
above.

However, we could accept that as a solution to the halting problem
if one could prove that there is a Turing machine that can indicate
halting or non-halting that way for all computations.

Refuting the HP pathological program/input pair is the the full scope
of my theory of computation work. Even without my POD24 diagnosis I
would have no time to verify this against an infinite set of programs.

That is a very modest goal as those programs are not deeded for
any purpose. They are only used to prove a theorem that can be
proven without those programs.

However, refuting a program/input pair is a category error. You can
refute a claim but a program/input pair is not claim.

Once I conquer the HP pathological program/input pair and
apply to to the foundation of {true on the basis of meaning}
expressed as finite strings, then I am done.

So far it seems that you have not yet even started. You have not yet
presented any intermediate achievement that could indicate that you
might find something interesting.

"a sentence may fail to make a statement if it is paradoxical or ungrounded." *Outline of a Theory of Truth --- Saul Kripke* https://www.impan.pl/~kz/truthseminar/Kripke_Outline.pdf

It is hard to avoid such sentences, especially if you want to say something about them.

How to define a True(L, x) predicate that refutes Tarski Undefinability:
*AKA The grounding of a truth-bearer to its truthmaker*

That is solved: no matter how you define it, the definition is not
useful for the purpose Tarski was considering.

True(L,x) returns true when x is derived from a set of truth preserving operations from finite string expressions of language that have been stipulated to have the semantic value of Boolean true.

That is not useful if there is no way to determine whether True(L,x) is
true.

False(L,x) is
defined as True(L,~x). Copyright 2022 PL Olcott

Neither is that. And hardly crative enough for copyright.

--
Mikko

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

XPost: sci.logic

joes <noreply@example.com> writes:

Am Thu, 16 May 2024 22:29:14 -0400 schrieb Richard Damon:

Yep, perhaps some day soon we will be rid of your lies.

That’s low.
Your continuous cries of „liar” aren’t any better than Peter’s spam.

Long before I stopped replying to PO I stopped calling his remarks lies.
He is simply too deluded to be reliably accused of lying. After all, he published a website claiming to bring new scripture to the world and
defended himself in court (on an unrelated matter) with the claim that
he was God. Unless all of that was just a game, he is not sufficiently
in touch with reality to be a liar.

When I did engage with him it was to try to pin down what he was really
saying and, after years of back-and-forth, he made two unequivocal
statement that, to my mind, render all subsequent discussion pointless.
First, when asked

"Here's the key question: do you still assert that H(P,P) == false is
the 'correct' answer even though P(P) halts?"

He replied:

"Yes that is the correct answer even though P(P) halts."

Second, when talking about axioms and proofs he claims that if

{A,B,C} |- X then {A,B,C,~A} ~|- X

(|- being "proves" and ~|- being "does not prove").

The first shows that he's not talking about that halting problem and the
second that when he says he's "refuted" all the proofs he does not know
what the words mean. Of course, he can retract these statements at any
time and move on, but he won't.

Some of his more deluded claims look like lies because he back-peddled
on them himself. His December 2018 claim to have

"... encoded all of the exact TMD instructions of the Linz Turing
machine H that correctly decides halting for its fully encoded input
pair: (Ĥ, Ĥ)."

was rowed-back and eventually claimed to be "poetic licence". Was it a
lie? I think his mental illness was simply in a manic phase and he'd
"seen the light" and wanted to tell the world. Maybe I am being too
kind here, I don't know.

What I do know is that it's pointless talking to someone who has made it
so clear that they are not talking about the halting problem and that
they don't even know what a proof is.

--
Ben.

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

On 5/18/24 1:11 PM, olcott wrote:

On 5/18/2024 3:23 AM, Mikko wrote:

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

On 5/17/2024 5:45 AM, Mikko wrote:

On 2024-05-16 14:48:21 +0000, olcott said:

On 5/16/2024 5:42 AM, Mikko wrote:

On 2024-05-15 15:06:26 +0000, olcott said:

On 5/15/2024 3:06 AM, Mikko wrote:

On 2024-05-14 14:32:26 +0000, olcott said:

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 }

That notation is not any better for the purpose.

I refer to transitioning through a specific state to indicate
a specific halt status value, for Turing Machines.

That does not satisfy the usual definition of "halt decider".

Yet it <is> an incremental improvement over both YES and NO are
the wrong answer for input D. YES <is> the correct answer and H
can not SAY this answer in the conventional way.

For every computation "yes" is the correct answer if and only if one
can
construct a finite sequence of configurations so that the first one
is the
initial configuration, each other one follows from the previous one
by a
transition rule, and no possible configuration follows from the last
one
by any transition rule. If "yes" is not the correct answer then "no"
is.
Therefore there is no D where neither "yes" and "no" is wrong for the
same input.

You are correct and I merely had a typo, I mean "NO" is the correct
answer if the above is not met, otherwise YES is the correct answer.

That obviously implies that there is no case where both "yes" and "no"
are right and there is no case where both "yes" and "no" are wrong.

What everyone gets confused about is that they disagree that:
a partial halt decider must determine its correct halt status
decision on the basis of the actual behavior that its input actually
specifies.

Who, other than you, has ever said otherwise?

You are in the wrong forum, I am changing it to comp.theory

Everyone besides me says that H must report on the behavior
of the computation that it is contained within this is both
impossible and incorrect.

No, H must report on the behavior of the program that its input
represents, EVEN IF that program calls (a copy of) the decider its self.

The fact that this means that H needs to determine what it will do
before it can decide what it will do is what gives it problems and make
the job impossible, but that is what it is required to do.

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