From: The Ghost In The Machine on
In sci.logic, Peter Olcott
<NoSpam(a)SeeScreen.com>
wrote
on Mon, 16 Oct 2006 01:40:42 -0500
<OPFYg.7971$eZ4.5217(a)dukeread06>:
>
> "The Ghost In The Machine" <ewill(a)sirius.tg00suus7038.net> wrote in message
> news:5geb04-pa.ln1(a)sirius.tg00suus7038.net...
>> In sci.logic, Peter Olcott
>> <NoSpam(a)SeeScreen.com>
>> wrote
>> on Sun, 15 Oct 2006 22:40:02 -0500
>> <laDYg.7965$eZ4.1292(a)dukeread06>:
>>>
>>> "The Ghost In The Machine" <ewill(a)sirius.tg00suus7038.net> wrote in message
>>> news:e7aa04-32t.ln1(a)sirius.tg00suus7038.net...
>>>> In sci.logic, Peter Olcott
>>>> <NoSpam(a)SeeScreen.com>
>>>> wrote
>>>> on Sun, 15 Oct 2006 12:38:39 -0500
>>>> <AmuYg.7908$eZ4.5473(a)dukeread06>:
>>>>>
>>>>> "The Ghost In The Machine" <ewill(a)sirius.tg00suus7038.net> wrote in message
>>>>> news:vp2a04-lfs.ln1(a)sirius.tg00suus7038.net...
>>>>>> In sci.logic, Peter Olcott
>>>>>> <NoSpam(a)SeeScreen.com>
>>>>>> wrote
>>>>>> on Sun, 15 Oct 2006 09:19:52 -0500
>>>>>> <csrYg.7886$eZ4.2645(a)dukeread06>:
>>>>>>> The Halt program throws an "Invalid Input" exception.
>>>>>>> This would be analogous to the hardware exception of an attempt to divide
>>>>>>> by
>>>>>>> zero.
>>>>>>>
>>>>>>
>>>>>> Useful, but slightly irrelevant.
>>>>>>
>>>>>> For purposes of this exercise I assume arrays of arbitrary
>>>>>> objects, similar to Java, with a twist: Java does not
>>>>>> have method/function pointers or closures. However,
>>>>>> one can always use introspection in Java, in a pinch,
>>>>>> or use a language such as LISP (which I'd have to look up
>>>>>> the syntax for).
>>>>>>
>>>>>> The construct
>>>>>>
>>>>>> void weirdfun(arg) {
>>>>>> while(HTest(arg[0], arg) == HALT)
>>>>>> ;
>>>>>> }
>>>>>>
>>>>>> appears to be a well-formed function, ready to be introduced
>>>>>> as the func parameter in HTest(func, parameters). The second
>>>>>> parameter to HTest is simply [weirdfun].
>>>>>>
>>>>>> At some point HTest has to determine whether weirdfun([weirdfun])
>>>>>> halts. If weirdfun([weirdfun]) does halt, then HTest(weirdfun,[weirdfun])
>>>>>> returns HALT, and weirdfun([weirdfun]) provably loops in that case,
>>>>>> calling HTest() uselessly again and again.
>>>>>>
>>>>>> If weirdfun([weirdfun]) loops, then HTest(weirdfun,[weirdfun]) will return
>>>>>> something other than HALT, and weirdfun([wierdfun]) provably halts.
>>>>>>
>>>>>> In either case HTest() is computing the answer incorrectly; therefore
>>>>>> HTest() cannot compute whether all functions halt (since we found
>>>>>> one that it doesn't work on).
>>>>>
>>>>> HTest() correctly invokes the "Invalid Input" exception and neither returns
>>>>> HALT
>>>>> nor returns Not(HALT)
>>>>
>>>> OK. So now it fails the test of being an algorithm and always returning
>>>> a correct result -- since it doesn't return any result at all.
>>>>
>>> In the exact same way and for the same kind of reason that the following
>>> assignment statement would fail the criterion measure that you just
>>> specified:
>>>
>>> double X = 50.0 / 0.0;
>>
>> At least there I can specify when the operation is invalid. If the
>> divisor is zero or the quotient overflows then it traps. I'll
>> refer you to the relevant literature for the microprocessor in
>> question if you want to pursue this further.
>>
>>>
>>>> Can't win that way! Besides, Turing Machines don't have exceptions as
>>>> such. Nor have you specified precisely on how it will determine when to
>>>> invoke that exception.
>>>
>>> It will invoke the exception in each and every case where the input is
>>> determined to be invalid.
>>
>> And how is my input invalid? Please indicate the algorithm used to
>> determine why my parameters to HTest
>>
>> HTest(weirdfun, [weirdfun])
>>
>> are invalid.
>>
>>> Since a Turing machine is theoretically capable of
>>> executing any computable algorithm (did I say this correctly?) therefore a
>>> Turing machine would be capable of duplicating the sequence equivalent to
>>> throwing an exception. We could for example adopt the simple protocol of
>>> returning zero for Not(HALT) one for HALTS, and two for INVALID_INPUT.
>>
>> Nice try, but weirdfun() merely tests for HALT in the loop.
>> If the algorithm returns any other value (including
>> I_HAVE_NO_CLUE) the function will halt. If HTest throws
>> an exception weirdfun() does not catch it, but a trivial
>> modification:
>>
>> void weirdfun2(arg) {
>> try
>> {
>> while(HTest(arg[0], arg) == HALT)
>> ;
>> }
>> catch(Throwable t)
>> {
>> }
>> }
>>
>> takes care of that. ("Throwable" is the root of all exceptions in Java.
>> All this does is guarantee that weirdfun2 will not throw an exception,
>> but will simply halt.)
>>
>> And now, of course, what does HTest(weirdfun2, [weirdfun2]) return?
>>
>> Admittedly, the contradiction is indeed lifted, since HTest() can throw
>> an exception in this case -- which is the wrong answer, of course, but
>> at least it gets out of contradiction territory.
>
> It is not the wrong answer, it is the only possible correct answer.

It is the equivalent of a fourth-and-punt. Every
implementation either halts, or it doesn't (though it may
take a very long while in some cases!). We may not know
whether it halts; one celebrated problem for instance is
to determine whether

unsigned CollatzCount(unsigned ix)
{
if(ix < 2) return 0;
else if(ix mod 2 == 0)
return 1 + CollatzCount(ix/2);
else
return 1 + CollatzCount(3*ix+1);
}

halts on all inputs, assuming indefinitely big unsigned integers.
(AFAIK, the answer is currently unknown.)

And then there's weirdfun(), of course.

Other possibilities include

boolean findTwoPrimes(unsigned sum, unsigned & p, unsigned & q)
{
for(p = 2; 2*p <= sum; p = nextPrime(p))
{
q = sum - p;
if(isPrime(q)) return true;
}

return false;
}

unsigned firstGoldbach()
{
unsigned e = 4;

while(findTwoPrimes(e,p,q))
e += 2;

return e;
}

which basically looks for the first even number that can't be
represented as the sum of two primes -- the refutation
of the Goldbach conjecture, if it exists.

The halting algorithm would have to give an answer on these as
well as weirdfun() -- or punt.

Some of these we *do* know the answer to:

unsigned largestPrime()
{
unsigned p = 3;

while(notLargestPrime(p))
p = nextPrime(p);

re
From: The Ghost In The Machine on
In sci.logic, MoeBlee
<jazzmobe(a)hotmail.com>
wrote
on 17 Oct 2006 17:41:25 -0700
<1161132085.275067.259900(a)e3g2000cwe.googlegroups.com>:
> Peter Olcott wrote:
>> "MoeBlee" <jazzmobe(a)hotmail.com> wrote in message
>> news:1161129027.125873.82790(a)f16g2000cwb.googlegroups.com...
>> > Peter Olcott wrote:
>> >> Malignant self-reference is the term that one of the respondents on this
>> >> group
>> >> provided for the self-reference in the halting problem. It is malignant in
>> >> the
>> >> sense that it is self-modifying program, that modifies itself in such a way
>> >> as
>> >> to prevent itself from functioning correctly.
>> >
>> > Which, has nothing to do with the halting problem.
>> >
>> > MoeBlee
>> >
>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>> Are you saying that the root cause of the "Problem" aspect of the "Halting
>> Problem" has nothing to do with self-reference?
>
> Define 'self-referential', 'malignantly self-referential',
> 'self-modifying', and 'functioning correctly' as mathematical
> predicates in the theory (or a theory) of which the unsolvability of
> the halting probelm is a theorem.

In the context of the halting problem the self-reference
is in fact a self-meta-reference. Given an alleged
implementation of the Halting Predicate HTest(func, args),
one constructs a new function

void WeirdFun(func)
{
while(HTest(func, [func]) == HALT)
;
}

If one prefers, one can use a templated form, which might look like:

template <function HTest>

void WeirdFun(func)
{
while(<HTest>(func, [func]) == HALT)
;
}

which means that for *any* alleged implementation of
the halting tester, one can construct a function upon
which it will yield an incorrect answer, namely, the call
HTest(WeirdFun<HTest>, [WeirdFun<HTest>]).

Now Peter has "solved" the Halting Problem by allowing
this answer, or by punting. Neither is much of a solution.

As for self-modifying -- no evidence of that here.
All I've done is defined one function using another as a
starting point.

>
> And please tell me what standard textbook(s) you use as your basic
> reference for this subject so that I may consult those textbooks in
> order to appreciate your understanding of the theorem and the subject.
>
> MoeBlee
>

--
#191, ewill3(a)earthlink.net
Useless C++ Programming Idea #992398129:
unsigned u; if(u < 0) ...

--
Posted via a free Usenet account from http://www.teranews.com

From: Alan Smaill on
"Peter Olcott" <NoSpam(a)SeeScreen.com> writes:

> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
> Are you saying that the root cause of the "Problem" aspect of the "Halting
> Problem" has nothing to do with self-reference?


The "problem" nomenclature is just the same as is used in
the Travelling Salesman Problem.

en.wikipedia.org/wiki/Traveling_salesman_problem

The halting problem, just as with the TSP, is well-posed and unambiguous.

--
Alan Smaill
From: Peter Olcott on

"Ben Bacarisse" <ben.usenet(a)bsb.me.uk> wrote in message
news:87lkneqm4p.fsf(a)bsb.me.uk...
> "Peter Olcott" <NoSpam(a)SeeScreen.com> writes:
>
>> "Ben Bacarisse" <ben.usenet(a)bsb.me.uk> wrote in message
>> news:87slhmqpxw.fsf(a)bsb.me.uk...
>>> "Peter Olcott" <NoSpam(a)SeeScreen.com> writes:
>>>
>>>> "Ben Bacarisse" <ben.usenet(a)bsb.me.uk> wrote in message
>>>> news:874pu2tqla.fsf(a)bsb.me.uk...
>>>>> "Peter Olcott" <NoSpam(a)SeeScreen.com> writes:
>>>>>
>>>>>> "Ben Bacarisse" <ben.usenet(a)bsb.me.uk> wrote in message
>>>>>> news:878xjetrqw.fsf(a)bsb.me.uk...
>>>>>>> "Peter Olcott" <NoSpam(a)SeeScreen.com> writes:
>>>>>>>
>>>>>>>> "MoeBlee" <jazzmobe(a)hotmail.com> wrote in message
>>>>>>>> news:1161118961.027553.142520(a)f16g2000cwb.googlegroups.com...
>>>>>>>>> Peter Olcott wrote:
>>>>>>>>>> I will frame this in the terms of the Halting Problem because I
>>>>>>>>>> understand
>>>>>>>>>> computer science much more deeply than math.
>>>>>>>>>
>>>>>>>>> Say what you want about computer science, but the statement of the
>>>>>>>>> unsolvability of the halting problem and the proof of the theorem are
>>>>>>>>> perfectly formed mathematics; the statement of the theorem and the
>>>>>>>>> proof are not "ill-formed" and is not analogous to division by zero,
>>>>>>>>> which has to do with conditional definition and descriptions that do
>>>>>>>>> not properly refer..
>>>>>>>>>
>>>>>>>>> MoeBlee
>>>>>>>>>
>>>>>>>>
>>>>>>>> The conclusion that a universal halt detector can not be constructed
>>>>>>>> is incorrect. The proofs do not show that a universal halt-detector
>>>>>>>> can not be constructed. The proofs only show that a universal
>>>>>>>> halt-detector can not provide the results of its analysis in the
>>>>>>>> case of malignant self-reference where the caller uses the results
>>>>>>>> to change the outcome of the analysis.
>>>>>>>
>>>>>>> I am curious. Do think that repeatedly re-stating your
>>>>>>> misunderstanding of the halting problem will persuade anyone? You
>>>>>>> have said the same thing in various ways to everyone who has posted,
>>>>>>> and they remain unmoved. Is it not time to start thinking that you
>>>>>>> may be mistaken? If not, let me ask a deeper question. What *would*
>>>>>>> start you thinking that you may be mistaken?
>>>>>>
>>>>>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>>>>>> Are you saying that I am wrong when I am saying that self-reference is
>>>>>> the root cause of the "problem" aspect of the "Halting Problem" ??
>>>>>
>>>>> No, I did not say anything about that. I thought my questions were
>>>>> quite clear.
>>>>>
>>>>> Now I am curious as to why you have answered so few of the direct
>>>>> questions you have been asked.
>>>>>
>>>> I would have to first know the specific details that you would
>>>> consider that I might be wrong about before I could begin to
>>>> consider than I might be wrong. In other words it must be an item by
>>>> item point for point complete dialogue. Blanket statements are
>>>> useless.
>>>
>>> I'm not going to answer that because I will assume that you would
>>> answer the same as I do below. Obviously, let me know if I am wrong
>>> about this.
>>>
>>>> What would it take for you to think that you might be
>>>> wrong?
>>>
>>> An alternate (presumably contradictry) theorem stated and proved. If
>>> you have not got that far yet, and are simply unhappy about some other
>>> proof, then tell us the theorem you have trouble with and say which
>>> axiom or deductive step in its proof is at fault. That is how the
>>> subject progresses. Anything less belongs in alt.waffle.computers.
>>
>> I am not using that model, I am using a model comparable to the above link.
>
> Ah, OK. I can now see why your are mistaken, but you have still not
> answered either of my questions. Would seeing a proper proof of the
> halting theorem change your mind?
>
> --
> Ben.

Explain this proof within the context of the model that I provided.


From: Peter Olcott on

"Patricia Shanahan" <pats(a)acm.org> wrote in message
news:AjiZg.10941$Y24.524(a)newsread4.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats(a)acm.org> wrote in message
>> news:zGdZg.15330$UG4.11773(a)newsread2.news.pas.earthlink.net...
>>> MoeBlee wrote:
>>>> Peter Olcott wrote:
>>>>> The conclusion that a universal halt detector can not be constructed is
>>>>> incorrect. The proofs do not show that a universal halt-detector can not
>>>>> be
>>>>> constructed. The proofs only show that a universal halt-detector can not
>>>>> provide
>>>>> the results of its analysis in the case of malignant self-reference where
>>>>> the
>>>>> caller uses the results to change the outcome of the analysis.
>>>> The proof is of a mathematical theorem. Whatever that has to do with a
>>>> "universal halt detector", I'll leave you to you. Meanwhile, "malignant
>>>> self-reference" has nothing to do with the mathematical theorem and
>>>> proof.
>>> "Malignant self-reference" is also, as far as I know, undefined in
>>> computer science.
>>>
>>> Patricia
>>
>> Malignant self-reference is the term that one of the respondents on this
>> group provided for the self-reference in the halting problem. It is malignant
>> in the sense that it is self-modifying program, that modifies itself in such
>> a way as to prevent itself from functioning correctly.
>
> Could you look at http://www.mtnmath.com/whatrh/node49.html and point to
> the program that modifies itself?
>
> Note that the proof of undecidability of halting can be done using
> Turing machines, which have separate, non-modifiable, storage for the
> program.
>
> Patricia

http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
Could you look at the above example, and point out how SELF-HALT is not self
modifying? This is the model that I am using in my investigation. I have been a
software developer for the last 22 years, but have never focused on the
mathematical abstractions. All of my work has been practical application.