Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
On Wednesday, May 24, 2023 at 9:14:36 PM UTC+2, Richard Damon wrote:
Following pseudocode for D:
arbitrarily long int D(int start) {
arbitrarily long int n = start
while (n is not a perfect number) {
n = n + 2
}
return n
}
What would Olcott's "simulating halt decider" return (answer) if
called with, say, H(D, 1)?
Why would you care? PO's H returns "does not halt" for at least some
halting computations (citations available on request) so the result
tells you nothing of interest.
PO equivocates over whether he is concerned about just the one case used
in the usual proof's construction or the general case, but regardless of
what side of that fence he is currently sitting, you can't use his H for anything useful.
How would it know the correct answer? Will it ever return an answer?
(Especially, _if_ there is no odd perfect number?)
On some days he will claim that he has never said he has a general halt decider, just one that can't be fooled by the "usual construction". It "can't be fooled" because he simply declares that H(H^, H^) == false is
the correct answer "even though" H^(H^) halts.
On other days, he throws caution to the wind and claims the general
case, but again with the set of non-halting computations "augmented" by
some unspecified set of halting ones.
Of course, he is also not an honest disputant, because he will avoid
giving a direct answer to a simple question for years (literally years),
and he will even say contradictory things days apart (again, citations available on request) so it can take some time to clear all the smoke
from the mirrors. But once he has said
"Yes that is the correct answer even though P(P) halts."
in reply to the question "do you still assert that H(P,P) == false is
the 'correct' answer even though P(P) halts?" I don't see any point in carrying on, or at least I see not point in saying anything else.
The one weapon we have against cranks is that most can't bear to retract
any substantive claim. This is why they are usually so evasive about
giving direct answers -- they know they will have to stick with them.
But once they have made the mistake of being clear, we should pay them
the courtesy of quoting them at every available opportunity.
...D(D) would not halt unless H stops the simulation.
H /can/ correctly determine this silly criterion (in this one case)...
On 5/25/2023 6:16 AM, Ben Bacarisse wrote:
Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
On Wednesday, May 24, 2023 at 9:14:36 PM UTC+2, Richard Damon wrote:
Following pseudocode for D:
arbitrarily long int D(int start) {
arbitrarily long int n = start
while (n is not a perfect number) {
n = n + 2
}
return n
}
What would Olcott's "simulating halt decider" return (answer) if
called with, say, H(D, 1)?
Why would you care? PO's H returns "does not halt" for at least some
halting computations (citations available on request) so the result
tells you nothing of interest.
PO equivocates over whether he is concerned about just the one case used
in the usual proof's construction or the general case, but regardless of
what side of that fence he is currently sitting, you can't use his H for
anything useful.
How would it know the correct answer? Will it ever return an answer?
(Especially, _if_ there is no odd perfect number?)
On some days he will claim that he has never said he has a general halt
decider, just one that can't be fooled by the "usual construction". It
"can't be fooled" because he simply declares that H(H^, H^) == false is
the correct answer "even though" H^(H^) halts.
On other days, he throws caution to the wind and claims the general
case, but again with the set of non-halting computations "augmented" by
some unspecified set of halting ones.
Of course, he is also not an honest disputant, because he will avoid
giving a direct answer to a simple question for years (literally years),
and he will even say contradictory things days apart (again, citations
available on request) so it can take some time to clear all the smoke
from the mirrors. But once he has said
"Yes that is the correct answer even though P(P) halts."
in reply to the question "do you still assert that H(P,P) == false is
the 'correct' answer even though P(P) halts?" I don't see any point in
carrying on, or at least I see not point in saying anything else.
The one weapon we have against cranks is that most can't bear to retract
any substantive claim. This is why they are usually so evasive about
giving direct answers -- they know they will have to stick with them.
But once they have made the mistake of being clear, we should pay them
the courtesy of quoting them at every available opportunity.
Ben has already agreed that H does correctly determine that halt status
of its input according to the Sipser approved criteria. (see quote
below) The Sipser approved criteria is a tautology thus necessarily
true.
Because all deciders only compute the mapping *from their inputs* to
their own accept or reject state and the only objection to my proof is
that it does not get the same result as a non-input this only objection
is nullified. *My proof is correct by tautology*
My reviewers insist on staying one recursive invocation away from
reality. H does correctly determine that D correctly simulated by H
cannot possibly terminate normally.
My reviewers only focus on the behavior after H has already made this
correct halt status decision, thus are clearly out-of-sync by one
recursive invocation.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.
*It is clear that the above is a tautology thus necessarily true*
and H does determine the halt status of D precisely according to that criteria and *Ben has agreed to this*
On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
...D(D) would not halt unless H stops the simulation.
H /can/ correctly determine this silly criterion (in this one case)...
H(D,D) fully operational in x86utm operating system: https://github.com/plolcott/x86utm
On 5/25/2023 7:01 PM, Richard Damon wrote:
On 5/25/23 11:30 AM, olcott wrote:
On 5/25/2023 6:16 AM, Ben Bacarisse wrote:
Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
On Wednesday, May 24, 2023 at 9:14:36 PM UTC+2, Richard Damon wrote: >>>>>
Following pseudocode for D:
arbitrarily long int D(int start) {
arbitrarily long int n = start
while (n is not a perfect number) {
n = n + 2
}
return n
}
What would Olcott's "simulating halt decider" return (answer) if
called with, say, H(D, 1)?
Why would you care? PO's H returns "does not halt" for at least some >>>> halting computations (citations available on request) so the result
tells you nothing of interest.
PO equivocates over whether he is concerned about just the one case
used
in the usual proof's construction or the general case, but
regardless of
what side of that fence he is currently sitting, you can't use his H
for
anything useful.
How would it know the correct answer? Will it ever return an answer? >>>>> (Especially, _if_ there is no odd perfect number?)
On some days he will claim that he has never said he has a general halt >>>> decider, just one that can't be fooled by the "usual construction". It >>>> "can't be fooled" because he simply declares that H(H^, H^) == false is >>>> the correct answer "even though" H^(H^) halts.
On other days, he throws caution to the wind and claims the general
case, but again with the set of non-halting computations "augmented" by >>>> some unspecified set of halting ones.
Of course, he is also not an honest disputant, because he will avoid
giving a direct answer to a simple question for years (literally
years),
and he will even say contradictory things days apart (again, citations >>>> available on request) so it can take some time to clear all the smoke
from the mirrors. But once he has said
"Yes that is the correct answer even though P(P) halts."
in reply to the question "do you still assert that H(P,P) == false is
the 'correct' answer even though P(P) halts?" I don't see any point in >>>> carrying on, or at least I see not point in saying anything else.
The one weapon we have against cranks is that most can't bear to
retract
any substantive claim. This is why they are usually so evasive about >>>> giving direct answers -- they know they will have to stick with them.
But once they have made the mistake of being clear, we should pay them >>>> the courtesy of quoting them at every available opportunity.
Ben has already agreed that H does correctly determine that halt status
of its input according to the Sipser approved criteria. (see quote
below) The Sipser approved criteria is a tautology thus necessarily
true.
Nope, you MIS-QUOTE him by removing context, which is just a form of
LYING.
The context does not change the fact that he agreed that H does
correctly determine the halt status of D according to the Sisper
approved criteria.
Because all deciders only compute the mapping *from their inputs* to
their own accept or reject state and the only objection to my proof is
that it does not get the same result as a non-input this only objection
is nullified. *My proof is correct by tautology*
SO, what mapping is this supposed to compute, if this is what ALL
decider do, is "Halting" the only type of decider?
Remember, Halting is DEFINED as the MACHINE coming to a final state,
and it does.
My reviewers insist on staying one recursive invocation away from
reality. H does correctly determine that D correctly simulated by H
cannot possibly terminate normally.
Except YOU are one invocation from the probem. It isn't asking about
the simulatiion done by H, but by the machine that H is TRYING to
simulate (but can't).
My reviewers only focus on the behavior after H has already made this
correct halt status decision, thus are clearly out-of-sync by one
recursive invocation.
Because it makes the WRONG decision by the definition of the problem,
what does the machine represented by the input do?
The definition of the problem that you are referring to contradicts the definition of a decider that must compute the mapping from
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
to an its own accept or reject state.
You think that H is wrong because the outer invocation halts only
because the inner invocation was correctly aborted.
You know that it is necessarily true that no invocation would ever halt unless the inner invocation was aborted, thus making the termination of
this inner invocation necessarily correct.
On 5/25/23 11:30 AM, olcott wrote:
On 5/25/2023 6:16 AM, Ben Bacarisse wrote:
Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
On Wednesday, May 24, 2023 at 9:14:36 PM UTC+2, Richard Damon wrote: >>>>
Following pseudocode for D:
arbitrarily long int D(int start) {
arbitrarily long int n = start
while (n is not a perfect number) {
n = n + 2
}
return n
}
What would Olcott's "simulating halt decider" return (answer) if
called with, say, H(D, 1)?
Why would you care? PO's H returns "does not halt" for at least some
halting computations (citations available on request) so the result
tells you nothing of interest.
PO equivocates over whether he is concerned about just the one case used >>> in the usual proof's construction or the general case, but regardless of >>> what side of that fence he is currently sitting, you can't use his H for >>> anything useful.
How would it know the correct answer? Will it ever return an answer?
(Especially, _if_ there is no odd perfect number?)
On some days he will claim that he has never said he has a general halt
decider, just one that can't be fooled by the "usual construction". It >>> "can't be fooled" because he simply declares that H(H^, H^) == false is
the correct answer "even though" H^(H^) halts.
On other days, he throws caution to the wind and claims the general
case, but again with the set of non-halting computations "augmented" by
some unspecified set of halting ones.
Of course, he is also not an honest disputant, because he will avoid
giving a direct answer to a simple question for years (literally years), >>> and he will even say contradictory things days apart (again, citations
available on request) so it can take some time to clear all the smoke
from the mirrors. But once he has said
"Yes that is the correct answer even though P(P) halts."
in reply to the question "do you still assert that H(P,P) == false is
the 'correct' answer even though P(P) halts?" I don't see any point in
carrying on, or at least I see not point in saying anything else.
The one weapon we have against cranks is that most can't bear to retract >>> any substantive claim. This is why they are usually so evasive about
giving direct answers -- they know they will have to stick with them.
But once they have made the mistake of being clear, we should pay them
the courtesy of quoting them at every available opportunity.
Ben has already agreed that H does correctly determine that halt status
of its input according to the Sipser approved criteria. (see quote
below) The Sipser approved criteria is a tautology thus necessarily
true.
Nope, you MIS-QUOTE him by removing context, which is just a form of LYING.
Because all deciders only compute the mapping *from their inputs* to
their own accept or reject state and the only objection to my proof is
that it does not get the same result as a non-input this only objection
is nullified. *My proof is correct by tautology*
SO, what mapping is this supposed to compute, if this is what ALL
decider do, is "Halting" the only type of decider?
Remember, Halting is DEFINED as the MACHINE coming to a final state, and
it does.
My reviewers insist on staying one recursive invocation away from
reality. H does correctly determine that D correctly simulated by H
cannot possibly terminate normally.
Except YOU are one invocation from the probem. It isn't asking about the simulatiion done by H, but by the machine that H is TRYING to simulate
(but can't).
My reviewers only focus on the behavior after H has already made this
correct halt status decision, thus are clearly out-of-sync by one
recursive invocation.
Because it makes the WRONG decision by the definition of the problem,
what does the machine represented by the input do?
YOU are the one just focusing on your POOP, and getting the wrong answer
for the actual question, which is the HALTING of the actual machine.
You don't seem to understand the the TURING MACHINE described by D is
the actual MACHINE, not H's attempt at simulating it.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
Right, and i n particular, what you don't seem to grasp is for H to meet
the requirements, it need to correctly determine that an UTM simulation
of the input would never stop, that is a simulation that doesn't stop
until it reaches a final state.
Since a UTM simulation of this input DOES reach a final state, as it simulates H past the point that H gives up and returns 0 to D, you never satisfy the conditions given.
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.
*It is clear that the above is a tautology thus necessarily true*
and H does determine the halt status of D precisely according to that
criteria and *Ben has agreed to this*
On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
...D(D) would not halt unless H stops the simulation.
H /can/ correctly determine this silly criterion (in this one case)...
He said:
Are you dancing round the fact that PO tricked the professor?
H(D,D) /does/ meet the criterion for PO's Other Halting problem -- the
one no one cares about. D(D) halts (so H is not halt decider), but D(D) would not halt unless H stops the simulation. H /can/ correctly
determine this silly criterion (in this one case) so H is a POOH decider (again, for this one case -- PO is not interested in the fact the POOH
is also undecidable in general).
Note, your OTHER problem, the one with the incorrect definition of what
it decides.
I guess by quoting him as support, you are admitting you are talking
about the problem Ben was refering to, you POOP, based on your "silly" criterion.
Thank you for making that clear.
You are just proving that you are the ignorant pathological lying idiot
that you have made yourself out to be.
H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm
On 5/25/2023 8:29 PM, olcott wrote:
On 5/25/2023 7:01 PM, Richard Damon wrote:
On 5/25/23 11:30 AM, olcott wrote:
On 5/25/2023 6:16 AM, Ben Bacarisse wrote:
Fritz Feldhase <franz.fritschee.ff@gmail.com> writes:
On Wednesday, May 24, 2023 at 9:14:36 PM UTC+2, Richard Damon wrote: >>>>>>
Following pseudocode for D:
arbitrarily long int D(int start) {
arbitrarily long int n = start
while (n is not a perfect number) {
n = n + 2
}
return n
}
What would Olcott's "simulating halt decider" return (answer) if
called with, say, H(D, 1)?
Why would you care? PO's H returns "does not halt" for at least some >>>>> halting computations (citations available on request) so the result
tells you nothing of interest.
PO equivocates over whether he is concerned about just the one case
used
in the usual proof's construction or the general case, but
regardless of
what side of that fence he is currently sitting, you can't use his
H for
anything useful.
How would it know the correct answer? Will it ever return an answer? >>>>>> (Especially, _if_ there is no odd perfect number?)
On some days he will claim that he has never said he has a general
halt
decider, just one that can't be fooled by the "usual
construction". It
"can't be fooled" because he simply declares that H(H^, H^) ==
false is
the correct answer "even though" H^(H^) halts.
On other days, he throws caution to the wind and claims the general
case, but again with the set of non-halting computations
"augmented" by
some unspecified set of halting ones.
Of course, he is also not an honest disputant, because he will avoid >>>>> giving a direct answer to a simple question for years (literally
years),
and he will even say contradictory things days apart (again, citations >>>>> available on request) so it can take some time to clear all the smoke >>>>> from the mirrors. But once he has said
"Yes that is the correct answer even though P(P) halts."
in reply to the question "do you still assert that H(P,P) == false is >>>>> the 'correct' answer even though P(P) halts?" I don't see any point in >>>>> carrying on, or at least I see not point in saying anything else.
The one weapon we have against cranks is that most can't bear to
retract
any substantive claim. This is why they are usually so evasive about >>>>> giving direct answers -- they know they will have to stick with them. >>>>> But once they have made the mistake of being clear, we should pay them >>>>> the courtesy of quoting them at every available opportunity.
Ben has already agreed that H does correctly determine that halt status >>>> of its input according to the Sipser approved criteria. (see quote
below) The Sipser approved criteria is a tautology thus necessarily
true.
Nope, you MIS-QUOTE him by removing context, which is just a form of
LYING.
The context does not change the fact that he agreed that H does
correctly determine the halt status of D according to the Sisper
approved criteria.
Because all deciders only compute the mapping *from their inputs* to
their own accept or reject state and the only objection to my proof is >>>> that it does not get the same result as a non-input this only objection >>>> is nullified. *My proof is correct by tautology*
SO, what mapping is this supposed to compute, if this is what ALL
decider do, is "Halting" the only type of decider?
Remember, Halting is DEFINED as the MACHINE coming to a final state,
and it does.
My reviewers insist on staying one recursive invocation away from
reality. H does correctly determine that D correctly simulated by H
cannot possibly terminate normally.
Except YOU are one invocation from the probem. It isn't asking about
the simulatiion done by H, but by the machine that H is TRYING to
simulate (but can't).
My reviewers only focus on the behavior after H has already made this
correct halt status decision, thus are clearly out-of-sync by one
recursive invocation.
Because it makes the WRONG decision by the definition of the problem,
what does the machine represented by the input do?
The definition of the problem that you are referring to contradicts
the definition of a decider that must compute the mapping from
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
AN INPUT
to an its own accept or reject state.
You think that H is wrong because the outer invocation halts only
because the inner invocation was correctly aborted.
You know that it is necessarily true that no invocation would ever halt
unless the inner invocation was aborted, thus making the termination of
this inner invocation necessarily correct.
I have better words. The termination of the simulation of D is mandated
by the requirements that a halt decider must always halt, thus
conclusively proving that this termination is necessarily correct.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 109:02:56 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,710 |