On 7/19/25 6:16 PM, olcott wrote:
On 7/19/2025 5:08 PM, wij wrote:
On Sat, 2025-07-19 at 16:36 -0500, olcott wrote:
On 7/19/2025 4:26 PM, wij wrote:
On Sat, 2025-07-19 at 16:05 -0500, olcott wrote:
On 7/19/2025 3:57 PM, wij wrote:
On Sat, 2025-07-19 at 15:41 -0500, olcott wrote:
On 7/19/2025 3:14 PM, wij wrote:
HP is very simple: H(D)=1 if D halts, H(D)=0 if D does not halt. >>>>>>>>
The standard proof assumes a decider
H(M,x) that determines whether machine
M halts on input x.
But this formulation is flawed, because:
Whatever the 'formulation' is, the HP result is a fact that no H
can decide
the halting status of any given D.
And that is wrong because H(⟨D⟩) is correctly determined.
It has always been a type mismatch error when H(D) was
assumed.
Yes, there is type mismatch problems in nearly all discussions.
But I don't think you will understand what it is.
I have proven that I do and you only deny this
because you are not interested in an honest
dialogue.
You like to ignore what people say, only insterested in one-sided talk,
showing you are not interested in honest discussion.
Turing machines can only process finite encodings
(e.g. ⟨M⟩), not executable entities like M.
So the valid formulation must be
H(⟨M⟩,x), where ⟨M⟩ is a string.
Halting Problem::= H(D)=1 if D halts, H(D)=0 if D does not halt.
The conclusion is, no such H exists.
And that is wrong because H(⟨D⟩) is correctly determined.
It has always been a type mismatch error when H(D) was
assumed.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
A type mismatch: HHH(DD) or HHH(<DDD>)?
DD points to the finite string machine
description of DD it does not point to
the executing process of DD.
That is what I predicted: You don't understand what you said.
(because it is a bit technical, I will skip this part)
typedef void (*ptr)();
int HHH(ptr P);
Do you even know what an executing process is?
Probably not and you will use some lame excuse for not answering.
The finite string of x86 machine code pointed to by P
*is not an executing process*
It is the equivalent of of a machine description
that completely specifies (not merely describes)
behavior.
Right, and perhaps you don't understand that the complete specification
of the x86 code of a program, and its input, FULLY SPECIFIES the
behavior of that program.
Thus, that behavior is eligable to be asked about.
It seems your logic is so primative it doesn't allow actual derevation
of results.
You also just don't understand the term-of-art meaning of the words, in
part because you admitted you were afraid to learn the basics of the
field as them might brainwash you into the wrong thinking of the
conventional users of the theory (which actualy just shows your own
wrong thinking).
Sorry, youa re just proving your are either mentally or morally
deficient, if not both.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)