Re: Unconventional partial halt decider and grounding to a truthmaker

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