On 5/10/25 9:49 PM, olcott wrote:
On 5/10/2025 8:07 PM, Richard Damon wrote:
On 5/10/25 9:00 PM, olcott wrote:
On 5/10/2025 6:56 PM, Mr Flibble wrote:
On Sat, 10 May 2025 18:40:53 -0400, Richard Damon wrote:
On 5/10/25 4:38 PM, Mr Flibble wrote:
How my refutation differs to Peter's:
* Peter refutes the halting problem based on pathological input
manifesting in a simulating halt decider as infinite recursion, this >>>>>> being treated as non-halting.
* Flibble refutes the halting problem based on patholgical input
manifesting as decider/input self-referencial conflation,
resulting in
the contradiction at the heart of the halting problem being a
category
(type) error, i.e. ill-formed.
These two refutations are related but not exactly the same.
/Flibble
And the problem is that you use incorrect categories.
The decider needs to be of the category "Program".
The input also needs to be of the category "Program", but provided
via a
representation. The act of representation lets us convert items of
category Program to the category of Finite String which can be an
input.
Those two categories you have identified are different hence the
category
error.
That is correct. A running program and an input finite
string ARE NOT THE SAME.
But there is a direct relationship between the two.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
The key thing is that they don't always have the same
behavior.
Sure they do, at least when defined so it has behavior.
Your DDD above isn't a program and thus can't be run or correctly
emulated as the HHH isn't part of it. Even if there happens to be an HHH
at that address, it can't be legally used by the program without
becoming undefined behavior.
It only HAS behavior when it has been specifically and explicitly paired
with a specific defintion of HHH and incorporates its full code into the algorithm of DDD.
This makes each different pairing a unique input, as they are all different.
When they do have different behavior the termination
analyzer is only allowed to report on the recursive
simulation behavior that its input specifies.
No, it needs to report on the ACTUAL behavior its input specifies, which
is DEFINED to be the behavior of the direct execution of said program.
It is not allowed to ignore this on the basis that the
direct execution or UTM simulation has no recursive
simulation.
What it isn't allowed to ignore is the ACTUAL DEFINED behavior of the
ACTUAL INPUT it was given (which include what HHH it calls), the fact
that various other versions of the input built on different version
might do something else is irrelevent. Since the version of HHH that you
claim gets the right answer DOES abort its emulation and returns 0, the
only version of DDD that needs to be considered is the version paired
with that exact same input, and the correct mapping of that program, as
defined by the correct emulation of it, is to halt.
Note call instructions at the x86 level do not change their behavior
just because at some other level the same call has been made, so yes, it
MUST "ignore" the fact that the call might be recursive, as that fact
has no impact at the assembly langugage level.
You seem to not understand the basic meanings of the words you are using.
This *IS* looking at the results of UTM(DD)
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)