XPost: comp.theory, sci.logic, sci.math
On 12/31/2021 10:54 PM, Richard Damon wrote:
On 12/31/21 11:48 PM, olcott wrote:
On 12/31/2021 10:29 PM, Richard Damon wrote:
On 12/31/21 11:19 PM, olcott wrote:
On 12/31/2021 10:02 PM, Richard Damon wrote:
On 12/31/21 10:57 PM, olcott wrote:
On 12/31/2021 9:50 PM, Richard Damon wrote:
On 12/31/21 10:39 PM, olcott wrote:
On 12/31/2021 9:10 PM, Richard Damon wrote:
On 12/31/21 9:50 PM, olcott wrote:
On 12/31/2021 8:39 PM, Richard Damon wrote:
On 12/31/21 8:50 PM, olcott wrote:
On 12/31/2021 7:37 PM, André G. Isaak wrote:
On 2021-12-31 18:17, olcott wrote:
On 12/31/2021 7:11 PM, André G. Isaak wrote:
On 2021-12-31 17:05, olcott wrote:
On 12/31/2021 5:33 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>> On 2021-12-31 16:02, olcott wrote:
On 12/31/2021 4:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>
An actual computer scientist will understand that >>>>>>>>>>>>>>>>>> embedded_H does compute the mapping from these inputs >>>>>>>>>>>>>>>>>> finite strings ⟨Ĥ⟩ ⟨Ĥ⟩ to this final state Ĥ.qn on the
basis that the actual input would never halt. >>>>>>>>>>>>>>>>>
You're not really in a position to state what an actual >>>>>>>>>>>>>>>>> computer scientist would understand. Only an actual >>>>>>>>>>>>>>>>> computer scientist can do that.
It is a self-evident truth that:
(a) The pure simulation of the Turing machine
description of a machine is computationally equivalent >>>>>>>>>>>>>>>> to the direct execution of this machine.
(b) The pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H would
never halt.
(c) If the pure simulation of the input to a halt >>>>>>>>>>>>>>>> decider would never halt then the halt decider correctly >>>>>>>>>>>>>>>> decides that this input does not halt.
A computer scientist would understand these things. >>>>>>>>>>>>>>>
It would appear that you ignored (and cut) all the actual >>>>>>>>>>>>>>> points in my post.
Why don't we simplify things a bit. When Ĥ ⟨Ĥ⟩ is called, >>>>>>>>>>>>>>> how does Ĥ determine that its input describes itself? You >>>>>>>>>>>>>>> claim this is done by string comparisons, but which >>>>>>>>>>>>>>> strings are being compared? The only string Ĥ has access >>>>>>>>>>>>>>> to its input string. What does it compare this string with? >>>>>>>>>>>>>>>
André
So far I have not gotten to any point of closure on >>>>>>>>>>>>>> anything that I have said. I must insist on points of >>>>>>>>>>>>>> closure for continued dialogue.
Do you agree that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by >>>>>>>>>>>>>> embedded_H would never halt?
Of course I don't, since that claim is simply false. >>>>>>>>>>>>>
Now why don't you actually answer the question I asked? >>>>>>>>>>>>>
André
We must stay on this point until we have mutual agreement. >>>>>>>>>>>> Why do you say it is false?
BIG QUESTION.
Is it even a proper question?
Is it a fact that embedded_H just does a pure simulation? >>>>>>>>>>>
Or. is there an abort condition?
Remember, any time you change any of the properties of the H >>>>>>>>>>> that you built H^ from, any analysis from previous H^s need >>>>>>>>>>> to be thrown out, or at least reconfirmed with the new H. >>>>>>>>>>
It is the case that when embedded_H simulates 0 to ∞ steps of >>>>>>>>>> its input that its input never halts.
Yes, but then it doesn't answer and fails.
It is the case that when embedded_H simulates 0 to ∞ steps of >>>>>>>> its input that its input never halts
CONCLUSIVELY PROVING THAT THIS INPUT NEVER HALTS EVEN IF IT IS >>>>>>>> ABORTED
Yes, But H can't do that aborting, because you just said that
embedded_H didn't abort it.
Do you think that it is possible to tell that an infinite loop
will never stop running without actually having to wait forever?
void Infinite_Loop(int N)
{
HERE: goto HERE;
}
_Infinite_Loop()
[00000cb5](01) 55 push ebp
[00000cb6](02) 8bec mov ebp,esp
[00000cb8](02) ebfe jmp 00000cb8
[00000cba](01) 5d pop ebp
[00000cbb](01) c3 ret
Size in bytes:(0007) [00000cbb]
In some cases, yes.
You seem to like your Herring Red.
The question is not is it possible to answer some other halting
questions, but if H can answer a particular one.
If it is the case that embedded_H does correctly determine its input
would never halt if it simulates 0 to ∞ steps of this input
and it makes this determination in a finite number of steps
and it aborts the simulation of this input
Which it can't as proven at:
Mesage ID <FOnzJ.162569$[email protected]>
Date: 2021-12-30 19:31:49 GMT
Subject: Re: Concise refutation of halting problem proofs V42
[compute the mapping]
FAIL.
That is irrelevant at this point in the dialogue.
WHY?
The fact that you just claim, with NO proof to have the Unicorn Halt
Decider to do your bidding.
You logic is UNSOUND, as are you.
this does not cause the input to halt because an input must reach
its final state to halt
i.e that ACTUAL Machine must not reach a halting state, not an
aborted simulation, but H& does reach that state.
Your words are incoherent.
When we hypothesize that embedded_H can determine that input to
embedded_H never reaches its final state in 0 to ∞ steps of simulation
and it can do this in a finite number of steps
You Hypothesize the impossible.
This is the only point that I am willing to discuss with anyone until
mutual agreement is achieved.
If embedded_H does correctly determine that its input cannot possibly
reach the final state of this input then it is correct for embedded_H to
aborts its simulation of this input and transition to Ĥ.qn.
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)