On 2/6/2015 3:39 PM, Kaz Kylheku wrote:
> On 2015-02-06, Peter Olcott <OCR4Screen> wrote:
>> I think that it is a subtle error to say that no TM can evaluate
>> halts(p,i) the actual
> That is more than a subtle error; that is an error of abusing the vocabulary of
> computer science that applies to programming language semantics. To evaluate
> means to reduce an expression to a value. Since halts(p, i) is a mathematical
> function, that is not applicable. What a procedure (or TM) does is to calculate
> the value of of a function for some argument values, such halts(p, i), or
> cos(0.3) or whatever.
>
>> truth is that no TM can consistently return a value that corresponds to
>> halts(p,i).
> "Consistently" is vague.
Not<ThereExists> phd in Partial_Halt_Deciders such that
phd(p,i) == halts(p,i) for all (p,i) in Programs x Inputs
// No specific phd decides halting correctly for every input.
It might be possible to iterate through phd in Partial_Halt_Deciders
such that phd(p,i) == halts(p,i) <ForEach> (p,i) in Programs x Inputs
// It may be possible to search for and find a phd that correctly decides
// any specific element of Programs x Inputs
// This would a a whole lot like finding a solution to the Halting Problem
*Halting Problem Solution* ???
Alternatively it may be possible to automatically dynamically construct a
halting decider for any possible specific static input string.
> If you simply mean "consistently with halts(p, i)"
> then it is redundant. Any discrepancy makes the calculation incorrect. If the
> calculation doesn't terminate for any <p, i>, with the correct value, then the
> calculation is said not to be "total". At best, the function can be correct
> for some defined subset of the p X i space; in which case it is "partial"
> rather than "total".
>
> If you mean "consistently from one invocation to another, given the same
> arguments", then that is a given; lack of such consistency means that the
> calculation isn't computing a mathematical function. It is depending
> on some hidden environmental inputs, or persistent state.
>
> There is no need for you or anyone else to invent any new terminology, in
> any case.
>
>> My whole point crucially depends upon this single quite subtle distinction.
>>
>> It seems to me that a TM could (as I have specified above) either report
>> a value
>> corresponding to halts(p,i) or report that it is not possible for it to
>> report a value
>> corresponding to halts(p,i) for every (p,i) in Programs x Inputs.
> Such a report is just an incorrect value, as far as the halts(p, i)
> function is concerned.
>
> It could be a correct value of some other function: one which has
> a three-valued range.
>
> But it is definitely not a correct halting decider.
I am only seeking to specify a halting decider decider, not a halting
decider.
>
> It also cannot be a total decider for the three-valued function
> that you would like. That is easy to show. No three-valued decider can
> correctly calculate the third error value either.
>
> Your only claim in support of the contrary view is that some magic
> exception exists in Rice's Theorem, which is the fallacy of special pleading.
Not at all. I propose that no valid counter example can possibly be found
that can prove that I am incorrect.
>
http://en.wikipedia.org/wiki/Special_pleading
>
> "Special pleading is a form of fallacious argument that involves an attempt to
> cite something as an exception to a generally accepted rule, principle, etc.
> without justifying the exception."
>
> E.g. "This is an exception to Rice's Theorem, because I *feel* that it must
> be so."