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:It is the case that when embedded_H simulates 0 to ∞ steps of >>>>>>>>>> its input that its input never halts.
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:It would appear that you ignored (and cut) all the actual >>>>>>>>>>>>>>> points in my post.
On 12/31/2021 4:06 PM, André G. Isaak wrote: >>>>>>>>>>>>>>>>You're not really in a position to state what an actual >>>>>>>>>>>>>>>>> computer scientist would understand. Only an actual >>>>>>>>>>>>>>>>> computer scientist can do that.
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. >>>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>
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. >>>>>>>>>>
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$np6.119786@fx46.iad>
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 63:59:03 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,785 |