On 8/10/25 8:14 PM, olcott wrote:
On 8/10/2025 6:14 PM, Mr Flibble wrote:
On Sun, 10 Aug 2025 18:10:30 -0500, olcott wrote:
On 8/10/2025 6:04 PM, dbush wrote:
On 8/10/2025 7:01 PM, olcott wrote:
On 8/10/2025 5:56 PM, dbush wrote:
*Trollish replies will be henceforth ignored*
Translation:
"I will ignore things that prove me wrong"
I will pay very close attention to any actual attempts to prove me
wrong. The closest attempt to prove me wrong is the fact that HHH(DD)==0 >>> and the directly executed DD() disagree.
It isn't an attempt, it is a fact: you have been proven wrong.
/Flibble
The halting problem itself has always been wrong
when it requires a Turing machine to directly
report on the behavior of another directly executed
Turing machine because no Turing machine can take
another directly executed Turing machine as an input.
Nope, just shows you don't even understand the concept of a probem.
It also says your thinking ability can't handle even simple concepts
like representations, at least for things that you need to think of as representation.
You probably don't understand that writing numbers like ten as 10 is
just a form of representation, and the encoding of Turing Machine is
done be essentially the same sort of thing as the encoding of numbers.
The conventional proofs talk about a halt decider H
reporting on the behavior of machine M on input P yet
H is not given machine M it is only given machine
description ⟨M⟩.
Right, because that *IS* the problem.
Maybe you don't understand that Turing Machines are designed to compute mappings of all kinds via the means of representation, and the "Halting Funciton" *IS* a function that takes as its input a Turing machine and
its input and maps it to Halting or Not-Halting.
This assumes that the behavior of machine M on input P
will be identical to the correct simulation of ⟨M⟩ on P.
This is axiomatically true except in one specific case:
Which it does, as that IS the semantic meaning of the input.
If it isn't, then you just lied to the decider.
When machine M contains simulating halt decider H
and M is applied to ⟨M⟩
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M applied to ⟨M⟩ halts
But since it *DOES* abort, that isn't a proof, but is based on a false
premise.
The behavior of the input will have its simulation started in the first
(c) will also abort itself (but after the decider stopped looking at the behavior by stopping its simulation of it) and return to H^ which will halt.
Thus, you are just showing that you ar just a stupid liar that refuses
to learn the meaning of the words.
Since you haven't specifically tried to redefine them, Halting and
Non-Halting are terms that appply to the direct execution of a Turing
Machine, or to a COMPLETE simulaiton of that machine, If you can't show
that the simulation of that exact input (and H^ includes the algorith of
the H it is built on, so changing H the H you want to talk about doig
the simulation can't change the alrogithm of the H that THIS H^ was
built on) will continue for an UNBOUNDED nubmer of steps, it doesn't
show non-halting.
Also H and H^ are PROGRAMS, which means they include ALL the algorithm
they use, and thus H^ includes the full detailed algorithm of H as part
of it, which needs to be in its representation.
Programs are deterministic, and depend ONLY on their input, so H can't
look somewhere else ot see the code of H in H^, that code has to be part
of the input.
Until you can argue that your definitions are equivalent of these, you
are just admitting you aren't working in computation theory, and jut
makeing a big category error to say you are.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)