f

#### A Possible "solution" to the Halting Problem

The Halt program throws an "Invalid Input" exception.
This would be analogous to the hardware exception of an attempt to divide by
zero.

 0
NoSpam266 (508)
10/15/2006 2:19:52 PM
comp.theory 5139 articles. 1 followers. marty.musatov (1143) is leader.

360 Replies
1277 Views

Similar Articles

[PageSpeed] 29

On Sun, 15 Oct 2006, Peter Olcott wrote:

> The Halt program throws an "Invalid Input" exception.
> This would be analogous to the hardware exception of an attempt to divide by
> zero.
>
Error 001:  Invalid input.  Please try again.

--
Won't we just love voice responding software?
Just imagine a sexy female voice saying,
"I'm sorry, invalid input.  Please try again."

Other favorites are
"Hang on while I try that extension."
"Or press one for more options."

But damn, the last victimized buyer of that voice answering system I
noticed didn't get a sexy female voice saying
"Or press one for more options."
Just an ordinary female voice.

Riddle of the day.  Have you given your life over to automation?
 0
marsh12 (26)
10/15/2006 2:32:33 PM
"William Elliot" <marsh@hevanet.remove.com> wrote in message
news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com...
> On Sun, 15 Oct 2006, Peter Olcott wrote:
>
>> The Halt program throws an "Invalid Input" exception.
>> This would be analogous to the hardware exception of an attempt to divide by
>> zero.
>>
> Error 001:  Invalid input.  Please try again.

The point is there are not any questions too difficult for logic to correctly
answer, logic itself is not incomplete as Kurt Godel proposed. There are merely
some questions where the question itself  is ill-formed.

>
> --
> Won't we just love voice responding software?
> Just imagine a sexy female voice saying,
> "I'm sorry, invalid input.  Please try again."
>
> Other favorites are
> "Hang on while I try that extension."
> "Or press one for more options."
>
> But damn, the last victimized buyer of that voice answering system I
> noticed didn't get a sexy female voice saying
> "Or press one for more options."
> Just an ordinary female voice.
>
> Riddle of the day.  Have you given your life over to automation?

 0
NoSpam266 (508)
10/15/2006 2:56:38 PM
On Sun, 15 Oct 2006, Peter Olcott wrote:
> "William Elliot" <marsh@hevanet.remove.com> wrote in message
> > On Sun, 15 Oct 2006, Peter Olcott wrote:
>
> The point is there are not any questions too difficult for logic to
> correctly answer, logic itself is not incomplete as Kurt Godel proposed.
>
> There are merely some questions where the question itself is ill-formed.

Go step off a paradigm shift.
 0
marsh12 (26)
10/15/2006 3:21:45 PM
In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
> "William Elliot" <marsh@hevanet.remove.com> wrote in message
> news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com...
> > On Sun, 15 Oct 2006, Peter Olcott wrote:
> >
> >> The Halt program throws an "Invalid Input" exception.
> >> This would be analogous to the hardware exception of an attempt to divide by
> >> zero.
> >>
> > Error 001:  Invalid input.  Please try again.
>
> The point is there are not any questions too difficult for logic to correctly
> answer, logic itself is not incomplete as Kurt Godel proposed. There are merely
> some questions where the question itself  is ill-formed.

Brilliant.  By defining any unsolvable problems as "ill-formed" then
we can say that all "well-formed" questions are solvable.  No more
unsolvable problems!

Advancement of science by changing definitions.  Gotta love it.

--

Steve Stringer
sillybanter@gmail.com

 0
10/15/2006 3:29:48 PM
Halting Problem:  There are two kinds of people, those who finish what
they start and those who ...
--
Regards,
Casey
 0
10/15/2006 3:36:58 PM
<sillybanter@gmail.com> wrote in message news:MtsYg.9714$gx6.5379@trnddc05... > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> "William Elliot" <marsh@hevanet.remove.com> wrote in message >> news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com... >> > On Sun, 15 Oct 2006, Peter Olcott wrote: >> > >> >> The Halt program throws an "Invalid Input" exception. >> >> This would be analogous to the hardware exception of an attempt to divide >> >> by >> >> zero. >> >> >> > Error 001: Invalid input. Please try again. >> >> The point is there are not any questions too difficult for logic to correctly >> answer, logic itself is not incomplete as Kurt Godel proposed. There are >> merely >> some questions where the question itself is ill-formed. > > Brilliant. By defining any unsolvable problems as "ill-formed" then > we can say that all "well-formed" questions are solvable. No more > unsolvable problems! > Since the only reason that these problems are unsolvable is because they are ill-formed, this makes perfect sense. To see it any other way would be like me saying that you don't even know how to tell the time of day because of your inability to correctly answer the following question; What time is it blue or green? > Advancement of science by changing definitions. Gotta love it. > > -- > > Steve Stringer > sillybanter@gmail.com >  0 NoSpam266 (508) 10/15/2006 3:39:48 PM <sillybanter@gmail.com> wrote in message news:MtsYg.9714$gx6.5379@trnddc05...
> In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>> "William Elliot" <marsh@hevanet.remove.com> wrote in message
>> news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com...
>> > On Sun, 15 Oct 2006, Peter Olcott wrote:
>> >
>> >> The Halt program throws an "Invalid Input" exception.
>> >> This would be analogous to the hardware exception of an attempt to divide
>> >> by
>> >> zero.
>> >>
>> > Error 001:  Invalid input.  Please try again.
>>
>> The point is there are not any questions too difficult for logic to correctly
>> answer, logic itself is not incomplete as Kurt Godel proposed. There are
>> merely
>> some questions where the question itself  is ill-formed.
>
> Brilliant.  By defining any unsolvable problems as "ill-formed" then
> we can say that all "well-formed" questions are solvable.  No more
> unsolvable problems!

X = 50.0 / 0.0
Is this an unsolvable problem or an ill-formed problem?

>
> Advancement of science by changing definitions.  Gotta love it.
>
> --
>
> Steve Stringer
> sillybanter@gmail.com
>

 0
NoSpam266 (508)
10/15/2006 3:56:32 PM
In article <QSsYg.7900$eZ4.333@dukeread06>, "Peter Olcott" <NoSpam@SeeScreen.com> writes: .... > >X = 50.0 / 0.0 >Is this an unsolvable problem or an ill-formed problem? > I cannot see a problem there at all, just an equation with an undefined RHS. What is the problem exactly? Derek Holt.  0 mareg (22) 10/15/2006 4:35:48 PM Peter Olcott wrote: > The Halt program throws an "Invalid Input" exception. > This would be analogous to the hardware exception of an attempt to divide by > zero. When exactly does the hypothetical Halt program throw this exception? That is, what is the computable property of the program text the Halt program uses to detect invalid input? Oh well, I guess we're in for another thousand message crank fest. -- Aatu Koskensilta (aatu.koskensilta@xortec.fi) "Wovon man nicht sprechen kann, daruber muss man schweigen" - Ludwig Wittgenstein, Tractatus Logico-Philosophicus  0 10/15/2006 4:58:39 PM In sci.logic, Peter Olcott <NoSpam@SeeScreen.com> wrote on Sun, 15 Oct 2006 09:19:52 -0500 <csrYg.7886$eZ4.2645@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).

If one doesn't like mu-loops, an alternate formulation is:

weirdfun(arg) {
if(HTest(arg[0], arg) == HALT)
weirdfun(arg);
}

which is almost identical except that the stack gets arbitrarily large
during execution.

Perhaps you have an idea as to how "Invalid Input" can be implemented?
Best I can do is to have HTest() look for self-references, but that
won't help much as one can make a trivial modification to HTest(),
yielding HTest'(), by e.g. declaring an extra local variable which
is uninvolved in the algorithm, or printing out extra debug statements.

Same operation, different function, HTest() lets the wight in, and
fails.

--
Useless C++ Programming Idea #992381111:
 0
ewill5 (11075)
10/15/2006 5:00:04 PM
<mareg@mimosa.csv.warwick.ac.uk> wrote in message
news:egto14$b1d$1@wisteria.csv.warwick.ac.uk...
> In article <QSsYg.7900$eZ4.333@dukeread06>, > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > ... > >> >>X = 50.0 / 0.0 >>Is this an unsolvable problem or an ill-formed problem? >> > > I cannot see a problem there at all, just an equation with an undefined RHS. > What is the problem exactly? > > Derek Holt. What is the value of X?  0 NoSpam266 (508) 10/15/2006 5:16:57 PM <mareg@mimosa.csv.warwick.ac.uk> wrote in message news:egto14$b1d$1@wisteria.csv.warwick.ac.uk... > In article <QSsYg.7900$eZ4.333@dukeread06>,
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
> ...
>
>>
>>X = 50.0 / 0.0
>>Is this an unsolvable problem or an ill-formed problem?
>>
>
> I cannot see a problem there at all, just an equation with an undefined RHS.
> What is the problem exactly?
>
> Derek Holt.

It is not an equation, the "=" sign is an assignment operator in computer
science.

 0
NoSpam266 (508)
10/15/2006 5:27:09 PM
"The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
news:vp2a04-lfs.ln1@sirius.tg00suus7038.net...
> In sci.logic, Peter Olcott
> <NoSpam@SeeScreen.com>
> wrote
> on Sun, 15 Oct 2006 09:19:52 -0500
> <csrYg.7886$eZ4.2645@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) > > If one doesn't like mu-loops, an alternate formulation is: > > weirdfun(arg) { > if(HTest(arg[0], arg) == HALT) > weirdfun(arg); > } > > which is almost identical except that the stack gets arbitrarily large > during execution. > > Perhaps you have an idea as to how "Invalid Input" can be implemented? > Best I can do is to have HTest() look for self-references, but that > won't help much as one can make a trivial modification to HTest(), > yielding HTest'(), by e.g. declaring an extra local variable which > is uninvolved in the algorithm, or printing out extra debug statements. > > Same operation, different function, HTest() lets the wight in, and > fails. > > -- > #191, ewill3@earthlink.net > Useless C++ Programming Idea #992381111: > while(bit&BITMASK) ;  0 NoSpam266 (508) 10/15/2006 5:38:39 PM In sci.logic, Peter Olcott <NoSpam@SeeScreen.com> wrote on Sun, 15 Oct 2006 12:38:39 -0500 <AmuYg.7908$eZ4.5473@dukeread06>:
>
> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net...
>> In sci.logic, Peter Olcott
>> <NoSpam@SeeScreen.com>
>> wrote
>> on Sun, 15 Oct 2006 09:19:52 -0500
>> <csrYg.7886$eZ4.2645@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. 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. > >> >> If one doesn't like mu-loops, an alternate formulation is: >> >> weirdfun(arg) { >> if(HTest(arg[0], arg) == HALT) >> weirdfun(arg); >> } >> >> which is almost identical except that the stack gets arbitrarily large >> during execution. >> >> Perhaps you have an idea as to how "Invalid Input" can be implemented? >> Best I can do is to have HTest() look for self-references, but that >> won't help much as one can make a trivial modification to HTest(), >> yielding HTest'(), by e.g. declaring an extra local variable which >> is uninvolved in the algorithm, or printing out extra debug statements. >> >> Same operation, different function, HTest() lets the wight in, and >> fails. >> >> -- >> #191, ewill3@earthlink.net >> Useless C++ Programming Idea #992381111: >> while(bit&BITMASK) ; > > -- #191, ewill3@earthlink.net Useless C++ Programming Idea #7878218: class C { private: virtual void stupid() = 0; };  0 ewill5 (11075) 10/15/2006 7:00:03 PM "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message news:e7aa04-32t.ln1@sirius.tg00suus7038.net... > In sci.logic, Peter Olcott > <NoSpam@SeeScreen.com> > wrote > on Sun, 15 Oct 2006 12:38:39 -0500 > <AmuYg.7908$eZ4.5473@dukeread06>:
>>
>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net...
>>> In sci.logic, Peter Olcott
>>> <NoSpam@SeeScreen.com>
>>> wrote
>>> on Sun, 15 Oct 2006 09:19:52 -0500
>>> <csrYg.7886$eZ4.2645@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; > 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. 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. > >> >>> >>> If one doesn't like mu-loops, an alternate formulation is: >>> >>> weirdfun(arg) { >>> if(HTest(arg[0], arg) == HALT) >>> weirdfun(arg); >>> } >>> >>> which is almost identical except that the stack gets arbitrarily large >>> during execution. >>> >>> Perhaps you have an idea as to how "Invalid Input" can be implemented? >>> Best I can do is to have HTest() look for self-references, but that >>> won't help much as one can make a trivial modification to HTest(), >>> yielding HTest'(), by e.g. declaring an extra local variable which >>> is uninvolved in the algorithm, or printing out extra debug statements. >>> >>> Same operation, different function, HTest() lets the wight in, and >>> fails. >>> >>> -- >>> #191, ewill3@earthlink.net >>> Useless C++ Programming Idea #992381111: >>> while(bit&BITMASK) ; >> >> > > > -- > #191, ewill3@earthlink.net > Useless C++ Programming Idea #7878218: > class C { private: virtual void stupid() = 0; };  0 NoSpam266 (508) 10/16/2006 3:40:02 AM "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message news:laDYg.7965$eZ4.1292@dukeread06...
>
> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
> news:e7aa04-32t.ln1@sirius.tg00suus7038.net...
>> In sci.logic, Peter Olcott
>> <NoSpam@SeeScreen.com>
>> wrote
>> on Sun, 15 Oct 2006 12:38:39 -0500
>> <AmuYg.7908$eZ4.5473@dukeread06>: >>> >>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message >>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net... >>>> In sci.logic, Peter Olcott >>>> <NoSpam@SeeScreen.com> >>>> wrote >>>> on Sun, 15 Oct 2006 09:19:52 -0500 >>>> <csrYg.7886$eZ4.2645@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;

P.S. although this is typically implemented at the CISC assembly language level
as a single machine instruction, there are numerous micro code instructions that
implement this instruction, thus it would be construed as an algorithm.

>
>> 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. 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.
>
>>
>>>
>>>>
>>>> If one doesn't like mu-loops, an alternate formulation is:
>>>>
>>>> weirdfun(arg) {
>>>>   if(HTest(arg[0], arg) == HALT)
>>>>     weirdfun(arg);
>>>> }
>>>>
>>>> which is almost identical except that the stack gets arbitrarily large
>>>> during execution.
>>>>
>>>> Perhaps you have an idea as to how "Invalid Input" can be implemented?
>>>> Best I can do is to have HTest() look for self-references, but that
>>>> won't help much as one can make a trivial modification to HTest(),
>>>> yielding HTest'(), by e.g. declaring an extra local variable which
>>>> is uninvolved in the algorithm, or printing out extra debug statements.
>>>>
>>>> Same operation, different function, HTest() lets the wight in, and
>>>> fails.
>>>>
>>>> --
>>>> Useless C++ Programming Idea #992381111:
>>>
>>>
>>
>>
>> --
>> Useless C++ Programming Idea #7878218:
>> class C { private: virtual void stupid() = 0; };
>
>

 0
NoSpam266 (508)
10/16/2006 3:53:48 AM
In sci.logic, Peter Olcott
<NoSpam@SeeScreen.com>
wrote
on Sun, 15 Oct 2006 22:40:02 -0500
<laDYg.7965$eZ4.1292@dukeread06>: > > "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message > news:e7aa04-32t.ln1@sirius.tg00suus7038.net... >> In sci.logic, Peter Olcott >> <NoSpam@SeeScreen.com> >> wrote >> on Sun, 15 Oct 2006 12:38:39 -0500 >> <AmuYg.7908$eZ4.5473@dukeread06>:
>>>
>>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
>>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net...
>>>> In sci.logic, Peter Olcott
>>>> <NoSpam@SeeScreen.com>
>>>> wrote
>>>> on Sun, 15 Oct 2006 09:19:52 -0500
>>>> <csrYg.7886$eZ4.2645@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. Of course, one implementation of HTest() is a simple one: enum {HALT, LOOP} HTest(function, arguments) throws CannotDetermineException { throw new CannotDetermineException(function + "(" + arguments + ")"); } which is about as useful as a tricycle with three broken wheels, but does satisfy the criteria for a limited halting function. So precisely which problem are you trying to solve here? > >> >>> >>>> >>>> If one doesn't like mu-loops, an alternate formulation is: >>>> >>>> weirdfun(arg) { >>>> if(HTest(arg[0], arg) == HALT) >>>> weirdfun(arg); >>>> } >>>> >>>> which is almost identical except that the stack gets arbitrarily large >>>> during execution. >>>> >>>> Perhaps you have an idea as to how "Invalid Input" can be implemented? >>>> Best I can do is to have HTest() look for self-references, but that >>>> won't help much as one can make a trivial modification to HTest(), >>>> yielding HTest'(), by e.g. declaring an extra local variable which >>>> is uninvolved in the algorithm, or printing out extra debug statements. >>>> >>>> Same operation, different function, HTest() lets the wight in, and >>>> fails. >>>> >>>> -- >>>> #191, ewill3@earthlink.net >>>> Useless C++ Programming Idea #992381111: >>>> while(bit&BITMASK) ; >>> >>> >> >> >> -- >> #191, ewill3@earthlink.net >> Useless C++ Programming Idea #7878218: >> class C { private: virtual void stupid() = 0; }; > > -- #191, ewill3@earthlink.net Linux. Because vaporware only goes so far.  0 ewill5 (11075) 10/16/2006 5:00:21 AM In sci.logic, Peter Olcott <NoSpam@SeeScreen.com> wrote on Sun, 15 Oct 2006 22:53:48 -0500 <fnDYg.7967$eZ4.986@dukeread06>:
>
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
> news:laDYg.7965$eZ4.1292@dukeread06... >> >> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message >> news:e7aa04-32t.ln1@sirius.tg00suus7038.net... >>> In sci.logic, Peter Olcott >>> <NoSpam@SeeScreen.com> >>> wrote >>> on Sun, 15 Oct 2006 12:38:39 -0500 >>> <AmuYg.7908$eZ4.5473@dukeread06>:
>>>>
>>>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
>>>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net...
>>>>> In sci.logic, Peter Olcott
>>>>> <NoSpam@SeeScreen.com>
>>>>> wrote
>>>>> on Sun, 15 Oct 2006 09:19:52 -0500
>>>>> <csrYg.7886$eZ4.2645@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; > > P.S. although this is typically implemented at the CISC assembly language level > as a single machine instruction, there are numerous micro code instructions that > implement this instruction, thus it would be construed as an algorithm. Point taken but mostly irrelevant for the halting problem. :-) > >> >>> 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. 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. >> >>> >>>> >>>>> >>>>> If one doesn't like mu-loops, an alternate formulation is: >>>>> >>>>> weirdfun(arg) { >>>>> if(HTest(arg[0], arg) == HALT) >>>>> weirdfun(arg); >>>>> } >>>>> >>>>> which is almost identical except that the stack gets arbitrarily large >>>>> during execution. >>>>> >>>>> Perhaps you have an idea as to how "Invalid Input" can be implemented? >>>>> Best I can do is to have HTest() look for self-references, but that >>>>> won't help much as one can make a trivial modification to HTest(), >>>>> yielding HTest'(), by e.g. declaring an extra local variable which >>>>> is uninvolved in the algorithm, or printing out extra debug statements. >>>>> >>>>> Same operation, different function, HTest() lets the wight in, and >>>>> fails. >>>>> >>>>> -- >>>>> #191, ewill3@earthlink.net >>>>> Useless C++ Programming Idea #992381111: >>>>> while(bit&BITMASK) ; >>>> >>>> >>> >>> >>> -- >>> #191, ewill3@earthlink.net >>> Useless C++ Programming Idea #7878218: >>> class C { private: virtual void stupid() = 0; }; >> >> > > -- #191, ewill3@earthlink.net Evil? Were I evil, I'd eat you *first*. :-)  0 ewill5 (11075) 10/16/2006 5:00:22 AM On Sun, 15 Oct 2006, Peter Olcott wrote: > <mareg@mimosa.csv.warwick.ac.uk> wrote in message > > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > >>X = 50.0 / 0.0 > >>Is this an unsolvable problem or an ill-formed problem? > > > > I cannot see a problem there at all, just an equation with an undefined RHS. > > What is the problem exactly? > > What is the value of X? > Just like he told you, X doesn't have a value.  0 marsh12 (26) 10/16/2006 5:14:13 AM Peter Olcott wrote: > The Halt program throws an "Invalid Input" exception. > This would be analogous to the hardware exception of an attempt to divide by > zero. The set of programs which the program claimed to halt, the set of programs which the program claimed to not halt, and the set of programs for which the program threw the exception would all have to be recursive. Hopefully the program would be sound, so that all the programs which the program claimed to halt would actually halt. So the set of programs which the program claimed to halt would be a recursive subset of the set of programs which do actually halt. This would mean there are some programs which do actually halt, but the program can't tell this.  0 10/16/2006 5:18:59 AM "William Elliot" <marsh@hevanet.remove.com> wrote in message news:Pine.BSI.4.58.0610152213330.1333@vista.hevanet.com... > On Sun, 15 Oct 2006, Peter Olcott wrote: >> <mareg@mimosa.csv.warwick.ac.uk> wrote in message >> > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > >> >>X = 50.0 / 0.0 >> >>Is this an unsolvable problem or an ill-formed problem? >> > >> > I cannot see a problem there at all, just an equation with an undefined >> > RHS. >> > What is the problem exactly? >> >> What is the value of X? >> > Just like he told you, X doesn't have a value. Which is the same result obtained from Halt() when it throws the INVALID_INPUT exception. It neither returns HALTS, nor NOT_HALTS.  0 NoSpam266 (508) 10/16/2006 6:30:22 AM "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message news:uheb04-pa.ln1@sirius.tg00suus7038.net... > In sci.logic, Peter Olcott > <NoSpam@SeeScreen.com> > wrote > on Sun, 15 Oct 2006 22:53:48 -0500 > <fnDYg.7967$eZ4.986@dukeread06>:
>>
>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote in message
>> news:laDYg.7965$eZ4.1292@dukeread06... >>> >>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message >>> news:e7aa04-32t.ln1@sirius.tg00suus7038.net... >>>> In sci.logic, Peter Olcott >>>> <NoSpam@SeeScreen.com> >>>> wrote >>>> on Sun, 15 Oct 2006 12:38:39 -0500 >>>> <AmuYg.7908$eZ4.5473@dukeread06>:
>>>>>
>>>>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in
>>>>> message
>>>>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net...
>>>>>> In sci.logic, Peter Olcott
>>>>>> <NoSpam@SeeScreen.com>
>>>>>> wrote
>>>>>> on Sun, 15 Oct 2006 09:19:52 -0500
>>>>>> <csrYg.7886$eZ4.2645@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; >> >> P.S. although this is typically implemented at the CISC assembly language >> level >> as a single machine instruction, there are numerous micro code instructions >> that >> implement this instruction, thus it would be construed as an algorithm. > > Point taken but mostly irrelevant for the halting problem. :-) It shows the simple mathematical operation of division, also It shows that your specified requirements of [the test of being an algorithm] also equally applies to the simple mathematical operation of division. > >> >>> >>>> 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. 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. >>> >>>> >>>>> >>>>>> >>>>>> If one doesn't like mu-loops, an alternate formulation is: >>>>>> >>>>>> weirdfun(arg) { >>>>>> if(HTest(arg[0], arg) == HALT) >>>>>> weirdfun(arg); >>>>>> } >>>>>> >>>>>> which is almost identical except that the stack gets arbitrarily large >>>>>> during execution. >>>>>> >>>>>> Perhaps you have an idea as to how "Invalid Input" can be implemented? >>>>>> Best I can do is to have HTest() look for self-references, but that >>>>>> won't help much as one can make a trivial modification to HTest(), >>>>>> yielding HTest'(), by e.g. declaring an extra local variable which >>>>>> is uninvolved in the algorithm, or printing out extra debug statements. >>>>>> >>>>>> Same operation, different function, HTest() lets the wight in, and >>>>>> fails. >>>>>> >>>>>> -- >>>>>> #191, ewill3@earthlink.net >>>>>> Useless C++ Programming Idea #992381111: >>>>>> while(bit&BITMASK) ; >>>>> >>>>> >>>> >>>> >>>> -- >>>> #191, ewill3@earthlink.net >>>> Useless C++ Programming Idea #7878218: >>>> class C { private: virtual void stupid() = 0; }; >>> >>> >> >> > > > -- > #191, ewill3@earthlink.net > Evil? Were I evil, I'd eat you *first*. :-)  0 NoSpam266 (508) 10/16/2006 6:37:28 AM "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message news:5geb04-pa.ln1@sirius.tg00suus7038.net... > In sci.logic, Peter Olcott > <NoSpam@SeeScreen.com> > wrote > on Sun, 15 Oct 2006 22:40:02 -0500 > <laDYg.7965$eZ4.1292@dukeread06>:
>>
>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
>> news:e7aa04-32t.ln1@sirius.tg00suus7038.net...
>>> In sci.logic, Peter Olcott
>>> <NoSpam@SeeScreen.com>
>>> wrote
>>> on Sun, 15 Oct 2006 12:38:39 -0500
>>> <AmuYg.7908$eZ4.5473@dukeread06>: >>>> >>>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message >>>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net... >>>>> In sci.logic, Peter Olcott >>>>> <NoSpam@SeeScreen.com> >>>>> wrote >>>>> on Sun, 15 Oct 2006 09:19:52 -0500 >>>>> <csrYg.7886$eZ4.2645@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?
>
> 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.

>
> Of course, one implementation of HTest() is a simple one:
>
> enum {HALT, LOOP} HTest(function, arguments)
> throws CannotDetermineException
> {
>    throw new CannotDetermineException(function + "(" + arguments + ")");
> }
>
> which is about as useful as a tricycle with three broken wheels, but
> does satisfy the criteria for a limited halting function.
>
> So precisely which problem are you trying to solve here?
>
>>
>>>
>>>>
>>>>>
>>>>> If one doesn't like mu-loops, an alternate formulation is:
>>>>>
>>>>> weirdfun(arg) {
>>>>>   if(HTest(arg[0], arg) == HALT)
>>>>>     weirdfun(arg);
>>>>> }
>>>>>
>>>>> which is almost identical except that the stack gets arbitrarily large
>>>>> during execution.
>>>>>
>>>>> Perhaps you have an idea as to how "Invalid Input" can be implemented?
>>>>> Best I can do is to have HTest() look for self-references, but that
>>>>> won't help much as one can make a trivial modification to HTest(),
>>>>> yielding HTest'(), by e.g. declaring an extra local variable which
>>>>> is uninvolved in the algorithm, or printing out extra debug statements.
>>>>>
>>>>> Same operation, different function, HTest() lets the wight in, and
>>>>> fails.
>>>>>
>>>>> --
>>>>> Useless C++ Programming Idea #992381111:
>>>>
>>>>
>>>
>>>
>>> --
>>> Useless C++ Programming Idea #7878218:
>>> class C { private: virtual void stupid() = 0; };
>>
>>
>
>
> --
> Linux.  Because vaporware only goes so far.

 0
NoSpam266 (508)
10/16/2006 6:40:42 AM
"Rupert" <rupertmccallum@yahoo.com> wrote in message
>
> Peter Olcott wrote:
>> The Halt program throws an "Invalid Input" exception.
>> This would be analogous to the hardware exception of an attempt to divide by
>> zero.
>
> The set of programs which the program claimed to halt, the set of
> programs which the program claimed to not halt, and the set of programs
> for which the program threw the exception would all have to be
> recursive.
>
> Hopefully the program would be sound, so that all the programs which
> the program claimed to halt would actually halt. So the set of programs
> which the program claimed to halt would be a recursive subset of the
> set of programs which do actually halt.
>
> This would mean there are some programs which do actually halt, but the
> program can't tell this.
>

It can determine that each and every program that HALTS does indeed HALT, yet
can not always provide this determination as a return value. This is not at all
the same thing as correctly concluding that its capabilities are inherently
limited, only its communication protocol is limited.

It knows that the program HALTS, and merely must refrain from saying that the
program HALTS, because saying that the program HALTS provides a different
execution trace, thus a different program, and therefore a different end result.

 0
NoSpam266 (508)
10/16/2006 7:32:21 AM
On Mon, 16 Oct 2006, Peter Olcott wrote:
> "William Elliot" <marsh@hevanet.remove.com> wrote in message
> > On Sun, 15 Oct 2006, Peter Olcott wrote:
> >> <mareg@mimosa.csv.warwick.ac.uk> wrote in message
> >> > "Peter Olcott" <NoSpam@SeeScreen.com> writes:
> >
> >> >>X = 50.0 / 0.0
> >> >>Is this an unsolvable problem or an ill-formed problem?
> >> >
> >> > I cannot see a problem there at all, just an equation with an undefined
> >> > RHS.
> >> > What is the problem exactly?
> >>
> >> What is the value of X?
> >>
> > Just like he told you, X doesn't have a value.
>
> Which is the same result obtained from Halt() when it throws the INVALID_INPUT
> exception. It neither returns HALTS, nor NOT_HALTS.
>
So what?  Computer programs already check to prevent division by zero.
 0
marsh12 (26)
10/16/2006 8:11:38 AM
In article <NbuYg.7907$eZ4.275@dukeread06>, "Peter Olcott" <NoSpam@SeeScreen.com> writes: > ><mareg@mimosa.csv.warwick.ac.uk> wrote in message >news:egto14$b1d$1@wisteria.csv.warwick.ac.uk... >> In article <QSsYg.7900$eZ4.333@dukeread06>,
>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>> ...
>>
>>>
>>>X = 50.0 / 0.0
>>>Is this an unsolvable problem or an ill-formed problem?
>>>
>>
>> I cannot see a problem there at all, just an equation with an undefined RHS.
>> What is the problem exactly?
>>
>> Derek Holt.
>
>It is not an equation, the "=" sign is an assignment operator in computer
>science.

In that case why not remove the ambiguity by using ":=" ?

Since the RHS of the assignment is not defined, the assignment fails.

Derek Holt.
 0
mareg (22)
10/16/2006 8:33:54 AM
"William Elliot" <marsh@hevanet.remove.com> wrote in message
news:Pine.BSI.4.58.0610160110200.2981@vista.hevanet.com...
> On Mon, 16 Oct 2006, Peter Olcott wrote:
>> "William Elliot" <marsh@hevanet.remove.com> wrote in message
>> > On Sun, 15 Oct 2006, Peter Olcott wrote:
>> >> <mareg@mimosa.csv.warwick.ac.uk> wrote in message
>> >> > "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>> >
>> >> >>X = 50.0 / 0.0
>> >> >>Is this an unsolvable problem or an ill-formed problem?
>> >> >
>> >> > I cannot see a problem there at all, just an equation with an undefined
>> >> > RHS.
>> >> > What is the problem exactly?
>> >>
>> >> What is the value of X?
>> >>
>> > Just like he told you, X doesn't have a value.
>>
>> Which is the same result obtained from Halt() when it throws the
>> INVALID_INPUT
>> exception. It neither returns HALTS, nor NOT_HALTS.
>>
> So what?  Computer programs already check to prevent division by zero.

It shows that  the specified requirements of [the test of being an algorithm]
also equally apply to the simple mathematical operation of division. This would
mean that if this test is valid, then even the simple operation of division
fails [the test of being an algorithm] . Because of this I would conclude that
either [the test of being an algorithm] is not a valid test, or the definition
of the term [algorithm] may be less useful than presupposed.

 0
NoSpam266 (508)
10/16/2006 12:12:13 PM
Peter Olcott wrote:
> "William Elliot" <marsh@hevanet.remove.com> wrote in message
> news:Pine.BSI.4.58.0610152213330.1333@vista.hevanet.com...
>> On Sun, 15 Oct 2006, Peter Olcott wrote:
>>> <mareg@mimosa.csv.warwick.ac.uk> wrote in message
>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>> X = 50.0 / 0.0
>>>>> Is this an unsolvable problem or an ill-formed problem?
>>>> I cannot see a problem there at all, just an equation with an undefined
>>>> RHS.
>>>> What is the problem exactly?
>>> What is the value of X?
>>>
>> Just like he told you, X doesn't have a value.
>
> Which is the same result obtained from Halt() when it throws the INVALID_INPUT
> exception. It neither returns HALTS, nor NOT_HALTS.

There is no magic to exception throwing. It is just a programming
language technique for communicating the results of a frequent test.
Anything that could be done by e.g. having an exception for division by
zero could also be done by having an explicit test for acceptability of
a division, combined with a division operation whose results are
completely undefined for invalid inputs:

if(isValid("50.0 / 0.0") then
X = 50.0 / 0.0
else
GiveUp

computed, exceptions are usually ignored in theory of computation.

However, if you are going to add them, the exception condition has to be
computable for them to make any sense. What is your algorithm for
computing whether a halting problem input is valid or not?

Patricia
 0
pats (3556)
10/16/2006 1:07:48 PM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:EuLYg.14458$UG4.11820@newsread2.news.pas.earthlink.net... > Peter Olcott wrote: >> "William Elliot" <marsh@hevanet.remove.com> wrote in message >> news:Pine.BSI.4.58.0610152213330.1333@vista.hevanet.com... >>> On Sun, 15 Oct 2006, Peter Olcott wrote: >>>> <mareg@mimosa.csv.warwick.ac.uk> wrote in message >>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>>>>> X = 50.0 / 0.0 >>>>>> Is this an unsolvable problem or an ill-formed problem? >>>>> I cannot see a problem there at all, just an equation with an undefined >>>>> RHS. >>>>> What is the problem exactly? >>>> What is the value of X? >>>> >>> Just like he told you, X doesn't have a value. >> >> Which is the same result obtained from Halt() when it throws the >> INVALID_INPUT exception. It neither returns HALTS, nor NOT_HALTS. > > There is no magic to exception throwing. It is just a programming > language technique for communicating the results of a frequent test. > Anything that could be done by e.g. having an exception for division by > zero could also be done by having an explicit test for acceptability of > a division, combined with a division operation whose results are > completely undefined for invalid inputs: > > if(isValid("50.0 / 0.0") then > X = 50.0 / 0.0 > else > GiveUp > > Because they add complication without adding anything to what can be > computed, exceptions are usually ignored in theory of computation. > > However, if you are going to add them, the exception condition has to be > computable for them to make any sense. What is your algorithm for > computing whether a halting problem input is valid or not? > > Patricia To frame the exception handling mechanism within the historical context of a Turing Machine we only need to establish three integer values mapped to three different semantic meanings: 0=NOT_HALTS 1=HALTS 2= INVALID_INPUT. The input is invalid in each and every case where providing the result of the determination of halting derives a different execution trace, thus changing the result.  0 NoSpam266 (508) 10/16/2006 3:42:50 PM Peter Olcott wrote: ..... > To frame the exception handling mechanism within the historical context of a > Turing Machine we only need to establish three integer values mapped to three > different semantic meanings: > 0=NOT_HALTS 1=HALTS 2= INVALID_INPUT. The input is invalid in each and > every case where providing the result of the determination of halting derives a > different execution trace, thus changing the result. > > Yes, but what is the algorithm for determining whether the result of the determination of halting derives a different execution trace? Or other proof that the set of invalid inputs is TM-decidable? The algorithm gets as input the Goedel number corresponding to a TM-computation, a combination of initial tape state and machine description. Patricia  0 pats (3556) 10/16/2006 4:16:22 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net...
> Peter Olcott wrote:
> ....
>> To frame the exception handling mechanism within the historical context of a
>> Turing Machine we only need to establish three integer values mapped to three
>> different semantic meanings:
>> 0=NOT_HALTS   1=HALTS    2= INVALID_INPUT. The input is invalid in each and
>> every case where providing the result of the determination of halting derives
>> a different execution trace, thus changing the result.
>
> Yes, but what is the algorithm for determining whether the result of the
> determination of halting derives a different execution trace?

You have it incorrectly, the result does not provide a different execution
trace. It is the act of providing this result that derives the different
execution trace. Halt() can determine that the test program will halt, it merely
can not provide the results of this determination to the caller in this case.
Halt() determines that providing the results of its correct and complete
analysis is used to alter the execution trace, thus forming a different
execution trace than the one that is the subject of the test.

> Or other
> proof that the set of invalid inputs is TM-decidable?
>
> The algorithm gets as input the Goedel number corresponding to a
> TM-computation, a combination of initial tape state and machine description.
>
> Patricia

 0
NoSpam266 (508)
10/16/2006 4:53:35 PM
Peter Olcott wrote:
> "Patricia Shanahan" <pats@acm.org> wrote in message
> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net... >> Peter Olcott wrote: >> .... >>> To frame the exception handling mechanism within the historical context of a >>> Turing Machine we only need to establish three integer values mapped to three >>> different semantic meanings: >>> 0=NOT_HALTS 1=HALTS 2= INVALID_INPUT. The input is invalid in each and >>> every case where providing the result of the determination of halting derives >>> a different execution trace, thus changing the result. >> Yes, but what is the algorithm for determining whether the result of the >> determination of halting derives a different execution trace? > > You have it incorrectly, the result does not provide a different execution > trace. It is the act of providing this result that derives the different > execution trace. Halt() can determine that the test program will halt, it merely > can not provide the results of this determination to the caller in this case. > Halt() determines that providing the results of its correct and complete > analysis is used to alter the execution trace, thus forming a different > execution trace than the one that is the subject of the test. Are you saying that the behavior of the algorithm depends on what its caller is going to do with the result? If so, that is a far bigger change in the concept of algorithm than merely adding exceptions. If not, I'm really confused about what you are saying. Patricia  0 pats (3556) 10/16/2006 10:27:25 PM Peter Olcott wrote: > "Rupert" <rupertmccallum@yahoo.com> wrote in message > news:1160975938.946169.291050@i3g2000cwc.googlegroups.com... > > > > Peter Olcott wrote: > >> The Halt program throws an "Invalid Input" exception. > >> This would be analogous to the hardware exception of an attempt to divide by > >> zero. > > > > The set of programs which the program claimed to halt, the set of > > programs which the program claimed to not halt, and the set of programs > > for which the program threw the exception would all have to be > > recursive. > > > > Hopefully the program would be sound, so that all the programs which > > the program claimed to halt would actually halt. So the set of programs > > which the program claimed to halt would be a recursive subset of the > > set of programs which do actually halt. > > > > This would mean there are some programs which do actually halt, but the > > program can't tell this. > > > > It can determine that each and every program that HALTS does indeed HALT, yet > can not always provide this determination as a return value. This is not at all > the same thing as correctly concluding that its capabilities are inherently > limited, only its communication protocol is limited. > I don't understand the distinction. > It knows that the program HALTS, and merely must refrain from saying that the > program HALTS, because saying that the program HALTS provides a different > execution trace, thus a different program, and therefore a different end result.  0 10/16/2006 10:46:08 PM On Mon, 16 Oct 2006, Peter Olcott wrote: > "William Elliot" <marsh@hevanet.remove.com> wrote in message > > On Mon, 16 Oct 2006, Peter Olcott wrote: > >> "William Elliot" <marsh@hevanet.remove.com> wrote in message > >> > On Sun, 15 Oct 2006, Peter Olcott wrote: > >> >> > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > Because of this I would conclude that either [the test of being an > algorithm] is not a valid test, or the definition of the term > [algorithm] may be less useful than presupposed. > Oh, that's your computer nerd handicap, that everything is programable computerese. Well it isn't. Definitions aren't algorithm and algorithms aren't definitions. However as you insist, would you give the definition of an algorithm, which of course by your naivete is the same as giving an algorithm for algorithm. Thus for your grandioso intellectual bravado Riddle of the day. What is the algorithm for algorithm? In the mean time, please produce an algorithm for a well ordering of the real numbers as constructed in ZFC. You'll also have fun producing an algorithm for determining if a number is transcendental. Test your algorithm with known transcendental numbers pi, e and log_e 2.  0 marsh12 (26) 10/16/2006 11:51:50 PM On Mon, 16 Oct 2006, Patricia Shanahan wrote: > > Are you saying that the behavior of the algorithm depends on what its > caller is going to do with the result? If so, that is a far bigger > change in the concept of algorithm than merely adding exceptions. > Of course, he's taken lessons from Bush, correct results are always produced by wishful thinking. > If not, I'm really confused about what you are saying. > Isn't it clear? Run his program on this thread. What's the output? HALT!  0 marsh12 (26) 10/16/2006 11:59:42 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:hHTYg.7886$Lv3.7266@newsread1.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net... >>> Peter Olcott wrote: >>> .... >>>> To frame the exception handling mechanism within the historical context of >>>> a Turing Machine we only need to establish three integer values mapped to >>>> three different semantic meanings: >>>> 0=NOT_HALTS 1=HALTS 2= INVALID_INPUT. The input is invalid in each and >>>> every case where providing the result of the determination of halting >>>> derives a different execution trace, thus changing the result. >>> Yes, but what is the algorithm for determining whether the result of the >>> determination of halting derives a different execution trace? >> >> You have it incorrectly, the result does not provide a different execution >> trace. It is the act of providing this result that derives the different >> execution trace. Halt() can determine that the test program will halt, it >> merely can not provide the results of this determination to the caller in >> this case. Halt() determines that providing the results of its correct and >> complete analysis is used to alter the execution trace, thus forming a >> different execution trace than the one that is the subject of the test. > > Are you saying that the behavior of the algorithm depends on what its caller > is going to do with the result? If so, that is a far bigger change in the > concept of algorithm than merely adding exceptions. The difficulty of the Halting Problem is that because of its infinitely recursive structure it is very difficult to see that the typical common sense assumptions that apply to nearly every other algorithm do not apply to this one. One of the most significant aspects of this atypical case, is that in the very unusual case of the Halting Problem, a function can see exactly how it is being called, and the effects of any actions that it takes upon its own caller. Within the specification of the Halting Problem, the Halt() function and its caller combined together form the program under test. In this case the behavior of one of the constituent parts (the Halt() function) forms the basis for the behavior of the other constituent part (the caller). Since this structure is directly presented to the Halt() function as input, the Halt() function can see exactly what its caller intends to do with any result that it provides (or actions that it takes). So the Halt() function breaks out of this otherwise infinitely recursive structure and provides the only possible correct answer given the specification of this problem: it throws the INVALID_INPUT exception. The Turing Machine equivalent of this would be halting with the ReadWrite Head of its tape positioned at a token indicating the semantic meaning of INVALID_INPUT. What this boils down to is not the Kurt Godel / Alan Turning conclusion that there exists some valid questions that are outside of the domain of logic, but, simply that there are some questions where the question itself is incorrect, and for this reason only, have no correct answer. > > If not, I'm really confused about what you are saying. > > Patricia  0 NoSpam266 (508) 10/17/2006 12:51:40 AM <rupertmccallum@yahoo.com> wrote in message news:1161038767.998763.305740@m73g2000cwd.googlegroups.com... > > Peter Olcott wrote: >> "Rupert" <rupertmccallum@yahoo.com> wrote in message >> news:1160975938.946169.291050@i3g2000cwc.googlegroups.com... >> > >> > Peter Olcott wrote: >> >> The Halt program throws an "Invalid Input" exception. >> >> This would be analogous to the hardware exception of an attempt to divide >> >> by >> >> zero. >> > >> > The set of programs which the program claimed to halt, the set of >> > programs which the program claimed to not halt, and the set of programs >> > for which the program threw the exception would all have to be >> > recursive. >> > >> > Hopefully the program would be sound, so that all the programs which >> > the program claimed to halt would actually halt. So the set of programs >> > which the program claimed to halt would be a recursive subset of the >> > set of programs which do actually halt. >> > >> > This would mean there are some programs which do actually halt, but the >> > program can't tell this. >> > >> >> It can determine that each and every program that HALTS does indeed HALT, yet >> can not always provide this determination as a return value. This is not at >> all >> the same thing as correctly concluding that its capabilities are inherently >> limited, only its communication protocol is limited. >> > > I don't understand the distinction. There is no incompleteness. > >> It knows that the program HALTS, and merely must refrain from saying that the >> program HALTS, because saying that the program HALTS provides a different >> execution trace, thus a different program, and therefore a different end >> result. >  0 NoSpam266 (508) 10/17/2006 12:53:00 AM Peter Olcott wrote: > "Patricia Shanahan" <pats@acm.org> wrote in message > news:hHTYg.7886$Lv3.7266@newsread1.news.pas.earthlink.net...
>> Peter Olcott wrote:
>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>>> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net... >>>> Peter Olcott wrote: >>>> .... >>>>> To frame the exception handling mechanism within the historical context of >>>>> a Turing Machine we only need to establish three integer values mapped to >>>>> three different semantic meanings: >>>>> 0=NOT_HALTS 1=HALTS 2= INVALID_INPUT. The input is invalid in each and >>>>> every case where providing the result of the determination of halting >>>>> derives a different execution trace, thus changing the result. >>>> Yes, but what is the algorithm for determining whether the result of the >>>> determination of halting derives a different execution trace? >>> You have it incorrectly, the result does not provide a different execution >>> trace. It is the act of providing this result that derives the different >>> execution trace. Halt() can determine that the test program will halt, it >>> merely can not provide the results of this determination to the caller in >>> this case. Halt() determines that providing the results of its correct and >>> complete analysis is used to alter the execution trace, thus forming a >>> different execution trace than the one that is the subject of the test. >> Are you saying that the behavior of the algorithm depends on what its caller >> is going to do with the result? If so, that is a far bigger change in the >> concept of algorithm than merely adding exceptions. > > The difficulty of the Halting Problem is that because of its infinitely > recursive structure it is very difficult to see that the typical common sense > assumptions that apply to nearly every other algorithm do not apply to this one. > One of the most significant aspects of this atypical case, is that in the very > unusual case of the Halting Problem, a function can see exactly how it is being > called, and the effects of any actions that it takes upon its own caller. > > Within the specification of the Halting Problem, the Halt() function and its > caller combined together form the program under test. In this case the behavior > of one of the constituent parts (the Halt() function) forms the basis for the > behavior of the other constituent part (the caller). Since this structure is > directly presented to the Halt() function as input, the Halt() function can see > exactly what its caller intends to do with any result that it provides (or > actions that it takes). > > So the Halt() function breaks out of this otherwise infinitely recursive > structure and provides the only possible correct answer given the specification > of this problem: it throws the INVALID_INPUT exception. The Turing Machine > equivalent of this would be halting with the ReadWrite Head of its tape > positioned at a token indicating the semantic meaning of INVALID_INPUT. I'm not sure whether all that means "yes" or "no". To try to understand, I'd like to nail down some terminology and program names. http://www.mtnmath.com/whatrh/node49.html contains a simplified version of the proof. Could you explain, in the terminology of that page, how h would detect a situation in which it should throw the exception. Patricia  0 pats (3556) 10/17/2006 1:50:50 AM "Patricia Shanahan" <pats@acm.org> wrote in message news:_FWYg.7998$Lv3.6750@newsread1.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> news:hHTYg.7886$Lv3.7266@newsread1.news.pas.earthlink.net... >>> Peter Olcott wrote: >>>> "Patricia Shanahan" <pats@acm.org> wrote in message >>>> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net...
>>>>> Peter Olcott wrote:
>>>>> ....
>>>>>> To frame the exception handling mechanism within the historical context
>>>>>> of a Turing Machine we only need to establish three integer values mapped
>>>>>> to three different semantic meanings:
>>>>>> 0=NOT_HALTS   1=HALTS    2= INVALID_INPUT. The input is invalid in each
>>>>>> and every case where providing the result of the determination of halting
>>>>>> derives a different execution trace, thus changing the result.
>>>>> Yes, but what is the algorithm for determining whether the result of the
>>>>> determination of halting derives a different execution trace?
>>>> You have it incorrectly, the result does not provide a different execution
>>>> trace. It is the act of providing this result that derives the different
>>>> execution trace. Halt() can determine that the test program will halt, it
>>>> merely can not provide the results of this determination to the caller in
>>>> this case. Halt() determines that providing the results of its correct and
>>>> complete analysis is used to alter the execution trace, thus forming a
>>>> different execution trace than the one that is the subject of the test.
>>> Are you saying that the behavior of the algorithm depends on what its caller
>>> is going to do with the result? If so, that is a far bigger change in the
>>> concept of algorithm than merely adding exceptions.
>>
>> The difficulty of the Halting Problem is that because of its infinitely
>> recursive structure it is very difficult to see that the typical common sense
>> assumptions that apply to nearly every other algorithm do not apply to this
>> one. One of the most significant aspects of this atypical case, is that in
>> the very unusual case of the Halting Problem, a function can see exactly how
>> it is being called, and the effects of any actions that it takes upon its own
>> caller.
>>
>> Within the specification of the Halting Problem, the Halt() function and its
>> caller combined together form the program under test. In this case the
>> behavior of one of the constituent parts (the Halt() function) forms the
>> basis for the behavior of the other constituent part (the caller). Since this
>> structure is directly presented to the Halt() function as input, the Halt()
>> function can see exactly what its caller intends to do with any result that
>> it provides (or actions that it takes).
>>
>> So the Halt() function breaks out of this otherwise infinitely recursive
>> structure and provides the only possible correct answer given the
>> specification of this problem: it throws the INVALID_INPUT exception. The
>> Turing Machine equivalent of this would be halting with the ReadWrite Head of
>> its tape positioned at a token indicating the semantic meaning of
>> INVALID_INPUT.
>
> I'm not sure whether all that means "yes" or "no".

Are you saying that the behavior of the algorithm depends on what its caller
is going to do with the result?

Yes!  In the atypical instance of the Halting Problem the called can know in
advance both that its actions will effect the caller, and  exactly how its
actions will effect the caller. Because it has this information in advance it
can decide what to do about it, and thereby effect the total outcome.

>
> To try to understand, I'd like to nail down some terminology and program
> names. http://www.mtnmath.com/whatrh/node49.html contains a simplified
> version of the proof.
>
> Could you explain, in the terminology of that page, how h would detect a
> situation in which it should throw the exception.
>
> Patricia

 0
NoSpam266 (508)
10/17/2006 2:20:24 AM
Peter Olcott wrote:
> "Patricia Shanahan" <pats@acm.org> wrote in message
> news:_FWYg.7998$Lv3.6750@newsread1.news.pas.earthlink.net... >> Peter Olcott wrote: >>> "Patricia Shanahan" <pats@acm.org> wrote in message >>> news:hHTYg.7886$Lv3.7266@newsread1.news.pas.earthlink.net...
>>>> Peter Olcott wrote:
>>>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>>>>> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net... >>>>>> Peter Olcott wrote: >>>>>> .... >>>>>>> To frame the exception handling mechanism within the historical context >>>>>>> of a Turing Machine we only need to establish three integer values mapped >>>>>>> to three different semantic meanings: >>>>>>> 0=NOT_HALTS 1=HALTS 2= INVALID_INPUT. The input is invalid in each >>>>>>> and every case where providing the result of the determination of halting >>>>>>> derives a different execution trace, thus changing the result. >>>>>> Yes, but what is the algorithm for determining whether the result of the >>>>>> determination of halting derives a different execution trace? >>>>> You have it incorrectly, the result does not provide a different execution >>>>> trace. It is the act of providing this result that derives the different >>>>> execution trace. Halt() can determine that the test program will halt, it >>>>> merely can not provide the results of this determination to the caller in >>>>> this case. Halt() determines that providing the results of its correct and >>>>> complete analysis is used to alter the execution trace, thus forming a >>>>> different execution trace than the one that is the subject of the test. >>>> Are you saying that the behavior of the algorithm depends on what its caller >>>> is going to do with the result? If so, that is a far bigger change in the >>>> concept of algorithm than merely adding exceptions. >>> The difficulty of the Halting Problem is that because of its infinitely >>> recursive structure it is very difficult to see that the typical common sense >>> assumptions that apply to nearly every other algorithm do not apply to this >>> one. One of the most significant aspects of this atypical case, is that in >>> the very unusual case of the Halting Problem, a function can see exactly how >>> it is being called, and the effects of any actions that it takes upon its own >>> caller. >>> >>> Within the specification of the Halting Problem, the Halt() function and its >>> caller combined together form the program under test. In this case the >>> behavior of one of the constituent parts (the Halt() function) forms the >>> basis for the behavior of the other constituent part (the caller). Since this >>> structure is directly presented to the Halt() function as input, the Halt() >>> function can see exactly what its caller intends to do with any result that >>> it provides (or actions that it takes). >>> >>> So the Halt() function breaks out of this otherwise infinitely recursive >>> structure and provides the only possible correct answer given the >>> specification of this problem: it throws the INVALID_INPUT exception. The >>> Turing Machine equivalent of this would be halting with the ReadWrite Head of >>> its tape positioned at a token indicating the semantic meaning of >>> INVALID_INPUT. >> I'm not sure whether all that means "yes" or "no". > > > Are you saying that the behavior of the algorithm depends on what its caller > is going to do with the result? > > Yes! In the atypical instance of the Halting Problem the called can know in > advance both that its actions will effect the caller, and exactly how its > actions will effect the caller. Because it has this information in advance it > can decide what to do about it, and thereby effect the total outcome. HOW does h know "exactly how its actions will affect this caller"? All it knows is its caller has fed it a number, and asked "Is this the Goedel number of a computation that halts?". We know that the TM in that computation uses a copy of h as part of its source code, but it could be obfuscated. > >> To try to understand, I'd like to nail down some terminology and program >> names. http://www.mtnmath.com/whatrh/node49.html contains a simplified >> version of the proof. >> >> Could you explain, in the terminology of that page, how h would detect a >> situation in which it should throw the exception. >> >> Patricia > >  0 pats (3556) 10/17/2006 3:11:27 AM On Tue, 17 Oct 2006, Patricia Shanahan wrote: > Peter Olcott wrote: > > Yes! In the atypical instance of the Halting Problem the called can > > know in advance both that its actions will effect the caller, and > > exactly how its actions will effect the caller. Because it has this > > information in advance it can decide what to do about it, and thereby > > effect the total outcome. > > HOW does h know "exactly how its actions will affect this caller"? All > it knows is its caller has fed it a number, and asked "Is this the > Goedel number of a computation that halts?". We know that the TM in that > computation uses a copy of h as part of its source code, but it could be > obfuscated. > Here's a halting algorithm for OP to lament upon. 1) OP, to prove the validity of his notion, will always ignore or misconstrue your comments. 2) No matter what you say or do, the results will be the same, OP notions is always correct. It can not, will not ever be else. 3) The program of you replying and OP stringing you along won't halt. 4) Therefore, output is not-halt. Thus the algorithm, as the algorithm has put out output, has halted. Then, dear Patricia, upon the futility of your expert efforts, do you HALT!  0 marsh12 (26) 10/17/2006 6:46:43 AM "William Elliot" <marsh@hevanet.remove.com> wrote in message news:Pine.BSI.4.58.0610162328190.15058@vista.hevanet.com... > On Tue, 17 Oct 2006, Patricia Shanahan wrote: >> Peter Olcott wrote: > >> > Yes! In the atypical instance of the Halting Problem the called can >> > know in advance both that its actions will effect the caller, and >> > exactly how its actions will effect the caller. Because it has this >> > information in advance it can decide what to do about it, and thereby >> > effect the total outcome. >> >> HOW does h know "exactly how its actions will affect this caller"? All >> it knows is its caller has fed it a number, and asked "Is this the >> Goedel number of a computation that halts?". We know that the TM in that >> computation uses a copy of h as part of its source code, but it could be >> obfuscated. >> > Here's a halting algorithm for OP to lament upon. > 1) OP, to prove the validity of his notion, will always ignore or > misconstrue your comments. > 2) No matter what you say or do, the results will be the same, OP > notions is always correct. It can not, will not ever be else. > 3) The program of you replying and OP stringing you along won't > halt. > 4) Therefore, output is not-halt. > > Thus the algorithm, as the algorithm has put out output, has halted. > Then, dear Patricia, upon the futility of your expert efforts, do you > HALT! That is factually incorrect. I was here a couple of years ago, and the line-of-reasoning that I presented at the time was proven to be incorrect by newstome@comcast.net a PhD computer science professor.  0 NoSpam266 (508) 10/17/2006 12:46:18 PM Peter Olcott wrote: > <sillybanter@gmail.com> wrote in message news:MtsYg.9714$gx6.5379@trnddc05...
> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
> >> "William Elliot" <marsh@hevanet.remove.com> wrote in message
> >> news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com...
> >> > On Sun, 15 Oct 2006, Peter Olcott wrote:
> >> >
> >> >> The Halt program throws an "Invalid Input" exception.
> >> >> This would be analogous to the hardware exception of an attempt to divide
> >> >> by
> >> >> zero.
> >> >>
> >> > Error 001:  Invalid input.  Please try again.
> >>
> >> The point is there are not any questions too difficult for logic to correctly
> >> answer, logic itself is not incomplete as Kurt Godel proposed. There are
> >> merely
> >> some questions where the question itself  is ill-formed.
> >
> > Brilliant.  By defining any unsolvable problems as "ill-formed" then
> > we can say that all "well-formed" questions are solvable.  No more
> > unsolvable problems!
> >
> Since the only reason that these problems are unsolvable is because they are
> ill-formed, this makes perfect sense. To see it any other way would be like me
> saying that you don't even know how to tell the time of day because of your
> inability to correctly answer the following question; What time is it blue or
> green?

Neither.

What's the prize?

C-B

> > Advancement of science by changing definitions.  Gotta love it.
> >
> > --
> >
> > Steve Stringer
> > sillybanter@gmail.com
> >

 0
shymathguy (92)
10/17/2006 1:45:48 PM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:zRXYg.10503$Y24.7729@newsread4.news.pas.earthlink.net... > Peter Olcott wrote: >> "Patricia Shanahan" <pats@acm.org> wrote in message >> news:_FWYg.7998$Lv3.6750@newsread1.news.pas.earthlink.net...
>>> Peter Olcott wrote:
>>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>>>> news:hHTYg.7886$Lv3.7266@newsread1.news.pas.earthlink.net... >>>>> Peter Olcott wrote: >>>>>> "Patricia Shanahan" <pats@acm.org> wrote in message >>>>>> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net...
>>>>>>> Peter Olcott wrote:
>>>>>>> ....
>>>>>>>> To frame the exception handling mechanism within the historical context
>>>>>>>> of a Turing Machine we only need to establish three integer values
>>>>>>>> mapped to three different semantic meanings:
>>>>>>>> 0=NOT_HALTS   1=HALTS    2= INVALID_INPUT. The input is invalid in each
>>>>>>>> and every case where providing the result of the determination of
>>>>>>>> halting derives a different execution trace, thus changing the result.
>>>>>>> Yes, but what is the algorithm for determining whether the result of the
>>>>>>> determination of halting derives a different execution trace?
>>>>>> You have it incorrectly, the result does not provide a different
>>>>>> execution trace. It is the act of providing this result that derives the
>>>>>> different execution trace. Halt() can determine that the test program
>>>>>> will halt, it merely can not provide the results of this determination to
>>>>>> the caller in this case. Halt() determines that providing the results of
>>>>>> its correct and complete analysis is used to alter the execution trace,
>>>>>> thus forming a different execution trace than the one that is the subject
>>>>>> of the test.
>>>>> Are you saying that the behavior of the algorithm depends on what its
>>>>> caller is going to do with the result? If so, that is a far bigger change
>>>>> in the concept of algorithm than merely adding exceptions.
>>>> The difficulty of the Halting Problem is that because of its infinitely
>>>> recursive structure it is very difficult to see that the typical common
>>>> sense assumptions that apply to nearly every other algorithm do not apply
>>>> to this one. One of the most significant aspects of this atypical case, is
>>>> that in the very unusual case of the Halting Problem, a function can see
>>>> exactly how it is being called, and the effects of any actions that it
>>>> takes upon its own caller.
>>>>
>>>> Within the specification of the Halting Problem, the Halt() function and
>>>> its caller combined together form the program under test. In this case the
>>>> behavior of one of the constituent parts (the Halt() function) forms the
>>>> basis for the behavior of the other constituent part (the caller). Since
>>>> this structure is directly presented to the Halt() function as input, the
>>>> Halt() function can see exactly what its caller intends to do with any
>>>> result that it provides (or actions that it takes).
>>>>
>>>> So the Halt() function breaks out of this otherwise infinitely recursive
>>>> structure and provides the only possible correct answer given the
>>>> specification of this problem: it throws the INVALID_INPUT exception. The
>>>> Turing Machine equivalent of this would be halting with the ReadWrite Head
>>>> of its tape positioned at a token indicating the semantic meaning of
>>>> INVALID_INPUT.
>>> I'm not sure whether all that means "yes" or "no".
>>
>>
>> Are you saying that the behavior of the algorithm depends on what its caller
>>  is going to do with the result?
>>
>> Yes!  In the atypical instance of the Halting Problem the called can know in
>> advance both that its actions will effect the caller, and  exactly how its
>> actions will effect the caller. Because it has this information in advance it
>> can decide what to do about it, and thereby effect the total outcome.
>
> HOW does h know "exactly how its actions will affect this caller"? All
> it knows is its caller has fed it a number, and asked "Is this the
> Goedel number of a computation that halts?". We know that the TM in that
> computation uses a copy of h as part of its source code, but it could be
> obfuscated.
>
The point that I am attempting to make transcends the historical mathematics
that frames the Halting Problem. My point exists within the context of the
natural language conclusions that we draw from this historical mathematical
proof. When one treats natural language more like a mathematical formalism, one
begins to realize that some commonly accepted notions lack a sufficient basis.

It would seem to me that one of these subtle errors applies to the historical
natural language conclusions that are formed on the basis of the Halting
Problem, and its equivalents. One of the problems that I see with this
historical framework is the artificial requirement that the result must be
construed as Boolean. It would seem to follow that a program must either halt or
fail to halt, thus a Boolean would seem to correspond to the only possible
result type. Whether or not a tertiary result type might be more appropriate has
never been fully explored, because it would seem to violate common sense.

The other problem with the natural language conclusions pertaining to the
Halting Problem and its equivalents has to do with the subtle precise meaning of
words and expressions. If one takes the historical definition of the problem
artificially constrained to providing a Boolean result, then one can correctly
conclude that a case can be constructed such that a Halt() function can not
provide a correct Boolean result. It can not provide a correct Boolean result
specifically because of the malignant self referential structure of the problem.

The inability to provide a correct Boolean result has been misconstrued to mean
that there are some problems that can never be solved, because there exists a
case of malignant self-reference where a correct Boolean result can not be
provided.

It is this last statement where the primary issue arises. The conclusion does
not logically follow from the premises. There is a subtle fallacy of
equivocation error in the forming of this conclusion. Every point that I have
ever made on this subject boils down to this one single issue. In order to fully
see what I am saying, one must treat natural language much more like a
mathematical formalism, otherwise subtle fallacies of equivocation enter the
analysis.

>
>>
>>> To try to understand, I'd like to nail down some terminology and program
>>> names. http://www.mtnmath.com/whatrh/node49.html contains a simplified
>>> version of the proof.
>>>
>>> Could you explain, in the terminology of that page, how h would detect a
>>> situation in which it should throw the exception.
>>>
>>> Patricia
>>

 0
NoSpam266 (508)
10/17/2006 2:07:51 PM
"Charlie-Boo" <shymathguy@gmail.com> wrote in message
>
> Peter Olcott wrote:
>> <sillybanter@gmail.com> wrote in message news:MtsYg.9714$gx6.5379@trnddc05... >> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> >> "William Elliot" <marsh@hevanet.remove.com> wrote in message >> >> news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com... >> >> > On Sun, 15 Oct 2006, Peter Olcott wrote: >> >> > >> >> >> The Halt program throws an "Invalid Input" exception. >> >> >> This would be analogous to the hardware exception of an attempt to >> >> >> divide >> >> >> by >> >> >> zero. >> >> >> >> >> > Error 001: Invalid input. Please try again. >> >> >> >> The point is there are not any questions too difficult for logic to >> >> correctly >> >> answer, logic itself is not incomplete as Kurt Godel proposed. There are >> >> merely >> >> some questions where the question itself is ill-formed. >> > >> > Brilliant. By defining any unsolvable problems as "ill-formed" then >> > we can say that all "well-formed" questions are solvable. No more >> > unsolvable problems! >> > >> Since the only reason that these problems are unsolvable is because they are >> ill-formed, this makes perfect sense. To see it any other way would be like >> me >> saying that you don't even know how to tell the time of day because of your >> inability to correctly answer the following question; What time is it blue or >> green? > > Neither. > > What's the prize? Since you did not provide an answer from the set of possible choices your answer is incorrect. Bertrand Russell's Barber Paradox has this same essential structure. > > C-B > >> > Advancement of science by changing definitions. Gotta love it. >> > >> > -- >> > >> > Steve Stringer >> > sillybanter@gmail.com >> > >  0 NoSpam266 (508) 10/17/2006 2:12:00 PM William Elliot wrote: > On Tue, 17 Oct 2006, Patricia Shanahan wrote: >> Peter Olcott wrote: > >>> Yes! In the atypical instance of the Halting Problem the called can >>> know in advance both that its actions will effect the caller, and >>> exactly how its actions will effect the caller. Because it has this >>> information in advance it can decide what to do about it, and thereby >>> effect the total outcome. >> HOW does h know "exactly how its actions will affect this caller"? All >> it knows is its caller has fed it a number, and asked "Is this the >> Goedel number of a computation that halts?". We know that the TM in that >> computation uses a copy of h as part of its source code, but it could be >> obfuscated. >> > Here's a halting algorithm for OP to lament upon. > 1) OP, to prove the validity of his notion, will always ignore or > misconstrue your comments. > 2) No matter what you say or do, the results will be the same, OP > notions is always correct. It can not, will not ever be else. > 3) The program of you replying and OP stringing you along won't > halt. > 4) Therefore, output is not-halt. > > Thus the algorithm, as the algorithm has put out output, has halted. > Then, dear Patricia, upon the futility of your expert efforts, do you > HALT! You're right. Peter Olcott posted a message that was formatted as though it were a reply to a very specific question I asked in my last message, but had nothing at all to do with the question. There is no point posting any more in this thread until he answers that question. Patricia  0 pats (3556) 10/17/2006 2:30:01 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:JN5Zg.14870$UG4.10019@newsread2.news.pas.earthlink.net...
> William Elliot wrote:
>> On Tue, 17 Oct 2006, Patricia Shanahan wrote:
>>> Peter Olcott wrote:
>>
>>>> Yes!  In the atypical instance of the Halting Problem the called can
>>>> know in advance both that its actions will effect the caller, and
>>>> exactly how its actions will effect the caller. Because it has this
>>>> information in advance it can decide what to do about it, and thereby
>>>> effect the total outcome.
>>> HOW does h know "exactly how its actions will affect this caller"? All
>>> it knows is its caller has fed it a number, and asked "Is this the
>>> Goedel number of a computation that halts?". We know that the TM in that
>>> computation uses a copy of h as part of its source code, but it could be
>>> obfuscated.
>>>
>> Here's a halting algorithm for OP to lament upon.
>> 1)  OP, to prove the validity of his notion, will always ignore or
>> 2)  No matter what you say or do, the results will be the same, OP
>> notions is always correct.  It can not, will not ever be else.
>> 3)  The program of you replying and OP stringing you along won't
>> halt.
>> 4)  Therefore, output is not-halt.
>>
>> Thus the algorithm, as the algorithm has put out output, has halted.
>> Then, dear Patricia, upon the futility of your expert efforts, do you
>> HALT!
>
> You're right. Peter Olcott posted a message that was formatted as though
> it were a reply to a very specific question I asked in my last message,
> but had nothing at all to do with the question.
>
> There is no point posting any more in this thread until he answers that
> question.
>
> Patricia

Take a look at the last reply that I just made to you. It sums up my whole
point.

 0
NoSpam266 (508)
10/17/2006 2:55:17 PM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:zRXYg.10503$Y24.7729@newsread4.news.pas.earthlink.net... > Peter Olcott wrote: >> "Patricia Shanahan" <pats@acm.org> wrote in message >> news:_FWYg.7998$Lv3.6750@newsread1.news.pas.earthlink.net...
>>> Peter Olcott wrote:
>>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>>>> news:hHTYg.7886$Lv3.7266@newsread1.news.pas.earthlink.net... >>>>> Peter Olcott wrote: >>>>>> "Patricia Shanahan" <pats@acm.org> wrote in message >>>>>> news:qfOYg.14496$UG4.1437@newsread2.news.pas.earthlink.net...
>>>>>>> Peter Olcott wrote:
>>>>>>> ....
>>>>>>>> To frame the exception handling mechanism within the historical context
>>>>>>>> of a Turing Machine we only need to establish three integer values
>>>>>>>> mapped to three different semantic meanings:
>>>>>>>> 0=NOT_HALTS   1=HALTS    2= INVALID_INPUT. The input is invalid in each
>>>>>>>> and every case where providing the result of the determination of
>>>>>>>> halting derives a different execution trace, thus changing the result.
>>>>>>> Yes, but what is the algorithm for determining whether the result of the
>>>>>>> determination of halting derives a different execution trace?
>>>>>> You have it incorrectly, the result does not provide a different
>>>>>> execution trace. It is the act of providing this result that derives the
>>>>>> different execution trace. Halt() can determine that the test program
>>>>>> will halt, it merely can not provide the results of this determination to
>>>>>> the caller in this case. Halt() determines that providing the results of
>>>>>> its correct and complete analysis is used to alter the execution trace,
>>>>>> thus forming a different execution trace than the one that is the subject
>>>>>> of the test.
>>>>> Are you saying that the behavior of the algorithm depends on what its
>>>>> caller is going to do with the result? If so, that is a far bigger change
>>>>> in the concept of algorithm than merely adding exceptions.
>>>> The difficulty of the Halting Problem is that because of its infinitely
>>>> recursive structure it is very difficult to see that the typical common
>>>> sense assumptions that apply to nearly every other algorithm do not apply
>>>> to this one. One of the most significant aspects of this atypical case, is
>>>> that in the very unusual case of the Halting Problem, a function can see
>>>> exactly how it is being called, and the effects of any actions that it
>>>> takes upon its own caller.
>>>>
>>>> Within the specification of the Halting Problem, the Halt() function and
>>>> its caller combined together form the program under test. In this case the
>>>> behavior of one of the constituent parts (the Halt() function) forms the
>>>> basis for the behavior of the other constituent part (the caller). Since
>>>> this structure is directly presented to the Halt() function as input, the
>>>> Halt() function can see exactly what its caller intends to do with any
>>>> result that it provides (or actions that it takes).
>>>>
>>>> So the Halt() function breaks out of this otherwise infinitely recursive
>>>> structure and provides the only possible correct answer given the
>>>> specification of this problem: it throws the INVALID_INPUT exception. The
>>>> Turing Machine equivalent of this would be halting with the ReadWrite Head
>>>> of its tape positioned at a token indicating the semantic meaning of
>>>> INVALID_INPUT.
>>> I'm not sure whether all that means "yes" or "no".
>>
>>
>> Are you saying that the behavior of the algorithm depends on what its caller
>>  is going to do with the result?
>>
>> Yes!  In the atypical instance of the Halting Problem the called can know in
>> advance both that its actions will effect the caller, and  exactly how its
>> actions will effect the caller. Because it has this information in advance it
>> can decide what to do about it, and thereby effect the total outcome.
>
> HOW does h know "exactly how its actions will affect this caller"? All
> it knows is its caller has fed it a number, and asked "Is this the
> Goedel number of a computation that halts?". We know that the TM in that
> computation uses a copy of h as part of its source code, but it could be
> obfuscated.

//
//  To make the problem more clear we are assuming:
//  (a) a purely interpreted language
//  (b) function call syntax results in inline expansion,
//       thus specifying the name of a function specifies
//       the body of the function.
//

void LoopIfHalts(string SourceCode)  {
if ( WillHalt(SourceCode, SourceCode) == TRUE )
while (TRUE)    // loop forever
;
else
return;
}

int WillHalt(string SourceCode, string InputData)   {

if (NotValid(SourceCode, InputData))
throw(INVALID_INPUT);

if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

LoopIfHalts(LoopIfHalts);

Within the context of this framework WillHalt() can see how it will be called
when the SourceCode of LoopIfHalts is fed to it as input, and thus see in
advance how its return value will used for malignant self-reference. Because it

>
>
>>
>>> To try to understand, I'd like to nail down some terminology and program
>>> names. http://www.mtnmath.com/whatrh/node49.html contains a simplified
>>> version of the proof.
>>>
>>> Could you explain, in the terminology of that page, how h would detect a
>>> situation in which it should throw the exception.
>>>
>>> Patricia
>>

 0
NoSpam266 (508)
10/17/2006 3:05:13 PM
Peter Olcott wrote:
> The Halt program throws an "Invalid Input" exception.
> This would be analogous to the hardware exception of an attempt to divide by
> zero.

Are you aware of the fact that the Clay Institute offers a $1 million reward for anyone who solves the Halting Problem? Alan Turing wasn't able to and nobody has ever solved it since (except when using a Computationally Based Logic). (I think Chaitin came closest by using a special number that vaporizes as soon as you so much as think about it. Bit # N = whether or not I will prove that I am not thinking about Chaitin at point in time N in the future. (I hope I get all zeros.)) C-B -HALT(I,J)* The Halting Problem is Unsolvable 1. NO(x,x) Known 2. HALT(I,J)* PREMISE 3. HALT(I,I)* SUB 2 4. ~HALT(I,I)* NOT 3 5. ~HALT(X,X) TRUE (THM) Peano 4 6. NO(X,X)v~HALT(X,X) UNION 1,5 7. ~YES(X,X) LIne 6 given CONS qed -~YES(x,x) is the Incompleteness Axiom - more generally -~P/P where general CBL is M # P / Q and the Theory of Computation is - X / YES : output all non-r.e. sets. Also X / YES : Output all r.e. sets. -~YES(x,x) The set of programs that don't halt yes on themselves is not r.e. 1. ~YES(x,x) Premise 2. M # ~YES(x,x) There must be a program that enumerates the set. 3. YES(M,a) , ~YES(a,a) A1 expr => DEF (syntax) 4. YES(M,M) , ~YES(M,M) SUB 3 5. P , ~P SUB 4 qed -P,~P is a basic axiom.  0 shymathguy (92) 10/17/2006 4:14:31 PM In article <Vt5Zg.8306$eZ4.1179@dukeread06>,
Peter Olcott <NoSpam@SeeScreen.com> wrote:
> [...] If one takes the historical definition of the problem
>artificially constrained to providing a Boolean result, then one can correctly
>conclude that a case can be constructed such that a Halt() function can not
>provide a correct Boolean result. It can not provide a correct Boolean result
>specifically because of the malignant self referential structure of the problem.

It isn't the Halting Problem itself that is "malignant" or "self-
referential", not anyway in its usual formulation or the related proofs.
Rather, it is one *specific* instance of a very similar problem, constructed
so as to "bust" a *specific* purported "Halt()" function.  For each potential
"Halt()" function, there exists a corresponding buster;  the conclusion is
that no such function can be correct.

>The inability to provide a correct Boolean result has been misconstrued to mean
>that there are some problems that can never be solved, because there exists a
>case of malignant self-reference where a correct Boolean result can not be
>provided.

There is no specific instance of the HP that can never be solved,
for an emulator that ran for sufficiently long would solve it;  sadly,
"sufficiently long" is not computable by means of a fixed, specific
algorithm [otherwise the HP would be solvable].  Also there is no great
difficulty in providing the correct results for the "buster" instances.
The problem is that the "busted" solver cannot itself do this;  and if
you write bigger and better solvers that can, then they in turn have
bigger and better "busters" that they cannot resolve.

Whether allowing more results is interesting or helpful is quite
another matter.  But it is not going to resolve the fundamental problem
underlying the HP -- that there is only a limited amount of information
that a specific program/algorithm [within the limitations of computing
and programming as usually understood] can determine about programs in
general, and that this information cannot reliably include such things
as whether or not the program halts, whether control ever passes to line
123, whether it ever prints "Hello, world!", whether it ever reads from
its input [in the usual, not the Turing Machine, sense], and so on.

for which these questions [in particular] can all be answered.  Indeed,
they can all be answered by a quite simple program.  But you may, in
practice, have to wait beyond the heat death of the Universe -- not a
problem for mathematics, only for mathematicians [and other real people].

--
Andy Walker, School of MathSci., Univ. of Nott'm, UK.
anw@maths.nott.ac.uk
 0
anw (25)
10/17/2006 4:23:58 PM
"Charlie-Boo" <shymathguy@gmail.com> wrote in message
> Peter Olcott wrote:
>> The Halt program throws an "Invalid Input" exception.
>> This would be analogous to the hardware exception of an attempt to divide by
>> zero.
>
> Are you aware of the fact that the Clay Institute offers a 1 million > reward for anyone who solves the Halting Problem? Alan Turing wasn't > able to and nobody has ever solved it since (except when using a > Computationally Based Logic). > > (I think Chaitin came closest by using a special number that vaporizes > as soon as you so much as think about it. Bit # N = whether or not I > will prove that I am not thinking about Chaitin at point in time N in > the future. (I hope I get all zeros.)) > > C-B > > -HALT(I,J)* The Halting Problem is Unsolvable > 1. NO(x,x) Known > 2. HALT(I,J)* PREMISE > 3. HALT(I,I)* SUB 2 > 4. ~HALT(I,I)* NOT 3 > 5. ~HALT(X,X) TRUE (THM) Peano 4 > 6. NO(X,X)v~HALT(X,X) UNION 1,5 > 7. ~YES(X,X) LIne 6 given CONS > qed > > -~YES(x,x) is the Incompleteness Axiom - more generally -~P/P where > general CBL is M # P / Q and the Theory of Computation is - X / YES : > output all non-r.e. sets. Also X / YES : Output all r.e. sets. > > -~YES(x,x) The set of programs that don't halt yes on themselves is > not r.e. > 1. ~YES(x,x) Premise > 2. M # ~YES(x,x) There must be a program that enumerates the set. > 3. YES(M,a) , ~YES(a,a) A1 expr => DEF (syntax) > 4. YES(M,M) , ~YES(M,M) SUB 3 > 5. P , ~P SUB 4 > qed > > -P,~P is a basic axiom. > Here is my closest approximation so far. // // To make the problem more clear we are assuming: // (a) a purely interpreted language // (b) function call syntax results in inline expansion, // thus specifying the name of a function specifies // the text body of the function. // void LoopIfHalts(string SourceCode) { if ( WillHalt(SourceCode, SourceCode) == TRUE ) while (TRUE) // loop forever ; else return; } int WillHalt(string SourceCode, string InputData) { if (NotValid(SourceCode, InputData)) throw(INVALID_INPUT); if ( TheProgramWillHalt(SourceCode, InputData) ) return TRUE; else return FALSE; } LoopIfHalts(LoopIfHalts); The INVALID_INPUT exception indicates that WillHalt() has detected a case of malignant self-reference where the result of its analysis is fed back into the analysis to change the result. This does not indicate that WillHalt() is unable to correctly derive the halt status of the universal set of programs. It only means that there exists at least one malignant case of self-reference where it can not provide the results of its correct and complete analysis as a return value.  0 NoSpam266 (508) 10/17/2006 4:32:53 PM Charlie-Boo wrote: > Peter Olcott wrote: >> The Halt program throws an "Invalid Input" exception. >> This would be analogous to the hardware exception of an attempt to divide by >> zero. > > Are you aware of the fact that the Clay Institute offers a1 million
> reward for anyone who solves the Halting Problem?  Alan Turing wasn't
> able to and nobody has ever solved it since (except when using a
> Computationally Based Logic).

I was not aware of that. The list of millennium challenge problems at
http://www.claymath.org/millennium/ is:

* Birch and Swinnerton-Dyer Conjecture
* Hodge Conjecture
* Navier-Stokes Equations
* P vs NP
* Poincar� Conjecture
* Riemann Hypothesis
* Yang-Mills Theory

Patricia
 0
pats (3556)
10/17/2006 4:55:42 PM
"Dr A. N. Walker" <anw@maths.nott.ac.uk> wrote in message
news:eh302u$pvn$1@oyez.ccc.nottingham.ac.uk...
> In article <Vt5Zg.8306eZ4.1179@dukeread06>, > Peter Olcott <NoSpam@SeeScreen.com> wrote: >> [...] If one takes the historical definition of the problem >>artificially constrained to providing a Boolean result, then one can correctly >>conclude that a case can be constructed such that a Halt() function can not >>provide a correct Boolean result. It can not provide a correct Boolean result >>specifically because of the malignant self referential structure of the >>problem. > > It isn't the Halting Problem itself that is "malignant" or "self- > referential", not anyway in its usual formulation or the related proofs. > Rather, it is one *specific* instance of a very similar problem, constructed > so as to "bust" a *specific* purported "Halt()" function. For each potential > "Halt()" function, there exists a corresponding buster; the conclusion is > that no such function can be correct. I thought that the "problem" part of the term "Halting Problem" was directly referring to the existence of this case of malignant self-reference such that it appears to defeat attempts to determine whether or not any program in the set of all programs, halts. > >>The inability to provide a correct Boolean result has been misconstrued to >>mean >>that there are some problems that can never be solved, because there exists a >>case of malignant self-reference where a correct Boolean result can not be >>provided. > > There is no specific instance of the HP that can never be solved, > for an emulator that ran for sufficiently long would solve it; sadly, > "sufficiently long" is not computable by means of a fixed, specific > algorithm [otherwise the HP would be solvable]. Also there is no great > difficulty in providing the correct results for the "buster" instances. > The problem is that the "busted" solver cannot itself do this; and if > you write bigger and better solvers that can, then they in turn have > bigger and better "busters" that they cannot resolve. > > Whether allowing more results is interesting or helpful is quite > another matter. But it is not going to resolve the fundamental problem > underlying the HP -- that there is only a limited amount of information > that a specific program/algorithm [within the limitations of computing > and programming as usually understood] can determine about programs in > general, and that this information cannot reliably include such things > as whether or not the program halts, My primary point is based on the subtle distinction between your precise statement of the conclusions that can be drawn from the HP, and the actual correct conclusions that can actually be drawn. It is apparently a very subtle fallacy of equivocation that people have continued to make for generations. One must treat English as a mathematical formalism to avoid having the next point slip right past the mind's ability to grasp it: The HP does not show any limitation what-so-ever to the capability to determine the halting status of any program. All that the HP shows is that there exists some cases of malignant self-reference where this determination can not be provided as a return value to a caller. > whether control ever passes to line > 123, whether it ever prints "Hello, world!", whether it ever reads from > its input [in the usual, not the Turing Machine, sense], and so on. > > This is quite different from asking about some specific program, > for which these questions [in particular] can all be answered. Indeed, > they can all be answered by a quite simple program. But you may, in > practice, have to wait beyond the heat death of the Universe -- not a > problem for mathematics, only for mathematicians [and other real people]. > > -- > Andy Walker, School of MathSci., Univ. of Nott'm, UK. > anw@maths.nott.ac.uk  0 NoSpam266 (508) 10/17/2006 6:36:22 PM There is a possible misunderstanding here about G=F6del's results. G=F6del didn't propose that logic is incomplete, he proved that logic cannot be entirely included in a formal system. This is a limit of formal systems, not of logic. Consequently, there's not much to worry about. Regards. Peter Olcott wrote: > "William Elliot" <marsh@hevanet.remove.com> wrote in message > news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com... > > On Sun, 15 Oct 2006, Peter Olcott wrote: > > > >> The Halt program throws an "Invalid Input" exception. > >> This would be analogous to the hardware exception of an attempt to div= ide by > >> zero. > >> > > Error 001: Invalid input. Please try again. > > The point is there are not any questions too difficult for logic to corre= ctly > answer, logic itself is not incomplete as Kurt Godel proposed. There are = merely > some questions where the question itself is ill-formed. > > > > > -- > > Won't we just love voice responding software? > > Just imagine a sexy female voice saying, > > "I'm sorry, invalid input. Please try again." > > > > Other favorites are > > "Hang on while I try that extension." > > "Or press one for more options." > > > > But damn, the last victimized buyer of that voice answering system I > > noticed didn't get a sexy female voice saying > > "Or press one for more options." > > Just an ordinary female voice. > > > > Riddle of the day. Have you given your life over to automation?  0 10/17/2006 7:10:46 PM I will frame this in the terms of the Halting Problem because I understand computer science much more deeply than math. The Halting Problem does not show that a universal halt detector can not be constructed that correctly determines whether or not any element in the set of all programs halts. It does not show this at all. What it does show is that there exists some cases of malignant self-reference where a universal halt detector is unable to provide its correct determination to a caller. It can not provide this correct determination to a caller in the case of malignant self-reference, because it can determine that malignant self-reference exists, and thus the act of returning this result (not the act of determining the result) is used by the caller to change the result. "LauLuna" <laureanoluna@yahoo.es> wrote in message news:1161112246.551042.42700@e3g2000cwe.googlegroups.com... There is a possible misunderstanding here about G�del's results. G�del didn't propose that logic is incomplete, he proved that logic cannot be entirely included in a formal system. This is a limit of formal systems, not of logic. Consequently, there's not much to worry about. Regards. Peter Olcott wrote: > "William Elliot" <marsh@hevanet.remove.com> wrote in message > news:Pine.BSI.4.58.0610150722520.7240@vista.hevanet.com... > > On Sun, 15 Oct 2006, Peter Olcott wrote: > > > >> The Halt program throws an "Invalid Input" exception. > >> This would be analogous to the hardware exception of an attempt to divide > >> by > >> zero. > >> > > Error 001: Invalid input. Please try again. > > The point is there are not any questions too difficult for logic to correctly > answer, logic itself is not incomplete as Kurt Godel proposed. There are > merely > some questions where the question itself is ill-formed. > > > > > -- > > Won't we just love voice responding software? > > Just imagine a sexy female voice saying, > > "I'm sorry, invalid input. Please try again." > > > > Other favorites are > > "Hang on while I try that extension." > > "Or press one for more options." > > > > But damn, the last victimized buyer of that voice answering system I > > noticed didn't get a sexy female voice saying > > "Or press one for more options." > > Just an ordinary female voice. > > > > Riddle of the day. Have you given your life over to automation?  0 NoSpam266 (508) 10/17/2006 7:24:43 PM 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  0 jazzmobe (307) 10/17/2006 9:02:41 PM "MoeBlee" <jazzmobe@hotmail.com> wrote in message news:1161118961.027553.142520@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.  0 NoSpam266 (508) 10/17/2006 9:23:32 PM 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. MoeBlee  0 jazzmobe (307) 10/17/2006 11:00:35 PM "MoeBlee" <jazzmobe@hotmail.com> wrote in message news:1161126035.398008.237140@i3g2000cwc.googlegroups.com... > 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. > > MoeBlee > The "Halting Problem" is about "Halting". The mathematics is an attempt to create a mathematical formalism that corresponds to the concept of halting.  0 NoSpam266 (508) 10/17/2006 11:09:19 PM Peter Olcott wrote: > "MoeBlee" <jazzmobe@hotmail.com> wrote in message > news:1161126035.398008.237140@i3g2000cwc.googlegroups.com... > > 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. > > > > MoeBlee > > > > The "Halting Problem" is about "Halting". The mathematics is an attempt to > create a mathematical formalism that corresponds to the concept of halting. The halting of a Turing machine, which is not a physical computer, but rather is a mathematical object. MoeBlee  0 jazzmobe (307) 10/17/2006 11:14:28 PM "MoeBlee" <jazzmobe@hotmail.com> wrote in message news:1161126868.246164.277940@e3g2000cwe.googlegroups.com... > Peter Olcott wrote: >> "MoeBlee" <jazzmobe@hotmail.com> wrote in message >> news:1161126035.398008.237140@i3g2000cwc.googlegroups.com... >> > 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. >> > >> > MoeBlee >> > >> >> The "Halting Problem" is about "Halting". The mathematics is an attempt to >> create a mathematical formalism that corresponds to the concept of halting. > > The halting of a Turing machine, which is not a physical computer, but > rather is a mathematical object. > > MoeBlee > A mathematical abstraction that could be represented as an actual physical device.  0 NoSpam266 (508) 10/17/2006 11:24:40 PM 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  0 pats (3556) 10/17/2006 11:28:31 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:zGdZg.15330UG4.11773@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.

 0
NoSpam266 (508)
10/17/2006 11:35:36 PM
Peter Olcott wrote:
> A mathematical abstraction that could be represented as an actual physical
> device.

Approximations by a physical device. No physical object is a Turing
machine. A Turing machine is a mathematical object.

MoeBlee

 0
jazzmobe (307)
10/17/2006 11:46:32 PM
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

 0
jazzmobe (307)
10/17/2006 11:50:27 PM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>> 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?

--
Ben.
 0
ben.usenet (6790)
10/18/2006 12:03:19 AM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> Peter Olcott wrote:
>> A mathematical abstraction that could be represented as an actual physical
>> device.
>
> Approximations by a physical device. No physical object is a Turing
> machine. A Turing machine is a mathematical object.
>
> MoeBlee
>
Yes, we aren't ever going to see the infinite tape storage.

 0
NoSpam266 (508)
10/18/2006 12:12:35 AM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> 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?

 0
NoSpam266 (508)
10/18/2006 12:16:30 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:878xjetrqw.fsf@bsb.me.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>> 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?
>
> --
> Ben.

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" ??

 0
NoSpam266 (508)
10/18/2006 12:18:49 AM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:878xjetrqw.fsf@bsb.me.uk...
>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>
>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>> 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

--
Ben.
 0
ben.usenet (6790)
10/18/2006 12:28:17 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:874pu2tqla.fsf@bsb.me.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:878xjetrqw.fsf@bsb.me.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>
>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>>> 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.
>
> --
> Ben.

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. What would it take for you to think that you
might be wrong?  (How open or closed it your mind?)

 0
NoSpam266 (508)
10/18/2006 12:37:08 AM
Peter Olcott wrote:
> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
> > 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.

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

 0
jazzmobe (307)
10/18/2006 12:41:25 AM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> Peter Olcott wrote:
>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>> > 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.

Let's start with just one, that will (hopefully) get us on the same page more
quickly:
[functioning correctly] would mean that a software function consistently
produces the results that it was designed to achieve.

>
> 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
>

 0
NoSpam266 (508)
10/18/2006 12:52:51 AM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> Peter Olcott wrote:
>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>> > 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.

Its not just a theorem, it also has the practical consequence of placing
(artificial) limits on eventual real world computation.

>
> 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
>

 0
NoSpam266 (508)
10/18/2006 1:00:34 AM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:874pu2tqla.fsf@bsb.me.uk...
>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:878xjetrqw.fsf@bsb.me.uk...
>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>
>>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>>>> 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

> 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.

--
Ben.
 0
ben.usenet (6790)
10/18/2006 3:10:35 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:87slhmqpxw.fsf@bsb.me.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:874pu2tqla.fsf@bsb.me.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>
>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>> news:878xjetrqw.fsf@bsb.me.uk...
>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>>
>>>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>>>>> 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
>
>> 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.
>
> --
> Ben.

I am not using that model, I am using a model comparable to the above link.

 0
NoSpam266 (508)
10/18/2006 3:26:58 AM
In sci.logic, Peter Olcott
<NoSpam@SeeScreen.com>
wrote
on Mon, 16 Oct 2006 01:40:42 -0500
<OPFYg.7971$eZ4.5217@dukeread06>: > > "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message > news:5geb04-pa.ln1@sirius.tg00suus7038.net... >> In sci.logic, Peter Olcott >> <NoSpam@SeeScreen.com> >> wrote >> on Sun, 15 Oct 2006 22:40:02 -0500 >> <laDYg.7965$eZ4.1292@dukeread06>:
>>>
>>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
>>> news:e7aa04-32t.ln1@sirius.tg00suus7038.net...
>>>> In sci.logic, Peter Olcott
>>>> <NoSpam@SeeScreen.com>
>>>> wrote
>>>> on Sun, 15 Oct 2006 12:38:39 -0500
>>>> <AmuYg.7908$eZ4.5473@dukeread06>: >>>>> >>>>> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message >>>>> news:vp2a04-lfs.ln1@sirius.tg00suus7038.net... >>>>>> In sci.logic, Peter Olcott >>>>>> <NoSpam@SeeScreen.com> >>>>>> wrote >>>>>> on Sun, 15 Oct 2006 09:19:52 -0500 >>>>>> <csrYg.7886$eZ4.2645@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?
>>
>> 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);

return p;
}

which will never terminate.  In fact notLargestPrime() probably won't
terminate.  But how would a halting algorithm know this mathematical
truism?

Another one, of course, is:

boolean findRationalApproximationSqrt(unsigned n, unsigned & p, unsigned & q)
{
for(q = 1; ; q ++)
{
for(p = 1; p < n * q; p++)
{
if(p * p = n * q * q)
{
return true;
}
}
}
}

Will this return a value or loop until one pulls the plug?

Of course one can implement a halting function if one's allowed to throw
an exception.  It's trivial, in fact:

boolean HTest(funcptr p, Object[] args) throws ICannotTellException
{
throw new ICannotTellException();
}

Voila...a function that correctly predicts whether a function on an
argument list will halt or not, when it's not throwing an exception.

(Since it always does, this particular function is slightly pointless.)

[rest snipped]

--
"640K ought to be enough for anybody."
- allegedly said by Bill Gates, 1981, but somebody had to make this up!

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

 0
ewill5 (11075)
10/18/2006 4:01:47 AM
In sci.logic, Peter Olcott
<NoSpam@SeeScreen.com>
wrote
on Tue, 17 Oct 2006 11:32:53 -0500
<UA7Zg.8314$eZ4.3841@dukeread06>: > > "Charlie-Boo" <shymathguy@gmail.com> wrote in message > news:1161101671.273314.18520@h48g2000cwc.googlegroups.com... >> Peter Olcott wrote: >>> The Halt program throws an "Invalid Input" exception. >>> This would be analogous to the hardware exception of an attempt to divide by >>> zero. >> >> Are you aware of the fact that the Clay Institute offers a$1 million
>> reward for anyone who solves the Halting Problem?  Alan Turing wasn't
>> able to and nobody has ever solved it since (except when using a
>> Computationally Based Logic).
>>
>> (I think Chaitin came closest by using a special number that vaporizes
>> as soon as you so much as think about it.  Bit # N = whether or not I
>> will prove that I am not thinking about Chaitin at point in time N in
>> the future.  (I hope I get all zeros.))
>>
>> C-B
>>
>>   -HALT(I,J)*  The Halting Problem is Unsolvable
>> 1. NO(x,x)   Known
>> 2. HALT(I,J)*   PREMISE
>> 3. HALT(I,I)*   SUB 2
>> 4. ~HALT(I,I)*   NOT 3
>> 5. ~HALT(X,X)      TRUE (THM)   Peano 4
>> 6. NO(X,X)v~HALT(X,X)   UNION 1,5
>> 7. ~YES(X,X)   LIne 6 given CONS
>>   qed
>>
>> -~YES(x,x) is the Incompleteness Axiom - more generally -~P/P where
>> general CBL is M # P / Q and the Theory of Computation is - X / YES :
>> output all non-r.e. sets.  Also X / YES : Output all r.e. sets.
>>
>>  -~YES(x,x)  The set of programs that don't halt yes on themselves is
>> not r.e.
>> 1. ~YES(x,x)   Premise
>> 2. M # ~YES(x,x)   There must be a program that enumerates the set.
>> 3. YES(M,a) , ~YES(a,a)   A1 expr => DEF (syntax)
>> 4. YES(M,M) , ~YES(M,M)   SUB 3
>> 5. P , ~P   SUB 4
>>  qed
>>
>> -P,~P is a basic axiom.
>>
>
> Here is my closest approximation so far.
>
> //
> //  To make the problem more clear we are assuming:
> //  (a) a purely interpreted language
> //  (b) function call syntax results in inline expansion,
> //       thus specifying the name of a function specifies
> //       the text body of the function.
> //
>
>
> void LoopIfHalts(string SourceCode)  {
>      if ( WillHalt(SourceCode, SourceCode) == TRUE )
>         while (TRUE)    // loop forever
>             ;
>      else
>         return;
> }
>
>
> int WillHalt(string SourceCode, string InputData)   {
>     if (NotValid(SourceCode, InputData))
>         throw(INVALID_INPUT);
>     if ( TheProgramWillHalt(SourceCode, InputData) )
>         return TRUE;
>     else
>         return FALSE;
> }
>
>
> LoopIfHalts(LoopIfHalts);
>
> The INVALID_INPUT exception indicates that WillHalt() has detected a case of
> malignant self-reference where the result of its analysis is fed back into the
> analysis to change the result. This does not indicate that WillHalt() is unable
> to correctly derive the halt status of the universal set of programs. It only
> means that there exists at least one malignant case of self-reference where it
> can not provide the results of its correct and complete analysis as a return
> value.
>

OK.  And what's to prevent LoopIfHalts from using a nearly exact *copy* of
TheProgramWillHalt() in its implementation?  There's an indefinite
number of modifications to a program that can be contemplated -- if
nothing else, one can assign an arbitrary number to an unused local
variable.

But there are a fair number of other modification methods: loop
unrolling, variable name changes, using an int where a boolean
would be sufficient, exchanging leftshift and * or rightshift and /,
bitflipping

v2 = v XOR 2^n

versus

if(floor(v / 2^n) mod 2 == 0) then v2 = v + 2^n; else v2 = v - 2^n;

etc.

--
Useless C++ Programming Idea #992398129:
unsigned u; if(u < 0) ...

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

 0
ewill5 (11075)
10/18/2006 4:09:05 AM
In sci.logic, MoeBlee
<jazzmobe@hotmail.com>
wrote
on 17 Oct 2006 17:41:25 -0700
> Peter Olcott wrote:
>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>> > 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
>

--
Useless C++ Programming Idea #992398129:
unsigned u; if(u < 0) ...

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

 0
ewill5 (11075)
10/18/2006 4:18:43 AM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:87slhmqpxw.fsf@bsb.me.uk...
>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:874pu2tqla.fsf@bsb.me.uk...
>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>
>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>>> news:878xjetrqw.fsf@bsb.me.uk...
>>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>>>
>>>>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>>>>>> 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
>>
>>> 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

--
Ben.
 0
ben.usenet (6790)
10/18/2006 4:32:54 AM
Peter Olcott wrote:
> "Patricia Shanahan" <pats@acm.org> wrote in message
> news:zGdZg.15330UG4.11773@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  0 pats (3556) 10/18/2006 4:45:20 AM "Peter Olcott" <NoSpam@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  0 smaill1 (89) 10/18/2006 9:46:48 AM "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:87lkneqm4p.fsf@bsb.me.uk... > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > >> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >> news:87slhmqpxw.fsf@bsb.me.uk... >>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>> >>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >>>> news:874pu2tqla.fsf@bsb.me.uk... >>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>>>> >>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >>>>>> news:878xjetrqw.fsf@bsb.me.uk... >>>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>>>>>> >>>>>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message >>>>>>>> news:1161118961.027553.142520@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.  0 NoSpam266 (508) 10/18/2006 12:01:33 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:AjiZg.10941Y24.524@newsread4.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> news:zGdZg.15330UG4.11773@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.  0 NoSpam266 (508) 10/18/2006 12:19:43 PM "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message news:fwezmbu0xdj.fsf@collins.inf.ed.ac.uk... > "Peter Olcott" <NoSpam@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 http://www.cprogramming.com/tutorial/computersciencetheory/halting.html None-the-less it is this mode that I am using in my investigation. I understand Turing Machines, and UTM's, both of these would mathematically map to this alternative model.  0 NoSpam266 (508) 10/18/2006 12:22:31 PM "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message news:10mg04-kc6.ln1@sirius.tg00suus7038.net... > In sci.logic, Peter Olcott > <NoSpam@SeeScreen.com> > wrote > on Tue, 17 Oct 2006 11:32:53 -0500 > <UA7Zg.8314eZ4.3841@dukeread06>:
>>
>> "Charlie-Boo" <shymathguy@gmail.com> wrote in message
>>> Peter Olcott wrote:
>>>> The Halt program throws an "Invalid Input" exception.
>>>> This would be analogous to the hardware exception of an attempt to divide
>>>> by
>>>> zero.
>>>
>>> Are you aware of the fact that the Clay Institute offers a 1 million >>> reward for anyone who solves the Halting Problem? Alan Turing wasn't >>> able to and nobody has ever solved it since (except when using a >>> Computationally Based Logic). >>> >>> (I think Chaitin came closest by using a special number that vaporizes >>> as soon as you so much as think about it. Bit # N = whether or not I >>> will prove that I am not thinking about Chaitin at point in time N in >>> the future. (I hope I get all zeros.)) >>> >>> C-B >>> >>> -HALT(I,J)* The Halting Problem is Unsolvable >>> 1. NO(x,x) Known >>> 2. HALT(I,J)* PREMISE >>> 3. HALT(I,I)* SUB 2 >>> 4. ~HALT(I,I)* NOT 3 >>> 5. ~HALT(X,X) TRUE (THM) Peano 4 >>> 6. NO(X,X)v~HALT(X,X) UNION 1,5 >>> 7. ~YES(X,X) LIne 6 given CONS >>> qed >>> >>> -~YES(x,x) is the Incompleteness Axiom - more generally -~P/P where >>> general CBL is M # P / Q and the Theory of Computation is - X / YES : >>> output all non-r.e. sets. Also X / YES : Output all r.e. sets. >>> >>> -~YES(x,x) The set of programs that don't halt yes on themselves is >>> not r.e. >>> 1. ~YES(x,x) Premise >>> 2. M # ~YES(x,x) There must be a program that enumerates the set. >>> 3. YES(M,a) , ~YES(a,a) A1 expr => DEF (syntax) >>> 4. YES(M,M) , ~YES(M,M) SUB 3 >>> 5. P , ~P SUB 4 >>> qed >>> >>> -P,~P is a basic axiom. >>> >> >> Here is my closest approximation so far. >> >> // >> // To make the problem more clear we are assuming: >> // (a) a purely interpreted language >> // (b) function call syntax results in inline expansion, >> // thus specifying the name of a function specifies >> // the text body of the function. >> // >> >> >> void LoopIfHalts(string SourceCode) { >> if ( WillHalt(SourceCode, SourceCode) == TRUE ) >> while (TRUE) // loop forever >> ; >> else >> return; >> } >> >> >> int WillHalt(string SourceCode, string InputData) { >> if (NotValid(SourceCode, InputData)) >> throw(INVALID_INPUT); >> if ( TheProgramWillHalt(SourceCode, InputData) ) >> return TRUE; >> else >> return FALSE; >> } >> >> >> LoopIfHalts(LoopIfHalts); >> >> The INVALID_INPUT exception indicates that WillHalt() has detected a case of >> malignant self-reference where the result of its analysis is fed back into >> the >> analysis to change the result. This does not indicate that WillHalt() is >> unable >> to correctly derive the halt status of the universal set of programs. It only >> means that there exists at least one malignant case of self-reference where >> it >> can not provide the results of its correct and complete analysis as a return >> value. >> > > OK. And what's to prevent LoopIfHalts from using a nearly exact *copy* of > TheProgramWillHalt() in its implementation? There's an indefinite > number of modifications to a program that can be contemplated -- if > nothing else, one can assign an arbitrary number to an unused local > variable. Only the outmost WillHalt() function needs to throw the INVALID_INPUT exception. This exception could also be called MALIGNANT_SELF_REFERENCE_DETECTED. In any case WillHalt() will know that itself halts, and when it does halt, it does provide the only possible correct answer. The only possible correct answer equally applies, regardless of what its caller does with this answer. > > But there are a fair number of other modification methods: loop > unrolling, variable name changes, using an int where a boolean > would be sufficient, exchanging leftshift and * or rightshift and /, > bitflipping > > v2 = v XOR 2^n > > versus > > if(floor(v / 2^n) mod 2 == 0) then v2 = v + 2^n; else v2 = v - 2^n; > > etc. > > -- > #191, ewill3@earthlink.net > Useless C++ Programming Idea #992398129: > unsigned u; if(u < 0) ... > > -- > Posted via a free Usenet account from http://www.teranews.com >  0 NoSpam266 (508) 10/18/2006 12:31:04 PM Peter Olcott wrote: > "Patricia Shanahan" <pats@acm.org> wrote in message > news:AjiZg.10941Y24.524@newsread4.news.pas.earthlink.net...
>> Peter Olcott wrote:
>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>>> news:zGdZg.15330UG4.11773@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. > > Are we looking at the same place? The SELF-HALT I found there definitely does not modify itself, unless the DOES-HALT algorithm involves self modification: SELF-HALT(program) { if(DOES-HALT(program, program)) infinite loop else halt } Note that in the actual proof "program" is an integer that encodes the code for the program, so nobody is operating on the running copy. You can also, less formally, think of it as being the ASCII encoding of the program source code. It is just a string. In any case, the proof can be done using Turing machines, which are inherently incapable of self-modification, so it does not in any way depend on self-modification. I don't see the relevance of the length of time you have been a software developer to the validity of your ideas. Normally, quality of thinking and writing matters far more than background in newsgroups. Patricia  0 pats (3556) 10/18/2006 1:02:20 PM "Peter Olcott" <NoSpam@SeeScreen.com> writes: > "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message > news:fwezmbu0xdj.fsf@collins.inf.ed.ac.uk... >> "Peter Olcott" <NoSpam@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 > > http://www.cprogramming.com/tutorial/computersciencetheory/halting.html > None-the-less it is this mode that I am using in my investigation. I > understand Turing Machines, and UTM's, both of these would mathematically > map to this alternative model. You can do what you want in your own work, obviously. What is the relevance of the link you just cited to my observation about the normal use in computer science? In that link, the word "problem" is used as I suggested. -- Alan Smaill  0 smaill1 (89) 10/18/2006 2:48:31 PM "Peter Olcott" <NoSpam@SeeScreen.com> writes: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:87lkneqm4p.fsf@bsb.me.uk... >> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >> <big snip> >>>>>>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html > Explain this proof within the context of the model that I provided. No thanks. More formal methods are the only way to avoid these vague, hand-waving arguments. -- Ben.  0 ben.usenet (6790) 10/18/2006 2:58:53 PM The Ghost In The Machine wrote: > In sci.logic, Peter Olcott > <NoSpam@SeeScreen.com> > wrote > on Tue, 17 Oct 2006 11:32:53 -0500 > <UA7Zg.8314eZ4.3841@dukeread06>:
>> "Charlie-Boo" <shymathguy@gmail.com> wrote in message
>>> Peter Olcott wrote:
>>>> The Halt program throws an "Invalid Input" exception.
>>>> This would be analogous to the hardware exception of an attempt to divide by
>>>> zero.
>>> Are you aware of the fact that the Clay Institute offers a 1 million >>> reward for anyone who solves the Halting Problem? Alan Turing wasn't >>> able to and nobody has ever solved it since (except when using a >>> Computationally Based Logic). >>> >>> (I think Chaitin came closest by using a special number that vaporizes >>> as soon as you so much as think about it. Bit # N = whether or not I >>> will prove that I am not thinking about Chaitin at point in time N in >>> the future. (I hope I get all zeros.)) >>> >>> C-B >>> >>> -HALT(I,J)* The Halting Problem is Unsolvable >>> 1. NO(x,x) Known >>> 2. HALT(I,J)* PREMISE >>> 3. HALT(I,I)* SUB 2 >>> 4. ~HALT(I,I)* NOT 3 >>> 5. ~HALT(X,X) TRUE (THM) Peano 4 >>> 6. NO(X,X)v~HALT(X,X) UNION 1,5 >>> 7. ~YES(X,X) LIne 6 given CONS >>> qed >>> >>> -~YES(x,x) is the Incompleteness Axiom - more generally -~P/P where >>> general CBL is M # P / Q and the Theory of Computation is - X / YES : >>> output all non-r.e. sets. Also X / YES : Output all r.e. sets. >>> >>> -~YES(x,x) The set of programs that don't halt yes on themselves is >>> not r.e. >>> 1. ~YES(x,x) Premise >>> 2. M # ~YES(x,x) There must be a program that enumerates the set. >>> 3. YES(M,a) , ~YES(a,a) A1 expr => DEF (syntax) >>> 4. YES(M,M) , ~YES(M,M) SUB 3 >>> 5. P , ~P SUB 4 >>> qed >>> >>> -P,~P is a basic axiom. >>> >> Here is my closest approximation so far. >> >> // >> // To make the problem more clear we are assuming: >> // (a) a purely interpreted language >> // (b) function call syntax results in inline expansion, >> // thus specifying the name of a function specifies >> // the text body of the function. >> // >> >> >> void LoopIfHalts(string SourceCode) { >> if ( WillHalt(SourceCode, SourceCode) == TRUE ) >> while (TRUE) // loop forever >> ; >> else >> return; >> } >> >> >> int WillHalt(string SourceCode, string InputData) { >> if (NotValid(SourceCode, InputData)) >> throw(INVALID_INPUT); >> if ( TheProgramWillHalt(SourceCode, InputData) ) >> return TRUE; >> else >> return FALSE; >> } >> >> >> LoopIfHalts(LoopIfHalts); >> >> The INVALID_INPUT exception indicates that WillHalt() has detected a case of >> malignant self-reference where the result of its analysis is fed back into the >> analysis to change the result. This does not indicate that WillHalt() is unable >> to correctly derive the halt status of the universal set of programs. It only >> means that there exists at least one malignant case of self-reference where it >> can not provide the results of its correct and complete analysis as a return >> value. >> > > OK. And what's to prevent LoopIfHalts from using a nearly exact *copy* of > TheProgramWillHalt() in its implementation? There's an indefinite > number of modifications to a program that can be contemplated -- if > nothing else, one can assign an arbitrary number to an unused local > variable. > > But there are a fair number of other modification methods: loop > unrolling, variable name changes, using an int where a boolean > would be sufficient, exchanging leftshift and * or rightshift and /, > bitflipping > > v2 = v XOR 2^n > > versus > > if(floor(v / 2^n) mod 2 == 0) then v2 = v + 2^n; else v2 = v - 2^n; > > etc. > I was thinking of going a little further. Suppose the implementation language for LoopIfHalts is language X. Pick any TM-equivalent language Y. Write a language Y interpreter in X, and an X to Y compiler. LoopIfHalts gets fed as SourceCode the interpreter, bundled with the compiled version of LoopIfHalts as the interpreted program. Language Y could be designed after WillHalt has been written. The only information WillHalt gets about language Y is the language X implementation of a Y interpreter. Perhaps we should just stick to Turing machines? WillHalt has to able to deal with analyzing a TM program, because Turing machine is a possible language Y. Patricia  0 pats (3556) 10/18/2006 3:43:16 PM On Tuesday 17 October 2006 14:36, Peter Olcott wrote: > My primary point is based on the subtle distinction between your precise > statement of the conclusions that can be drawn from the HP, and the actual > correct conclusions that can actually be drawn. ... > > The HP does not show any limitation what-so-ever to the capability to > determine the halting status of any program. All that the HP shows ... In my personal experience I find that the unsolvability of the Halting Problem is a real limit (not just a problem in, say, definition) and that the theorem is useful. From time to time we would have trouble "writing" some powerful routines. We would think we had a solution, only to find we overlooked something, and we'd try to generalize to solve the *real* problem. Not infrequently after the second or third attempt, we'd ponder and realize that the problem was equivalent to solving the Halting Problem. With that we were satisfied with heuristics. Because of these experiences and the proofs I've seen, I am skeptical of purported solutions to the Halting Problem. True, the Halting Problem may be redefined such that there is a solution, but I've never found the redefined problem applicable in the real world. Sincerely, -paul- -- Paul E. Black (p.black@acm.org)  0 p.black (279) 10/18/2006 4:21:08 PM In article <Jo9Zg.9173eZ4.2688@dukeread06>,
Peter Olcott <NoSpam@SeeScreen.com> wrote:
>I thought that the "problem" part of the term "Halting Problem" was directly
>referring to the existence of this case of malignant self-reference such that it
>appears to defeat attempts to determine whether or not any program in the set of
>all programs, halts.

What you are calling "malignant self-reference" is nothing at all
to do with the HP itself, nor with whether it is solvable, nor with the
fact that it isn't.  Rather, it arises in one specific proof that the HP
is unsolvable.  There are other ways to show the basic result, including
a simple one based on the "busy beaver" idea.  There is also no need for
the HP to refer to programs *at all*;  there is a simple equivalent
formulation entirely in terms of data [eg as supplied to a UTM].

>The HP does not show any limitation what-so-ever to the capability to determine
>the halting status of any program.

The HP is merely a problem;  as such it doesn't show anything at
all.  However, the proof that it is unsolvable does show a limitation;
viz that there is no program that solves it.  This is quite different
from, for example, the syntax analysis problem, for it is quite usual
for people to write syntax checkers, or the convex-hull-of-a-set-of-
points-in-N-dimensions problem, or the search-data-for-a-specified-string
problem, or many other potentially interesting problems.  [But it is
similar to many other interesting but, sadly, unsolvable problems.]

>				    All that the HP shows is that there exists
>some cases of malignant self-reference where this determination can not be
>provided as a return value to a caller.

No, it doesn't show that.  No matter how MSR your program may be,
there are programs out there that will show whether or not your program
with its data will halt.  But this is a game of "you show me yours and
I'll show you mine".  Given your program/data, I have a tester that will
investigate it;  but given my tester, you can write a program/data that
busts it.  It's important who is made to show his hand first.

--
Andy Walker, School of MathSci., Univ. of Nott'm, UK.
anw@maths.nott.ac.uk
 0
anw (25)
10/18/2006 4:24:07 PM
Peter Olcott wrote:
> > 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.
>
> Let's start with just one, that will (hopefully) get us on the same page more
> quickly:
> [functioning correctly] would mean that a software function consistently
> produces the results that it was designed to achieve.

Yes, "software function consistencly produces the results that it was
designed to achieve," is surely a rigorous mathematical definition.
Reading that, I now realize I was entirely mistaken to doubt your
complete expertise and profound grasp of the mathematics of this
subject.

MoeBlee

 0
jazzmobe (307)
10/18/2006 4:58:31 PM
On Wed, 18 Oct 2006 12:21:08 -0400, Paul E. Black <p.black@acm.org>
said:
>
> Because of these experiences and the proofs I've seen, I am skeptical
> of purported solutions to the Halting Problem.

It's definitely a good thing to be skeptical of purported solutions to
provably unsolvable problems!

> True, the Halting Problem may be redefined such that there is a
> solution,

You can't redefine the Halting Problem; it is what it is.  The most you
can do is decide to use the words "the Halting Problem" to mean some-
thing other than what everyone else means by them.  Many unsolvable
problems have been "solved" in this manner in this newsgroup. :-)

 0
cmenzel (185)
10/18/2006 5:10:01 PM
Peter Olcott wrote:
> "The Ghost In The Machine" <ewill@sirius.tg00suus7038.net> wrote in message
> news:10mg04-kc6.ln1@sirius.tg00suus7038.net...
>> In sci.logic, Peter Olcott
>> <NoSpam@SeeScreen.com>
>> wrote
>> on Tue, 17 Oct 2006 11:32:53 -0500
>> <UA7Zg.8314eZ4.3841@dukeread06>: >>> "Charlie-Boo" <shymathguy@gmail.com> wrote in message >>> news:1161101671.273314.18520@h48g2000cwc.googlegroups.com... >>>> Peter Olcott wrote: >>>>> The Halt program throws an "Invalid Input" exception. >>>>> This would be analogous to the hardware exception of an attempt to divide >>>>> by >>>>> zero. No, and it is not analogous. You do not understand the halting problem, your conception is fictitious and your posts are irrelevant to the Halting Problem. Your comments are more relevant to what they call automated program checkers which fail with a complex program and that idea is why programmers always have to check their code to see if it performs as intended. Perhaps the idea of self-reference is involved as one needs a program checker, a program checker to check the program checker, a program checker to check the program checker which is checking the program checker which is checking the program checker and so on and so on ... which is the concept of infinite regress. http://pag.csail.mit.edu/~mernst/pubs/generate-specs-issta2002.pdf Your ideas may be correct for what you are talking about, I don't know. But you are not talking about the Halting Problem that other people refer to with that label, you are talking about your own interpretation of what that term means which is based on ignorance. I mean that you don't get to invent your own personal definitions for terms which have and have had a special agreed upon meaning for 70 years, criticize your delusions, and claim that is what other people mean. That is called a strawman argument. I think more likely that your posts are a shabby trick to advertise your website so you get paid for more visits to your website which inflicts popup advertising on the visitor. Perhaps that scenario is not more likely as it gives you too much credit for being clever. You are a disgusting intellectual fraud and stupid. You gave your whole game away when you claim as a qualification, Peter Olcott wrote: 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. ------------------------------------------------- Patricia Shanahan replied: In any case, the proof can be done using Turing machines, which are inherently incapable of self-modification, so it does not in any way depend on self-modification. I don't see the relevance of the length of time you have been a software developer to the validity of your ideas. Normally, quality of thinking and writing matters far more than background in newsgroups. Patricia --------------------------------------------------- Peter, I don't think you know what a Turing Machine is. They are not physically realizable (only a subset) and are abstract or ideal machines. In particular they have an unbounded tape (potentially infinite). That means they don't fail because they run out of memory which can be a problem for a physical computer which all have a finite amount of memory which limits the solutions which can be physically computed. There are neither time nor memory constraints for Turing machines which is what I mean by not physically realizable, they are abstract. The reason Turing added the finitely unbounded tape was to eliminate from consideration programs that would complete *if* they had enough memory from programs whose halting is undecidable even if they have as much memory as could ever be needed. Nor is a procedure possible to distinguish "genuine" halting from depletion of available memory. It doesn't appear that you have ever read a paper describing what a Turing machine is, or you certainly did not understand it. Your posts are all imaginary garbage. http://www.earlham.edu/~peters/courses/logsys/turing2.htm  0 10/18/2006 8:08:20 PM Peter Olcott wrote: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:87lkneqm4p.fsf@bsb.me.uk... >> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >> >>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >>> news:87slhmqpxw.fsf@bsb.me.uk... >>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>>> >>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >>>>> news:874pu2tqla.fsf@bsb.me.uk... >>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>>>>> >>>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >>>>>>> news:878xjetrqw.fsf@bsb.me.uk... >>>>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>>>>>>> >>>>>>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message >>>>>>>>> news:1161118961.027553.142520@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. > > http://moonbase.wwc.edu/~aabyan/Theory/Computable.html#halting "The Halting Problem for a programming language. We will use the "C" programming language, yet any language will work. Assumption: There exists a way to write a function named Halts such that: int Halts(char * P, char * I) { /* code that reads the source code for a "C" program, P, determines that P is a legal program, then determines if P eventually halts (or exits) when P reads the input string I, and finally sets a variable "halt" to 1 if P halts on input I, else sets "halt" to 0 */ return halt; } Construct a program called Diagonal.c as follows: int main() { char I[100000000]; /* make as big as you want or use malloc */ read_a_C_program_into( I ); if ( Halts(I,I) ) { while(1){} } /* loop forever, means does not halt */ else return 1; } Compile and link Diagonal.c into the executable program Diagonal. Now execute Diagonal < Diagonal.c. Consider two mutually exclusive cases: Case 1: Halts(I,I) returns a value 1. This means, by the definition of Halts, that Diagonal.c halts when given the input Diagonal.c. BUT! we are running Diagonal.c (having been compiled and linked) and so we see that Halts(I,I) returns a value 1 causes the "if" statement to be true and the "while(1){}" statement to be executed, which never halts, thus our executing Diagonal.c does NOT halt. This is a contradiction because this case says that Diagonal.c does halt when given input Diagonal.c. Well, try the other case. Case 2: Halts(I,I) returns a value 0. This means, by the definition of halts, that Diagonal.c does NOT halt when given the input Diagonal.c. BUT! we are running Diagonal.c (having been compiled and linked) and so we see that Halts(I,I) returns a value 0 causes the "else" to be executed and the main function halts (stops, exits). This is a contradiction because this case says that Diagonal.c does NOT halt when given input Diagonal.c. There are no other cases, Halts can only return 1 or 0. Thus what must be wrong is our assumption "there exists a way to write a function named Halts..." . "  0 10/18/2006 8:37:11 PM William Elliot wrote: > On Sun, 15 Oct 2006, Peter Olcott wrote: > > <mareg@mimosa.csv.warwick.ac.uk> wrote in message > > > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > > > >>X = 50.0 / 0.0 > > >>Is this an unsolvable problem or an ill-formed problem? > > > > > > I cannot see a problem there at all, just an equation with an undefined RHS. > > > What is the problem exactly? > > > > What is the value of X? > > > Just like he told you, X doesn't have a value. I am not a normal poster to this group but I stumbled upon this and it seems like maybe we make too much out of things. Isn't there something about amoung multiple possible explinations the most likely is the simplist. That is an ill-formed question. If I have a bucket of beans (like the kind you used to play with at the grocery store when you were a kid) we can determin how many handfuls it would require to empty it. That is division. So the question is "How long will it take to empty this bucket if I take nothing out?" and that sounds like something for Buda, not Comp Science. Forgive me if I am too simplistic.  0 10/18/2006 8:41:58 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:wBpZg.8700Lv3.4747@newsread1.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> news:AjiZg.10941$Y24.524@newsread4.news.pas.earthlink.net... >>> Peter Olcott wrote: >>>> "Patricia Shanahan" <pats@acm.org> wrote in message >>>> news:zGdZg.15330$UG4.11773@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.
>
> Are we looking at the same place? The SELF-HALT I found there definitely
> does not modify itself, unless the DOES-HALT algorithm involves self
> modification:
>
> SELF-HALT(program)
> {
>     if (DOES-HALT(program, program))
>         infinite loop
>     else
>         halt
> }
>
> Note that in the actual proof "program" is an integer that encodes the
> code for the program, so nobody is operating on the running copy. You
> can also, less formally, think of it as being the ASCII encoding of the
> program source code. It is just a string.
>
> In any case, the proof can be done using Turing machines, which are
> inherently incapable of self-modification, so it does not in any way
> depend on self-modification.

Can't a UTM modify itself by writing to the tape that contains it?
In any case what I mean by self-modification is the fact that the SELF-HALT
attempts to modify the determination of DOES-HALT by doing the opposite of this
determination. This attempt is defeated by the following code:

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

>
> I don't see the relevance of the length of time you have been a software
> developer to the validity of your ideas. Normally, quality of thinking
> and writing matters far more than background in newsgroups.
>
> Patricia

 0
NoSpam266 (508)
10/18/2006 9:41:22 PM
Peter Olcott wrote:
> <mareg@mimosa.csv.warwick.ac.uk> wrote in message
> news:egto14$b1d$1@wisteria.csv.warwick.ac.uk...
> > In article <QSsYg.7900eZ4.333@dukeread06>, > > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > > ... > > > >> > >>X = 50.0 / 0.0 > >>Is this an unsolvable problem or an ill-formed problem? > >> > > > > I cannot see a problem there at all, just an equation with an undefined RHS. > > What is the problem exactly? > > > > Derek Holt. > > It is not an equation, the "=" sign is an assignment operator in computer > science. Okay, but at some point the computer must perform the calculation/equation 50/0. Therefore we could say: y = 50/0 x := y And since we can't figure out the first line, how are we to assign the variable? I know there is a difference between assignment and equality, but wouldn't assignment imply an equation exist?  0 10/18/2006 9:43:06 PM "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message news:fwepscp1xz4.fsf@collins.inf.ed.ac.uk... > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > >> "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message >> news:fwezmbu0xdj.fsf@collins.inf.ed.ac.uk... >>> "Peter Olcott" <NoSpam@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 >> >> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html >> None-the-less it is this mode that I am using in my investigation. I >> understand Turing Machines, and UTM's, both of these would mathematically >> map to this alternative model. > > You can do what you want in your own work, obviously. > > What is the relevance of the link you just cited to my observation > about the normal use in computer science? > In that link, the word "problem" is used as I suggested. > > > -- > Alan Smaill I am using the sort of model that the link provides as my basis, rather than the formal mathematical model. int WillHalt(string SourceCode, string InputData) { if (MalignantSelfReference(SourceCode, InputData)) throw(MALIGNANT_SELF_REFERENCE); if ( TheProgramWillHalt(SourceCode, InputData) ) return TRUE; else return FALSE; } This defeats the "problem" aspect of the Halting Problem.  0 NoSpam266 (508) 10/18/2006 9:44:14 PM "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:87wt6x8yc2.fsf@bsb.me.uk... > "Peter Olcott" <NoSpam@SeeScreen.com> writes: > >> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message >> news:87lkneqm4p.fsf@bsb.me.uk... >>> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >>> > <big snip> >>>>>>>> >>>>>>>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html >> Explain this proof within the context of the model that I provided. > > No thanks. More formal methods are the only way to avoid these vague, > hand-waving arguments. > > -- > Ben. Or perhaps they are a way to make a model that only seems to correspond to the actuality, with slight errors of the precise mathematical mapping, thus creating the fallacy of equivocation.  0 NoSpam266 (508) 10/18/2006 9:45:59 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:oYrZg.11120Y24.7883@newsread4.news.pas.earthlink.net...
> The Ghost In The Machine wrote:
>> In sci.logic, Peter Olcott
>> <NoSpam@SeeScreen.com>
>>  wrote
>> on Tue, 17 Oct 2006 11:32:53 -0500
>> <UA7Zg.8314$eZ4.3841@dukeread06>: >>> "Charlie-Boo" <shymathguy@gmail.com> wrote in message >>> news:1161101671.273314.18520@h48g2000cwc.googlegroups.com... >>>> Peter Olcott wrote: >>>>> The Halt program throws an "Invalid Input" exception. >>>>> This would be analogous to the hardware exception of an attempt to divide >>>>> by >>>>> zero. >>>> Are you aware of the fact that the Clay Institute offers a$1 million
>>>> reward for anyone who solves the Halting Problem?  Alan Turing wasn't
>>>> able to and nobody has ever solved it since (except when using a
>>>> Computationally Based Logic).
>>>>
>>>> (I think Chaitin came closest by using a special number that vaporizes
>>>> as soon as you so much as think about it.  Bit # N = whether or not I
>>>> will prove that I am not thinking about Chaitin at point in time N in
>>>> the future.  (I hope I get all zeros.))
>>>>
>>>> C-B
>>>>
>>>>   -HALT(I,J)*  The Halting Problem is Unsolvable
>>>> 1. NO(x,x)   Known
>>>> 2. HALT(I,J)*   PREMISE
>>>> 3. HALT(I,I)*   SUB 2
>>>> 4. ~HALT(I,I)*   NOT 3
>>>> 5. ~HALT(X,X)      TRUE (THM)   Peano 4
>>>> 6. NO(X,X)v~HALT(X,X)   UNION 1,5
>>>> 7. ~YES(X,X)   LIne 6 given CONS
>>>>   qed
>>>>
>>>> -~YES(x,x) is the Incompleteness Axiom - more generally -~P/P where
>>>> general CBL is M # P / Q and the Theory of Computation is - X / YES :
>>>> output all non-r.e. sets.  Also X / YES : Output all r.e. sets.
>>>>
>>>>  -~YES(x,x)  The set of programs that don't halt yes on themselves is
>>>> not r.e.
>>>> 1. ~YES(x,x)   Premise
>>>> 2. M # ~YES(x,x)   There must be a program that enumerates the set.
>>>> 3. YES(M,a) , ~YES(a,a)   A1 expr => DEF (syntax)
>>>> 4. YES(M,M) , ~YES(M,M)   SUB 3
>>>> 5. P , ~P   SUB 4
>>>>  qed
>>>>
>>>> -P,~P is a basic axiom.
>>>>
>>> Here is my closest approximation so far.
>>>
>>> //
>>> //  To make the problem more clear we are assuming:
>>> //  (a) a purely interpreted language
>>> //  (b) function call syntax results in inline expansion,
>>> //       thus specifying the name of a function specifies
>>> //       the text body of the function.
>>> //
>>>
>>>
>>> void LoopIfHalts(string SourceCode)  {
>>>      if ( WillHalt(SourceCode, SourceCode) == TRUE )
>>>         while (TRUE)    // loop forever
>>>             ;
>>>      else
>>>         return;
>>> }
>>>
>>>
>>> int WillHalt(string SourceCode, string InputData)   {
>>>     if (NotValid(SourceCode, InputData))
>>>         throw(INVALID_INPUT);
>>>     if ( TheProgramWillHalt(SourceCode, InputData) )
>>>         return TRUE;
>>>     else
>>>         return FALSE;
>>> }
>>>
>>>
>>> LoopIfHalts(LoopIfHalts);
>>>
>>> The INVALID_INPUT exception indicates that WillHalt() has detected a case of
>>> malignant self-reference where the result of its analysis is fed back into
>>> the analysis to change the result. This does not indicate that WillHalt() is
>>> unable to correctly derive the halt status of the universal set of programs.
>>> It only means that there exists at least one malignant case of
>>> self-reference where it can not provide the results of its correct and
>>> complete analysis as a return value.
>>
>> OK.  And what's to prevent LoopIfHalts from using a nearly exact *copy* of
>> TheProgramWillHalt() in its implementation?  There's an indefinite
>> number of modifications to a program that can be contemplated -- if
>> nothing else, one can assign an arbitrary number to an unused local
>> variable.
>>
>> But there are a fair number of other modification methods: loop
>> unrolling, variable name changes, using an int where a boolean
>> would be sufficient, exchanging leftshift and * or rightshift and /,
>> bitflipping
>>
>> v2 = v XOR 2^n
>>
>> versus
>>
>> if(floor(v / 2^n) mod 2 == 0) then v2 = v + 2^n; else v2 = v - 2^n;
>>
>> etc.
>>
>
> I was thinking of going a little further.
>
> Suppose the implementation language for LoopIfHalts is language X. Pick
> any TM-equivalent language Y. Write a language Y interpreter in X, and
> an X to Y compiler. LoopIfHalts gets fed as SourceCode the interpreter,
> bundled with the compiled version of LoopIfHalts as the interpreted program.
>
> Language Y could be designed after WillHalt has been written. The only
> information WillHalt gets about language Y is the language X
> implementation of a Y interpreter.
>
> Perhaps we should just stick to Turing machines? WillHalt has to able to
> deal with analyzing a TM program, because Turing machine is a possible
> language Y.
>
> Patricia

So the equivalent of the return value of the Halt() function from the TM is the
integer value that the TM's ReadWrite head rests on when the TM halts. In this
case  DOES_NOT_HALT=0  HALTS=1    MALIGNANT_SELF_REFERENCE=2. This scenario
breaks out of the infinite recursion of the original specification of the
problem, and provides the only possible correct answer.

 0
NoSpam266 (508)
10/18/2006 9:51:12 PM
"Paul E. Black" <p.black@acm.org> wrote in message
news:eh5k9g02mma@news3.newsguy.com...
> On Tuesday 17 October 2006 14:36, Peter Olcott wrote:
>> My primary point is based on the subtle distinction between your precise
>> statement of the conclusions that can be drawn from the HP, and the actual
>> correct conclusions that can actually be drawn. ...
>>
>> The HP does not show any limitation what-so-ever to the capability to
>> determine the halting status of any program. All that the HP shows ...
>
> In my personal experience I find that the unsolvability of the Halting
> Problem is a real limit (not just a problem in, say, definition) and
> that the theorem is useful.
>
> From time to time we would have trouble "writing" some powerful
> routines.  We would think we had a solution, only to find we
> overlooked something, and we'd try to generalize to solve the
> *real* problem.  Not infrequently after the second or third attempt,
> we'd ponder and realize that the problem was equivalent to solving the
> Halting Problem.  With that we were satisfied with heuristics.
>
> Because of these experiences and the proofs I've seen, I am skeptical
> of purported solutions to the Halting Problem.  True, the Halting
> Problem may be redefined such that there is a solution, but I've never
> found the redefined problem applicable in the real world.
>
> Sincerely,
> -paul-
> --
> Paul E. Black (p.black@acm.org)

The conclusion of the Halting Problem is that it purports to show that some
things are not computable. If one treats English as a mathematical formalism,
one sees that this conclusion is flatly incorrect. The Halting problem does not
show that the correct halting status of every element in the set of all programs
can not be determined.

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

This function breaks out of the infinite recursive self reference of the HP
thus defeating the conclusions drawn from the HP. It knows whether or not the
program under test halts, Since it KNOWS this therefore it HAS DETERMINED THIS.

 0
NoSpam266 (508)
10/18/2006 9:58:13 PM
"Dr A. N. Walker" <anw@maths.nott.ac.uk> wrote in message
news:eh5kf7$dj8$1@oyez.ccc.nottingham.ac.uk...
> In article <Jo9Zg.9173eZ4.2688@dukeread06>, > Peter Olcott <NoSpam@SeeScreen.com> wrote: >>I thought that the "problem" part of the term "Halting Problem" was directly >>referring to the existence of this case of malignant self-reference such that >>it >>appears to defeat attempts to determine whether or not any program in the set >>of >>all programs, halts. > > What you are calling "malignant self-reference" is nothing at all > to do with the HP itself, nor with whether it is solvable, nor with the > fact that it isn't. Rather, it arises in one specific proof that the HP > is unsolvable. There are other ways to show the basic result, including > a simple one based on the "busy beaver" idea. There is also no need for > the HP to refer to programs *at all*; Then what would it be that we are attempting to test the halting of? It would seem that you must be wrong here. If there are no programs, then there is no halting, thus no "Halting Problem" is possible, merely mathematical abstractions that falsely call themselves the HP. > there is a simple equivalent > formulation entirely in terms of data [eg as supplied to a UTM]. A UTM is essentially defined as being a program. > >>The HP does not show any limitation what-so-ever to the capability to >>determine >>the halting status of any program. > > The HP is merely a problem; as such it doesn't show anything at > all. However, the proof that it is unsolvable does show a limitation; > viz that there is no program that solves it. This is quite different > from, for example, the syntax analysis problem, for it is quite usual > for people to write syntax checkers, or the convex-hull-of-a-set-of- > points-in-N-dimensions problem, or the search-data-for-a-specified-string > problem, or many other potentially interesting problems. [But it is > similar to many other interesting but, sadly, unsolvable problems.] > >> All that the HP shows is that there exists >>some cases of malignant self-reference where this determination can not be >>provided as a return value to a caller. > > No, it doesn't show that. No matter how MSR your program may be, > there are programs out there that will show whether or not your program > with its data will halt. But this is a game of "you show me yours and Not when the result of this determination is structured as listed below: http://www.cprogramming.com/tutorial/computersciencetheory/halting.html > I'll show you mine". Given your program/data, I have a tester that will > investigate it; but given my tester, you can write a program/data that > busts it. It's important who is made to show his hand first. > > -- > Andy Walker, School of MathSci., Univ. of Nott'm, UK. > anw@maths.nott.ac.uk  0 NoSpam266 (508) 10/18/2006 10:05:31 PM Peter Olcott wrote: .... > Can't a UTM modify itself by writing to the tape that contains it? Nope. The UTM itself is not on any tape. The program it is running is on a tape. However, if a UTM-like program allowed self-modification by the program it is running, it would not be a UTM, because it would not be accurately simulating Turing-machine behavior. It would be simulating some form of Von Neumann machine, in which the program is part of the data. > In any case what I mean by self-modification is the fact that the SELF-HALT > attempts to modify the determination of DOES-HALT by doing the opposite of this > determination. This attempt is defeated by the following code: No, it merely uses the result of a DOES-HALT call to decide what it is going to do next. > > int WillHalt(string SourceCode, string InputData) { > if (MalignantSelfReference(SourceCode, InputData)) > throw(MALIGNANT_SELF_REFERENCE); > if ( TheProgramWillHalt(SourceCode, InputData) ) > return TRUE; > else > return FALSE; > } You still have not defined a malignant self reference, or explained how to calculate it in the face of program transformations, including translations into other languages. To me, the problem seems insurmountable. The MalignantSelfReference function has to make a determination that appears to me to be the sort of test that is halting-problem equivalent. Of course, I can't prove that until you define what it does. Patricia  0 pats (3556) 10/18/2006 10:09:23 PM "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message news:slrnejcnv9.297d.cmenzel@philebus.tamu.edu... > On Wed, 18 Oct 2006 12:21:08 -0400, Paul E. Black <p.black@acm.org> > said: >> >> Because of these experiences and the proofs I've seen, I am skeptical >> of purported solutions to the Halting Problem. > > It's definitely a good thing to be skeptical of purported solutions to > provably unsolvable problems! > >> True, the Halting Problem may be redefined such that there is a >> solution, > > You can't redefine the Halting Problem; it is what it is. The most you > can do is decide to use the words "the Halting Problem" to mean some- > thing other than what everyone else means by them. Many unsolvable > problems have been "solved" in this manner in this newsgroup. :-) > Everyone else is taking them to mean something that they do not in fact mean. I wish that my 100% completely precise version of the English language, LUCID existed, then I could explain what I mean once, and everyone would see. Because this language does not exist, people slip and slide subtle nuances of meaning, and miss my point from their slight equivocations of meaning. What is the official precise English language conclusion drawn from the results of the mathematical analysis of the Halting Problem? Isn't it something along the lines of "It is impossible to determine the halting status of every element in the set of all programs"?  0 NoSpam266 (508) 10/18/2006 10:20:46 PM Peter Olcott wrote: .... > So the equivalent of the return value of the Halt() function from the TM is the > integer value that the TM's ReadWrite head rests on when the TM halts. In this > case DOES_NOT_HALT=0 HALTS=1 MALIGNANT_SELF_REFERENCE=2. This scenario > breaks out of the infinite recursion of the original specification of the > problem, and provides the only possible correct answer. OK, so now we are down to a well-defined environment. Perhaps you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing machine computation? Patricia  0 pats (3556) 10/18/2006 10:22:10 PM "Stephen Harris" <cyberguard-1048@yahoo.com> wrote in message news:XfwZg.176326S3.2843@newssvr25.news.prodigy.net...
> Peter Olcott wrote:
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:87lkneqm4p.fsf@bsb.me.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>
>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>> news:87slhmqpxw.fsf@bsb.me.uk...
>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>>
>>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>>>> news:874pu2tqla.fsf@bsb.me.uk...
>>>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>>>>
>>>>>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>>>>>> news:878xjetrqw.fsf@bsb.me.uk...
>>>>>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>>>>>>
>>>>>>>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>>>>>>>>> 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
>>>>>
>>>>>> 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.
>
> http://moonbase.wwc.edu/~aabyan/Theory/Computable.html#halting
>
> "The Halting Problem for a programming language.
>
> We will use the "C" programming language, yet any language will work.
>
> Assumption: There exists a way to write a function named Halts such that:
>
>         int Halts(char * P, char * I)
>         {
>           /* code that reads the source code for a "C" program, P,
>              determines that P is a legal program, then determines if P
>              eventually halts (or exits) when P reads the input string I,
>              and finally sets a variable "halt" to 1 if P halts on input I,
>              else sets "halt" to 0 */
>           return halt;
>         }
>
> Construct a program called Diagonal.c as follows:
>
>       int main()
>       {
>         char I[100000000];  /* make as big as you want or use malloc */
>         if ( Halts(I,I) )  { while(1){} }   /* loop forever, means does not
> halt */
>         else return 1;
>       }
>
> Compile and link Diagonal.c into the executable program Diagonal. Now execute
> Diagonal < Diagonal.c.
>
> Consider two mutually exclusive cases:
>
> Case 1: Halts(I,I) returns a value 1.
>     This means, by the definition of Halts, that Diagonal.c halts when given
> the input Diagonal.c. BUT! we are running Diagonal.c (having been compiled and
> linked) and so we see that Halts(I,I) returns a value 1 causes the "if"
> statement to be true and the "while(1){}" statement to be executed, which
> never halts, thus our executing Diagonal.c does NOT halt. This is a
> contradiction because this case says that Diagonal.c does halt when given
> input Diagonal.c. Well, try the other case.
> Case 2: Halts(I,I) returns a value 0.
>     This means, by the definition of halts, that Diagonal.c does NOT halt when
> given the input Diagonal.c. BUT! we are running Diagonal.c (having been
> compiled and linked) and so we see that Halts(I,I) returns a value 0 causes
> the "else" to be executed and the main function halts (stops, exits). This is
> a contradiction because this case says that Diagonal.c does NOT halt when
> given input Diagonal.c. There are no other cases, Halts can only return 1 or
> 0. Thus what must be wrong is our assumption "there exists a way to write a
> function named Halts..." . "

Within that definition of the Halting Problem, the HP seems to be validated.
That form of the HP artificially constrains itself to a Boolean result. The
actual problem is of the tertiary form that I have provided. The original
artificial restriction to a two valued Boolean result, artificially limits the
solution set.

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

 0
NoSpam266 (508)
10/18/2006 10:29:06 PM
>
> William Elliot wrote:
>> On Sun, 15 Oct 2006, Peter Olcott wrote:
>> > <mareg@mimosa.csv.warwick.ac.uk> wrote in message
>> > > "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>
>> > >>X = 50.0 / 0.0
>> > >>Is this an unsolvable problem or an ill-formed problem?
>> > >
>> > > I cannot see a problem there at all, just an equation with an undefined
>> > > RHS.
>> > > What is the problem exactly?
>> >
>> > What is the value of X?
>> >
>> Just like he told you, X doesn't have a value.
>
> I am not a normal poster to this group but I stumbled upon this and it
> seems like maybe we make too much out of things.  Isn't there something
> about amoung multiple possible explinations the most likely is the
> simplist.
>
> That is an ill-formed question.
>
> If I have a bucket of beans (like the kind you used to play with at the
> grocery store when you were a kid) we can determin how many handfuls it
> would require to empty it.  That is division.  So the question is "How
> long will it take to empty this bucket if I take nothing out?"  and
> that sounds like something for Buda, not Comp Science.
>
> Forgive me if I am too simplistic.
>

Actually it would seem that you are the only one that has completely understood
what I am saying. You even formed the same atypical conclusion that I formed
about what division by zero really means, as opposed to and contrast with
conventional wisdom. The Halting Problem too, is merely an ill-formed question,
nothing more, and nothing less.

 0
NoSpam266 (508)
10/18/2006 10:32:55 PM
Peter Olcott wrote:
> What is the
> official precise English language conclusion drawn from the results of the
> mathematical analysis of the Halting Problem?

Why not start by at least informing yourself of an exact mathematical
statement of the theorem and its proof?

MoeBlee

 0
jazzmobe (307)
10/18/2006 10:33:10 PM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> Peter Olcott wrote:
>> What is the
>> official precise English language conclusion drawn from the results of the
>> mathematical analysis of the Halting Problem?
>
> Why not start by at least informing yourself of an exact mathematical
> statement of the theorem and its proof?
>
> MoeBlee
>

That is not within my purpose. My purpose is to show that the Halting Problem is
really nothing more than an ill-formed question.

 0
NoSpam266 (508)
10/18/2006 10:43:46 PM
"Peter Olcott" <NoSpam@SeeScreen.com> wrote:
> The Halting Problem too, is merely an ill-formed question, nothing more,
> and nothing less.

How do you deal with the fact that the halting problem for some kinds of
computation *is* solvable?  That's what complexity analysis is about.
Any time you make a database query, it will have gone through an optimizer
that solves the halting problem for the database query language (and does
considerably more than that).  There is nothing at all ill-formed about

This works because database query languages can't do as much as Turing
machines or unbounded-memory abstract machines programmed in C can.  Read
a book and you might see what the relevant difference is.

==============  j-c  ======  @  ======  purr . demon . co . uk  ==============
Jack Campin:  11 Third St, Newtongrange EH22 4PU, Scotland | tel 0131 660 4760
<http://www.purr.demon.co.uk/jack/>   for CD-ROMs and free | fax 0870 0554 975
stuff: Scottish music, food intolerance, & Mac logic fonts | mob 07800 739 557
 0
bogus20 (22)
10/18/2006 10:59:49 PM
Peter Olcott wrote:
> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
> > Peter Olcott wrote:
> >> What is the
> >> official precise English language conclusion drawn from the results of the
> >> mathematical analysis of the Halting Problem?
> >
> > Why not start by at least informing yourself of an exact mathematical
> > statement of the theorem and its proof?
> >
> > MoeBlee
> >
>
> That is not within my purpose. My purpose is to show that the Halting Problem is
> really nothing more than an ill-formed question.

You know it's ill-formed but you don't know anything about the actual
math of it. Right. Gotcha.

MoeBlee

 0
jazzmobe (307)
10/18/2006 11:08:46 PM
On Wed, 18 Oct 2006 17:20:46 -0500, Peter Olcott <NoSpam@SeeScreen.com>
said:
>
> "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
> news:slrnejcnv9.297d.cmenzel@philebus.tamu.edu...
>> On Wed, 18 Oct 2006 12:21:08 -0400, Paul E. Black <p.black@acm.org>
>> said:
>>>
>>> Because of these experiences and the proofs I've seen, I am
>>> skeptical of purported solutions to the Halting Problem.
>>
>> It's definitely a good thing to be skeptical of purported solutions
>> to provably unsolvable problems!
>>
>>> True, the Halting Problem may be redefined such that there is a
>>> solution,
>>
>> You can't redefine the Halting Problem; it is what it is.  The most
>> you can do is decide to use the words "the Halting Problem" to mean
>> some- thing other than what everyone else means by them.  Many
>> unsolvable problems have been "solved" in this manner in this
>> newsgroup. :-)
>
> Everyone else is taking them to mean something that they do not in
> fact mean.

So you're saying that these apparent crackpots really *aren't* claiming
to have solved the Halting Problem / refuted Cantor's theorem /
uncovered the flaw in G�del's proof / <your favorite crackpot project
here>?  It sure *looks* like that's what they're claiming, since they
say things like "The Halting Problem is solvable" and "I have identified
the flaw in Cantor's/G�del's proof".  But like you say, maybe they mean
something by those words other than what people who know what they are
talking about mean by those words.

> I wish that my 100% completely precise version of the English
> language, LUCID existed,

Name's taken, dude!  That's a shamep. ;-)

> then I could explain what I mean once, and everyone would see. Because
> this language does not exist, people slip and slide subtle nuances of
> meaning, and miss my point from their slight equivocations of meaning.

Ah, yes, it's all their fault.  Thing is, there's no slipping and
sliding on nuances of meaning when it comes to the statement and
analysis of the Halting Problem.  It's a piece of very simple, painfully
clear mathematics.  Anyone making the sorts of claims you are making
simply hasn't done their homework.

> What is the official precise English language conclusion drawn from
> the results of the mathematical analysis of the Halting Problem?
> Isn't it something along the lines of "It is impossible to determine
> the halting status of every element in the set of all programs"?

Why say "every element in the set of all programs" when you could just
say "every program"?  But no, that's not right, since, among lots of
other things, it makes no reference to input.  Better is something along
these lines:  There is no algorithm for determining, for every program P
and input I, whether or not P halts on I.  But for this to be a
*precise* English language expression of the proposition you want,
you'll have to include, at least, the mathematical definitions of
"algorithm", "program", "input", "program ... halts on input ...", and
related notions like that of a program execution.  If you aren't using
those definitions, you're probably either talking nonsense or you've
simply changed the subject to something no one cares about.

 0
cmenzel (185)
10/18/2006 11:19:51 PM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:87wt6x8yc2.fsf@bsb.me.uk...
>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>
>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>> news:87lkneqm4p.fsf@bsb.me.uk...
>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>
>> <big snip>
>>>>>>>>>
>>>>>>>>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>>> Explain this proof within the context of the model that I provided.
>>
>> No thanks.  More formal methods are the only way to avoid these vague,
>> hand-waving arguments.
>>
>
> Or perhaps they are a way to make a model that only seems to
> correspond to the actuality, with slight errors of the precise
> mathematical mapping, thus creating the fallacy of equivocation.

Perhaps.  How will you ever know?  When someone says something that
"sounds reasonable"?  That was the point of my asking the questions you
did not answer.  I am genuinely curious to know if you really think
your vague words will persuade anyone here to change his/her mind and what
kind of thing anyone here might say that would cause you to doubt your
arguments.  I suspect that you don't really think anyone will be
persuaded and that you are just enjoying a good troll.

PS.  Please stop quoting sigs.  A biot of snipping would not go amiss
either.

--
Ben.
 0
ben.usenet (6790)
10/18/2006 11:20:51 PM
Peter Olcott wrote:
> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>> Peter Olcott wrote:
>>> What is the
>>> official precise English language conclusion drawn from the results of the
>>> mathematical analysis of the Halting Problem?
>> Why not start by at least informing yourself of an exact mathematical
>> statement of the theorem and its proof?
>>
>> MoeBlee
>>
>
> That is not within my purpose. My purpose is to show that the Halting Problem is
> really nothing more than an ill-formed question.

The whole Halting Problem? There are large classes of computations that
provably halt. Indeed, there are algorithms that are known to halt for
every input. On the other hand, there are computations that can be
proved to not halt. Not only is the question interesting and

In between, there is a set of computations for which neither halting nor
not-halting has been proved.

The non-decidability of the halting problem tells us that we can never
reduce that set to the empty set.

As far as I can tell, you agree with that conclusion. You don't seem to
have contributed anything interesting, such as an algorithm for deciding
whether a computation is one that can never be proved to halt or not-halt.

Patricia
 0
pats (3556)
10/18/2006 11:36:53 PM
This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C6F2E5.ECC84BE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

"Jack Campin - bogus address" <bogus@purr.demon.co.uk> wrote in message =
news:bogus-5894C8.23594918102006@news.news.demon.net...
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote:
>> The Halting Problem too, is merely an ill-formed question, nothing =
more,
>> and nothing less.=20
>=20
> How do you deal with the fact that the halting problem for some kinds =
of
> computation *is* solvable?  That's what complexity analysis is about.
> Any time you make a database query, it will have gone through an =
optimizer
> that solves the halting problem for the database query language (and =
does
> considerably more than that).  There is nothing at all ill-formed =
>=20
> This works because database query languages can't do as much as Turing
> machines or unbounded-memory abstract machines programmed in C can.  =
> a book and you might see what the relevant difference is.

+-----------------------+
|                       |
V                       |
(What is the answer to this quesion?)--+

What is it about the about above question that make it unsolvable?

>=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  j-c  =3D=3D=3D=3D=3D=3D  @ =
=3D=3D=3D=3D=3D=3D  purr . demon . co . uk  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Jack Campin:  11 Third St, Newtongrange EH22 4PU, Scotland | tel 0131 =
660 4760
> <http://www.purr.demon.co.uk/jack/>   for CD-ROMs and free | fax 0870 =
0554 975
> stuff: Scottish music, food intolerance, & Mac logic fonts | mob 07800 =
739 557
------=_NextPart_000_0008_01C6F2E5.ECC84BE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR>
<STYLE></STYLE>
<BODY>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>"Jack Campin - bogus address" =
&lt;</FONT><A=20
href=3D"mailto:bogus@purr.demon.co.uk"><FONT face=3DArial=20
size=3D2>bogus@purr.demon.co.uk</FONT></A><FONT face=3DArial =
size=3D2>&gt; wrote in=20
message </FONT><A=20
href=3D"news:bogus-5894C8.23594918102006@news.news.demon.net"><FONT =
face=3DArial=20
size=3D2>news:bogus-5894C8.23594918102006@news.news.demon.net</FONT></A><=
FONT=20
face=3DArial size=3D2>...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt; "Peter Olcott" &lt;</FONT><A=20
href=3D"mailto:NoSpam@SeeScreen.com"><FONT face=3DArial=20
size=3D2>NoSpam@SeeScreen.com</FONT></A><FONT face=3DArial size=3D2>&gt; =

wrote:<BR>&gt;&gt; The Halting Problem too, is merely an ill-formed =
question,=20
nothing more,<BR>&gt;&gt; and nothing less. <BR>&gt; <BR>&gt; How do you =
deal=20
with the fact that the halting problem for some kinds of<BR>&gt; =
computation=20
*is* solvable?&nbsp; That's what complexity analysis is about.<BR>&gt; =
Any time=20
you make a database query, it will have gone through an =
optimizer<BR>&gt; that=20
solves the halting problem for the database query language (and =
does<BR>&gt;=20
considerably more than that).&nbsp; There is nothing at all ill-formed=20
<BR>&gt;=20
This works because database query languages can't do as much as =
Turing<BR>&gt;=20
machines or unbounded-memory abstract machines programmed in C =
can.&nbsp;=20
Read<BR>&gt; a book and you might see what the relevant difference=20
is.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
+-----------------------+</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
|</FONT></DIV>
<DIV><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
&nbsp;&nbsp;=20
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|</FONT=
></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>(What is the answer to this=20
quesion?)--+</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
question that make=20
it unsolvable?</FONT></DIV>
<DIV><BR><FONT face=3DArial size=3D2>&gt; <BR>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&nbsp; j-c&nbsp;=20
=3D=3D=3D=3D=3D=3D&nbsp; @&nbsp; =3D=3D=3D=3D=3D=3D&nbsp; purr . demon . =
co . uk&nbsp;=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>&gt; Jack Campin:&nbsp; 11 =
Third St, Newtongrange EH22 4PU,=20
Scotland | tel 0131 660 4760<BR>&gt; &lt;</FONT><A=20
href=3D"http://www.purr.demon.co.uk/jack/"><FONT face=3DArial=20
size=3D2>http://www.purr.demon.co.uk/jack/</FONT></A><FONT face=3DArial=20
size=3D2>&gt;&nbsp;&nbsp; for CD-ROMs and free | fax 0870 0554 =
975<BR>&gt; stuff:=20
Scottish music, food intolerance, &amp; Mac logic fonts | mob 07800 739=20
557</FONT></DIV></BODY></HTML>

------=_NextPart_000_0008_01C6F2E5.ECC84BE0--

 0
NoSpam266 (508)
10/18/2006 11:47:54 PM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> Peter Olcott wrote:
>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>> > Peter Olcott wrote:
>> >> What is the
>> >> official precise English language conclusion drawn from the results of the
>> >> mathematical analysis of the Halting Problem?
>> >
>> > Why not start by at least informing yourself of an exact mathematical
>> > statement of the theorem and its proof?
>> >
>> > MoeBlee
>> >
>>
>> That is not within my purpose. My purpose is to show that the Halting Problem
>> is
>> really nothing more than an ill-formed question.
>
> You know it's ill-formed but you don't know anything about the actual
> math of it. Right. Gotcha.
>
> MoeBlee
>

I know that the UTM form mathematically maps to the form that I provided.

 0
NoSpam266 (508)
10/18/2006 11:49:09 PM
"Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
news:slrnejddkn.297d.cmenzel@philebus.tamu.edu...
> On Wed, 18 Oct 2006 17:20:46 -0500, Peter Olcott <NoSpam@SeeScreen.com>
> said:
>>
>> "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
>> news:slrnejcnv9.297d.cmenzel@philebus.tamu.edu...
>>> On Wed, 18 Oct 2006 12:21:08 -0400, Paul E. Black <p.black@acm.org>
>>> said:
>>>>
>>>> Because of these experiences and the proofs I've seen, I am
>>>> skeptical of purported solutions to the Halting Problem.
>>>
>>> It's definitely a good thing to be skeptical of purported solutions
>>> to provably unsolvable problems!
>>>
>>>> True, the Halting Problem may be redefined such that there is a
>>>> solution,
>>>
>>> You can't redefine the Halting Problem; it is what it is.  The most
>>> you can do is decide to use the words "the Halting Problem" to mean
>>> some- thing other than what everyone else means by them.  Many
>>> unsolvable problems have been "solved" in this manner in this
>>> newsgroup. :-)
>>
>> Everyone else is taking them to mean something that they do not in
>> fact mean.
>
> So you're saying that these apparent crackpots really *aren't* claiming
> to have solved the Halting Problem / refuted Cantor's theorem /
> uncovered the flaw in G�del's proof / <your favorite crackpot project
> here>?  It sure *looks* like that's what they're claiming, since they
> say things like "The Halting Problem is solvable" and "I have identified
> the flaw in Cantor's/G�del's proof".  But like you say, maybe they mean
> something by those words other than what people who know what they are
> talking about mean by those words.
>
>> I wish that my 100% completely precise version of the English
>> language, LUCID existed,
>
> Name's taken, dude!  That's a shamep. ;-)
>
>> then I could explain what I mean once, and everyone would see. Because
>> this language does not exist, people slip and slide subtle nuances of
>> meaning, and miss my point from their slight equivocations of meaning.
>
> Ah, yes, it's all their fault.  Thing is, there's no slipping and
> sliding on nuances of meaning when it comes to the statement and
> analysis of the Halting Problem.  It's a piece of very simple, painfully
> clear mathematics.  Anyone making the sorts of claims you are making
> simply hasn't done their homework.
>
>> What is the official precise English language conclusion drawn from
>> the results of the mathematical analysis of the Halting Problem?
>> Isn't it something along the lines of "It is impossible to determine
>> the halting status of every element in the set of all programs"?
>
> Why say "every element in the set of all programs" when you could just
> say "every program"?  But no, that's not right, since, among lots of
> other things, it makes no reference to input.  Better is something along
> these lines:  There is no algorithm for determining, for every program P
> and input I, whether or not P halts on I.

But that is NOT what the halting proof shows. My whole point is that the above
conclusion can not be correctly drawn from the results of the Halting Problem.
What the Halting Problem shows, and the English conclusions that are drawn from
what the Halting Problem shows do not precisely correspond.

> But for this to be a
> *precise* English language expression of the proposition you want,
> you'll have to include, at least, the mathematical definitions of
> "algorithm", "program", "input", "program ... halts on input ...", and
> related notions like that of a program execution.  If you aren't using
> those definitions, you're probably either talking nonsense or you've
> simply changed the subject to something no one cares about.
>

 0
NoSpam266 (508)
10/18/2006 11:56:21 PM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:87ac3t8b3g.fsf@bsb.me.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:87wt6x8yc2.fsf@bsb.me.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>
>>>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>>> news:87lkneqm4p.fsf@bsb.me.uk...
>>>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>>>
>>> <big snip>
>>>>>>>>>>
>>>>>>>>>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>>>> Explain this proof within the context of the model that I provided.
>>>
>>> No thanks.  More formal methods are the only way to avoid these vague,
>>> hand-waving arguments.
>>>
>>
>> Or perhaps they are a way to make a model that only seems to
>> correspond to the actuality, with slight errors of the precise
>> mathematical mapping, thus creating the fallacy of equivocation.
>
> Perhaps.  How will you ever know?  When someone says something that
> "sounds reasonable"?  That was the point of my asking the questions you
> did not answer.  I am genuinely curious to know if you really think
> your vague words will persuade anyone here to change his/her mind and what
> kind of thing anyone here might say that would cause you to doubt your
> arguments.  I suspect that you don't really think anyone will be
> persuaded and that you are just enjoying a good troll.
>

The mathematical mapping between the mathematical conclusions drawn from the HP,
and the English language statements used to describe these conclusions is not
precisely correct. Further still the degree of this error is great.

> PS.  Please stop quoting sigs.  A biot of snipping would not go amiss
> either.

This is gibberish to me.

>
> --
> Ben.

 0
NoSpam266 (508)
10/19/2006 12:02:59 AM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:pUyZg.11247$Y24.7075@newsread4.news.pas.earthlink.net... > Peter Olcott wrote: >> "MoeBlee" <jazzmobe@hotmail.com> wrote in message >> news:1161210790.800534.60930@h48g2000cwc.googlegroups.com... >>> Peter Olcott wrote: >>>> What is the >>>> official precise English language conclusion drawn from the results of the >>>> mathematical analysis of the Halting Problem? >>> Why not start by at least informing yourself of an exact mathematical >>> statement of the theorem and its proof? >>> >>> MoeBlee >>> >> >> That is not within my purpose. My purpose is to show that the Halting Problem >> is really nothing more than an ill-formed question. > > The whole Halting Problem? There are large classes of computations that > provably halt. Indeed, there are algorithms that are known to halt for > every input. On the other hand, there are computations that can be > proved to not halt. Not only is the question interesting and > well-formed, it is frequently answered. > > In between, there is a set of computations for which neither halting nor > not-halting has been proved. > > The non-decidability of the halting problem tells us that we can never > reduce that set to the empty set. That seems to be a very precise English language statement that is most typically used to describe the results of the HP. It is this statement that I refute. I may be wrong, I have been wrong before, but, it is still this specific statement that I refute. The HP can be decided, yet the answer can not be restricted to YES or NO because the question is not a YES or NO question. The true meaning of the HP goes straight to the essence of truth itself, and thus the true essence of reality, as opposed to and contrast with misconceptions and illusions. > > As far as I can tell, you agree with that conclusion. You don't seem to > have contributed anything interesting, such as an algorithm for deciding > whether a computation is one that can never be proved to halt or not-halt. > > Patricia  0 NoSpam266 (508) 10/19/2006 12:23:24 AM Peter Olcott wrote: > I know that the UTM form mathematically maps to the form that I provided. Sure you do. MoeBlee  0 jazzmobe (307) 10/19/2006 12:29:52 AM Peter Olcott wrote: > "Patricia Shanahan" <pats@acm.org> wrote in message > news:pUyZg.11247$Y24.7075@newsread4.news.pas.earthlink.net...
>> Peter Olcott wrote:
>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>> Peter Olcott wrote:
>>>>> What is the
>>>>> official precise English language conclusion drawn from the results of the
>>>>> mathematical analysis of the Halting Problem?
>>>> Why not start by at least informing yourself of an exact mathematical
>>>> statement of the theorem and its proof?
>>>>
>>>> MoeBlee
>>>>
>>> That is not within my purpose. My purpose is to show that the Halting Problem
>>> is really nothing more than an ill-formed question.
>> The whole Halting Problem? There are large classes of computations that
>> provably halt. Indeed, there are algorithms that are known to halt for
>> every input. On the other hand, there are computations that can be
>> proved to not halt. Not only is the question interesting and
>> well-formed, it is frequently answered.
>>
>> In between, there is a set of computations for which neither halting nor
>> not-halting has been proved.
>>
>> The non-decidability of the halting problem tells us that we can never
>> reduce that set to the empty set.
>
> That seems to be a very precise English language statement that is most
> typically used to describe the results of the HP. It is this statement that I
> refute. I may be wrong, I have been wrong before, but, it is still this specific
> statement that I refute. The HP can be decided, yet the answer can not be
> restricted to YES or NO because the question is not a YES or NO question.
>
> The true meaning of the HP goes straight to the essence of truth itself, and
> thus the true essence of reality, as opposed to and contrast with misconceptions
> and illusions.
>

I'm not sure what you are disagreeing with. How does your statement
differ from the idea that, for any claimed halting decision procedure,
there are some computations for which it cannot provide a yes/no answer?

Patricia
 0
pats (3556)
10/19/2006 12:57:22 AM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:S3AZg.15658$UG4.11496@newsread2.news.pas.earthlink.net... > Peter Olcott wrote: >> "Patricia Shanahan" <pats@acm.org> wrote in message >> news:pUyZg.11247$Y24.7075@newsread4.news.pas.earthlink.net...
>>> Peter Olcott wrote:
>>>> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
>>>>> Peter Olcott wrote:
>>>>>> What is the
>>>>>> official precise English language conclusion drawn from the results of
>>>>>> the
>>>>>> mathematical analysis of the Halting Problem?
>>>>> Why not start by at least informing yourself of an exact mathematical
>>>>> statement of the theorem and its proof?
>>>>>
>>>>> MoeBlee
>>>>>
>>>> That is not within my purpose. My purpose is to show that the Halting
>>>> Problem is really nothing more than an ill-formed question.
>>> The whole Halting Problem? There are large classes of computations that
>>> provably halt. Indeed, there are algorithms that are known to halt for
>>> every input. On the other hand, there are computations that can be
>>> proved to not halt. Not only is the question interesting and
>>> well-formed, it is frequently answered.
>>>
>>> In between, there is a set of computations for which neither halting nor
>>> not-halting has been proved.
>>>
>>> The non-decidability of the halting problem tells us that we can never
>>> reduce that set to the empty set.
>>
>> That seems to be a very precise English language statement that is most
>> typically used to describe the results of the HP. It is this statement that I
>> refute. I may be wrong, I have been wrong before, but, it is still this
>> specific statement that I refute. The HP can be decided, yet the answer can
>> not be restricted to YES or NO because the question is not a YES or NO
>> question.
>>
>> The true meaning of the HP goes straight to the essence of truth itself, and
>> thus the true essence of reality, as opposed to and contrast with
>> misconceptions and illusions.
>>
>
> I'm not sure what you are disagreeing with. How does your statement
> differ from the idea that, for any claimed halting decision procedure,
> there are some computations for which it cannot provide a yes/no answer?
>
> Patricia

What it boils down to is this, (at least within the scope of the HP) it is not
that there exists some problems too difficult to be solved by computation, it is
merely the case that some ill-formed questions have no correct answer.

 0
NoSpam266 (508)
10/19/2006 1:06:18 AM
On Wed, 18 Oct 2006 18:56:21 -0500, Peter Olcott <NoSpam@SeeScreen.com>
said:
>> ...
>>> What is the official precise English language conclusion drawn from
>>> the results of the mathematical analysis of the Halting Problem?
>>> Isn't it something along the lines of "It is impossible to determine
>>> the halting status of every element in the set of all programs"?
>>
>> Why say "every element in the set of all programs" when you could just
>> say "every program"?  But no, that's not right, since, among lots of
>> other things, it makes no reference to input.  Better is something along
>> these lines:  There is no algorithm for determining, for every program P
>> and input I, whether or not P halts on I.
>
> But that is NOT what the halting proof shows.

Well, 'fraid it is (modulo mathematically precise definitions of the
relevant concepts).  The Halting Problem is this: for any given program
P and input I, to decide whether P halts on I.  And what has been proved
is this: the Halting Problem is unsolvable; there is no decision
procedure that solves this problem.

> My whole point is that the above conclusion can not be correctly drawn
> from the results of the Halting Problem.  What the Halting Problem
> shows, and the English conclusions that are drawn from what the
> Halting Problem shows do not precisely correspond.

If that is your point, then you understand neither the Halting Problem
nor the proof of its unsolvability.  But the great thing is, you can!
There's lots of interesting texts where you can learn about it.  Don't
you want to understand what you think you're talking about?  Cuz right
now you don't.  Really.  I am not kidding.

 0
cmenzel (185)
10/19/2006 1:37:15 AM
Peter Olcott wrote:
....
> What it boils down to is this, (at least within the scope of the HP) it is not
> that there exists some problems too difficult to be solved by computation, it is
> merely the case that some ill-formed questions have no correct answer.
>
>

I might agree with that formulation if you presented an algorithm for
deciding if something is an ill-formed question. I've asked for it often
enough, without result, that by now I'm convinced you do not have any
algorithm for identifying what you call an ill-formed question, or
distinguishing them from questions you consider well-formed.

I'm not surprised, because I strongly suspect that even if you defined
what you consider to be an ill-formed question, deciding the set of
ill-formed questions would still be halting-problem equivalent, and
cannot depend on the existence of an ill-formed question decider.

How are we supposed to avoid asking ill-formed questions, or to find out
that we have asked one, without an algorithm for deciding if a question
is ill-formed?

Patricia

 0
pats (3556)
10/19/2006 1:53:44 AM
Peter Olcott wrote:
> it is
> merely the case that some ill-formed questions have no correct answer.

There is no "ill-formed question" involved in the theorem that, to
quote a standard textbook, "there exists a Turing machine whose halting
problem is recursively unsolvable."

Whatever else goes in informal discussion about that theorem, you at
least do recognize that the above is a description of a theorem (and
that there's nothing such as an "ill formed question") in the proof of
such mathematical theorems, right?

MoeBlee

 0
jazzmobe (307)
10/19/2006 1:56:07 AM
In article <pUyZg.11247$Y24.7075@newsread4.news.pas.earthlink.net>, Patricia Shanahan <pats@acm.org> wrote: > Peter Olcott wrote: > > "MoeBlee" <jazzmobe@hotmail.com> wrote in message > > news:1161210790.800534.60930@h48g2000cwc.googlegroups.com... > >> Peter Olcott wrote: > >>> What is the > >>> official precise English language conclusion drawn from the results of > >>> the > >>> mathematical analysis of the Halting Problem? > >> Why not start by at least informing yourself of an exact mathematical > >> statement of the theorem and its proof? > >> > >> MoeBlee > >> > > > > That is not within my purpose. My purpose is to show that the Halting > > Problem is > > really nothing more than an ill-formed question. > > The whole Halting Problem? There are large classes of computations that > provably halt. Indeed, there are algorithms that are known to halt for > every input. On the other hand, there are computations that can be > proved to not halt. Not only is the question interesting and > well-formed, it is frequently answered. > > In between, there is a set of computations for which neither halting nor > not-halting has been proved. > > The non-decidability of the halting problem tells us that we can never > reduce that set to the empty set. > > As far as I can tell, you agree with that conclusion. You don't seem to > have contributed anything interesting, such as an algorithm for deciding > whether a computation is one that can never be proved to halt or not-halt. <pedantry> A proof that there is no proof that some computation halts implies that the computation in fact does not halt. </pedantry> And IMO, you are very unlikely to provoke any entertaining fallacies from PO. > Patricia  0 see80 (286) 10/19/2006 1:57:21 AM Peter Olcott says... >What it boils down to is this, (at least within the scope of the HP) >it is not that there exists some problems too difficult to be solved >by computation, it is merely the case that some ill-formed questions >have no correct answer. I'm afraid to ask, but what is ill-formed about the question: Does polynomial equation P have any positive integer solutions? The halting problem is provably equivalent to that problem. For example, the polynomial equation x^2 + y^2 = z^2 has infinitely many integer solutions, for example x=3, y=4, z=5. In contrast, the equation x^3 + y^3 = z^3 has no positive integer solutions. It would be nice if we had a computer program that whenever it is given a polynomial equation, returns "true" if the equation has integer solutions, and returns "false" if it does not. What is ill-formed about the question "Does this polynomial equation have any positive integer solutions?" Well, it is provably the case that there is no deterministic computer program that can solve this problem. This problem is provably equivalent to the halting problem. -- Daryl McCullough Ithaca, NY  0 10/19/2006 2:00:16 AM "Patricia Shanahan" <pats@acm.org> wrote in message news:IUAZg.9011$Lv3.6307@newsread1.news.pas.earthlink.net...
> Peter Olcott wrote:
> ...
>> What it boils down to is this, (at least within the scope of the HP) it is
>> not that there exists some problems too difficult to be solved by
>> computation, it is merely the case that some ill-formed questions have no
>
> I might agree with that formulation if you presented an algorithm for
> deciding if something is an ill-formed question. I've asked for it often
> enough, without result, that by now I'm convinced you do not have any
> algorithm for identifying what you call an ill-formed question, or
> distinguishing them from questions you consider well-formed.
>
> I'm not surprised, because I strongly suspect that even if you defined
> what you consider to be an ill-formed question, deciding the set of
> ill-formed questions would still be halting-problem equivalent, and
> cannot depend on the existence of an ill-formed question decider.
>
> How are we supposed to avoid asking ill-formed questions, or to find out
> that we have asked one, without an algorithm for deciding if a question
> is ill-formed?
>
> Patricia
>

It is not that difficult really. I will explain how an ill-formed question can
be determined in terms of the example below. See the end of the example for the
analytical commentary.

void LoopIfHalts(string SourceCode)  {
if ( WillHalt(SourceCode, SourceCode) == TRUE )
while (TRUE)    // loop forever
;
else
return;
}

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

LoopIfHalts(LoopIfHalts);

// ANALYTICAL COMMENTARY
WillHalt() is provided with the source code of LoopIfHalts(), as input, so
WillHalt() can see exactly how the return value of the invocation of itself
under test will be used to toggle the result of the analysis of the invocation
of itself under test.  WillHalt() can see that LoopIfHalts() is toggling the
result of the invocation of itself under test to invalidate the analysis of the
invocation of itself under test.

Therefore WillHalt() can determine that the question:   "Does
LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and is thus
an erroneously formed because it is asking a YES or NO question that has no

If you don't agree with this, then please point out every step and every detail
that you do not agree with.

 0
NoSpam266 (508)
10/19/2006 2:45:19 AM
"MoeBlee" <jazzmobe@hotmail.com> wrote in message
> Peter Olcott wrote:
>> it is
>> merely the case that some ill-formed questions have no correct answer.
>
> There is no "ill-formed question" involved in the theorem that, to
> quote a standard textbook, "there exists a Turing machine whose halting
> problem is recursively unsolvable."
>

It is only unsolvable, because it is ill-formed. One could say that all
ill-formed questions are unsolvable questions, this leaves out a crucial detail.
How tall are you, (blue or green) ? is an unsolvable math problem, more
importantly it is an ill-formed question.

> Whatever else goes in informal discussion about that theorem, you at
> least do recognize that the above is a description of a theorem (and
> that there's nothing such as an "ill formed question") in the proof of
> such mathematical theorems, right?
>
> MoeBlee
>
It matters not whether an ill-formed question is posed in natural language or in
the language of mathematical formalism, in either case it is still an ill-formed
question.

 0
NoSpam266 (508)
10/19/2006 2:54:28 AM
Peter Olcott says...

>What it boils down to is this, (at least within the scope of the HP)
>it is not that there exists some problems too difficult to be solved
>by computation, it is merely the case that some ill-formed questions

Here's another question that is provably equivalent to the halting
problem.

Let's define a little game with symbols.

A term is something formed from the symbols S and K
according to the following rules:

S is a term.
K is a term.
If x and y are expressions, then so is (x y).

Now, we give the following "rewrite rules" on terms:

1. If x, y, and z are any terms, then (((S x) y) z)
can be rewritten as ((x z) (y z)).

2. If x and y are any terms, then ((K x) y)
can be rewritten as x.

(((S K) K) S)

we can rewrite it using rule 1 as

((K S) (K S))

then we can rewrite it using rule 2 as

S

Define a term as being in "normal form" if
neither of the above rules apply. For example,
the following terms are all in normal form:

1. S
2. K
3. ((S K) K)
4. (K S)

Finally, define a term to be "normalizable" if
it is possible to convert it (using the rewrite
rules) into a term in normal form. It is called
"unnormalizable" if you keep on applying the
rules without every reaching a normal form.
An example of an unnormalizable term is the
following:

(((S ((S K) K)) ((S K) K)) ((S ((S K) K)) ((S K) K)))

So here is a question that is provably unsolvable
by any deterministic computer program:

There is no computer program which, given any term,
will output "true" if that term is normalizable,
and "false" if it is not.

This is provably equivalent to the halting problem.
What is ill-formed about the question of whether
a term is normalizable?

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 2:55:03 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:eh6m7g02hkl@drn.newsguy.com...
> Peter Olcott says...
>
>>What it boils down to is this, (at least within the scope of the HP)
>>it is not that there exists some problems too difficult to be solved
>>by computation, it is merely the case that some ill-formed questions
>
> I'm afraid to ask, but what is ill-formed about the question:
>

>   Does polynomial equation P have any positive integer solutions?
>
> The halting problem is provably equivalent to that problem.
>
> For example, the polynomial equation
>
>     x^2 + y^2 = z^2
>
> has infinitely many integer solutions, for example x=3, y=4, z=5.
> In contrast, the equation
>
>    x^3 + y^3 = z^3
>
> has no positive integer solutions.
>
> It would be nice if we had a computer program that whenever it
> is given a polynomial equation, returns "true" if the equation
> has integer solutions, and returns "false" if it does not. What
> is ill-formed about the question "Does this polynomial equation
> have any positive integer solutions?"
>
> Well, it is provably the case that there is no deterministic
> computer program that can solve this problem. This problem
> is provably equivalent to the halting problem.
>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/19/2006 2:56:15 AM
Peter Olcott says...

>It is not that difficult really. I will explain how an ill-formed question can
>be determined in terms of the example below. See the end of the example for the
>analytical commentary.
>
>void LoopIfHalts(string SourceCode)  {
>     if ( WillHalt(SourceCode, SourceCode) == TRUE )
>        while (TRUE)    // loop forever
>            ;
>     else
>        return;
>}
>
>
>int WillHalt(string SourceCode, string InputData)   {
>    if (MalignantSelfReference(SourceCode, InputData))
>        throw(MALIGNANT_SELF_REFERENCE);
>    if ( TheProgramWillHalt(SourceCode, InputData) )
>        return TRUE;
>    else
>        return FALSE;
>}

You are assuming that there is a program
MalignantSelfReference(SourceCode, InputData)
which will return true if executing that
particular source code on that input data
results in a "malignant self reference".

But then determining whether something involves
"malignant self reference" is, in fact,
equivalent to solving the halting problem.

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 3:11:18 AM
Peter Olcott wrote:
> "Patricia Shanahan" <pats@acm.org> wrote in message
....
>> How are we supposed to avoid asking ill-formed questions, or to find out
>> that we have asked one, without an algorithm for deciding if a question
>> is ill-formed?
>>
>> Patricia
>>
>
> It is not that difficult really. I will explain how an ill-formed question can
> be determined in terms of the example below. See the end of the example for the
> analytical commentary.
>
> void LoopIfHalts(string SourceCode)  {
>      if ( WillHalt(SourceCode, SourceCode) == TRUE )
>         while (TRUE)    // loop forever
>             ;
>      else
>         return;
> }
>
>
> int WillHalt(string SourceCode, string InputData)   {
>     if (MalignantSelfReference(SourceCode, InputData))
>         throw(MALIGNANT_SELF_REFERENCE);
>     if ( TheProgramWillHalt(SourceCode, InputData) )
>         return TRUE;
>     else
>         return FALSE;
> }
>
>
> LoopIfHalts(LoopIfHalts);
>
> // ANALYTICAL COMMENTARY
> WillHalt() is provided with the source code of LoopIfHalts(), as input, so

Not necessarily. It can be provided with the source code of any program
that is equivalent to LoopIfHalts in the sense of halting on SoureCode
if, and only if, SourceCode itself does so:

if ( WillHalt(ObfuscateHorribly(SourceCode),SourceCode) == True )

For example, ObfuscateHorribly may translate SourceCode to Snobol, and
wrap it up with a Snobol interpreter.

> WillHalt() can see exactly how the return value of the invocation of itself
> under test will be used to toggle the result of the analysis of the invocation
> of itself under test.  WillHalt() can see that LoopIfHalts() is toggling the
> result of the invocation of itself under test to invalidate the analysis of the
> invocation of itself under test.

How does it recognize programs equivalent, but not identical, to itself?

Moreover, you need to consider far more complicated LoopIfHalts
implementations. The result of the WillHalt test may be run through all
sorts of calculations before ultimately controlling a halt or loop decision.

The loop can be far subtler. It might, for example, be a search for the
largest prime number.

>
> Therefore WillHalt() can determine that the question:   "Does
> LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and is thus
> an erroneously formed because it is asking a YES or NO question that has no
> correct YES or NO answer.
>
> If you don't agree with this, then please point out every step and every detail
> that you do not agree with.

I've written out a couple of my objections. Essentially, I believe
MalignantSelfReference has to perform two very difficult tests:

1. Determine whether two programs, its source code and its first
parameter, have the same halting behavior on a given input.

2. Find out whether its result ever affects a loop-or-terminate decision.

Patricia
 0
pats (3556)
10/19/2006 3:21:15 AM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:LaCZg.9137Lv3.7949@newsread1.news.pas.earthlink.net... > Peter Olcott wrote: >> "Patricia Shanahan" <pats@acm.org> wrote in message > ... >>> How are we supposed to avoid asking ill-formed questions, or to find out >>> that we have asked one, without an algorithm for deciding if a question >>> is ill-formed? >>> >>> Patricia >>> >> >> It is not that difficult really. I will explain how an ill-formed question >> can be determined in terms of the example below. See the end of the example >> for the analytical commentary. >> >> void LoopIfHalts(string SourceCode) { >> if ( WillHalt(SourceCode, SourceCode) == TRUE ) >> while (TRUE) // loop forever >> ; >> else >> return; >> } >> >> >> int WillHalt(string SourceCode, string InputData) { >> if (MalignantSelfReference(SourceCode, InputData)) >> throw(MALIGNANT_SELF_REFERENCE); >> if ( TheProgramWillHalt(SourceCode, InputData) ) >> return TRUE; >> else >> return FALSE; >> } >> >> >> LoopIfHalts(LoopIfHalts); >> >> // ANALYTICAL COMMENTARY >> WillHalt() is provided with the source code of LoopIfHalts(), as input, so > > Not necessarily. It can be provided with the source code of any program > that is equivalent to LoopIfHalts in the sense of halting on SoureCode > if, and only if, SourceCode itself does so: > > if ( WillHalt(ObfuscateHorribly(SourceCode),SourceCode) == True ) > > For example, ObfuscateHorribly may translate SourceCode to Snobol, and > wrap it up with a Snobol interpreter. > > >> WillHalt() can see exactly how the return value of the invocation of itself >> under test will be used to toggle the result of the analysis of the >> invocation of itself under test. WillHalt() can see that LoopIfHalts() is >> toggling the result of the invocation of itself under test to invalidate the >> analysis of the invocation of itself under test. > > How does it recognize programs equivalent, but not identical, to itself? > > Moreover, you need to consider far more complicated LoopIfHalts > implementations. The result of the WillHalt test may be run through all > sorts of calculations before ultimately controlling a halt or loop decision. I can do as others have done and complicate the problem beyond all possible recognition. Instead I chose to boil the problem down to its most fundamental essence. Try to address the problem as I have framed it, and refrain from attempts to change this framework. The ability to complicate the example so that no one can understand it, is not a valid form of refutation. Within the exact and precise framework that I have defined the Halting Problem, is it now clear, that at least within the context of this framework that the question: "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is thus erroneously formed because it is asking a YES or NO question that has no correct YES or NO answer. > > The loop can be far subtler. It might, for example, be a search for the > largest prime number. > >> >> Therefore WillHalt() can determine that the question: "Does >> LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is >> thus an erroneously formed because it is asking a YES or NO question that has >> no correct YES or NO answer. >> >> If you don't agree with this, then please point out every step and every >> detail that you do not agree with. > > I've written out a couple of my objections. Essentially, I believe > MalignantSelfReference has to perform two very difficult tests: Not in the form of the fundamental essence that I have framed it. In the precise form that I framed the problem it becomes obviously clear that asking the question: "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is thus erroneously formed because it is asking a YES or NO question that has no correct YES or NO answer. If you do not see this, within the specific context of this precisely defined framework, what point is it that you disagree with? > > 1. Determine whether two programs, its source code and its first parameter, > have the same halting behavior on a given input. > > 2. Find out whether its result ever affects a loop-or-terminate decision. > > Patricia Maybe it might help if you don't begin your response starting with the goal of refutation?  0 NoSpam266 (508) 10/19/2006 4:10:12 AM Peter Olcott wrote: .... > I can do as others have done and complicate the problem beyond all possible > recognition. Instead I chose to boil the problem down to its most fundamental > essence. Try to address the problem as I have framed it, and refrain from > attempts to change this framework. The ability to complicate the example so that > no one can understand it, is not a valid form of refutation. > > Within the exact and precise framework that I have defined the Halting Problem, > is it now clear, that at least within the context of this framework that the > question: > "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is > thus erroneously formed because it is asking a YES or NO question that has no > correct YES or NO answer. .... If you are defining your own problem, you can solve it any way you like, but please don't call it "the Halting Problem" unless you really do mean a decision procedure for the set of terminating Turing machine computations. > Maybe it might help if you don't begin your response starting with the goal of > refutation? It would not help at all with testing the validity of your ideas, which is my objective. If you are trying to test a program, do you feed it only the easy cases, or do you feed it deliberately difficult cases, such as the largest and smallest permitted inputs? Patricia  0 pats (3556) 10/19/2006 4:33:30 AM >>> The Halting Problem too, is merely an ill-formed question, nothing more, >>> and nothing less. >> How do you deal with the fact that the halting problem for some kinds of >> computation *is* solvable? That's what complexity analysis is about. >> Any time you make a database query, it will have gone through an optimizer >> that solves the halting problem for the database query language (and does >> considerably more than that). There is nothing at all ill-formed about >> asking how long it will take to get an answer. >> This works because database query languages can't do as much as Turing >> machines or unbounded-memory abstract machines programmed in C can. Read >> a book and you might see what the relevant difference is. > > +-----------------------+ > | | > V | > (What is the answer to this quesion?)--+ > > What is it about the about above question that make it unsolvable? That's a pretty boring question. The difference between database query languages and Turing machines is interesting, important, and *written up in books* which you would be better occupied reading than flinging around defensive bullshit like this. What's stopping you from reading about computability? ============== j-c ====== @ ====== purr . demon . co . uk ============== Jack Campin: 11 Third St, Newtongrange EH22 4PU, Scotland | tel 0131 660 4760 <http://www.purr.demon.co.uk/jack/> for CD-ROMs and free | fax 0870 0554 975 stuff: Scottish music, food intolerance, & Mac logic fonts | mob 07800 739 557  0 bogus20 (22) 10/19/2006 9:55:03 AM "Peter Olcott" <NoSpam@SeeScreen.com> writes: > "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message > news:fwepscp1xz4.fsf@collins.inf.ed.ac.uk... >> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >> >>> "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message >>> news:fwezmbu0xdj.fsf@collins.inf.ed.ac.uk... >>>> "Peter Olcott" <NoSpam@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 >>> >>> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html >>> None-the-less it is this mode that I am using in my investigation. I >>> understand Turing Machines, and UTM's, both of these would mathematically >>> map to this alternative model. >> >> You can do what you want in your own work, obviously. >> >> What is the relevance of the link you just cited to my observation >> about the normal use in computer science? >> In that link, the word "problem" is used as I suggested. >> >> >> -- >> Alan Smaill > > I am using the sort of model that the link provides as my basis, > rather than the > formal mathematical model. > > int WillHalt(string SourceCode, string InputData) { > if (MalignantSelfReference(SourceCode, InputData)) > throw(MALIGNANT_SELF_REFERENCE); > if ( TheProgramWillHalt(SourceCode, InputData) ) > return TRUE; > else > return FALSE; > } > > This defeats the "problem" aspect of the Halting Problem. You have simply ignored my question. Yes, you can tackle what problems you want and call them what you want from your own piont of view. Yet again, do you agree that in standard usage in computer science, the terminology "Halting Problem" uses "problem" in the same way as in the terminology "Travelling Salesman Problem"? This is a small enough point which for some reason you seem determined to ignore. -- Alan Smaill  0 smaill1 (89) 10/19/2006 10:39:08 AM "Patricia Shanahan" <pats@acm.org> wrote in message news:ueDZg.11396Y24.6326@newsread4.news.pas.earthlink.net...
> Peter Olcott wrote:
> ...
>> I can do as others have done and complicate the problem beyond all  possible
>> recognition. Instead I chose to boil the problem down to its most fundamental
>> essence. Try to address the problem as I have framed it, and refrain from
>> attempts to change this framework. The ability to complicate the example so
>> that no one can understand it, is not a valid form of refutation.
>>
>> Within the exact and precise framework that I have defined the Halting
>> Problem, is it now clear, that at least within the context of this framework
>> that the question:
>> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and
>> is thus erroneously formed because it is asking a YES or NO question that has
>> no correct YES or NO answer.
> ...
>
> If you are defining your own problem, you can solve it any way you like,
> but please don't call it "the Halting Problem" unless you really do mean
> a decision procedure for the set of terminating Turing machine computations.
>
>> Maybe it might help if you don't begin your response starting with the goal
>> of refutation?
>
> It would not help at all with testing the validity of your ideas, which
> is my objective.
>
> If you are trying to test a program, do you feed it only the easy cases,
> or do you feed it deliberately difficult cases, such as the largest and
> smallest permitted inputs?
>
> Patricia

So you agree that my example shows that within the specific context of this
example I have shown that this specific form of a Halting Problem is merely the
ill-formed question of:
"Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and is
thus erroneously formed because it is asking a YES or NO question that has no

If you agree with this please say so, if you don't agree with this then please
explain why you do not agree.

Apparently you do not agree that this example of a Halting Problem
mathematically maps tot he original Halting Problem. I will proceed to this step
only after we have formed agreement on the preceding step. Effective
communication must proceed one step at a time, or it does not work effectively.

 0
NoSpam266 (508)
10/19/2006 12:14:14 PM
"Jack Campin - bogus address" <bogus@purr.demon.co.uk> wrote in message
news:bogus-A85378.10550219102006@news.news.demon.net...
>>>> The Halting Problem too, is merely an ill-formed question, nothing more,
>>>> and nothing less.
>>> How do you deal with the fact that the halting problem for some kinds of
>>> computation *is* solvable?  That's what complexity analysis is about.
>>> Any time you make a database query, it will have gone through an optimizer
>>> that solves the halting problem for the database query language (and does
>>> considerably more than that).  There is nothing at all ill-formed about
>>> This works because database query languages can't do as much as Turing
>>> machines or unbounded-memory abstract machines programmed in C can.  Read
>>> a book and you might see what the relevant difference is.
>>
>>                +-----------------------+
>>                |                       |
>>                V                       |
>> (What is the answer to this quesion?)--+
>>
>> What is it about the about above question that make it unsolvable?
>
> That's a pretty boring question.  The difference between database query
> languages and Turing machines is interesting, important, and *written
> up in books* which you would be better occupied reading than flinging
> around defensive bullshit like this.
>

I have read about it. In order to make my point effectively I must boil the
original problem down to its most fundamental essence and achieve agreement on
this point, and the and only then proceed to show that this simplified version
mathematically maps to the original. Now can you please answer the original
question, that it is boring is merely evasive.
>
> ==============  j-c  ======  @  ======  purr . demon . co . uk  ==============
> Jack Campin:  11 Third St, Newtongrange EH22 4PU, Scotland | tel 0131 660 4760
> <http://www.purr.demon.co.uk/jack/>   for CD-ROMs and free | fax 0870 0554 975
> stuff: Scottish music, food intolerance, & Mac logic fonts | mob 07800 739 557

 0
NoSpam266 (508)
10/19/2006 12:16:55 PM
"Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message
news:fwehcy01tf7.fsf@collins.inf.ed.ac.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message
>> news:fwepscp1xz4.fsf@collins.inf.ed.ac.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>
>>>> "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message
>>>> news:fwezmbu0xdj.fsf@collins.inf.ed.ac.uk...
>>>>> "Peter Olcott" <NoSpam@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
>>>>
>>>>    http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>>>>   None-the-less it is this mode that I am using in my investigation. I
>>>> understand Turing Machines, and UTM's, both of these would mathematically
>>>> map to this alternative model.
>>>
>>> You can do what you want in your own work, obviously.
>>>
>>> What is the relevance of the link you just cited to my observation
>>> about the normal use in computer science?
>>> In that link, the word "problem" is used as I suggested.
>>>
>>>
>>> --
>>> Alan Smaill
>>
>> I am using the sort of model that the link provides as my basis,
>> rather than the
>> formal mathematical model.
>>
>> int WillHalt(string SourceCode, string InputData)   {
>>     if (MalignantSelfReference(SourceCode, InputData))
>>         throw(MALIGNANT_SELF_REFERENCE);
>>     if ( TheProgramWillHalt(SourceCode, InputData) )
>>         return TRUE;
>>     else
>>         return FALSE;
>> }
>>
>> This defeats the "problem" aspect of the Halting Problem.
>
> You have simply ignored my question.
> Yes, you can tackle what problems you want and call them what
> you want from your own piont of view.
>
> Yet again, do you agree that in standard usage in computer science,
> the terminology "Halting Problem" uses "problem" in the same way
> as in the terminology "Travelling Salesman Problem"?
>
> This is a small enough point which for some reason you
> seem determined to ignore.
>
> --
> Alan Smaill

In order for me to cause comprehension to occur, I must insist on making one
point at a time, and not allow the process to go off on any tangents. Please
analyze the  ANALYTICAL COMMENTARY mentioned below, as it applies within the
specific context of this single example. Whether or not this example
mathematically maps to the UTM form of the Halting Problem or any other form of
the HP will only be addressed after this example has been fully addressed.

void LoopIfHalts(string SourceCode)  {
if ( WillHalt(SourceCode, SourceCode) == TRUE )
while (TRUE)    // loop forever
;
else
return;
}

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

LoopIfHalts(LoopIfHalts);

// ANALYTICAL COMMENTARY
WillHalt() is provided with the source code of LoopIfHalts(), as input, so
WillHalt() can see exactly how the return value of the invocation of itself
under test will be used to toggle the result of the analysis of the invocation
of itself under test.  WillHalt() can see that LoopIfHalts() is toggling the
result of the invocation of itself under test to invalidate the analysis of the
invocation of itself under test.

Therefore WillHalt() can determine that the question:
"Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and is
thus erroneously formed because it is asking a YES or NO question that has no

If you don't agree with this, then please point out every step and every detail
that you do not agree with. Please do not change the subject to anything at all
outside of the scope of this specifically focused example. Whether or not this
form of a halting problem mathematically maps to any other form will only be
addressed after this example has been fully explored.

 0
NoSpam266 (508)
10/19/2006 12:29:54 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:eh6qcm02r5d@drn.newsguy.com...
> Peter Olcott says...
>
>>It is not that difficult really. I will explain how an ill-formed question can
>>be determined in terms of the example below. See the end of the example for
>>the
>>analytical commentary.
>>
>>void LoopIfHalts(string SourceCode)  {
>>     if ( WillHalt(SourceCode, SourceCode) == TRUE )
>>        while (TRUE)    // loop forever
>>            ;
>>     else
>>        return;
>>}
>>
>>
>>int WillHalt(string SourceCode, string InputData)   {
>>    if (MalignantSelfReference(SourceCode, InputData))
>>        throw(MALIGNANT_SELF_REFERENCE);
>>    if ( TheProgramWillHalt(SourceCode, InputData) )
>>        return TRUE;
>>    else
>>        return FALSE;
>>}
>
> You are assuming that there is a program
> MalignantSelfReference(SourceCode, InputData)
> which will return true if executing that
> particular source code on that input data
> results in a "malignant self reference".
>
> But then determining whether something involves
> "malignant self reference" is, in fact,
> equivalent to solving the halting problem.
>
> --
> Daryl McCullough
> Ithaca, NY
>

I am assuming nothing. I have shown step by step point by point, item by item ,
exactly and precisely how such a program could be constructed within the precise
focus of this specific example. Please restrict all discussion to this specific
example, and do not raise any issue pertaining to whether or not this example of
a halting problem mathematically maps to any other form of a HP. these will be
addressed at a later late, provided that we reach agreement on this example. If
we do not reach agreement on this example all these other points become moot.

LoopIfHalts(LoopIfHalts);

// ANALYTICAL COMMENTARY
WillHalt() is provided with the source code of LoopIfHalts(), as input, so
WillHalt() can see exactly how the return value of the invocation of itself
under test will be used to toggle the result of the analysis of the invocation
of itself under test.  WillHalt() can see that LoopIfHalts() is toggling the
result of the invocation of itself under test to invalidate the analysis of the
invocation of itself under test.

Therefore WillHalt() can determine that the question:
"Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and is
thus erroneously formed because it is asking a YES or NO question that has no

 0
NoSpam266 (508)
10/19/2006 12:36:15 PM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message
> news:fwehcy01tf7.fsf@collins.inf.ed.ac.uk...
>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
....
>>> I am using the sort of model that the link provides as my basis,
>>> rather than the
>>> formal mathematical model.
>>>
>>> int WillHalt(string SourceCode, string InputData)   {
>>>     if (MalignantSelfReference(SourceCode, InputData))
>>>         throw(MALIGNANT_SELF_REFERENCE);
>>>     if ( TheProgramWillHalt(SourceCode, InputData) )
>>>         return TRUE;
>>>     else
>>>         return FALSE;
>>> }
>>>
>>> This defeats the "problem" aspect of the Halting Problem.
>>
>> You have simply ignored my question.
>> Yes, you can tackle what problems you want and call them what
>> you want from your own piont of view.
>>
>> Yet again, do you agree that in standard usage in computer science,
>> the terminology "Halting Problem" uses "problem" in the same way
>> as in the terminology "Travelling Salesman Problem"?
>>
>> This is a small enough point which for some reason you
>> seem determined to ignore.
>>
>> --
>> Alan Smaill
>
> In order for me to cause comprehension to occur, I must insist on making one
> point at a time, and not allow the process to go off on any tangents.

You will I hope allow that comprehension involves the person
you are addressing as well as the person trying to get ideas across.

I cannot comprehend why you want to avoid answering a simple
yes or no to my question. Your answer would help me to see where
you are coming from, either way.

--
Alan Smaill
 0
smaill1 (89)
10/19/2006 12:47:41 PM
Peter Olcott says...

>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote

>> You are assuming that there is a program
>> MalignantSelfReference(SourceCode, InputData)
>> which will return true if executing that
>> particular source code on that input data
>> results in a "malignant self reference".
>>
>> But then determining whether something involves
>> "malignant self reference" is, in fact,
>> equivalent to solving the halting problem.

>I am assuming nothing. I have shown step by step point by point,
>item by item, exactly and precisely how such a program could be
>constructed within the precise focus of this specific example.

What you have described is perhaps a way to detect *explicit*
self-reference. However, given any computer program, there are
infinitely many programs that do the exact same thing, but have
different source codes. It is not possible to detect that
two programs are, in fact, equivalent programs.

In light of that, consider your proposed solution.

You want to have a program willHalt(p,x) with three
possible outcomes:

(1) If program p halts on input x, then willHalt returns true.
(2) If program p does not halt on input x, then willHalt returns false.
(3) If program p makes a self-referential call on willHalt, then willHalt
throws an exception.

Okay, so now let Q(p,x) be some other program with two inputs.
Let F(x) be a program with the following behavior:

if Q(x,x) returns true, then loop forever,
if Q(x,x) returns false, then halt.

Now, let's run willHalt(F,F). How does willHalt decide whether
to throw a "MalignantSelfReferenceException"?

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 1:07:25 PM
Peter Olcott says...

>>>int WillHalt(string SourceCode, string InputData)   {
>>>    if (MalignantSelfReference(SourceCode, InputData))
>>>        throw(MALIGNANT_SELF_REFERENCE);
>>>    if ( TheProgramWillHalt(SourceCode, InputData) )
>>>        return TRUE;
>>>    else
>>>        return FALSE;
>>>}
>>
>> You are assuming that there is a program
>> MalignantSelfReference(SourceCode, InputData)
>> which will return true if executing that
>> particular source code on that input data
>> results in a "malignant self reference".

>I am assuming nothing.

Yes, you are. You are assuming that
MalignantSelfReference(SourceCode,InputData)
can detect whether there is a "malignant self
reference". There is no such program.

Once again, you have your program
WillHalt(string SourceCode, string InputData).

Now, let Q(p,x) be a function that has exactly
the same behavior as WillHalt, but completely
different source code. Let f(x) be the following
function

f(String x) {
if (Q(x,x)) {
loop();
}
}

Let #f be the source code for f, and consider the computation

WillHalt(#f,#f)

On what basis will WillHalt throw a Malignant Self Reference
Exception? Step through the computation of
MalignantSelfReference(#f,#f), and show how it decides
whether to return true or not.

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 1:19:23 PM
Peter Olcott says...

>void LoopIfHalts(string SourceCode)  {
>     if ( WillHalt(SourceCode, SourceCode) == TRUE )
>        while (TRUE)    // loop forever
>            ;
>     else
>        return;
>}
>
>
>int WillHalt(string SourceCode, string InputData)   {
>    if (MalignantSelfReference(SourceCode, InputData))
>        throw(MALIGNANT_SELF_REFERENCE);
>    if ( TheProgramWillHalt(SourceCode, InputData) )
>        return TRUE;
>    else
>        return FALSE;
>}
>
>
>LoopIfHalts(LoopIfHalts);

The original statement of the halting problem doesn't
include "exceptions". Throwing an exception is just one
particular way of halting. However, if you want to say
that there are three possible results of running a program:
(1) The program halts, (2) the program runs forever, or (3)
the program throws an exception, then we can recast the
halting problem as follows:

There is no program throwsException(p,x) such that
(1) If the program whose source code is p, when run on input x
throws an exception, then throwsException returns true.
(2) If the program whose source code is p, when run on input x
never throws an exception, then throwsException returns false.

There is no program throwsException that works correctly on
all inputs.

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 1:27:15 PM
Peter Olcott says...

>So you agree that my example shows that within the specific context of this
>example I have shown that this specific form of a Halting Problem is merely the
>ill-formed question of:
>"Does LoopIfHalts(LoopIfHalts) halt?"

That's not an ill-formed question. It is a perfectly good question, and it
has a perfectly good answer: Yes, it halts (by throwing an exception).

(The semantics of exceptions hasn't been spelled out, but in most normal
programming languages, if a program throws an exception, then the program
stops at that point.)

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 1:48:51 PM
In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:

> So the equivalent of the return value of the Halt() function from
> the TM is the integer value that the TM's ReadWrite head rests on
> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1
> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
> recursion of the original specification of the problem, and provides
> the only possible correct answer.

In the standard presentation of the halting problem, there is no
recursion, infinite or otherwise.  Don't be confused by the fact that
the same name of a function is used in the analyzed program and in the
analyzer - it's not the same thing, and these two instances of
"Halt" are completely separate.

That can certainly be confusing, but if you don't understand that then
consider it like this: Take the putative Halt procedure and everywhere
you see "Halt" just replace that with the name "CopyOfHalt".  Now you
have something completely equivalent, and you can call "CopyOfHalt" in
the "LoopIfHalts" function.  There is no requirement in the halting
problem proof that CopyOfHalt be recursive (or that it not be
recursive for that matter).  And CopyOfHalt certainly can't call
"LoopIfHalts" or the original "Halt" function, so there's no chance of
indirect recursion there either.  So now we have something that
clearly doesn't have to be recursive in any shape or form, and yet the
proof of the halting problem still works out.

How does that affect your belief that somehow "infinite recursion" is
involved?

--

Steve Stringer
sillybanter@gmail.com

 0
10/19/2006 1:48:55 PM
In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:

> That seems to be a very precise English language statement that is
> most typically used to describe the results of the HP. It is this
> statement that I refute. I may be wrong, I have been wrong before,
> but, it is still this specific statement that I refute. The HP can
> be decided, yet the answer can not be restricted to YES or NO
> because the question is not a YES or NO question.

There are certainly problems that are ill-formed, but the halting
problem is not one of those.  Deal with the real form of the halting
problem for a minute - don't try to change the model or anything.  Now
consider the following statement:

Given a TM (or a program in any TM-equivalent language, if you
prefer) and an input, when the TM is run with the input it either
halts in a finite number of steps or it doesn't.

Do you somehow disagree with that?  I'm not sure how you could - that
seems to partition the space of possibilities quite nicely.  Either
something happens or it doesn't.  Yes or no.  Completely well formed.
*You* may not know for a particular program/input whether the answer
is yes or no, so you might want to add a third choice "I dont' know",
but that's a different question - and doesn't negate the fact that
there *is* a yes or a no answer.

--

Steve Stringer
sillybanter@gmail.com

 0
10/19/2006 1:53:54 PM
In article <KyxZg.28265eZ4.22514@dukeread06>, Peter Olcott <NoSpam@SeeScreen.com> wrote: >> [...] There is also no need for >> the HP to refer to programs *at all*; >Then what would it be that we are attempting to test the halting of? It would >seem that you must be wrong here. If there are no programs, then there is no >halting, thus no "Halting Problem" is possible, [...] I didn't say "there are no programs", only that the HP doesn't need to refer to them. Ever since the invention of the "stored program" concept, we have known that there is no interesting distinction between "program" and "data". As for "halting", this is merely one particular state of the computer [and not usually, since the invention of operating systems, an actual literal "halt", but merely an instruction to the OS that it is not to return control to this program]. >> there is a simple equivalent >> formulation entirely in terms of data [eg as supplied to a UTM]. >A UTM is essentially defined as being a program. A UTM is essentially a *computer*. Spot the difference. >>> All that the HP shows is that there exists >>>some cases of malignant self-reference where this determination can not be >>>provided as a return value to a caller. >> No, it doesn't show that. No matter how MSR your program may be, >> there are programs out there that will show whether or not your program >> with its data will halt. But this is a game of "you show me yours and >> I'll show you mine". >Not when the result of this determination is structured as listed below: > http://www.cprogramming.com/tutorial/computersciencetheory/halting.html Yes, even so. What that [standard] proof shows is that *if* you show me your [purported] halt-tester, *then* I can construct a derived [MSR] program on which your tester fails. I can't write down that code without seeing the code that claims to be a correct tester, and after I have written down my buster, all it shows is that your code is incorrect. The MSR program is not itself hard to analyse -- no harder than your code on which it is based. *Your* code cannot analyse it, but there is other code out there that can [but that code in turn is not going to be able to analyse some inputs]. See "http://www.maths.nott.ac.uk/personal/anw/G12FCO/lect18.html" for perhaps relevant [though now rather old] discussion. [The preceding lecture discusses UTMs and the standard HP proof, and there are also relevant snippets in later lectures.] It's not MSR-ness of code that makes it hard to analyse, but what we might loosely call "3x+1" or "Collatz" behaviour -- code with lots of special cases that never seem to explode to the extent that it's provable we're losing, but never collapse to a result either, so that it always seems worthwhile to go on a little longer. -- Andy Walker, School of MathSci., Univ. of Nott'm, UK. anw@maths.nott.ac.uk  0 anw (25) 10/19/2006 2:15:33 PM In sci.logic, Patricia Shanahan <pats@acm.org> wrote on Wed, 18 Oct 2006 22:22:10 GMT <mOxZg.15598UG4.10415@newsread2.news.pas.earthlink.net>:
> Peter Olcott wrote:
> ...
>> So the equivalent of the return value of the Halt() function from the TM is the
>> integer value that the TM's ReadWrite head rests on when the TM halts. In this
>> case  DOES_NOT_HALT=0  HALTS=1    MALIGNANT_SELF_REFERENCE=2. This scenario
>> breaks out of the infinite recursion of the original specification of the
>> problem, and provides the only possible correct answer.
>
> OK, so now we are down to a well-defined environment. Perhaps
> you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing
> machine computation?
>
> Patricia

It can always be true, which leads to a Halt() function
that always throws an exception.  This is a valid if
pointless solution.

In any event, Turing machines cannot reference themselves;
there's no concept of a pointer therein.  Coding systems
might; one old machine in particular (the HP 21xx series),
when presented with JSR Addr, did the following:

which in its way is a form of code modification.
(The return was simply a JMP ADDR,I.)

On a higher level one can contemplate function synthesis,
in language that support first-level functions.  However,
that isn't self-referential, but function copying.

--
Useless C++ Programming Idea #7878218:
class C { private: virtual void stupid() = 0; };

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

 0
ewill5 (11075)
10/19/2006 2:16:23 PM
In sci.logic, MoeBlee
<jazzmobe@hotmail.com>
wrote
on 18 Oct 2006 17:29:52 -0700
> Peter Olcott wrote:
>> I know that the UTM form mathematically maps to the form that I provided.
>
> Sure you do.
>
> MoeBlee
>

Without a well-defined method of testing for MALIGNANT_SELF_REFERENCE, I
for one would stipulate that Peter Olcott's solution is of little use.

(Assuming MALIGNANT_SELF_REFERENCE can even be defined.)

--
Linux.  Because life's too short for a buggy OS.

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

 0
ewill5 (11075)
10/19/2006 2:18:15 PM
The Ghost In The Machine wrote:
> In sci.logic, Patricia Shanahan
> <pats@acm.org>
>  wrote
> on Wed, 18 Oct 2006 22:22:10 GMT
> <mOxZg.15598$UG4.10415@newsread2.news.pas.earthlink.net>: >> Peter Olcott wrote: >> ... >>> So the equivalent of the return value of the Halt() function from the TM is the >>> integer value that the TM's ReadWrite head rests on when the TM halts. In this >>> case DOES_NOT_HALT=0 HALTS=1 MALIGNANT_SELF_REFERENCE=2. This scenario >>> breaks out of the infinite recursion of the original specification of the >>> problem, and provides the only possible correct answer. >> OK, so now we are down to a well-defined environment. Perhaps >> you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing >> machine computation? >> >> Patricia > > It can always be true, which leads to a Halt() function > that always throws an exception. This is a valid if > pointless solution. Whether it is a valid solution depends on the definition of MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP exception, then always throwing it is valid but pointless. To the extent that I've been able to find out its meaning, it seems to relate to whether the result will be used to control whether the TM halts or not. That, of course, is a halting problem equivalent test, so it cannot be implemented. Patricia  0 pats (3556) 10/19/2006 3:42:15 PM In article <o_JZg.31120$eZ4.25272@dukeread06>,
Peter Olcott <NoSpam@SeeScreen.com> wrote:
>"Patricia Shanahan" <pats@acm.org> wrote in message
>news:ueDZg.11396$Y24.6326@newsread4.news.pas.earthlink.net... >> [...] >So you agree that my example shows that within the specific context of this >example I have shown that this specific form of a Halting Problem is merely the >ill-formed question of: >"Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is >thus erroneously formed because it is asking a YES or NO question that has no >correct YES or NO answer. I don't know what PatS may or may not agree with, but *I* don't agree. It isn't that the question is ill-formed, or has no correct YES or NO answer, but rather that we can't tell you *which* is the correct answer until *after* you show us the code. The proof shows that there is no *correct* HP solver, and thus your "LoopIfHalts" code is built from a program that doesn't work. Once you either tell us from your own analysis why your "Halt" code doesn't work [and "LoopIfHalts" will give you a specific non-working instance for you to look at], or show us the code so that we can look for ourselves, *then* we can work out what the halting status of "LoopIfHalts(LoopIfHalts)" is. You can't reasonably expect us to do that with no knowledge of what the secret "Halt" subroutine within "LoopIfHalts" really does, only that it doesn't do what it is claimed to do. -- Andy Walker, School of MathSci., Univ. of Nott'm, UK. anw@maths.nott.ac.uk  0 anw (25) 10/19/2006 3:57:41 PM Peter Olcott wrote: > "Patricia Shanahan" <pats@acm.org> wrote in message > news:ueDZg.11396$Y24.6326@newsread4.news.pas.earthlink.net...
>> Peter Olcott wrote:
>> ...
>>> I can do as others have done and complicate the problem beyond all  possible
>>> recognition. Instead I chose to boil the problem down to its most fundamental
>>> essence. Try to address the problem as I have framed it, and refrain from
>>> attempts to change this framework. The ability to complicate the example so
>>> that no one can understand it, is not a valid form of refutation.
>>>
>>> Within the exact and precise framework that I have defined the Halting
>>> Problem, is it now clear, that at least within the context of this framework
>>> that the question:
>>> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and
>>> is thus erroneously formed because it is asking a YES or NO question that has
>>> no correct YES or NO answer.
>> ...
>>
>> If you are defining your own problem, you can solve it any way you like,
>> but please don't call it "the Halting Problem" unless you really do mean
>> a decision procedure for the set of terminating Turing machine computations.
>>
>>> Maybe it might help if you don't begin your response starting with the goal
>>> of refutation?
>> It would not help at all with testing the validity of your ideas, which
>> is my objective.
>>
>> If you are trying to test a program, do you feed it only the easy cases,
>> or do you feed it deliberately difficult cases, such as the largest and
>> smallest permitted inputs?
>>
>> Patricia
>
> So you agree that my example shows that within the specific context of this
> example I have shown that this specific form of a Halting Problem is merely the
> ill-formed question of:
> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO answer, and is
> thus erroneously formed because it is asking a YES or NO question that has no
> correct YES or NO answer.
>
> If you agree with this please say so, if you don't agree with this then please
> explain why you do not agree.

I strongly disagree with any idea of using the term "halting problem"
for this, because the Halting Problem is a decision problem. It asks
whether its input is, or is not, a member of a specific language, and
the only possible answers are to accept or reject the input.

can be created if you assume the set of Turing machine computations that
halt is a decidable language.

In my opinion, the only reasonable reaction to the LoopIfHalts behavior
is to conclude that there is no decision algorithm for halting TM
computations. Once you accept that, LoopIfHalts cannot be written
because there is no Halts function for it to call.

Instead of working on the decision problem, you seem to be trying to
construct a function that maps input strings to "Yes", "No", or "MSR".
Whether MSR is the correct output for a specific input depends on
exactly how MSR is defined. I cannot comment on which result is the
right one for a given program until you define your function.

I strongly suspect your function will be either unrelated to the Halting
problem or not computable, but I won't know which unless you define it.

>
> Apparently you do not agree that this example of a Halting Problem
> mathematically maps tot he original Halting Problem. I will proceed to this step
> only after we have formed agreement on the preceding step. Effective
> communication must proceed one step at a time, or it does not work effectively.
 0
pats (3556)
10/19/2006 4:29:06 PM
Peter Olcott wrote:
> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
> > Peter Olcott wrote:
> >> it is
> >> merely the case that some ill-formed questions have no correct answer.
> >
> > There is no "ill-formed question" involved in the theorem that, to
> > quote a standard textbook, "there exists a Turing machine whose halting
> > problem is recursively unsolvable."
> >
>
> It is only unsolvable, because it is ill-formed. One could say that all
> ill-formed questions are unsolvable questions, this leaves out a crucial detail.
> How tall are you, (blue or green) ? is an unsolvable math problem, more
> importantly it is an ill-formed question.

There is no question at all in the statement or proof of the theorem.
There are no interrogatives in a fully formalized proof of the halting
theorem. The interrogatives involved are for the purpose of motivating
the mathematics, but are not part of the theorem itself nor its proof.
Morevover, there is nothing "ill-formed" in the questions. Either a
given Turing machine with an initial state halts or it doesn't, and
regarding any Turing machine with an inititial state we can ask whether
it halts.

> It matters not whether an ill-formed question is posed in natural language or in
> the language of mathematical formalism, in either case it is still an ill-formed
> question.

There are no interrogatives in a fully formalized proof of the
unsolvability of the halting problem.

MoeBlee

 0
jazzmobe (307)
10/19/2006 4:35:21 PM
In sci.logic, Patricia Shanahan
<pats@acm.org>
wrote
on Thu, 19 Oct 2006 15:42:15 GMT
<r1NZg.15912$UG4.2273@newsread2.news.pas.earthlink.net>: > The Ghost In The Machine wrote: >> In sci.logic, Patricia Shanahan >> <pats@acm.org> >> wrote >> on Wed, 18 Oct 2006 22:22:10 GMT >> <mOxZg.15598$UG4.10415@newsread2.news.pas.earthlink.net>:
>>> Peter Olcott wrote:
>>> ...
>>>> So the equivalent of the return value of the Halt() function from the TM is the
>>>> integer value that the TM's ReadWrite head rests on when the TM halts. In this
>>>> case  DOES_NOT_HALT=0  HALTS=1    MALIGNANT_SELF_REFERENCE=2. This scenario
>>>> breaks out of the infinite recursion of the original specification of the
>>>> problem, and provides the only possible correct answer.
>>> OK, so now we are down to a well-defined environment. Perhaps
>>> you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing
>>> machine computation?
>>>
>>> Patricia
>>
>> It can always be true, which leads to a Halt() function
>> that always throws an exception.  This is a valid if
>> pointless solution.
>
> Whether it is a valid solution depends on the definition of
> MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP
> exception, then always throwing it is valid but pointless.
>
> To the extent that I've been able to find out its meaning, it seems to
> relate to whether the result will be used to control whether the TM
> halts or not. That, of course, is a halting problem equivalent test, so
> it cannot be implemented.

Assuming 'MALIGNANT_SELF_REFERENCE' can be well-defined
at all.  Given any code sequence, there are a lot of code
sequences that do exactly the same sequence of actions
(take the original and stick NOPs on the front, if nothing
else).  Any of these might be used in the implementation of
LoopIfHalts().

>
> Patricia

--
Murphy was an optimist.

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

 0
ewill5 (11075)
10/19/2006 5:48:28 PM
Peter Olcott wrote:
> "MoeBlee" <jazzmobe@hotmail.com> wrote in message
> > Peter Olcott wrote:
> >> What is the
> >> official precise English language conclusion drawn from the results of the
> >> mathematical analysis of the Halting Problem?
> >
> > Why not start by at least informing yourself of an exact mathematical
> > statement of the theorem and its proof?
> >
> > MoeBlee
> >
>
> That is not within my purpose. My purpose is to show that the Halting Problem is
> really nothing more than an ill-formed question.

Ill-formed in what sense?  The problem is that it is inconsistent -
regarding whether a program that runs the program being specified
against its input as both program and input, when run against itself
halts or not.

Results from Mathematical Logic manifest themselves in common
programming activities.  In this case, it is just a case where the
programmer sends the specs back to the applications specialist for
fixing due to bad logic in the spec.

(I know people don't like the idea that the HP is simply an example of
bad specs, but it's true.  There is an inconsistency in the spec when
you put all of its aspects together.  You simply have to look at it as
a scientist, rather than becoming emotional and defensive about it.)

C-B

 0
shymathguy (92)
10/19/2006 7:37:40 PM
"Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message
news:fwebqo8cw0i.fsf@collins.inf.ed.ac.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> "Alan Smaill" <smaill@SPAMinf.ed.ac.uk> wrote in message
>> news:fwehcy01tf7.fsf@collins.inf.ed.ac.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
> ...
>>>> I am using the sort of model that the link provides as my basis,
>>>> rather than the
>>>> formal mathematical model.
>>>>
>>>> int WillHalt(string SourceCode, string InputData)   {
>>>>     if (MalignantSelfReference(SourceCode, InputData))
>>>>         throw(MALIGNANT_SELF_REFERENCE);
>>>>     if ( TheProgramWillHalt(SourceCode, InputData) )
>>>>         return TRUE;
>>>>     else
>>>>         return FALSE;
>>>> }
>>>>
>>>> This defeats the "problem" aspect of the Halting Problem.
>>>
>>> You have simply ignored my question.
>>> Yes, you can tackle what problems you want and call them what
>>> you want from your own piont of view.
>>>
>>> Yet again, do you agree that in standard usage in computer science,
>>> the terminology "Halting Problem" uses "problem" in the same way
>>> as in the terminology "Travelling Salesman Problem"?

This is a specific example of one of the tangents that I don't want to go off
on. I can not adequately answer this question without spending more time than I
have to spend.

>>>
>>> This is a small enough point which for some reason you
>>> seem determined to ignore.
>>>
>>> --
>>> Alan Smaill
>>
>> In order for me to cause comprehension to occur, I must insist on making one
>> point at a time, and not allow the process to go off on any tangents.
>
> You will I hope allow that comprehension involves the person
> you are addressing as well as the person trying to get ideas across.
>
> I cannot comprehend why you want to avoid answering a simple
> yes or no to my question. Your answer would help me to see where
> you are coming from, either way.
>
> Evidently, you will not answer.
>
>
> --
> Alan Smaill

 0
NoSpam266 (508)
10/19/2006 9:34:06 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
> Peter Olcott says...
>
>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote
>
>
>>> You are assuming that there is a program
>>> MalignantSelfReference(SourceCode, InputData)
>>> which will return true if executing that
>>> particular source code on that input data
>>> results in a "malignant self reference".
>>>
>>> But then determining whether something involves
>>> "malignant self reference" is, in fact,
>>> equivalent to solving the halting problem.
>
>>I am assuming nothing. I have shown step by step point by point,
>>item by item, exactly and precisely how such a program could be
>>constructed within the precise focus of this specific example.
>
> What you have described is perhaps a way to detect *explicit*
> self-reference. However, given any computer program, there are
> infinitely many programs that do the exact same thing, but have
> different source codes. It is not possible to detect that
> two programs are, in fact, equivalent programs.
>
> In light of that, consider your proposed solution.
>
> You want to have a program willHalt(p,x) with three
> possible outcomes:
>
> (1) If program p halts on input x, then willHalt returns true.
> (2) If program p does not halt on input x, then willHalt returns false.
> (3) If program p makes a self-referential call on willHalt, then willHalt
> throws an exception.
>
> Okay, so now let Q(p,x) be some other program with two inputs.
> Let F(x) be a program with the following behavior:
>
>     if Q(x,x) returns true, then loop forever,
>     if Q(x,x) returns false, then halt.
>
> Now, let's run willHalt(F,F). How does willHalt decide whether
> to throw a "MalignantSelfReferenceException"?

Would you agree that I have shown, that in the specific instance of a halting
problem that I have provided, that in this specific case, the "problem" is
merely that the question:
"Does LoopIfHalts(LoopIfHalts) halt?"  is of the ill-form of requiring a YES or
NO answer to a question that has no correct YES or NO answer? Only after you
answer this point will I proceed with even the slightest trace of any steps
beyond this point, or any other points besides this point.

>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/19/2006 9:40:55 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:eh7u0r02aiu@drn.newsguy.com...
> Peter Olcott says...
>
>>>>int WillHalt(string SourceCode, string InputData)   {
>>>>    if (MalignantSelfReference(SourceCode, InputData))
>>>>        throw(MALIGNANT_SELF_REFERENCE);
>>>>    if ( TheProgramWillHalt(SourceCode, InputData) )
>>>>        return TRUE;
>>>>    else
>>>>        return FALSE;
>>>>}
>>>
>>> You are assuming that there is a program
>>> MalignantSelfReference(SourceCode, InputData)
>>> which will return true if executing that
>>> particular source code on that input data
>>> results in a "malignant self reference".
>
>>I am assuming nothing.
>
> Yes, you are. You are assuming that
> MalignantSelfReference(SourceCode,InputData)
> can detect whether there is a "malignant self
> reference". There is no such program.

I provided the detailed steps of the design of such a program for this specific
instance of a halting problem TWICE !!!  Please stay completely focused on the
specific example that I have provided, and do not proceed to any other points
besides or beyond this sharply focused point. Every other point is 100%
completely and totally moot, unless and until we can get past this first single
point.

>
> Once again, you have your program
> WillHalt(string SourceCode, string InputData).
>
> Now, let Q(p,x) be a function that has exactly
> the same behavior as WillHalt, but completely
> different source code. Let f(x) be the following
> function
>
>     f(String x) {
>        if (Q(x,x)) {
>           loop();
>        }
>     }
>
> Let #f be the source code for f, and consider the computation
>
>    WillHalt(#f,#f)
>
> On what basis will WillHalt throw a Malignant Self Reference
> Exception? Step through the computation of
> MalignantSelfReference(#f,#f), and show how it decides
> whether to return true or not.
>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/19/2006 9:44:22 PM
<sillybanter@gmail.com> wrote in message news:bnLZg.5347NK5.1822@trnddc08... > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: > >> So the equivalent of the return value of the Halt() function from >> the TM is the integer value that the TM's ReadWrite head rests on >> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1 >> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite >> recursion of the original specification of the problem, and provides >> the only possible correct answer. > > In the standard presentation of the halting problem, there is no > recursion, infinite or otherwise. Don't be confused by the fact that > the same name of a function is used in the analyzed program and in the > analyzer - it's not the same thing, and these two instances of > "Halt" are completely separate. See the ANALYTICAL COMMENTARY of this example mentioned below to see my current point. // // To make the problem more clear we are assuming // that function call syntax results in inline expansion, // thus specifying the name of a function specifies the // text body of the function. // void LoopIfHalts(string SourceCode) { if ( WillHalt(SourceCode, SourceCode) == TRUE ) while (TRUE) // loop forever ; else return; } int WillHalt(string SourceCode, string InputData) { if (MalignantSelfReference(SourceCode, InputData)) throw(MALIGNANT_SELF_REFERENCE); if ( TheProgramWillHalt(SourceCode, InputData) ) return TRUE; else return FALSE; } LoopIfHalts(LoopIfHalts); // ANALYTICAL COMMENTARY WillHalt() is provided with the source code of LoopIfHalts(), as input, so WillHalt() can see exactly how the return value of the invocation of itself under test will be used to toggle the result of the analysis of the invocation of itself under test. WillHalt() can see that LoopIfHalts() is toggling the result of the invocation of itself under test to invalidate the analysis of the invocation of itself under test. Therefore WillHalt() can determine that the question: "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is thus erroneously formed because it is asking a YES or NO question that has no correct YES or NO answer. > > That can certainly be confusing, but if you don't understand that then > consider it like this: Take the putative Halt procedure and everywhere > you see "Halt" just replace that with the name "CopyOfHalt". Now you > have something completely equivalent, and you can call "CopyOfHalt" in > the "LoopIfHalts" function. There is no requirement in the halting > problem proof that CopyOfHalt be recursive (or that it not be > recursive for that matter). And CopyOfHalt certainly can't call > "LoopIfHalts" or the original "Halt" function, so there's no chance of > indirect recursion there either. So now we have something that > clearly doesn't have to be recursive in any shape or form, and yet the > proof of the halting problem still works out. > > How does that affect your belief that somehow "infinite recursion" is > involved? > > -- > > Steve Stringer > sillybanter@gmail.com >  0 NoSpam266 (508) 10/19/2006 9:47:07 PM <sillybanter@gmail.com> wrote in message news:SrLZg.5348NK5.2906@trnddc08...
> In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>
>> That seems to be a very precise English language statement that is
>> most typically used to describe the results of the HP. It is this
>> statement that I refute. I may be wrong, I have been wrong before,
>> but, it is still this specific statement that I refute. The HP can
>> be decided, yet the answer can not be restricted to YES or NO
>> because the question is not a YES or NO question.
>
> There are certainly problems that are ill-formed, but the halting
> problem is not one of those.  Deal with the real form of the halting

I think that I have shown in my prior response to you at least one example of a
halting problem, that is only a problem because it is ill formed. Iff (if and
only if) I can reach a consensus on this  point, I will proceed to a UTM version
of the same problem, and attempt to show the mathematical mapping from the prior
example to the UTM example. I will not do this unless or until I have reached a
consensus on my prior point.

> problem for a minute - don't try to change the model or anything.  Now
> consider the following statement:
>
>  Given a TM (or a program in any TM-equivalent language, if you
>  prefer) and an input, when the TM is run with the input it either
>  halts in a finite number of steps or it doesn't.
>
> Do you somehow disagree with that?  I'm not sure how you could - that
> seems to partition the space of possibilities quite nicely.  Either
> something happens or it doesn't.  Yes or no.  Completely well formed.
> *You* may not know for a particular program/input whether the answer
> is yes or no, so you might want to add a third choice "I dont' know",
> but that's a different question - and doesn't negate the fact that
> there *is* a yes or a no answer.
>
> --
>
> Steve Stringer
> sillybanter@gmail.com
>

 0
NoSpam266 (508)
10/19/2006 9:50:25 PM
"Dr A. N. Walker" <anw@maths.nott.ac.uk> wrote in message
news:eh81a5$p72$1@oyez.ccc.nottingham.ac.uk...
> In article <KyxZg.28265eZ4.22514@dukeread06>, > Peter Olcott <NoSpam@SeeScreen.com> wrote: >>> [...] There is also no need for >>> the HP to refer to programs *at all*; >>Then what would it be that we are attempting to test the halting of? It would >>seem that you must be wrong here. If there are no programs, then there is no >>halting, thus no "Halting Problem" is possible, [...] > > I didn't say "there are no programs", only that the HP doesn't > need to refer to them. Ever since the invention of the "stored program" > concept, we have known that there is no interesting distinction between > "program" and "data". As for "halting", this is merely one particular > state of the computer [and not usually, since the invention of operating > systems, an actual literal "halt", but merely an instruction to the OS > that it is not to return control to this program]. > >>> there is a simple equivalent >>> formulation entirely in terms of data [eg as supplied to a UTM]. >>A UTM is essentially defined as being a program. > > A UTM is essentially a *computer*. Spot the difference. The same sort of difference between a computer language runtime interpreter program, and this exact same thing when it is called the Java virtual machine, there is no actual difference, its all a mere play on words. > >>>> All that the HP shows is that there exists >>>>some cases of malignant self-reference where this determination can not be >>>>provided as a return value to a caller. >>> No, it doesn't show that. No matter how MSR your program may be, >>> there are programs out there that will show whether or not your program >>> with its data will halt. But this is a game of "you show me yours and >>> I'll show you mine". >>Not when the result of this determination is structured as listed below: >> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html > > Yes, even so. What that [standard] proof shows is that *if* you > show me your [purported] halt-tester, *then* I can construct a derived > [MSR] program on which your tester fails. I can't write down that code > without seeing the code that claims to be a correct tester, and after I > have written down my buster, all it shows is that your code is incorrect. > The MSR program is not itself hard to analyse -- no harder than your code > on which it is based. *Your* code cannot analyse it, but there is other > code out there that can [but that code in turn is not going to be able to > analyse some inputs]. > > See "http://www.maths.nott.ac.uk/personal/anw/G12FCO/lect18.html" > for perhaps relevant [though now rather old] discussion. [The preceding > lecture discusses UTMs and the standard HP proof, and there are also > relevant snippets in later lectures.] > > It's not MSR-ness of code that makes it hard to analyse, but what > we might loosely call "3x+1" or "Collatz" behaviour -- code with lots of > special cases that never seem to explode to the extent that it's provable > we're losing, but never collapse to a result either, so that it always > seems worthwhile to go on a little longer. > > -- > Andy Walker, School of MathSci., Univ. of Nott'm, UK. > anw@maths.nott.ac.uk  0 NoSpam266 (508) 10/19/2006 9:57:53 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:r1NZg.15912UG4.2273@newsread2.news.pas.earthlink.net...
> The Ghost In The Machine wrote:
>> In sci.logic, Patricia Shanahan
>> <pats@acm.org>
>>  wrote
>> on Wed, 18 Oct 2006 22:22:10 GMT
>> <mOxZg.15598$UG4.10415@newsread2.news.pas.earthlink.net>: >>> Peter Olcott wrote: >>> ... >>>> So the equivalent of the return value of the Halt() function from the TM is >>>> the integer value that the TM's ReadWrite head rests on when the TM halts. >>>> In this case DOES_NOT_HALT=0 HALTS=1 MALIGNANT_SELF_REFERENCE=2. This >>>> scenario breaks out of the infinite recursion of the original specification >>>> of the problem, and provides the only possible correct answer. >>> OK, so now we are down to a well-defined environment. Perhaps >>> you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing >>> machine computation? >>> >>> Patricia >> >> It can always be true, which leads to a Halt() function >> that always throws an exception. This is a valid if >> pointless solution. > > Whether it is a valid solution depends on the definition of > MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP > exception, then always throwing it is valid but pointless. It is equivalent to saying that no correct answer exists to the question, "How tall are you green or blue?" because the question itself is ill-formed. It is not at all equivalent to I_GIVE_UP. > > To the extent that I've been able to find out its meaning, it seems to > relate to whether the result will be used to control whether the TM > halts or not. That, of course, is a halting problem equivalent test, so > it cannot be implemented. > > Patricia  0 NoSpam266 (508) 10/19/2006 10:01:19 PM Peter Olcott wrote: > "Patricia Shanahan" <pats@acm.org> wrote in message > news:r1NZg.15912$UG4.2273@newsread2.news.pas.earthlink.net...
>> The Ghost In The Machine wrote:
>>> In sci.logic, Patricia Shanahan
>>> <pats@acm.org>
>>>  wrote
>>> on Wed, 18 Oct 2006 22:22:10 GMT
>>> <mOxZg.15598$UG4.10415@newsread2.news.pas.earthlink.net>: >>>> Peter Olcott wrote: >>>> ... >>>>> So the equivalent of the return value of the Halt() function from the TM is >>>>> the integer value that the TM's ReadWrite head rests on when the TM halts. >>>>> In this case DOES_NOT_HALT=0 HALTS=1 MALIGNANT_SELF_REFERENCE=2. This >>>>> scenario breaks out of the infinite recursion of the original specification >>>>> of the problem, and provides the only possible correct answer. >>>> OK, so now we are down to a well-defined environment. Perhaps >>>> you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing >>>> machine computation? >>>> >>>> Patricia >>> It can always be true, which leads to a Halt() function >>> that always throws an exception. This is a valid if >>> pointless solution. >> Whether it is a valid solution depends on the definition of >> MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP >> exception, then always throwing it is valid but pointless. > > It is equivalent to saying that no correct answer exists to the question, "How > tall are you green or blue?" because the question itself is ill-formed. It is > not at all equivalent to I_GIVE_UP. There is a very big difference. Whether there is a correct answer to "How tall are you, x or y" depends on whether the set {x,y} includes your height. That is decidable: measure the person in question, look at all elements of {x,y} that represent lengths, and see if any of them match the height. Similarly, whether a division involves division by zero is decidable: Compare the divisor to zero. If it is equal, there is a division by zero. Whether a program uses the result of a given function call to control whether to loop forever or to halt is not decidable. Patricia  0 pats (3556) 10/19/2006 10:11:09 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:mJNZg.11568$Y24.3672@newsread4.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> news:ueDZg.11396Y24.6326@newsread4.news.pas.earthlink.net... >>> Peter Olcott wrote: >>> ... >>>> I can do as others have done and complicate the problem beyond all >>>> possible recognition. Instead I chose to boil the problem down to its most >>>> fundamental essence. Try to address the problem as I have framed it, and >>>> refrain from attempts to change this framework. The ability to complicate >>>> the example so that no one can understand it, is not a valid form of >>>> refutation. >>>> >>>> Within the exact and precise framework that I have defined the Halting >>>> Problem, is it now clear, that at least within the context of this >>>> framework that the question: >>>> "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, >>>> and is thus erroneously formed because it is asking a YES or NO question >>>> that has no correct YES or NO answer. >>> ... >>> >>> If you are defining your own problem, you can solve it any way you like, >>> but please don't call it "the Halting Problem" unless you really do mean >>> a decision procedure for the set of terminating Turing machine computations. >>> >>>> Maybe it might help if you don't begin your response starting with the goal >>>> of refutation? >>> It would not help at all with testing the validity of your ideas, which >>> is my objective. >>> >>> If you are trying to test a program, do you feed it only the easy cases, >>> or do you feed it deliberately difficult cases, such as the largest and >>> smallest permitted inputs? >>> >>> Patricia >> >> So you agree that my example shows that within the specific context of this >> example I have shown that this specific form of a Halting Problem is merely >> the ill-formed question of: >> "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and >> is thus erroneously formed because it is asking a YES or NO question that has >> no correct YES or NO answer. >> >> If you agree with this please say so, if you don't agree with this then >> please explain why you do not agree. > > I strongly disagree with any idea of using the term "halting problem" > for this, because the Halting Problem is a decision problem. It asks > whether its input is, or is not, a member of a specific language, and > the only possible answers are to accept or reject the input. http://www.cprogramming.com/tutorial/computersciencetheory/halting.html void LoopIfHalts(string SourceCode) { if ( WillHalt(SourceCode, SourceCode) == TRUE ) while (TRUE) // loop forever ; else return; } int WillHalt(string SourceCode, string InputData) { if (MalignantSelfReference(SourceCode, InputData)) throw(MALIGNANT_SELF_REFERENCE); if ( TheProgramWillHalt(SourceCode, InputData) ) return TRUE; else return FALSE; } LoopIfHalts(LoopIfHalts); My version of a "Halting Problem" is essentially identical to the one on the link, the only difference is that I have added a possible solution. In each of these cases the entire subject matter focuses on the ability to determine whether or not a program halts. This by itself forms a completely sufficient condition to call both of these halting problems. If your issue is that at least one of these does not sufficiently correspond to the original UTM Halting Problem, then your point is off-topic. That topic will be covered as soon as consensus is achieved this halting problem. > > Note that the traditional proof shows that self-contradictory programs > can be created if you assume the set of Turing machine computations that > halt is a decidable language. > > In my opinion, the only reasonable reaction to the LoopIfHalts behavior > is to conclude that there is no decision algorithm for halting TM > computations. Once you accept that, LoopIfHalts cannot be written > because there is no Halts function for it to call. > > Instead of working on the decision problem, you seem to be trying to > construct a function that maps input strings to "Yes", "No", or "MSR". > Whether MSR is the correct output for a specific input depends on > exactly how MSR is defined. I cannot comment on which result is the > right one for a given program until you define your function. > > I strongly suspect your function will be either unrelated to the Halting > problem or not computable, but I won't know which unless you define it. I have defined it at least twice. The problem is that you are assuming that I must define it to work universally, whereas the actual requirements of the problem as I have precisely specified it only require me to show that it works for this single isolated case. Here it is again, for this single isolated case: // ANALYTICAL COMMENTARY WillHalt() is provided with the source code of LoopIfHalts(), as input, so WillHalt() can see exactly how the return value of the invocation of itself under test will be used to toggle the result of the analysis of the invocation of itself under test. WillHalt() can see that LoopIfHalts() is toggling the result of the invocation of itself under test to invalidate the analysis of the invocation of itself under test. Therefore WillHalt() can determine that the question: "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is thus erroneously formed because it is asking a YES or NO question that has no correct YES or NO answer. > >> >> Apparently you do not agree that this example of a Halting Problem >> mathematically maps tot he original Halting Problem. I will proceed to this >> step only after we have formed agreement on the preceding step. Effective >> communication must proceed one step at a time, or it does not work >> effectively.  0 NoSpam266 (508) 10/19/2006 10:14:04 PM "MoeBlee" <jazzmobe@hotmail.com> wrote in message news:1161275720.941271.93980@h48g2000cwc.googlegroups.com... > Peter Olcott wrote: >> "MoeBlee" <jazzmobe@hotmail.com> wrote in message >> news:1161222967.470438.31270@m7g2000cwm.googlegroups.com... >> > Peter Olcott wrote: >> >> it is >> >> merely the case that some ill-formed questions have no correct answer. >> > >> > There is no "ill-formed question" involved in the theorem that, to >> > quote a standard textbook, "there exists a Turing machine whose halting >> > problem is recursively unsolvable." >> > >> >> It is only unsolvable, because it is ill-formed. One could say that all >> ill-formed questions are unsolvable questions, this leaves out a crucial >> detail. >> How tall are you, (blue or green) ? is an unsolvable math problem, more >> importantly it is an ill-formed question. > > There is no question at all in the statement or proof of the theorem. > There are no interrogatives in a fully formalized proof of the halting > theorem. The interrogatives involved are for the purpose of motivating > the mathematics, but are not part of the theorem itself nor its proof. So then you are necessarily saying that the "Halting Problem" must have nothing at all do with whether or not anything at all halts! Someone goofed somewhere here, and it sure does not seem to be me. > Morevover, there is nothing "ill-formed" in the questions. Either a > given Turing machine with an initial state halts or it doesn't, and Whoops didn't that last statement imply a question ??? > regarding any Turing machine with an inititial state we can ask whether > it halts. That was a question for sure, it looks like you just not contradicted yourself! The problem with translating statements between English and mathematical formalisms and back is that things get lost, in the translation, and things get added that were not in the other form. The "Halting Problem" is fundamentally about whether or not a TM halts. This is inherently and fundamentally a question. If the mathematical formalism loses track of this, then the mathematical formalism errs. > >> It matters not whether an ill-formed question is posed in natural language or >> in >> the language of mathematical formalism, in either case it is still an >> ill-formed >> question. > > There are no interrogatives in a fully formalized proof of the > unsolvability of the halting problem. > > MoeBlee >  0 NoSpam266 (508) 10/19/2006 10:22:18 PM Peter Olcott says... >> Whether it is a valid solution depends on the definition of >> MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP >> exception, then always throwing it is valid but pointless. > >It is equivalent to saying that no correct answer exists to the question, "How >tall are you green or blue?" because the question itself is ill-formed. It is >not at all equivalent to I_GIVE_UP. On the contrary, there is nothing ill-formed about the question: Does the program LoopIfHalts halt when it is fed its own source code as input. It's a perfectly sensible question to ask, and your program WillHalt fails to give a correct answer. Instead, your program raises an exception. It gives up, rather than answering the question. -- Daryl McCullough Ithaca, NY  0 10/19/2006 10:23:33 PM Peter Olcott says... >I think that I have shown in my prior response to you at least one example of a >halting problem, that is only a problem because it is ill formed. No, you did not. There is nothing ill formed about the question: Does LoopIfHalts halt when given its own source code as an input? Your program WillHalt fails to answer that question, but there is nothing ill formed about the question. >Iff (if and only if) I can reach a consensus on this point Your point is false. There is nothing ill-formed about the question. -- Daryl McCullough Ithaca, NY  0 10/19/2006 10:26:40 PM Peter Olcott says... > > >"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote >> Yes, you are. You are assuming that >> MalignantSelfReference(SourceCode,InputData) >> can detect whether there is a "malignant self >> reference". There is no such program. > >I provided the detailed steps of the design of such a program >for this specific instance of a halting problem TWICE !!! You described a MalignantSelfReference detector that works by checking if LoopIfHalts makes calls to WillHalt. If instead LoopIfHalts uses a program that is different from, but has the same behavior as WillHalt, then your detector will not work. -- Daryl McCullough Ithaca, NY  0 10/19/2006 10:30:18 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:1KSZg.9408Lv3.7227@newsread1.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> news:r1NZg.15912$UG4.2273@newsread2.news.pas.earthlink.net... >>> The Ghost In The Machine wrote: >>>> In sci.logic, Patricia Shanahan >>>> <pats@acm.org> >>>> wrote >>>> on Wed, 18 Oct 2006 22:22:10 GMT >>>> <mOxZg.15598$UG4.10415@newsread2.news.pas.earthlink.net>:
>>>>> Peter Olcott wrote:
>>>>> ...
>>>>>> So the equivalent of the return value of the Halt() function from the TM
>>>>>> is the integer value that the TM's ReadWrite head rests on when the TM
>>>>>> halts. In this case  DOES_NOT_HALT=0  HALTS=1
>>>>>> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
>>>>>> recursion of the original specification of the problem, and provides the
>>>>> OK, so now we are down to a well-defined environment. Perhaps
>>>>> you can explain how you define a MALIGNANT_SELF_REFERENCE in a Turing
>>>>> machine computation?
>>>>>
>>>>> Patricia
>>>> It can always be true, which leads to a Halt() function
>>>> that always throws an exception.  This is a valid if
>>>> pointless solution.
>>> Whether it is a valid solution depends on the definition of
>>> MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP
>>> exception, then always throwing it is valid but pointless.
>>
>> It is equivalent to saying that no correct answer exists to the question,
>> "How tall are you green or blue?" because the question itself is ill-formed.
>> It is not at all equivalent to I_GIVE_UP.
>
> There is a very big difference. Whether there is a correct answer to
> "How tall are you, x or y" depends on whether the set {x,y} includes
> your height. That is decidable: measure the person in question, look at
> all elements of {x,y} that represent lengths, and see if any of them
> match the height.

How tall are you blue or green (where blue and green are colors and no possible
numerical quantity)  can not possibly be correctly answered entirely due to the
ill-form of the question itself. The particular and specific example of a
halting problem, is only a problem for this exact same sort of reason. It is
100% completely impossible to correctly decide between the alternatives of blue
and green to select one of these alternatives that provides the correct
numerical quantity representing one's height. This problem is undecidable.

>
> Similarly, whether a division involves division by zero is decidable:
> Compare the divisor to zero. If it is equal, there is a division by zero.

The question is not "Is there division by zero?"
int double X = 50.0 / 0.0;
The question is what is the numerical quantity of this specific instance of
division by zero? This question is undecidable.

>
> Whether a program uses the result of a given function call to control
> whether to loop forever or to halt is not decidable.
>
> Patricia

That is obviously completely decidable, (within the specific example that I
provided) just look at the source code, and you can see whether or not this is
occurring.

 0
NoSpam266 (508)
10/19/2006 10:31:34 PM
Peter Olcott says...

>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote

>> You want to have a program willHalt(p,x) with three
>> possible outcomes:
>>
>> (1) If program p halts on input x, then willHalt returns true.
>> (2) If program p does not halt on input x, then willHalt returns false.
>> (3) If program p makes a self-referential call on willHalt, then willHalt
>> throws an exception.
>>
>> Okay, so now let Q(p,x) be some other program with two inputs.
>> Let F(x) be a program with the following behavior:
>>
>>     if Q(x,x) returns true, then loop forever,
>>     if Q(x,x) returns false, then halt.
>>
>> Now, let's run willHalt(F,F). How does willHalt decide whether
>> to throw a "MalignantSelfReferenceException"?
>
>Would you agree that I have shown, that in the specific instance of
>a halting problem that I have provided, that in this specific case,
>the "problem" is merely that the question: "Does LoopIfHalts(LoopIfHalts)
>halt?"  is of the ill-form of requiring a YES or
>NO answer to a question that has no correct YES or NO answer?

No, I don't agree with that, at all. It is a perfectly well-formed
question to ask whether LoopIfHalts(LoopIfHalts) halts. The fact that
WillHalt can't correct answer the question doesn't make the question
ill-formed.

It *is* a yes-no question. It has a yes-no answer. The way that
you have defined LoopIfHalts, it *does* halt (by throwing an exception).

--
Daryl McCullough
Ithaca, NY

 0
10/19/2006 10:34:33 PM
Peter Olcott wrote:
> "Patricia Shanahan" <pats@acm.org> wrote in message
....
>> I strongly disagree with any idea of using the term "halting problem"
>> for this, because the Halting Problem is a decision problem. It asks
>> whether its input is, or is not, a member of a specific language, and
>> the only possible answers are to accept or reject the input.
>
>    http://www.cprogramming.com/tutorial/computersciencetheory/halting.html

That page indeed deals, at least informally, with the halting problem.

However, you seem to have failed to grasp the fact that changing the
rules of the game to allow three results from your function, instead of
the two possible answers from a decision procedure, also changes the
correct design of the calling program in the non-existence proof.

That page is completely irrelevant to your revised problem.

I've already presented one possible replacement program that takes into
account the new rules, as far as I've been able to discover them.

Patricia
 0
pats (3556)
10/19/2006 10:34:47 PM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:b4TZg.11664Y24.2730@newsread4.news.pas.earthlink.net... > Peter Olcott wrote: >> "Patricia Shanahan" <pats@acm.org> wrote in message > ... >>> I strongly disagree with any idea of using the term "halting problem" >>> for this, because the Halting Problem is a decision problem. It asks >>> whether its input is, or is not, a member of a specific language, and >>> the only possible answers are to accept or reject the input. >> >> http://www.cprogramming.com/tutorial/computersciencetheory/halting.html > > That page indeed deals, at least informally, with the halting problem. > > However, you seem to have failed to grasp the fact that changing the > rules of the game to allow three results from your function, instead of > the two possible answers from a decision procedure, also changes the > correct design of the calling program in the non-existence proof. It shows that the original limitation to the two possible Boolean values was artificially contrived to create a problem where none truly existed. What is more plausible, there is something fundamentally wrong with the most basic conception of truth, or a large number of fallible human beings became confused about the fundamental conception of truth for many decades? The fundamental concept of truth is not broken, it retains its full integrity regardless of fallible human misconceptions. > > That page is completely irrelevant to your revised problem. > > I've already presented one possible replacement program that takes into > account the new rules, as far as I've been able to discover them. > > Patricia I missed that.  0 NoSpam266 (508) 10/19/2006 10:47:47 PM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh8tt501jne@drn.newsguy.com... > Peter Olcott says... > >>> Whether it is a valid solution depends on the definition of >>> MALIGNANT_SELF_REFERENCE. If it is just equivalent to the I_GIVE_UP >>> exception, then always throwing it is valid but pointless. >> >>It is equivalent to saying that no correct answer exists to the question, "How >>tall are you green or blue?" because the question itself is ill-formed. It is >>not at all equivalent to I_GIVE_UP. > > On the contrary, there is nothing ill-formed about the question: > > Does the program LoopIfHalts halt when it is fed its own source > code as input. There is nothing ill-formed about this question until one adds the specific context of the LoopIfHalts() program. Thenn (then and only then) the question become ill-formed. There are many questions that are not ill-formed until adding a specific context. > > It's a perfectly sensible question to ask, and your program WillHalt > fails to give a correct answer. Instead, your program raises an > exception. It gives up, rather than answering the question. > > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/19/2006 10:53:45 PM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh8u3001k82@drn.newsguy.com... > Peter Olcott says... > >>I think that I have shown in my prior response to you at least one example of >>a >>halting problem, that is only a problem because it is ill formed. > > No, you did not. There is nothing ill formed about the question: > > Does LoopIfHalts halt when given its own source code as an input? > > Your program WillHalt fails to answer that question, but there is nothing > ill formed about the question. > >>Iff (if and only if) I can reach a consensus on this point > > Your point is false. There is nothing ill-formed about the question. When we add the context that the program always changes the result of any answer that is provided, thenn, the quesion become ill-formed. > > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/19/2006 10:55:40 PM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh8u9q01kru@drn.newsguy.com... > Peter Olcott says... >> >> >>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote > >>> Yes, you are. You are assuming that >>> MalignantSelfReference(SourceCode,InputData) >>> can detect whether there is a "malignant self >>> reference". There is no such program. >> >>I provided the detailed steps of the design of such a program >>for this specific instance of a halting problem TWICE !!! > > You described a MalignantSelfReference detector that works > by checking if LoopIfHalts makes calls to WillHalt. > If instead LoopIfHalts uses a program that is different from, > but has the same behavior as WillHalt, then your detector > will not work. > > -- > Daryl McCullough > Ithaca, NY > So then you admit that I have solved a halting problem, yet do not accept that this solution can be generalized to all halting problems?  0 NoSpam266 (508) 10/20/2006 12:58:03 AM Peter Olcott says... "Daryl McCullough" wrote >> You described a MalignantSelfReference detector that works >> by checking if LoopIfHalts makes calls to WillHalt. >> If instead LoopIfHalts uses a program that is different from, >> but has the same behavior as WillHalt, then your detector >> will not work. > >So then you admit that I have solved a halting problem, No, you have done no such thing. To solve the halting problem means to have a program which, given *any* program p and any input x, returns true if p halts on x, and returns false otherwise. Your program WillHalt doesn't do that. -- Daryl McCullough Ithaca, NY  0 10/20/2006 1:20:41 AM Peter Olcott says... "Daryl McCullough" wrote >> There is nothing ill formed about the question: >> >> Does LoopIfHalts halt when given its own source code as an input? >> >> Your program WillHalt fails to answer that question, but there is nothing >> ill formed about the question. >> >>>Iff (if and only if) I can reach a consensus on this point >> >> Your point is false. There is nothing ill-formed about the question. > >When we add the context that the program always changes the >result of any answer that is provided, then, the quesion >become ill-formed. No, it's not. As you described it, LoopIfHalts *halts* (after raising an exception) if given its own source code as input. So the correct answer to the question is: Yes, LoopIfHalts halts when given its own source code as input. The answer is "true". It's *always* true. There is nothing ill-defined about the question. It's just that WillHalts fails to give the correct answer. -- Daryl McCullough Ithaca, NY  0 10/20/2006 1:27:17 AM Peter Olcott says... >"Daryl McCullough" wrote >> On the contrary, there is nothing ill-formed about the question: >> >> Does the program LoopIfHalts halt when it is fed its own source >> code as input. > >There is nothing ill-formed about this question until one adds >the specific context of the LoopIfHalts() program. Still there is nothing ill-formed about the question. As you've defined it, the answer is "yes". LoopIfHalts halts (after raising an exception) when given its own source code as an input. >There are many questions that are not ill-formed until adding a specific >context. Perhaps, but this is not one of them. -- Daryl McCullough Ithaca, NY  0 10/20/2006 1:29:55 AM "Charlie-Boo" <shymathguy@gmail.com> wrote in message news:1161286660.787506.128520@i42g2000cwa.googlegroups.com... > Peter Olcott wrote: >> "MoeBlee" <jazzmobe@hotmail.com> wrote in message >> news:1161210790.800534.60930@h48g2000cwc.googlegroups.com... >> > Peter Olcott wrote: >> >> What is the >> >> official precise English language conclusion drawn from the results of the >> >> mathematical analysis of the Halting Problem? >> > >> > Why not start by at least informing yourself of an exact mathematical >> > statement of the theorem and its proof? >> > >> > MoeBlee >> > >> >> That is not within my purpose. My purpose is to show that the Halting Problem >> is >> really nothing more than an ill-formed question. > > Ill-formed in what sense? The problem is that it is inconsistent - > regarding whether a program that runs the program being specified > against its input as both program and input, when run against itself > halts or not. Inconsistent in the sense of the ANALYTICAL COMMENTARY mentioned below // // To make the problem more clear we are assuming // that function call syntax results in inline expansion, // thus specifying the name of a function specifies the // text body of the function. // void LoopIfHalts(string SourceCode) { if ( WillHalt(SourceCode, SourceCode) == TRUE ) while (TRUE) // loop forever ; else return; } int WillHalt(string SourceCode, string InputData) { if (MalignantSelfReference(SourceCode, InputData)) throw(MALIGNANT_SELF_REFERENCE); if ( TheProgramWillHalt(SourceCode, InputData) ) return TRUE; else return FALSE; } LoopIfHalts(LoopIfHalts); // ANALYTICAL COMMENTARY WillHalt() is provided with the source code of LoopIfHalts(), as input, so WillHalt() can see exactly how the return value of the invocation of itself under test will be used to toggle the result of the analysis of the invocation of itself under test. WillHalt() can see that LoopIfHalts() is toggling the result of the invocation of itself under test to invalidate the analysis of the invocation of itself under test. Therefore WillHalt() can determine that the question: "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO answer, and is thus erroneously formed because it is asking a YES or NO question that has no correct YES or NO answer. > > Results from Mathematical Logic manifest themselves in common > programming activities. In this case, it is just a case where the > programmer sends the specs back to the applications specialist for > fixing due to bad logic in the spec. > > (I know people don't like the idea that the HP is simply an example of > bad specs, but it's true. There is an inconsistency in the spec when > you put all of its aspects together. You simply have to look at it as > a scientist, rather than becoming emotional and defensive about it.) > > C-B >  0 NoSpam266 (508) 10/20/2006 1:32:45 AM Peter Olcott says... >"Charlie-Boo" <shymathguy@gmail.com> wrote >>> That is not within my purpose. My purpose is to show that the >>> Halting Problem is really nothing more than an ill-formed question. >> >> Ill-formed in what sense? The problem is that it is inconsistent - >> regarding whether a program that runs the program being specified >> against its input as both program and input, when run against itself >> halts or not. > >Inconsistent in the sense of the ANALYTICAL COMMENTARY mentioned below Your commentary doesn't show that the halting problem is an ill-formed question. If a program is deterministic, then whether it halts or not is a meaningful question. The fact that WillHalt is unable to correctly answer question doesn't make the question ill-formed. -- Daryl McCullough Ithaca, NY  0 10/20/2006 1:51:49 AM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh989902chq@drn.newsguy.com... > Peter Olcott says... > > "Daryl McCullough" wrote > >>> You described a MalignantSelfReference detector that works >>> by checking if LoopIfHalts makes calls to WillHalt. >>> If instead LoopIfHalts uses a program that is different from, >>> but has the same behavior as WillHalt, then your detector >>> will not work. >> >>So then you admit that I have solved a halting problem, > > No, you have done no such thing. To solve the halting > problem means to have a program which, given *any* > program p and any input x, returns true if p halts on > x, and returns false otherwise. Your program WillHalt > doesn't do that. See that now I wasn't 100% exact and precise in the choice of my words. I did not really "solve" a halting problem, what I did was show that the only reason that the example of a halting problem that I provided could not be solved because the problem itself was merely an ill-formed question. Would you agree with that? If not, then exactly and precisely, point by point detail by detail what is it that you disagree with, the precisely stated conclusion formed above? > > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/20/2006 2:05:04 AM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh98ll02di5@drn.newsguy.com... > Peter Olcott says... > > "Daryl McCullough" wrote > >>> There is nothing ill formed about the question: >>> >>> Does LoopIfHalts halt when given its own source code as an input? >>> >>> Your program WillHalt fails to answer that question, but there is nothing >>> ill formed about the question. >>> >>>>Iff (if and only if) I can reach a consensus on this point >>> >>> Your point is false. There is nothing ill-formed about the question. >> >>When we add the context that the program always changes the >>result of any answer that is provided, then, the quesion >>become ill-formed. > > No, it's not. As you described it, LoopIfHalts *halts* (after > raising an exception) if given its own source code as input. > So the correct answer to the question is: Yes, LoopIfHalts > halts when given its own source code as input. > > The answer is "true". It's *always* true. There is nothing > ill-defined about the question. It's just that WillHalts > fails to give the correct answer. Yet again you fail to get the precise context correctly, (don't feel bad most everyone had made this same mistake for many decades). The correct answer to the question, also depends on the context of whom is being asked. When you are asked the question there is a different correct answer than when WillHalt() is asked this same question. If I ask you the name of your wife, I get one answer, if I ask your wife the exact same question, "What is the name of your wife?" I get a different answer. Context is everything. > > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/20/2006 2:11:44 AM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh9a3l02het@drn.newsguy.com... > Peter Olcott says... > >>"Charlie-Boo" <shymathguy@gmail.com> wrote > >>>> That is not within my purpose. My purpose is to show that the >>>> Halting Problem is really nothing more than an ill-formed question. >>> >>> Ill-formed in what sense? The problem is that it is inconsistent - >>> regarding whether a program that runs the program being specified >>> against its input as both program and input, when run against itself >>> halts or not. >> >>Inconsistent in the sense of the ANALYTICAL COMMENTARY mentioned below > > Your commentary doesn't show that the halting problem is an > ill-formed question. Yet another case of the lack of precision on your taking the meaning that I am specifying. I am not yet even beginning to talk about THE Halting Problem, I am only talking about one specific instance of A halting problem. > If a program is deterministic, then whether > it halts or not is a meaningful question. The fact that WillHalt > is unable to correctly answer question doesn't make the question > ill-formed. In the specific instance of WillHalt() indeed it does. In the specific instance of WillHalt() it can see than any answer that it provides is corrupted. You think that you can see what the true answer is, and WillHalt() can not see this. This is not the case. WillHalt() can determine the correct answer, the same way that you can determine the correct answer. It merely can not provide this correct answer in the form of a Boolean, because its output path is intentionally corrupted. It can see that its output path is intentionally corrupted, and thus there is no possible correct Boolean answer that it can provide, so it simply calls the game on the count of cheating. > > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/20/2006 2:19:30 AM Peter Olcott says... >"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote >> No, you have done no such thing. To solve the halting >> problem means to have a program which, given *any* >> program p and any input x, returns true if p halts on >> x, and returns false otherwise. Your program WillHalt >> doesn't do that. > >See that now I wasn't 100% exact and precise in the choice of my words. >I did not really "solve" a halting problem, You didn't solve anything, Peter. You just wrote down a couple of programs in pseudo-code. >what I did was show that the only reason that the example of a >halting problem that I provided could not be solved >because the problem itself was merely an ill-formed question. >Would you agree with that? No, there is nothing ill-formed about the question: Does LoopIfHalts halt when given its own source code as input? >If not, then exactly and precisely, point by point detail >by detail what is it that you disagree with What I disagree with is the claim that the question "Does LoopIfHalts halt when given its own source code as input?" is ill-formed. It's perfectly well-formed, and it has a perfectly clear answer: Yes! If WillHalt and MalignantSelfReference behave as advertised, then LoopIfHalts(LoopIfHalts) halts by raising an exception. -- Daryl McCullough Ithaca, NY  0 10/20/2006 2:21:15 AM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:eh9bqr02m8o@drn.newsguy.com... > Peter Olcott says... > >>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote > >>> No, you have done no such thing. To solve the halting >>> problem means to have a program which, given *any* >>> program p and any input x, returns true if p halts on >>> x, and returns false otherwise. Your program WillHalt >>> doesn't do that. >> >>See that now I wasn't 100% exact and precise in the choice of my words. >>I did not really "solve" a halting problem, > > You didn't solve anything, Peter. You just wrote down a couple > of programs in pseudo-code. > >>what I did was show that the only reason that the example of a >>halting problem that I provided could not be solved >>because the problem itself was merely an ill-formed question. >>Would you agree with that? > > No, there is nothing ill-formed about the question: Does > LoopIfHalts halt when given its own source code as input? > >>If not, then exactly and precisely, point by point detail >>by detail what is it that you disagree with > > What I disagree with is the claim that the question > "Does LoopIfHalts halt when given its own source code as input?" > is ill-formed. It's perfectly well-formed, and it has a perfectly > clear answer: Yes! If WillHalt and MalignantSelfReference behave > as advertised, then LoopIfHalts(LoopIfHalts) halts by raising > an exception. Yes, except you ignored the fact that WillHalt() can see that its output path is corrupted. If your output path was corrupted, you would have the same problem. The error that everyone makes on this problem is concluding that WillHalt() can not determine whether or not LoopIfHalts(LoopIfHalts) will halt. WillHalt() CAN DETERMINE that LoopIfHalts(LoopIfHalts) HALTS!!! It merely can not provide the result of this determination using its intentionally corrupted output path. Thus it is not undecidable at all!!! > > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/20/2006 2:52:59 AM Peter Olcott says... >"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote >> If a program is deterministic, then whether >> it halts or not is a meaningful question. The fact that WillHalt >> is unable to correctly answer question doesn't make the question >> ill-formed. > >In the specific instance of WillHalt() indeed it does. No, it doesn't. -- Daryl McCullough Ithaca, NY  0 10/20/2006 3:45:48 AM Peter Olcott says... >"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote >> As you described it, LoopIfHalts *halts* (after >> raising an exception) if given its own source code as input. >> So the correct answer to the question is: Yes, LoopIfHalts >> halts when given its own source code as input. >> >> The answer is "true". It's *always* true. There is nothing >> ill-defined about the question. It's just that WillHalts >> fails to give the correct answer. > >Yet again you fail to get the precise context correctly, >(don't feel bad most everyone had made this same mistake >for many decades). I don't feel bad, it's just that what you are saying is wrong. >The correct answer to the question, also depends on the context >of whom is being asked. No, it does not. >When you are asked the question there is a different correct >answer than when WillHalt() is asked this same question. No, there is not. >If I ask you the name of your wife, I get one answer, >if I ask your wife the exact same question, "What is >the name of your wife?" I get a different answer. >Context is everything. Yes, there are questions whose answer depends on the context, but the halting problem is not one of them. -- Daryl McCullough Ithaca, NY  0 10/20/2006 3:49:27 AM In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: > > <sillybanter@gmail.com> wrote in message news:bnLZg.5347NK5.1822@trnddc08...
> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
> >
> >> So the equivalent of the return value of the Halt() function from
> >> the TM is the integer value that the TM's ReadWrite head rests on
> >> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1
> >> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
> >> recursion of the original specification of the problem, and provides
> >> the only possible correct answer.
> >
> > In the standard presentation of the halting problem, there is no
> > recursion, infinite or otherwise.  Don't be confused by the fact that
> > the same name of a function is used in the analyzed program and in the
> > analyzer - it's not the same thing, and these two instances of
> > "Halt" are completely separate.
>
> See the  ANALYTICAL COMMENTARY of this example mentioned below to see my current
> point.

> ...

> // ANALYTICAL COMMENTARY
> WillHalt() is provided with the source code of LoopIfHalts(), as
> input, so WillHalt() can see exactly how the return value of the
> invocation of itself under test will be used to toggle the result
> of the analysis of the invocation of itself under test.  WillHalt()
> can see that LoopIfHalts() is toggling the result of the invocation
> of itself under test to invalidate the analysis of the invocation
> of itself under test.
>
> Therefore WillHalt() can determine that the question:
> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
> answer, and is thus erroneously formed because it is asking a
> YES or NO question that has no correct YES or NO answer.

Except that it, of course, DOES have a correct YES or NO answer.
LoopIfHalts(LoopIfHalts) absolutely either halts in a finite number of
steps or it doesn't.  It's that simple.  The fact that "WillHalt"
can't correctly determine which of these is the correct answer is
irrelevant to whether the answer exists or not.

So the problem is not ill-formed, but WillHalt doesn't get the right
answer.  That's the whole point, you know...

--

Steve Stringer
sillybanter@gmail.com

 0
10/20/2006 4:54:11 AM
In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>
> <sillybanter@gmail.com> wrote in message news:SrLZg.5348NK5.2906@trnddc08... > > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: > > > >> That seems to be a very precise English language statement that is > >> most typically used to describe the results of the HP. It is this > >> statement that I refute. I may be wrong, I have been wrong before, > >> but, it is still this specific statement that I refute. The HP can > >> be decided, yet the answer can not be restricted to YES or NO > >> because the question is not a YES or NO question. > > > > There are certainly problems that are ill-formed, but the halting > > problem is not one of those. Deal with the real form of the halting > I think that I have shown in my prior response to you at least one > example of a halting problem, that is only a problem because it is > ill formed. No, you certainly haven't. The halting problem is not ill-formed, and has a well-defined answer for each and every input. Including the one that you think, for some reason, doesn't have a yes or no answer. > Iff (if and only if) I can reach a consensus on this > point, I will proceed to a UTM version of the same problem, and > attempt to show the mathematical mapping from the prior example to > the UTM example. I will not do this unless or until I have reached a > consensus on my prior point. You will not get consensus on this point, because you're wrong, and pretty much everyone here except you sees that quite clearly. -- Steve Stringer sillybanter@gmail.com  0 10/20/2006 4:56:51 AM "Peter Olcott" <NoSpam@SeeScreen.com> writes: > It is equivalent to saying that no correct answer exists to the > question, "How tall are you green or blue?" because the question > itself is ill-formed. It is not at all equivalent to I_GIVE_UP. You have not been able to say exactly when a question is ill-formed, and you are very worried about what you see as "malignant self-reference", but the HP comes in many disguises. As a programmer you will be very familiar with context-free grammars. CFGs are used to describe the syntax of all sorts of programming languages: a finite set of clauses describe how, starting from an initial clause, sequences of strings drawn from the grammar's "terminal alphabet" can be generated. Given the simple alphabet S = {0, 1} this grammar: E -> D E | /\ D -> 0 | 1 has the rather boring property that is can generate all strings of 0s and 1s. We say the language of the grammar L(E) = S* (the set of all string made from the symbols in S). I am using /\ to mean the empty string (since it shows up better) and | to show alternatives in rules. The grammar: X -> D X | 1 D -> 0 | 1 does not generate all string because every string in L(X) ends with a 1. It seems to me a simple and well-formed question to ask of a grammar, G, if L(G) = S* and, more specifically, to imagine a program bool generates_all_binary_strings(grammar g) { if (<have a really good look at g and if it does>) return true; else return false } This problem is equivalent to the Halting Problem so the The Halting Theorem tells me that no such program exists, but where is the ill-formedness of the question and where is the malignancy? [Aside. I don't really expect you to be convinced by this. In fact I expect you to say "since I've solved the HP this one is solvable too!". But since you have resolutely refused to say what kind of thing might shake you resolve, I thought I'd try this take -- a simple, easy to understand problem that is just as "nasty" as the HP.] -- Ben.  0 ben.usenet (6790) 10/20/2006 5:20:07 AM "Peter Olcott" <NoSpam@SeeScreen.com> writes: > The Halt program throws an "Invalid Input" exception. > This would be analogous to the hardware exception of an attempt to divide by > zero. For those of you joining this giant thread, I offer a summary, Please correct my inevitable misunderstandings. The OP suggests only a possible "solution" (note the quotes) because I suspect he does not believe it either. All discussion has been obliged to avoid mathematics as this is so precise that it introduces inaccuracies when the results are mapped to the "real world". After several heroic attempts to get his ideas pinned down (by others), it seems to me that he has, possibly[1], solved another problem which I will call the Peter Olcott Problem (POP): Given a program P and input I, return one of {yes, no, <third way>}. "Yes" (and "no") are only to returned when P halts (or not) on input I. The <third way> is not yet entirely resolved. Regular readers will not be surprised by this, as it is well know that POP is solvable. In fact there are an infinity of programs (we are obliged to avoid the formality of Turing Machines) that can solve it, ranging from the trivial: HALTish(P, I) return maybe; through versions for with "maybe" is returned for fewer and fewer (P, I) pairs. No interesting claim has yet been made about the measure of the set of (P, I) for which "maybe" is returned ("empty" and "finite" would both be worth a paper). Oh, and we should not feel to bad about being wrong. Lots of people have been wrong about this over the past 70 years. [1] I say possibly because without any formal definitions it almost impossible to say. -- Ben.  0 ben.usenet (6790) 10/20/2006 6:01:37 AM Peter Olcott schrieb: > // ANALYTICAL COMMENTARY > WillHalt() is provided with the source code of LoopIfHalts(), as > input, so WillHalt() can see exactly how the return value of the > invocation of itself under test will be used to toggle the result > of the analysis of the invocation of itself under test. WillHalt() > can see that LoopIfHalts() is toggling the result of the invocation > of itself under test to invalidate the analysis of the invocation > of itself under test. Would you be so kind and show us how WillHalt accomplishes this, in a more precise form than a verbal comment? It all comes down to you definition of MalignantSelfReference, which I believe is itself undecidable.  0 10/20/2006 7:51:12 AM Peter Olcott wrote: > "Patricia Shanahan" <pats@acm.org> wrote in message > news:b4TZg.11664Y24.2730@newsread4.news.pas.earthlink.net...
>> Peter Olcott wrote:
>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>> ...
>>>> I strongly disagree with any idea of using the term "halting problem"
>>>> for this, because the Halting Problem is a decision problem. It asks
>>>> whether its input is, or is not, a member of a specific language, and
>>>> the only possible answers are to accept or reject the input.
>>>    http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>> That page indeed deals, at least informally, with the halting problem.
>>
>> However, you seem to have failed to grasp the fact that changing the
>> rules of the game to allow three results from your function, instead of
>> the two possible answers from a decision procedure, also changes the
>> correct design of the calling program in the non-existence proof.
>
> It shows that the original limitation to the two possible Boolean values was
> artificially contrived to create a problem where none truly existed.
> What is more plausible, there is something fundamentally wrong with the most
> basic conception of truth, or a large number of fallible human beings became
> confused about the fundamental conception of truth for many decades? The
> fundamental concept of truth is not broken, it retains its full integrity
> regardless of fallible human misconceptions.
>
>> That page is completely irrelevant to your revised problem.
>>
>> I've already presented one possible replacement program that takes into
>> account the new rules, as far as I've been able to discover them.
>>
>> Patricia
>
> I missed that.

****************************
">>" from Peter
">" from me

>> WillHalt() is provided with the source code of LoopIfHalts(), as input, so
>
> Not necessarily. It can be provided with the source code of any program
> that is equivalent to LoopIfHalts in the sense of halting on SoureCode
> if, and only if, SourceCode itself does so:
>
> if ( WillHalt(ObfuscateHorribly(SourceCode),SourceCode) == True )
>
> For example, ObfuscateHorribly may translate SourceCode to Snobol, and
> wrap it up with a Snobol interpreter.
>
>
>> WillHalt() can see exactly how the return value of the invocation of itself under test will be used to toggle the result of the analysis of the invocation of itself under test.  WillHalt() can see that LoopIfHalts() is toggling the result of the invocation of itself under test to invalidate the analysis of the invocation of itself under test.
>
> How does it recognize programs equivalent, but not identical, to itself?
>
> Moreover, you need to consider far more complicated LoopIfHalts
> implementations. The result of the WillHalt test may be run through all
> sorts of calculations before ultimately controlling a halt or loop decision.
>
> The loop can be far subtler. It might, for example, be a search for the
> largest prime number.

*******************************

So, how does WillHalt work if the program it is given is a Snobol
interpreter bound with a Snobol program that may, or may not, be
halting-equivalent to the program calling WillHalt?

Or, for that matter, an interpreter for some new, unpublished,
programming language bound with a program in that language that may, or
may not, be halting-equivalent to the calling program?

Patricia
 0
pats (3556)
10/20/2006 8:27:06 AM
"Peter Olcott" <NoSpam@SeeScreen.com> wrote:
>     if (MalignantSelfReference(SourceCode, InputData))

This isn't code, it's wishful thinking.  You haven't proved that
any such function as MalignantSelfReference can exist, you haven't
programmed it, and you haven't proved that it always returns a value.

For that matter you haven't even *specified* it.

==============  j-c  ======  @  ======  purr . demon . co . uk  ==============
Jack Campin:  11 Third St, Newtongrange EH22 4PU, Scotland | tel 0131 660 4760
<http://www.purr.demon.co.uk/jack/>   for CD-ROMs and free | fax 0870 0554 975
stuff: Scottish music, food intolerance, & Mac logic fonts | mob 07800 739 557
 0
bogus20 (22)
10/20/2006 10:11:27 AM
Jack Campin - bogus address wrote:
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote:
>>     if (MalignantSelfReference(SourceCode, InputData))
>
> This isn't code, it's wishful thinking.  You haven't proved that
> any such function as MalignantSelfReference can exist, you haven't
> programmed it, and you haven't proved that it always returns a value.
>
> For that matter you haven't even *specified* it.

He has said something to the effect that a program contains "malignant
self-reference" if it has a call to Halt with its own source as an argument.

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
 0
10/20/2006 10:37:44 AM
Aatu Koskensilta says...
>
>Jack Campin - bogus address wrote:
>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote:
>>>     if (MalignantSelfReference(SourceCode, InputData))
>>
>> This isn't code, it's wishful thinking.  You haven't proved that
>> any such function as MalignantSelfReference can exist, you haven't
>> programmed it, and you haven't proved that it always returns a value.
>>
>> For that matter you haven't even *specified* it.
>
>He has said something to the effect that a program contains "malignant
>self-reference" if it has a call to Halt with its own source as an argument.

I seem to remember an article from long ago in which Peter suggested
that tight computer security could be used to solve the halting
problem. The idea is that you keep the source code for Halt secret,
so that nobody can ever use it to generate a logical contradiction.

--
Daryl McCullough
Ithaca, NY

 0
10/20/2006 11:18:15 AM
Daryl McCullough wrote:
> I seem to remember an article from long ago in which Peter suggested
> that tight computer security could be used to solve the halting
> problem. The idea is that you keep the source code for Halt secret,
> so that nobody can ever use it to generate a logical contradiction.

That was one of his sillier ideas, yes. It appears he didn't follow my
earlier suggestion and read up on recursive functions so as to be able
to show how to implement "protected memory" and what not in terms of those.

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
 0
10/20/2006 11:53:42 AM
"Patricia Shanahan" <pats@acm.org> wrote in message
news:uL%Zg.16267$UG4.9344@newsread2.news.pas.earthlink.net... > Peter Olcott wrote: >> "Patricia Shanahan" <pats@acm.org> wrote in message >> news:b4TZg.11664$Y24.2730@newsread4.news.pas.earthlink.net...
>>> Peter Olcott wrote:
>>>> "Patricia Shanahan" <pats@acm.org> wrote in message
>>> ...
>>>>> I strongly disagree with any idea of using the term "halting problem"
>>>>> for this, because the Halting Problem is a decision problem. It asks
>>>>> whether its input is, or is not, a member of a specific language, and
>>>>> the only possible answers are to accept or reject the input.
>>>>    http://www.cprogramming.com/tutorial/computersciencetheory/halting.html
>>> That page indeed deals, at least informally, with the halting problem.
>>>
>>> However, you seem to have failed to grasp the fact that changing the
>>> rules of the game to allow three results from your function, instead of
>>> the two possible answers from a decision procedure, also changes the
>>> correct design of the calling program in the non-existence proof.
>>
>> It shows that the original limitation to the two possible Boolean values was
>> artificially contrived to create a problem where none truly existed.
>> What is more plausible, there is something fundamentally wrong with the most
>> basic conception of truth, or a large number of fallible human beings became
>> confused about the fundamental conception of truth for many decades? The
>> fundamental concept of truth is not broken, it retains its full integrity
>> regardless of fallible human misconceptions.
>>
>>> That page is completely irrelevant to your revised problem.
>>>
>>> I've already presented one possible replacement program that takes into
>>> account the new rules, as far as I've been able to discover them.
>>>
>>> Patricia
>>
>> I missed that.
>
> ****************************
> ">>" from Peter
> ">" from me
>
>>> WillHalt() is provided with the source code of LoopIfHalts(), as input, so
>>
>> Not necessarily. It can be provided with the source code of any program
>> that is equivalent to LoopIfHalts in the sense of halting on SoureCode
>> if, and only if, SourceCode itself does so:
>>
>> if ( WillHalt(ObfuscateHorribly(SourceCode),SourceCode) == True )
>>
>> For example, ObfuscateHorribly may translate SourceCode to Snobol, and
>> wrap it up with a Snobol interpreter.
>>
>>
>>> WillHalt() can see exactly how the return value of the invocation of itself
>>> under test will be used to toggle the result of the analysis of the
>>> invocation of itself under test.  WillHalt() can see that LoopIfHalts() is
>>> toggling the result of the invocation of itself under test to invalidate the
>>> analysis of the invocation of itself under test.
>>
>> How does it recognize programs equivalent, but not identical, to itself?
>>
>> Moreover, you need to consider far more complicated LoopIfHalts
>> implementations. The result of the WillHalt test may be run through all
>> sorts of calculations before ultimately controlling a halt or loop decision.
>>
>> The loop can be far subtler. It might, for example, be a search for the
>> largest prime number.
>
> *******************************
>
> So, how does WillHalt work if the program it is given is a Snobol
> interpreter bound with a Snobol program that may, or may not, be
> halting-equivalent to the program calling WillHalt?
>
> Or, for that matter, an interpreter for some new, unpublished,
> programming language bound with a program in that language that may, or
> may not, be halting-equivalent to the calling program?
>
> Patricia

I will only proceed beyond this example, iff you agree that I have made my point
with this example.

 0
NoSpam266 (508)
10/20/2006 12:36:12 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:eh9gpc093@drn.newsguy.com...
> Peter Olcott says...
>
>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote
>
>>> If a program is deterministic, then whether
>>> it halts or not is a meaningful question. The fact that WillHalt
>>> is unable to correctly answer question doesn't make the question
>>> ill-formed.
>>
>>In the specific instance of WillHalt() indeed it does.
>
> No, it doesn't.
>
> --
> Daryl McCullough
> Ithaca, NY
>
I have proven that it does, if you don't think that it does, then prove that it
does not.

 0
NoSpam266 (508)
10/20/2006 12:37:38 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:eh9h070n5@drn.newsguy.com...
> Peter Olcott says...
>
>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote
>
>>> As you described it, LoopIfHalts *halts* (after
>>> raising an exception) if given its own source code as input.
>>> So the correct answer to the question is: Yes, LoopIfHalts
>>> halts when given its own source code as input.
>>>
>>> The answer is "true". It's *always* true. There is nothing
>>> ill-defined about the question. It's just that WillHalts
>>> fails to give the correct answer.
>>
>>Yet again you fail to get the precise context correctly,
>
> I don't feel bad, it's just that what you are saying
> is wrong.
>
>>The correct answer to the question, also depends on the context
>
> No, it does not.
>
>>When you are asked the question there is a different correct
>
> No, there is not.
>
>>Context is everything.
>
> Yes, there are questions whose answer depends on the
> context, but the halting problem is not one of them.

Merely an empty unsupported statement. I have proven my point, and you have
failed to correctly point out the specific error of it. Now you are not even
bothering to point out any errors, and have resorted to mere unsupported
statements.

>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/20/2006 12:40:07 PM
<sillybanter@gmail.com> wrote in message news:TDYZg.3794$4T6.1422@trnddc02... > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> >> <sillybanter@gmail.com> wrote in message news:bnLZg.5347$NK5.1822@trnddc08...
>> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>> >
>> >> So the equivalent of the return value of the Halt() function from
>> >> the TM is the integer value that the TM's ReadWrite head rests on
>> >> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1
>> >> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
>> >> recursion of the original specification of the problem, and provides
>> >> the only possible correct answer.
>> >
>> > In the standard presentation of the halting problem, there is no
>> > recursion, infinite or otherwise.  Don't be confused by the fact that
>> > the same name of a function is used in the analyzed program and in the
>> > analyzer - it's not the same thing, and these two instances of
>> > "Halt" are completely separate.
>>
>> See the  ANALYTICAL COMMENTARY of this example mentioned below to see my
>> current
>> point.
>
>> ...
>
>> // ANALYTICAL COMMENTARY
>> WillHalt() is provided with the source code of LoopIfHalts(), as
>> input, so WillHalt() can see exactly how the return value of the
>> invocation of itself under test will be used to toggle the result
>> of the analysis of the invocation of itself under test.  WillHalt()
>> can see that LoopIfHalts() is toggling the result of the invocation
>> of itself under test to invalidate the analysis of the invocation
>> of itself under test.
>>
>> Therefore WillHalt() can determine that the question:
>> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
>> answer, and is thus erroneously formed because it is asking a
>> YES or NO question that has no correct YES or NO answer.
>
> Except that it, of course, DOES have a correct YES or NO answer.

So which of the correct YES or NO answers can WillHalt() provide such that it
has provided the correct YES or NO answer? If you are correct, then you MUST be
able to correctly select one of these, otherwise YOU ARE INCORRECT!!!  THERE
EXISTS NO CORRECT YES OR NO ANSWER THAT WillHalt() CAN POSSIBLY PROVIDE, THUS
THIS HALTING PROBLEM IS MERELY THE CASE OF THE INABILITY TO CORRECTLY ANSWER AN
ILL-FORMED QUESTION ENTIRELY DUE TO THE FACT THAT THE QUESTION ITSELF IS
ILL-FORMED!!!

> LoopIfHalts(LoopIfHalts) absolutely either halts in a finite number of
> steps or it doesn't.  It's that simple.  The fact that "WillHalt"
> can't correctly determine which of these is the correct answer is
> irrelevant to whether the answer exists or not.
>
> So the problem is not ill-formed, but WillHalt doesn't get the right
> answer.  That's the whole point, you know...
>
> --
>
> Steve Stringer
> sillybanter@gmail.com
>

 0
NoSpam266 (508)
10/20/2006 12:46:00 PM
Peter Olcott wrote:
> "Patricia Shanahan" <pats@acm.org> wrote in message
....
> I will only proceed beyond this example, iff you agree that I have made my point
> with this example.

Bye.
 0
pats (3556)
10/20/2006 12:57:36 PM
Peter Olcott wrote:
> So which of the correct YES or NO answers can WillHalt() provide such that it
> has provided the correct YES or NO answer? If you are correct, then you MUST be
> able to correctly select one of these, otherwise YOU ARE INCORRECT!!!  THERE
> EXISTS NO CORRECT YES OR NO ANSWER THAT WillHalt() CAN POSSIBLY PROVIDE

Too bad for WillHalt, then. The program still either halts or does not
halt given the input.

> THUS THIS HALTING PROBLEM IS MERELY THE CASE OF THE INABILITY TO CORRECTLY ANSWER
> AN ILL-FORMED QUESTION ENTIRELY DUE TO THE FACT THAT THE QUESTION ITSELF IS
> ILL-FORMED!!!

Yep, it might be that WillHalt could answer "Well, this question is
posed so that I can't possibly answer it correctly", but then it would
have to use some algorithm to decide which program-input pairs
constitute ill-formed questions. What is your proposed algorithm for
doing so?

For example, is the following question ill-formed:

Does the program P halt with input 0?

where P is a program executing the following algorithm

1. n := 4
2. if n isn't a sum of two primes, go into an endless loop if
WillHalt("P",0) returns true and otherwise print "neener-neener"
3. n := n+2
4. Go to step 2

What is the algorithm WillHalt uses to determine whether this is an
ill-formed question or not?

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
 0
10/20/2006 1:03:34 PM
<sillybanter@gmail.com> wrote in message news:TDYZg.3794$4T6.1422@trnddc02... > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> >> <sillybanter@gmail.com> wrote in message news:bnLZg.5347$NK5.1822@trnddc08...
>> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>> >
>> >> So the equivalent of the return value of the Halt() function from
>> >> the TM is the integer value that the TM's ReadWrite head rests on
>> >> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1
>> >> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
>> >> recursion of the original specification of the problem, and provides
>> >> the only possible correct answer.
>> >
>> > In the standard presentation of the halting problem, there is no
>> > recursion, infinite or otherwise.  Don't be confused by the fact that
>> > the same name of a function is used in the analyzed program and in the
>> > analyzer - it's not the same thing, and these two instances of
>> > "Halt" are completely separate.
>>
>> See the  ANALYTICAL COMMENTARY of this example mentioned below to see my
>> current
>> point.
>
>> ...
>
>> // ANALYTICAL COMMENTARY
>> WillHalt() is provided with the source code of LoopIfHalts(), as
>> input, so WillHalt() can see exactly how the return value of the
>> invocation of itself under test will be used to toggle the result
>> of the analysis of the invocation of itself under test.  WillHalt()
>> can see that LoopIfHalts() is toggling the result of the invocation
>> of itself under test to invalidate the analysis of the invocation
>> of itself under test.
>>
>> Therefore WillHalt() can determine that the question:
>> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
>> answer, and is thus erroneously formed because it is asking a
>> YES or NO question that has no correct YES or NO answer.
>
> Except that it, of course, DOES have a correct YES or NO answer.
> LoopIfHalts(LoopIfHalts) absolutely either halts in a finite number of
> steps or it doesn't.  It's that simple.  The fact that "WillHalt"
> can't correctly determine which of these is the correct answer is
> irrelevant to whether the answer exists or not.
>
> So the problem is not ill-formed, but WillHalt doesn't get the right
> answer.  That's the whole point, you know...

It does get the right answer!!! It simply can not provide the results of its
correct and complete decision to a caller that toggles the result of this return
value. I will say it again, most everyone have missed this point:  IT DOES GET

>
> --
>
> Steve Stringer
> sillybanter@gmail.com
>

 0
NoSpam266 (508)
10/20/2006 1:26:04 PM
<sillybanter@gmail.com> wrote in message news:nGYZg.3795$4T6.1868@trnddc02... > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> >> <sillybanter@gmail.com> wrote in message news:SrLZg.5348$NK5.2906@trnddc08...
>> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>> >
>> >> That seems to be a very precise English language statement that is
>> >> most typically used to describe the results of the HP. It is this
>> >> statement that I refute. I may be wrong, I have been wrong before,
>> >> but, it is still this specific statement that I refute. The HP can
>> >> be decided, yet the answer can not be restricted to YES or NO
>> >> because the question is not a YES or NO question.
>> >
>> > There are certainly problems that are ill-formed, but the halting
>> > problem is not one of those.  Deal with the real form of the halting
>
>> I think that I have shown in my prior response to you at least one
>> example of a halting problem, that is only a problem because it is
>> ill formed.
>
> No, you certainly haven't.  The halting problem is not ill-formed, and
> has a well-defined answer for each and every input.  Including the one
> that you think, for some reason, doesn't have a yes or no answer.
>
>> Iff (if and only if) I can reach a consensus on this
>> point, I will proceed to a UTM version of the same problem, and
>> attempt to show the mathematical mapping from the prior example to
>> the UTM example. I will not do this unless or until I have reached a
>> consensus on my prior point.
>
> You will not get consensus on this point, because you're wrong, and
> pretty much everyone here except you sees that quite clearly.
>
> --
>
> Steve Stringer
> sillybanter@gmail.com
>

Or, pretty much everyone here does not 100% completely grasp every subtle nuance
of the complete meaning of my statements.

 0
NoSpam266 (508)
10/20/2006 1:27:32 PM
Peter Olcott schrieb:

> It does get the right answer!!! It simply can not provide the results of its
> correct and complete decision to a caller that toggles the result of this return
> value. I will say it again, most everyone have missed this point:  IT DOES GET
How do check for this? Do you just search for the string "WillHalt" with
needed parameters?
 0
10/20/2006 1:44:19 PM
Peter Olcott says...

>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote

>> Yes, there are questions whose answer depends on the
>> context, but the halting problem is not one of them.
>
>Merely an empty unsupported statement.

No, it's a provably correct statement.

>I have proven my point,

No, you haven't.

--
Daryl McCullough
Ithaca, NY

 0
10/20/2006 1:59:52 PM
Peter Olcott says...

>>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote
>>
>>>> If a program is deterministic, then whether
>>>> it halts or not is a meaningful question. The fact that WillHalt
>>>> is unable to correctly answer question doesn't make the question
>>>> ill-formed.
>>>
>>>In the specific instance of WillHalt() indeed it does.
>>
>> No, it doesn't.

>I have proven that it does

No, you haven't. The way you described it, WillHalt will throw
a "MalignantSelfReferenceException", which is not correctly answering
the question.

--
Daryl McCullough
Ithaca, NY

 0
10/20/2006 2:02:18 PM
In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
> <sillybanter@gmail.com> wrote in message news:TDYZg.3794$4T6.1422@trnddc02... > > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: > >> > >> <sillybanter@gmail.com> wrote in message news:bnLZg.5347$NK5.1822@trnddc08...
> >> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
> >> >
> >> >> So the equivalent of the return value of the Halt() function from
> >> >> the TM is the integer value that the TM's ReadWrite head rests on
> >> >> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1
> >> >> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
> >> >> recursion of the original specification of the problem, and provides
> >> >> the only possible correct answer.
> >> >
> >> > In the standard presentation of the halting problem, there is no
> >> > recursion, infinite or otherwise.  Don't be confused by the fact that
> >> > the same name of a function is used in the analyzed program and in the
> >> > analyzer - it's not the same thing, and these two instances of
> >> > "Halt" are completely separate.
> >>
> >> See the  ANALYTICAL COMMENTARY of this example mentioned below to see my
> >> current
> >> point.
> >
> >> ...
> >
> >> // ANALYTICAL COMMENTARY
> >> WillHalt() is provided with the source code of LoopIfHalts(), as
> >> input, so WillHalt() can see exactly how the return value of the
> >> invocation of itself under test will be used to toggle the result
> >> of the analysis of the invocation of itself under test.  WillHalt()
> >> can see that LoopIfHalts() is toggling the result of the invocation
> >> of itself under test to invalidate the analysis of the invocation
> >> of itself under test.
> >>
> >> Therefore WillHalt() can determine that the question:
> >> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
> >> answer, and is thus erroneously formed because it is asking a
> >> YES or NO question that has no correct YES or NO answer.
> >
> > Except that it, of course, DOES have a correct YES or NO answer.

> So which of the correct YES or NO answers can WillHalt() provide
> such that it has provided the correct YES or NO answer? If you are
> correct, then you MUST be able to correctly select one of these,
> otherwise YOU ARE INCORRECT!!!  THERE EXISTS NO CORRECT YES OR NO
> ANSWER THAT WillHalt() CAN POSSIBLY PROVIDE, THUS THIS HALTING
> PROBLEM IS MERELY THE CASE OF THE INABILITY TO CORRECTLY ANSWER AN
> ILL-FORMED QUESTION ENTIRELY DUE TO THE FACT THAT THE QUESTION
> ITSELF IS ILL-FORMED!!!

If you really think about what you yourself just wrote there, you
would see that you've exactly described the contradiction that is the
heart of the halting problem proof, and hence you have proved that the
halting problem is undecidable.

Let me try to point this out as clearly as I can - you say "which of
the correct YES or NO answers can WillHalt() provide such that it has
provided the correct YES or NO answer?"  The answer is NEITHER.  That
doesn't mean that the answer doesn't exist just that this particular
algorithm (WillHalt) is wrong.  That WillHalt doesn't "provide the
correct YES or NO answer" in no way, shape, or form implies that the
answer doesn't exist - just that this particular algorithm can't
determine it.

You say "THERE EXISTS NO CORRECT YES OR NO ANSWER THAT WillHalt() CAN
POSSIBLY PROVIDE" - you're absolutely correct that WillHalt will
never, ever provide the correct input on this particular input.  So
what?  *Other* algorithms could take this exact same input (with the
WillHalt source code) and PROVIDE THE CORRECT ANSWER (we're typing in
all caps now I see).  But they'll give the wrong answer on *other*
inputs.

Here's another attempt at explaining it:  we agree that WillHalt
doesn't return the right YES or NO answer.  There are really only two
possibilities:

1) The problem is ill-formed and there is no correct answer.
2) The problem is well-formed and WillHalt is wrong.

The reason WillHalt fails is precisly because of #2.  You argue that
the problem is ill-formed *because* WillHalt fails - that's a
completely bogus argument because of the (correct) possibility of #2.

If the problem is ill-formed, then you should be able to describe why
that is so, without talking about how one particular algorithm
behaves.  That algorithm not behaving well on a particular input just
means that the algorithm is wrong on that input.  Other algorithms are
correct on that input, and so the problem is not ill-formed.

So here's your specific challenge: try to argue that the problem is
ill-formed without relying on how one particular algorithm behaves on
one particular input, because that's falacious reasoning.

--

Steve Stringer
sillybanter@gmail.com

 0
10/20/2006 3:10:12 PM
In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
> <sillybanter@gmail.com> wrote in message news:TDYZg.3794$4T6.1422@trnddc02... > > Except that it, of course, DOES have a correct YES or NO answer. > > LoopIfHalts(LoopIfHalts) absolutely either halts in a finite number of > > steps or it doesn't. It's that simple. The fact that "WillHalt" > > can't correctly determine which of these is the correct answer is > > irrelevant to whether the answer exists or not. > > > > So the problem is not ill-formed, but WillHalt doesn't get the right > > answer. That's the whole point, you know... > It does get the right answer!!! It simply can not provide the > results of its correct and complete decision to a caller that > toggles the result of this return value. I will say it again, most > everyone have missed this point: IT DOES GET THE RIGHT ANSWER!!! It does not get the correct YES or NO answer, which you have acknowledged in other posts. It gives a cop-out "None of the above" answer - it may be correct that the algorithm doesn't know the answer, but there *is* a correct YES or NO answer that it does *not* get. -- Steve Stringer sillybanter@gmail.com  0 10/20/2006 3:14:07 PM On Fri, 20 Oct 2006 08:27:32 -0500, Peter Olcott <NoSpam@SeeScreen.com> said: > > <sillybanter@gmail.com> wrote in message > news:nGYZg.3795$4T6.1868@trnddc02...
>>> Iff (if and only if) I can reach a consensus on this
>>> point, I will proceed to a UTM version of the same problem, and
>>> attempt to show the mathematical mapping from the prior example to
>>> the UTM example. I will not do this unless or until I have reached a
>>> consensus on my prior point.
>>
>> You will not get consensus on this point, because you're wrong, and
>> pretty much everyone here except you sees that quite clearly.
>
> Or, pretty much everyone here does not 100% completely grasp every
> subtle nuance of the complete meaning of my statements.

Or not. :-)  What are the odds, dude?

 0
cmenzel (185)
10/20/2006 4:11:59 PM
On 20 Oct 2006 04:18:15 -0700, Daryl McCullough
<stevendaryl3016@yahoo.com> said:
> Aatu Koskensilta says...
>>
>>Jack Campin - bogus address wrote:
>>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote:
>>>>     if (MalignantSelfReference(SourceCode, InputData))
>>>
>>> This isn't code, it's wishful thinking.  You haven't proved that
>>> any such function as MalignantSelfReference can exist, you haven't
>>> programmed it, and you haven't proved that it always returns a value.
>>>
>>> For that matter you haven't even *specified* it.
>>
>>He has said something to the effect that a program contains "malignant
>>self-reference" if it has a call to Halt with its own source as an
>>argument.
>
> I seem to remember an article from long ago in which Peter suggested
> that tight computer security could be used to solve the halting
> problem. The idea is that you keep the source code for Halt secret,
> so that nobody can ever use it to generate a logical contradiction.

Yes, and if only Russell hadn't sent that damned letter to Frege we
could still be using Naive Comprehension!

 0
cmenzel (185)
10/20/2006 4:14:34 PM
On Thursday 19 October 2006 18:14, Peter Olcott wrote:
> int WillHalt(string SourceCode, string InputData)   {
>     if (MalignantSelfReference(SourceCode, InputData))
>         throw(MALIGNANT_SELF_REFERENCE);
>     if ( TheProgramWillHalt(SourceCode, InputData) )
>         return TRUE;
>     else
>         return FALSE;
> }

Peter, in the spirit of your MalignantSelfReference() routine, I have
a program that solves the question of the existence of God:

void doesGodExist() {
if GodExists()
write("Yes, God exists");
else
write("No, God does not exist");
}

Since the subroutine GodExists() always terminates and gives the
correct answer, clearly this program will final provide mankind with
the answer to the question of whether God exists.

If you disagree that this is correct, please point out exactly where
the problem is with doesGodExit().

Sincerely,
-paul-
--
Paul E. Black (p.black@acm.org)
 0
p.black (279)
10/20/2006 6:46:23 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:eh7vo302e00@drn.newsguy.com...
> Peter Olcott says...
>
>>So you agree that my example shows that within the specific context of this
>>example I have shown that this specific form of a Halting Problem is merely
>>the
>>ill-formed question of:
>>"Does LoopIfHalts(LoopIfHalts) halt?"
>
> That's not an ill-formed question. It is a perfectly good question, and it
> has a perfectly good answer: Yes, it halts (by throwing an exception).

Yes you can see that the program halts, AND WillHalt() can also SEE that the
program halts. It is not undecidable because both you and WillHalt() can decide
this.

>
> (The semantics of exceptions hasn't been spelled out, but in most normal
> programming languages, if a program throws an exception, then the program
> stops at that point.)
>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/20/2006 8:06:29 PM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:87y7rbmum0.fsf@bsb.me.uk...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> It is equivalent to saying that no correct answer exists to the
>> question, "How tall are you green or blue?" because the question
>> itself is ill-formed. It is not at all equivalent to I_GIVE_UP.
>
> You have not been able to say exactly when a question is ill-formed,

I have said this many times here it is again.

//
//  To make the problem more clear we are assuming
//  that function call syntax results in inline expansion,
//  thus specifying the name of a function specifies the
//  text body of the function.
//

void LoopIfHalts(string SourceCode)  {
if ( WillHalt(SourceCode, SourceCode) == TRUE )
while (TRUE)    // loop forever
;
else
return;
}

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

LoopIfHalts(LoopIfHalts);

// ANALYTICAL COMMENTARY
WillHalt() is provided with the source code of LoopIfHalts(), as
input, so WillHalt() can see exactly how the return value of the
invocation of itself under test will be used to toggle the result
of the analysis of the invocation of itself under test.  WillHalt()
can see that LoopIfHalts() is toggling the result of the invocation
of itself under test to invalidate the analysis of the invocation
of itself under test.

Therefore WillHalt() can determine that the question:
"Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
YES or NO question that has no correct YES or NO answer.

> and you are very worried about what you see as "malignant
> self-reference", but the HP comes in many disguises.
>
> As a programmer you will be very familiar with context-free grammars.
> CFGs are used to describe the syntax of all sorts of programming
> languages: a finite set of clauses describe how, starting from an
> initial clause, sequences of strings drawn from the grammar's "terminal
> alphabet" can be generated.  Given the simple alphabet S = {0, 1} this
> grammar:
>
>  E -> D E | /\
>  D -> 0 | 1
>
> has the rather boring property that is can generate all strings of 0s
> and 1s.  We say the language of the grammar L(E) = S* (the set of all
> string made from the symbols in S).  I am using /\ to mean the empty
> string (since it shows up better) and | to show alternatives in rules.
>
> The grammar:
>
>  X -> D X | 1
>  D -> 0 | 1
>
> does not generate all string because every string in L(X) ends with a 1.
>
> It seems to me a simple and well-formed question to ask of a grammar,
> G, if L(G) = S* and, more specifically, to imagine a program
>
>  bool generates_all_binary_strings(grammar g)
>  {
>      if (<have a really good look at g and if it does>)
>           return true;
>      else return false
>  }
>
> This problem is equivalent to the Halting Problem so the The Halting
> Theorem tells me that no such program exists, but where is the
> ill-formedness of the question and where is the malignancy?
>
> [Aside.  I don't really expect you to be convinced by this.  In fact I
> expect you to say "since I've solved the HP this one is solvable
> too!".  But since you have resolutely refused to say what kind of
> thing might shake you resolve, I thought I'd try this take -- a
> simple, easy to understand problem that is just as "nasty" as the HP.]
>
> --
> Ben.

 0
NoSpam266 (508)
10/20/2006 8:09:04 PM
"Jens Auer" <jens.auer-news@betaversion.net> wrote in message
news:eh9v3q$lhs$1@f1node01.rhrz.uni-bonn.de...
> Peter Olcott schrieb:
>> // ANALYTICAL COMMENTARY
>> WillHalt() is provided with the source code of LoopIfHalts(), as
>> input, so WillHalt() can see exactly how the return value of the
>> invocation of itself under test will be used to toggle the result
>> of the analysis of the invocation of itself under test.  WillHalt()
>> can see that LoopIfHalts() is toggling the result of the invocation
>> of itself under test to invalidate the analysis of the invocation
>> of itself under test.
> Would you be so kind and show us how WillHalt accomplishes this, in a more
> precise form than a verbal comment? It all comes down to you definition of
> MalignantSelfReference, which I believe is itself undecidable.

I have already said this quite a few times in the ANALYTICAL COMMENTARY. Why
don't you point out the precise point within the exact phrase of this ANALYTICAL
COMMENTARY that you either fail to understand, or disagree with.

WillHalt() performs the same sort of simulated execution trace that a human
would use to unequivocally determine that it WILL indeed HALT. From this same
sort of simulated execution trace it can obviously see (in the same way that a
person can see) that providing this decision back to its caller is corrupted by
its caller to change the result of the decision.

Because it can see this (in the same way that a person can see this), it can
determine (in the same way that a person can determine) that even though it
knows full well that it will halt, (thus is not undecidable) it can not provide
this result back to its caller without the result becoming corrupted by the
caller.

//
//  To make the problem more clear we are assuming
//  that function call syntax results in inline expansion,
//  thus specifying the name of a function specifies the
//  text body of the function.
//

void LoopIfHalts(string SourceCode)  {
if ( WillHalt(SourceCode, SourceCode) == TRUE )
while (TRUE)    // loop forever
;
else
return;
}

int WillHalt(string SourceCode, string InputData)   {
if (MalignantSelfReference(SourceCode, InputData))
throw(MALIGNANT_SELF_REFERENCE);
if ( TheProgramWillHalt(SourceCode, InputData) )
return TRUE;
else
return FALSE;
}

LoopIfHalts(LoopIfHalts);

// ANALYTICAL COMMENTARY
WillHalt() is provided with the source code of LoopIfHalts(), as
input, so WillHalt() can see exactly how the return value of the
invocation of itself under test will be used to toggle the result
of the analysis of the invocation of itself under test.  WillHalt()
can see that LoopIfHalts() is toggling the result of the invocation
of itself under test to invalidate the analysis of the invocation
of itself under test.

Therefore WillHalt() can determine that the question:
"Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
YES or NO question that has no correct YES or NO answer.

 0
NoSpam266 (508)
10/20/2006 8:23:24 PM
"Jack Campin - bogus address" <bogus@purr.demon.co.uk> wrote in message
news:bogus-6F2222.11112720102006@news.news.demon.net...
> "Peter Olcott" <NoSpam@SeeScreen.com> wrote:
>>     if (MalignantSelfReference(SourceCode, InputData))
>
> This isn't code, it's wishful thinking.  You haven't proved that
> any such function as MalignantSelfReference can exist, you haven't
> programmed it, and you haven't proved that it always returns a value.
>
> For that matter you haven't even *specified* it.

I have specified it several times, you are merely looking at it through the
biased filter of a closed mind.

>
> ==============  j-c  ======  @  ======  purr . demon . co . uk  ==============
> Jack Campin:  11 Third St, Newtongrange EH22 4PU, Scotland | tel 0131 660 4760
> <http://www.purr.demon.co.uk/jack/>   for CD-ROMs and free | fax 0870 0554 975
> stuff: Scottish music, food intolerance, & Mac logic fonts | mob 07800 739 557

 0
NoSpam266 (508)
10/20/2006 8:24:44 PM
"Aatu Koskensilta" <aatu.koskensilta@xortec.fi> wrote in message
news:VF1_g.9762aa.9293@reader1.news.jippii.net... > Jack Campin - bogus address wrote: >> "Peter Olcott" <NoSpam@SeeScreen.com> wrote: >>> if (MalignantSelfReference(SourceCode, InputData)) >> >> This isn't code, it's wishful thinking. You haven't proved that >> any such function as MalignantSelfReference can exist, you haven't >> programmed it, and you haven't proved that it always returns a value. >> >> For that matter you haven't even *specified* it. > > He has said something to the effect that a program contains "malignant > self-reference" if it has a call to Halt with its own source as an argument. AND, the return value of this call to Halt() is specifically and intentionally used to corrupt this result. There are other required factors too, essentially if it is in the form of the provided example then it is the form of MALIGNANT_SELF_REFERENCE. > > -- > Aatu Koskensilta (aatu.koskensilta@xortec.fi) > > "Wovon man nicht sprechen kann, daruber muss man schweigen" > - Ludwig Wittgenstein, Tractatus Logico-Philosophicus  0 NoSpam266 (508) 10/20/2006 8:28:41 PM "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message news:ehab9n01r9b@drn.newsguy.com... > Aatu Koskensilta says... >> >>Jack Campin - bogus address wrote: >>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote: >>>> if (MalignantSelfReference(SourceCode, InputData)) >>> >>> This isn't code, it's wishful thinking. You haven't proved that >>> any such function as MalignantSelfReference can exist, you haven't >>> programmed it, and you haven't proved that it always returns a value. >>> >>> For that matter you haven't even *specified* it. >> >>He has said something to the effect that a program contains "malignant >>self-reference" if it has a call to Halt with its own source as an argument. > > I seem to remember an article from long ago in which Peter suggested > that tight computer security could be used to solve the halting > problem. The idea is that you keep the source code for Halt secret, > so that nobody can ever use it to generate a logical contradiction. > > -- > Daryl McCullough > Ithaca, NY > That entire line-or-reasoning had been correctly refuted by a PhD computer science professor calling themselves NewToMe. The line-of-reasoning that I am providing now is the only possible line-of-reasoning that could work within the categorically complete enumeration of every possible line-of-reasoning that could ever possibly exist.  0 NoSpam266 (508) 10/20/2006 8:31:42 PM Peter Olcott wrote: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:87y7rbmum0.fsf@bsb.me.uk... >> "Peter Olcott" <NoSpam@SeeScreen.com> writes: >> >>> It is equivalent to saying that no correct answer exists to the >>> question, "How tall are you green or blue?" because the question >>> itself is ill-formed. It is not at all equivalent to I_GIVE_UP. >> You have not been able to say exactly when a question is ill-formed, > > I have said this many times here it is again. > > // > // To make the problem more clear we are assuming > // that function call syntax results in inline expansion, > // thus specifying the name of a function specifies the > // text body of the function. > // > > void LoopIfHalts(string SourceCode) { > if ( WillHalt(SourceCode, SourceCode) == TRUE ) > while (TRUE) // loop forever > ; > else > return; > } > > int WillHalt(string SourceCode, string InputData) { > if (MalignantSelfReference(SourceCode, InputData)) > throw(MALIGNANT_SELF_REFERENCE); > if ( TheProgramWillHalt(SourceCode, InputData) ) > return TRUE; > else > return FALSE; > } > > LoopIfHalts(LoopIfHalts); > > // ANALYTICAL COMMENTARY > WillHalt() is provided with the source code of LoopIfHalts(), as > input, so WillHalt() can see exactly how the return value of the > invocation of itself under test will be used to toggle the result > of the analysis of the invocation of itself under test. WillHalt() > can see that LoopIfHalts() is toggling the result of the invocation > of itself under test to invalidate the analysis of the invocation > of itself under test. > > Therefore WillHalt() can determine that the question: > "Does LoopIfHalts(LoopIfHalts) halt?" has no correct YES or NO > answer, and is thus erroneously formed because it is asking a > YES or NO question that has no correct YES or NO answer. > > In order to define a function you need to state the domain and co-domain, and a rule determining which element of the co-domain is associated with each element of the domain. All you have told us about MalignantSelfReference is a single element of its domain, and that it is true for that element. From its use in an if-test, I assume it is a Boolean function, a function whose co-domain is a set containing some representation of "true" and "false", but I have not yet been told about any element of its domain for which it is false. If its domain really only contained one element, then it could be defined by telling us the value for that element. However, that would make it inappropriate for the way it is being used in WillHalt. Without a definition, other than a single domain-range pair, for MalignantSelfReference, the source code is useless for defining your WillHalt. Patricia  0 pats (3556) 10/20/2006 8:53:32 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:4J3_g.9838Lv3.8958@newsread1.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Patricia Shanahan" <pats@acm.org> wrote in message
> ...
>> I will only proceed beyond this example, iff you agree that I have made my
>> point with this example.
>
> Bye.

I would much rather fail to make my point entirely that to get caught up in any
endlessly circular arguments. I simply don't have time for these. If the only
way that you can possibly refute me is by continuing to change the subject, then
you have not refuted me at all.

Try it with the more specific break down.

You as a human can see the greater perspective regarding whether or not
LoopIfHalts(LoopIfHalts) will halt. You can see that it will halt, the correct
asnwer is obviously YES. Let's take this next step:
What correct YES or NO answer can WillHalt() provide to LoopIfHalts() ???

Are you seeing something that WillHalt() can not possibly see, or are you merely
providing an answer that WillHalt() can not possibly provide?

Is there any difference what-so-ever between KNOWING an answer, and PROVIDING an
Is KNOWING an answer 100% exactly and precisely the same thing as PROVIDING and

 0
NoSpam266 (508)
10/20/2006 8:54:29 PM
"Aatu Koskensilta" <aatu.koskensilta@xortec.fi> wrote in message
news:DO3_g.9833$vw1.5754@reader1.news.jippii.net... > Peter Olcott wrote: >> So which of the correct YES or NO answers can WillHalt() provide such that it >> has provided the correct YES or NO answer? If you are correct, then you MUST >> be able to correctly select one of these, otherwise YOU ARE INCORRECT!!! >> THERE EXISTS NO CORRECT YES OR NO ANSWER THAT WillHalt() CAN POSSIBLY PROVIDE > > Too bad for WillHalt, then. The program still either halts or does not halt > given the input. > >> THUS THIS HALTING PROBLEM IS MERELY THE CASE OF THE INABILITY TO CORRECTLY >> ANSWER AN ILL-FORMED QUESTION ENTIRELY DUE TO THE FACT THAT THE QUESTION >> ITSELF IS ILL-FORMED!!! > > Yep, it might be that WillHalt could answer "Well, this question is posed so > that I can't possibly answer it correctly", but then it would have to use some > algorithm to decide which program-input pairs constitute ill-formed questions. > What is your proposed algorithm for doing so? In order to make it possible for me to make my point, I must insist that the conversation never digresses to tangents until the prerequisite point is made. I have already shown, and it is completely obvious that there is no possible correct YES or NO answer that WillHalt() can possibly provide. The fact that there is a possible correct YES or NO answer that someone else can provide always draws people's attention from the fact that there is no possible correct YES or NO answer that WillHalt() can possibly provide. From the fact that there is no possible YES or NO answer that WillHalt() can possibly provide, the logical leap is made that WillHalt() must not know the answer because it can not provide the answer. This is stated in the form WillHalt() can not correctly decide whether or not LoopIfHalts(LoopIfHalts) will halt. My point is that this logical leap is an error, it does not logically follow. It might even be possible for WillHalt() to always provide the correct determination regarding whether or not LoopIfHalts(LoopIfHalts) will halt. I will not begin to provide my reasoning on this point until the prerequisite point is first made. > > For example, is the following question ill-formed: > > Does the program P halt with input 0? > > where P is a program executing the following algorithm > > 1. n := 4 > 2. if n isn't a sum of two primes, go into an endless loop if > WillHalt("P",0) returns true and otherwise print "neener-neener" > 3. n := n+2 > 4. Go to step 2 > > What is the algorithm WillHalt uses to determine whether this is an ill-formed > question or not? > > -- > Aatu Koskensilta (aatu.koskensilta@xortec.fi) > > "Wovon man nicht sprechen kann, daruber muss man schweigen" > - Ludwig Wittgenstein, Tractatus Logico-Philosophicus  0 NoSpam266 (508) 10/20/2006 9:10:50 PM "Jens Auer" <jens.auer-news@betaversion.net> wrote in message news:ehajpt$p5k1@f1node01.rhrz.uni-bonn.de... > Peter Olcott schrieb: > >> It does get the right answer!!! It simply can not provide the results of its >> correct and complete decision to a caller that toggles the result of this >> return value. I will say it again, most everyone have missed this point: IT >> DOES GET THE RIGHT ANSWER!!! > How do check for this? Do you just search for the string "WillHalt" with > needed parameters? It can do a simulated execution trace using the SourceCode for LoopIfHalts(), and its own SourceCode, if needed.  0 NoSpam266 (508) 10/20/2006 9:12:11 PM In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: > "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message > news:ehab9n01r9b@drn.newsguy.com... > > Aatu Koskensilta says... > >> > >>Jack Campin - bogus address wrote: > >>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote: > >>>> if (MalignantSelfReference(SourceCode, InputData)) > >>> > >>> This isn't code, it's wishful thinking. You haven't proved that > >>> any such function as MalignantSelfReference can exist, you haven't > >>> programmed it, and you haven't proved that it always returns a value. > >>> > >>> For that matter you haven't even *specified* it. > >> > >>He has said something to the effect that a program contains "malignant > >>self-reference" if it has a call to Halt with its own source as an argument. > > > > I seem to remember an article from long ago in which Peter suggested > > that tight computer security could be used to solve the halting > > problem. The idea is that you keep the source code for Halt secret, > > so that nobody can ever use it to generate a logical contradiction. > > > > -- > > Daryl McCullough > > Ithaca, NY > That entire line-or-reasoning had been correctly refuted by a PhD > computer science professor calling themselves NewToMe. The > line-of-reasoning that I am providing now is the only possible > line-of-reasoning that could work within the categorically complete > enumeration of every possible line-of-reasoning that could ever > possibly exist. Actually, that's "NewsToMe" (Usenet News - get it?). I know that, because that was me -- I've just changed ISPs and posting names now... -- Steve Stringer sillybanter@gmail.com  0 10/20/2006 9:16:23 PM Peter Olcott schrieb: > I have already said this quite a few times in the ANALYTICAL COMMENTARY. Why > don't you point out the precise point within the exact phrase of this ANALYTICAL > COMMENTARY that you either fail to understand, or disagree with. > > WillHalt() performs the same sort of simulated execution trace that a human > would use to unequivocally determine that it WILL indeed HALT. From this same > sort of simulated execution trace it can obviously see (in the same way that a > person can see) that providing this decision back to its caller is corrupted by > its caller to change the result of the decision. So, you can obviously see if a program terminates on any input? This is great, I can't and if I need to show it, I have to prove it by hand (or with the help of some semi-automated verification tool), but this is not as simple as looking at it. > Because it can see this (in the same way that a person can see this), it can > determine (in the same way that a person can determine) that even though it > knows full well that it will halt, (thus is not undecidable) it can not provide > this result back to its caller without the result becoming corrupted by the > caller. > // ANALYTICAL COMMENTARY > WillHalt() is provided with the source code of LoopIfHalts(), as > input, so WillHalt() can see exactly how the return value of the > invocation of itself under test will be used to toggle the result > of the analysis of the invocation of itself under test. WillHalt() > can see that LoopIfHalts() is toggling the result of the invocation > of itself under test to invalidate the analysis of the invocation > of itself under test. So, if I get this correctly (without a precise in terms of source code definition of MalignantSelfReference() this is more guessing than reasoning.), WillHalt checks the source code it is given as argument whether it is called somewhere, and the result is used to form the contradiction. By this, you hope to avoid the constructed counter-example. But what do you do if I feed in the source code of LoopIfHalts, where I replaced the call to WillHalt with another function (as a source code entity, not a mathematical function) which has the same behaviour (in computational terms, both program compute the same function)? Can your magic function MalignantSelfReference() detect this? Still, I would like to see a definition of MalignantSelfReference, even as pseudo-code or as a mathematical definition for the set of programs it decides. This would ease talking very much.  0 10/20/2006 9:18:05 PM "Patricia Shanahan" <pats@acm.org> wrote in message news:gHa_g.12168Y24.4097@newsread4.news.pas.earthlink.net...
> Peter Olcott wrote:
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:87y7rbmum0.fsf@bsb.me.uk...
>>> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>>>
>>>> It is equivalent to saying that no correct answer exists to the
>>>> question, "How tall are you green or blue?" because the question
>>>> itself is ill-formed. It is not at all equivalent to I_GIVE_UP.
>>> You have not been able to say exactly when a question is ill-formed,
>>
>> I have said this many times here it is again.
>>
>> //
>> //  To make the problem more clear we are assuming
>> //  that function call syntax results in inline expansion,
>> //  thus specifying the name of a function specifies the
>> //  text body of the function.
>> //
>>
>> void LoopIfHalts(string SourceCode)  {
>>      if ( WillHalt(SourceCode, SourceCode) == TRUE )
>>         while (TRUE)    // loop forever
>>             ;
>>      else
>>         return;
>> }
>>
>> int WillHalt(string SourceCode, string InputData)   {
>>     if (MalignantSelfReference(SourceCode, InputData))
>>         throw(MALIGNANT_SELF_REFERENCE);
>>     if ( TheProgramWillHalt(SourceCode, InputData) )
>>         return TRUE;
>>     else
>>         return FALSE;
>> }
>>
>> LoopIfHalts(LoopIfHalts);
>>
>> // ANALYTICAL COMMENTARY
>> WillHalt() is provided with the source code of LoopIfHalts(), as
>> input, so WillHalt() can see exactly how the return value of the
>> invocation of itself under test will be used to toggle the result
>> of the analysis of the invocation of itself under test.  WillHalt()
>> can see that LoopIfHalts() is toggling the result of the invocation
>> of itself under test to invalidate the analysis of the invocation
>> of itself under test.
>>
>> Therefore WillHalt() can determine that the question:
>> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
>> answer, and is thus erroneously formed because it is asking a
>> YES or NO question that has no correct YES or NO answer.
>>
>>
>
> In order to define a function you need to state the domain and
> co-domain, and a rule determining which element of the co-domain is
> associated with each element of the domain.
>
> All you have told us about MalignantSelfReference is a single element of
> its domain, and that it is true for that element. From its use in an
> if-test, I assume it is a Boolean function, a function whose co-domain
> is a set containing some representation of "true" and "false", but I
> have not yet been told about any element of its domain for which it is
> false.
>
> If its domain really only contained one element, then it could be
> defined by telling us the value for that element. However, that would
> make it inappropriate for the way it is being used in WillHalt.
>
> Without a definition, other than a single domain-range pair, for
> MalignantSelfReference, the source code is useless for defining your
> WillHalt.
>
> Patricia

It simply sees the same obvious things in this specific example that a person
can see. At this point this function is only intended to work for this one
single example. It is completely obvious to anyone with much compsci background
that WillHalt() can not possible provide a correct YES or NO answer within this
example. All that  MalignantSelfReference(SourceCode, InputData) does is make
this same obvious determination for this single isolated example.

 0
NoSpam266 (508)
10/20/2006 9:21:38 PM
Peter Olcott schrieb:

> > How do check for this? Do you just search for the string "WillHalt" with
> > needed parameters?
>
> It can do a simulated execution trace using the SourceCode for LoopIfHalts(),
> and its own SourceCode, if needed.
So, the set of all programs which are MalignantSelfReference is the set
of all programs equivalent to LoopIfHalts? Is this what you want to
check? What do you do if the given source code is not equivalent, but
does not terminate? Remember, we are in the process of deciding if it
halts, so we do not know yet if it does or doesn't.
Anyway, program equivalence is itself undecidable. You have won
nothing.
Instead of talking around it, take a minute and write down your
algorithm to check if a program is MalignantSelfReference.

 0
10/20/2006 9:31:57 PM
>
> Peter Olcott schrieb:
>
>> > How do check for this? Do you just search for the string "WillHalt" with
>> > needed parameters?
>>
>> It can do a simulated execution trace using the SourceCode for LoopIfHalts(),
>> and its own SourceCode, if needed.
> So, the set of all programs which are MalignantSelfReference is the set
> of all programs equivalent to LoopIfHalts? Is this what you want to

To make my points in prerequisite order, we only need to assume that
MalignantSelfReference() will correctly work for this single isolated example.

> check? What do you do if the given source code is not equivalent, but
> does not terminate? Remember, we are in the process of deciding if it
> halts, so we do not know yet if it does or doesn't.
> Anyway, program equivalence is itself undecidable. You have won
> nothing.
> Instead of talking around it, take a minute and write down your
> algorithm to check if a program is MalignantSelfReference.
>

 0
NoSpam266 (508)
10/20/2006 9:43:06 PM
<sillybanter@gmail.com> wrote in message news:H0b_g.42rx.8@trnddc04... > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> "Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message >> news:ehab9n01r9b@drn.newsguy.com... >> > Aatu Koskensilta says... >> >> >> >>Jack Campin - bogus address wrote: >> >>> "Peter Olcott" <NoSpam@SeeScreen.com> wrote: >> >>>> if (MalignantSelfReference(SourceCode, InputData)) >> >>> >> >>> This isn't code, it's wishful thinking. You haven't proved that >> >>> any such function as MalignantSelfReference can exist, you haven't >> >>> programmed it, and you haven't proved that it always returns a value. >> >>> >> >>> For that matter you haven't even *specified* it. >> >> >> >>He has said something to the effect that a program contains "malignant >> >>self-reference" if it has a call to Halt with its own source as an >> >>argument. >> > >> > I seem to remember an article from long ago in which Peter suggested >> > that tight computer security could be used to solve the halting >> > problem. The idea is that you keep the source code for Halt secret, >> > so that nobody can ever use it to generate a logical contradiction. >> > >> > -- >> > Daryl McCullough >> > Ithaca, NY > >> That entire line-or-reasoning had been correctly refuted by a PhD >> computer science professor calling themselves NewToMe. The >> line-of-reasoning that I am providing now is the only possible >> line-of-reasoning that could work within the categorically complete >> enumeration of every possible line-of-reasoning that could ever >> possibly exist. > > Actually, that's "NewsToMe" (Usenet News - get it?). > > I know that, because that was me -- I've just changed ISPs and posting > names now... > > -- > > Steve Stringer > sillybanter@gmail.com > So you are the PhD computer science professor that correctly refuted my prior line-of-reasoning? What was the basis for this correct refutation?  0 NoSpam266 (508) 10/20/2006 9:45:15 PM Peter Olcott schrieb: > "Jens Auer" <jens.muaddib@googlemail.com> wrote in message > news:1161379917.023649.306150@i42g2000cwa.googlegroups.com... > > > > Peter Olcott schrieb: > > > >> > How do check for this? Do you just search for the string "WillHalt" with > >> > needed parameters? > >> > >> It can do a simulated execution trace using the SourceCode for LoopIfHalts(), > >> and its own SourceCode, if needed. > > So, the set of all programs which are MalignantSelfReference is the set > > of all programs equivalent to LoopIfHalts? Is this what you want to > > To make my points in prerequisite order, we only need to assume that > MalignantSelfReference() will correctly work for this single isolated example. But then your MalignantSelfReference() is useless, since it would not recognize any transformed, but computationally equivalent function to LoopIfHalts(), because it contains just one set. These functions would form the contradictions for your Peter-Olcott-Halting-Problem in the same way as the real Halting Problem, so your WillHalt can't exist. If you insist on not defining either MalignantSelfReference() by a precise definition (*not* in informal english, but as an algorithm in some form) or the set of all functions it recognizes, the discussion is useless and a waste of time.  0 10/20/2006 10:12:32 PM "Jens Auer" <jens.muaddib@googlemail.com> wrote in message news:1161382352.504072.11180@b28g2000cwb.googlegroups.com... > Peter Olcott schrieb: > >> "Jens Auer" <jens.muaddib@googlemail.com> wrote in message >> news:1161379917.023649.306150@i42g2000cwa.googlegroups.com... >> > >> > Peter Olcott schrieb: >> > >> >> > How do check for this? Do you just search for the string "WillHalt" with >> >> > needed parameters? >> >> >> >> It can do a simulated execution trace using the SourceCode for >> >> LoopIfHalts(), >> >> and its own SourceCode, if needed. >> > So, the set of all programs which are MalignantSelfReference is the set >> > of all programs equivalent to LoopIfHalts? Is this what you want to >> >> To make my points in prerequisite order, we only need to assume that >> MalignantSelfReference() will correctly work for this single isolated >> example. > But then your MalignantSelfReference() is useless, since it would not No its not is proves the one prerequisite point so that we can then proceed to the next step. Once my point is proven within the specific context is this single isolated example, thenn (then and only then) we can proceed to generalize this point. There is no sense in generalizing any point that is not yet made. > recognize any transformed, but computationally equivalent function to > LoopIfHalts(), because it contains just one set. These functions would > form the contradictions for your Peter-Olcott-Halting-Problem in the > same way as the real Halting Problem, so your WillHalt can't exist. If > you insist on not defining either MalignantSelfReference() by a precise > definition (*not* in informal english, but as an algorithm in some > form) or the set of all functions it recognizes, the discussion is > useless and a waste of time. >  0 NoSpam266 (508) 10/20/2006 10:18:49 PM "Jens Auer" <jens.muaddib@googlemail.com> wrote in message news:1161379085.191236.24700@e3g2000cwe.googlegroups.com... > Peter Olcott schrieb: > >> I have already said this quite a few times in the ANALYTICAL COMMENTARY. Why >> don't you point out the precise point within the exact phrase of this >> ANALYTICAL >> COMMENTARY that you either fail to understand, or disagree with. >> >> WillHalt() performs the same sort of simulated execution trace that a human >> would use to unequivocally determine that it WILL indeed HALT. From this same >> sort of simulated execution trace it can obviously see (in the same way that >> a >> person can see) that providing this decision back to its caller is corrupted >> by >> its caller to change the result of the decision. > So, you can obviously see if a program terminates on any input? This is > great, I can't and if I need to show it, I have to prove it by hand (or > with the help of some semi-automated verification tool), but this is > not as simple as looking at it. > >> Because it can see this (in the same way that a person can see this), it can >> determine (in the same way that a person can determine) that even though it >> knows full well that it will halt, (thus is not undecidable) it can not >> provide >> this result back to its caller without the result becoming corrupted by the >> caller. > >> // ANALYTICAL COMMENTARY >> WillHalt() is provided with the source code of LoopIfHalts(), as >> input, so WillHalt() can see exactly how the return value of the >> invocation of itself under test will be used to toggle the result >> of the analysis of the invocation of itself under test. WillHalt() >> can see that LoopIfHalts() is toggling the result of the invocation >> of itself under test to invalidate the analysis of the invocation >> of itself under test. > So, if I get this correctly (without a precise in terms of source code > definition of MalignantSelfReference() this is more guessing than > reasoning.), WillHalt checks the source code it is given as argument > whether it is called somewhere, and the result is used to form the > contradiction. By this, you hope to avoid the constructed > counter-example. > But what do you do if I feed in the source code of LoopIfHalts, where I > replaced the call to WillHalt with another function (as a source code > entity, not a mathematical function) which has the same behaviour (in > computational terms, both program compute the same function)? Can your > magic function MalignantSelfReference() detect this? It makes no sense at all to attempt to generalize any point that is not yet made. I must restrict all of my responses to the single isolated example that I have provided, because of the inherent prerequisite order of my points. Only after this example is fully analyzed would it make any sense to proceed beyond this example. If I can't prove my point within the context of this single isolated example, then every other point becomes completely moot. > > Still, I would like to see a definition of MalignantSelfReference, even > as pseudo-code or as a mathematical definition for the set of programs > it decides. This would ease talking very much. >  0 NoSpam266 (508) 10/20/2006 10:30:23 PM <sillybanter@gmail.com> wrote in message news:oF5_g.21A27.19@trnddc08...
> In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>> <sillybanter@gmail.com> wrote in message news:TDYZg.3794$4T6.1422@trnddc02... >> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >> >> >> >> <sillybanter@gmail.com> wrote in message >> >> news:bnLZg.5347$NK5.1822@trnddc08...
>> >> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>> >> >
>> >> >> So the equivalent of the return value of the Halt() function from
>> >> >> the TM is the integer value that the TM's ReadWrite head rests on
>> >> >> when the TM halts. In this case DOES_NOT_HALT=0 HALTS=1
>> >> >> MALIGNANT_SELF_REFERENCE=2. This scenario breaks out of the infinite
>> >> >> recursion of the original specification of the problem, and provides
>> >> >> the only possible correct answer.
>> >> >
>> >> > In the standard presentation of the halting problem, there is no
>> >> > recursion, infinite or otherwise.  Don't be confused by the fact that
>> >> > the same name of a function is used in the analyzed program and in the
>> >> > analyzer - it's not the same thing, and these two instances of
>> >> > "Halt" are completely separate.
>> >>
>> >> See the  ANALYTICAL COMMENTARY of this example mentioned below to see my
>> >> current
>> >> point.
>> >
>> >> ...
>> >
>> >> // ANALYTICAL COMMENTARY
>> >> WillHalt() is provided with the source code of LoopIfHalts(), as
>> >> input, so WillHalt() can see exactly how the return value of the
>> >> invocation of itself under test will be used to toggle the result
>> >> of the analysis of the invocation of itself under test.  WillHalt()
>> >> can see that LoopIfHalts() is toggling the result of the invocation
>> >> of itself under test to invalidate the analysis of the invocation
>> >> of itself under test.
>> >>
>> >> Therefore WillHalt() can determine that the question:
>> >> "Does LoopIfHalts(LoopIfHalts) halt?"   has no correct YES or NO
>> >> answer, and is thus erroneously formed because it is asking a
>> >> YES or NO question that has no correct YES or NO answer.
>> >
>> > Except that it, of course, DOES have a correct YES or NO answer.
>
>> So which of the correct YES or NO answers can WillHalt() provide
>> such that it has provided the correct YES or NO answer? If you are
>> correct, then you MUST be able to correctly select one of these,
>> otherwise YOU ARE INCORRECT!!!  THERE EXISTS NO CORRECT YES OR NO
>> ANSWER THAT WillHalt() CAN POSSIBLY PROVIDE, THUS THIS HALTING
>> PROBLEM IS MERELY THE CASE OF THE INABILITY TO CORRECTLY ANSWER AN
>> ILL-FORMED QUESTION ENTIRELY DUE TO THE FACT THAT THE QUESTION
>> ITSELF IS ILL-FORMED!!!
>
> If you really think about what you yourself just wrote there, you
> would see that you've exactly described the contradiction that is the
> heart of the halting problem proof, and hence you have proved that the
> halting problem is undecidable.

Right there is the error. This reasoning has not shown that the HP is
undecidable. There is a subtle but crucial distinction between deciding the
correct answer to a question, and providing a correct answer to a question. It
is very possible to provide a correct answer without knowing it (guessing is
possible), and it is also possible to know the correct answer without providing
it. There is nothing at all that prevents WillHalt() from deciding the correct

>
> Let me try to point this out as clearly as I can - you say "which of
> the correct YES or NO answers can WillHalt() provide such that it has
> provided the correct YES or NO answer?"  The answer is NEITHER.  That
> doesn't mean that the answer doesn't exist just that this particular
> algorithm (WillHalt) is wrong.  That WillHalt doesn't "provide the
> correct YES or NO answer" in no way, shape, or form implies that the
> answer doesn't exist - just that this particular algorithm can't
> determine it.
>
> You say "THERE EXISTS NO CORRECT YES OR NO ANSWER THAT WillHalt() CAN
> POSSIBLY PROVIDE" - you're absolutely correct that WillHalt will
> never, ever provide the correct input on this particular input.  So
> what?  *Other* algorithms could take this exact same input (with the
> WillHalt source code) and PROVIDE THE CORRECT ANSWER (we're typing in
> all caps now I see).  But they'll give the wrong answer on *other*
> inputs.
>
> Here's another attempt at explaining it:  we agree that WillHalt
> doesn't return the right YES or NO answer.  There are really only two
> possibilities:
>
>  1) The problem is ill-formed and there is no correct answer.
>  2) The problem is well-formed and WillHalt is wrong.
>
> The reason WillHalt fails is precisly because of #2.  You argue that
> the problem is ill-formed *because* WillHalt fails - that's a
> completely bogus argument because of the (correct) possibility of #2.
>
> If the problem is ill-formed, then you should be able to describe why
> that is so, without talking about how one particular algorithm
> behaves.  That algorithm not behaving well on a particular input just
> means that the algorithm is wrong on that input.  Other algorithms are
> correct on that input, and so the problem is not ill-formed.
>
> So here's your specific challenge: try to argue that the problem is
> ill-formed without relying on how one particular algorithm behaves on
> one particular input, because that's falacious reasoning.

I will make no attempt to generalize the single isolated example that I
provided, because it would be fruitless to attempt to generalize any point not

>
> --
>
> Steve Stringer
> sillybanter@gmail.com
>

 0
NoSpam266 (508)
10/20/2006 10:53:03 PM
"Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
news:slrnejhtaf.297d.cmenzel@philebus.tamu.edu...
> On Fri, 20 Oct 2006 08:27:32 -0500, Peter Olcott <NoSpam@SeeScreen.com>
> said:
>>
>> <sillybanter@gmail.com> wrote in message
>> news:nGYZg.37954T6.1868@trnddc02... >>>> Iff (if and only if) I can reach a consensus on this >>>> point, I will proceed to a UTM version of the same problem, and >>>> attempt to show the mathematical mapping from the prior example to >>>> the UTM example. I will not do this unless or until I have reached a >>>> consensus on my prior point. >>> >>> You will not get consensus on this point, because you're wrong, and >>> pretty much everyone here except you sees that quite clearly. >> >> Or, pretty much everyone here does not 100% completely grasp every >> subtle nuance of the complete meaning of my statements. > > Or not. :-) What are the odds, dude? > I think that the odds that the fundamental concept of truth is broken are far less than the odds of many people being confused for many decades.  0 NoSpam266 (508) 10/20/2006 10:55:28 PM "Daryl McCullough" <stevendarhyl3016@yahoo.com> wrote in message news:ehakta02j4r@drn.newsguy.com... > Peter Olcott says... > >>>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote >>> >>>>> If a program is deterministic, then whether >>>>> it halts or not is a meaningful question. The fact that WillHalt >>>>> is unable to correctly answer question doesn't make the question >>>>> ill-formed. >>>> >>>>In the specific instance of WillHalt() indeed it does. >>> >>> No, it doesn't. > >>I have proven that it does > > No, you haven't. The way you described it, WillHalt will throw > a "MalignantSelfReferenceException", which is not correctly answering > the question. > If you were WillHalt() what correct answer would you provide? If someone corrupted your output mechanism by tying you up and taping your mouth shut, what correct answer would you provide? Does tying you up, and taping your mouth shut make the problem undecidable? > -- > Daryl McCullough > Ithaca, NY >  0 NoSpam266 (508) 10/20/2006 10:59:07 PM Peter Olcott says... >"Daryl McCullough" <stevendarhyl3016@yahoo.com> wrote >> No, you haven't. The way you described it, WillHalt will throw >> a "MalignantSelfReferenceException", which is not correctly answering >> the question. >> > >If you were WillHalt() what correct answer would you provide? If I were WillHalt, I would answer the way I was programmed to, which is to raise an exception. However, the correct answer in this case is "yes", LoopIfHalts(LoopIfHalts) halts (by throwing an exception). WillHalt fails to give the correct answer in this case, and if I were WillHalt, then I would fail to give the correct answer in this case. -- Daryl McCullough Ithaca, NY  0 10/20/2006 11:43:37 PM Peter Olcott says... >I think that the odds that the fundamental concept of truth is broken are far >less than the odds of many people being confused for many decades. Even better odds are that (1) the fundamental concept of truth is *not* broken, and (2) the halting problem is undecidable, as many people have concluded over the decades, and (3) that Peter Olcott is confused both about the halting problem and the concept of truth. -- Daryl McCullough Ithaca, NY  0 10/20/2006 11:45:40 PM Peter Olcott says... >Right there is the error. This reasoning has not shown that the HP is >undecidable. There is a subtle but crucial distinction between deciding the >correct answer to a question, and providing a correct answer to a question. No, as far as computer programs are concerned, there is no difference. To say that a computer program can decide a question *means* that it provides the correct answer. -- Daryl McCullough Ithaca, NY  0 10/20/2006 11:48:26 PM Peter Olcott wrote: > "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message > news:slrnejhtaf.297d.cmenzel@philebus.tamu.edu... >> On Fri, 20 Oct 2006 08:27:32 -0500, Peter Olcott <NoSpam@SeeScreen.com> >> said: >>> <sillybanter@gmail.com> wrote in message >>> news:nGYZg.37954T6.1868@trnddc02...
>>>>> Iff (if and only if) I can reach a consensus on this
>>>>> point, I will proceed to a UTM version of the same problem, and
>>>>> attempt to show the mathematical mapping from the prior example to
>>>>> the UTM example. I will not do this unless or until I have reached a
>>>>> consensus on my prior point.
>>>> You will not get consensus on this point, because you're wrong, and
>>>> pretty much everyone here except you sees that quite clearly.
>>> Or, pretty much everyone here does not 100% completely grasp every
>>> subtle nuance of the complete meaning of my statements.
>> Or not. :-)  What are the odds, dude?
>>
> I think that the odds that the fundamental concept of truth is broken are far
> less than the odds of many people being confused for many decades.

There is nothing about the fundamental concept of truth that is broken
by proof of undecidability of the Halting problem.

Suppose we are given an arbitrary decision algorithm A. We don't know
what A does. Maybe someone thinks it is a Halting problem decision
algorithm. Maybe it was intended to decide if its input describes the
combination of a traveling salesman problem and the total weight for a
solution. Maybe we have no idea what, if anything, it was designed to do.

We can supply an input that proves A is not a Halting problem decision
algorithm. The input is the description of a computation (program and
input). If that computation halts, it is an input A rejects. If
that computation loops for ever, it is an input A accepts.

We can do that for any decision algorithm A, so most of us deduce that
there is no decision algorithm for the Halting problem.

If you take the existence of a decision algorithm for the Halting
problem as an axiom, while retaining the normal axioms that ultimately
underly theory of computation, you end up with an inconsistent system of
axioms. Even then, it is the set of axioms that is broken, not the
fundamental concept of truth.

Patricia
 0
pats (3556)
10/20/2006 11:56:22 PM
Peter Olcott says...

>> Would you be so kind and show us how WillHalt accomplishes this, in a more
>> precise form than a verbal comment? It all comes down to you definition of
>> MalignantSelfReference, which I believe is itself undecidable.
>
>I have already said this quite a few times in the ANALYTICAL COMMENTARY.

Actually, it doesn't matter. If WillHalt raises an exception, instead
of answering "true" or "false", then it doesn't solve the halting problem
in this instance.

--
Daryl McCullough
Ithaca, NY

 0
10/20/2006 11:57:28 PM
Peter Olcott says...

>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote:

>>>So you agree that my example shows that within the specific context of this
>>>example I have shown that this specific form of a Halting Problem is merely
>>>the ill-formed question of: "Does LoopIfHalts(LoopIfHalts) halt?"
>>
>> That's not an ill-formed question. It is a perfectly good question, and it
>> has a perfectly good answer: Yes, it halts (by throwing an exception).
>
>Yes you can see that the program halts, AND WillHalt() can also SEE that the
>program halts.

Then why did you call it an ill-formed question? You are contradicting
yourself.

--
Daryl McCullough
Ithaca, NY

 0
10/20/2006 11:58:50 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehbmv902e76@drn.newsguy.com...
> Peter Olcott says...
>
>>"Daryl McCullough" <stevendarhyl3016@yahoo.com> wrote
>
>>> No, you haven't. The way you described it, WillHalt will throw
>>> a "MalignantSelfReferenceException", which is not correctly answering
>>> the question.
>>>
>>
>>If you were WillHalt() what correct answer would you provide?
>
> If I were WillHalt, I would answer the way I was programmed to,
> which is to raise an exception. However, the correct answer in
> this case is "yes", LoopIfHalts(LoopIfHalts) halts
> (by throwing an exception). WillHalt fails to give the correct
> answer in this case, and if I were WillHalt, then I would fail
> to give the correct answer in this case.
>
> --
> Daryl McCullough
> Ithaca, NY
>

If someone corrupted your output mechanism by tying you up and taping your mouth
shut, what correct answer would you provide? Does tying you up, and taping your
mouth shut make the problem undecidable?

 0
NoSpam266 (508)
10/21/2006 12:02:36 AM
Peter Olcott says...

>If someone corrupted your output mechanism by tying you up and taping

If my mouth were taped shut, I wouldn't provide a correct answer.
But that doesn't make the question ill-formed. The question is
perfectly well-formed, even though WillHalt fails to give the
right answer, and me with my mouth taped up fails to give the

--
Daryl McCullough
Ithaca, NY

 0
10/21/2006 12:14:59 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehbn8a02euo@drn.newsguy.com...
> Peter Olcott says...
>
>>Right there is the error. This reasoning has not shown that the HP is
>>undecidable. There is a subtle but crucial distinction between deciding the
>>correct answer to a question, and providing a correct answer to a question.
>
> No, as far as computer programs are concerned, there is no difference.
> To say that a computer program can decide a question *means* that it
>
> --
> Daryl McCullough
> Ithaca, NY
>

int Greater(int X, int Y) {
if (X > Y)
return 1;  // decided and provided
return 0;   // decided and provided
}

void Greater(int X, int Y) {
if (X > Y)
;  // decided, yet not provided
}

 0
NoSpam266 (508)
10/21/2006 12:16:46 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehbnp802ggv@drn.newsguy.com...
> Peter Olcott says...
>
>>> Would you be so kind and show us how WillHalt accomplishes this, in a more
>>> precise form than a verbal comment? It all comes down to you definition of
>>> MalignantSelfReference, which I believe is itself undecidable.
>>
>>I have already said this quite a few times in the ANALYTICAL COMMENTARY.
>
> Actually, it doesn't matter. If WillHalt raises an exception, instead
> of answering "true" or "false", then it doesn't solve the halting problem
> in this instance.

It does not solve the HP, it merely shows the HP itself to be ill-formed.

>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/21/2006 12:18:50 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehbnrq02gnk@drn.newsguy.com...
> Peter Olcott says...
>
>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote:
>
>>>>So you agree that my example shows that within the specific context of this
>>>>example I have shown that this specific form of a Halting Problem is merely
>>>>the ill-formed question of: "Does LoopIfHalts(LoopIfHalts) halt?"
>>>
>>> That's not an ill-formed question. It is a perfectly good question, and it
>>> has a perfectly good answer: Yes, it halts (by throwing an exception).
>>
>>Yes you can see that the program halts, AND WillHalt() can also SEE that the
>>program halts.
>
> Then why did you call it an ill-formed question? You are contradicting
> yourself.

It is analogous to insisting on a verbal answer from a mute person. It is not
that the mute has not correctly determining the answer.

>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/21/2006 12:21:08 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehboq302j8a@drn.newsguy.com...
> Peter Olcott says...
>
>>If someone corrupted your output mechanism by tying you up and taping
>
> If my mouth were taped shut, I wouldn't provide a correct answer.
> But that doesn't make the question ill-formed. The question is
> perfectly well-formed, even though WillHalt fails to give the
> right answer, and me with my mouth taped up fails to give the
>
> --
> Daryl McCullough
> Ithaca, NY
>
Does tying you up, and taping your mouth shut make the problem undecidable for
you, or do you still know that the program will halt, even though you can't tell
anyone?

 0
NoSpam266 (508)
10/21/2006 12:38:31 AM
On Fri, 20 Oct 2006 17:55:28 -0500, Peter Olcott <NoSpam@SeeScreen.com>
said:
>
> "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
> news:slrnejhtaf.297d.cmenzel@philebus.tamu.edu...
>> On Fri, 20 Oct 2006 08:27:32 -0500, Peter Olcott
>> <NoSpam@SeeScreen.com> said:
>>>
>>> <sillybanter@gmail.com> wrote in message
>>> news:nGYZg.3795$4T6.1868@trnddc02... >>>>> Iff (if and only if) I can reach a consensus on this >>>>> point, I will proceed to a UTM version of the same problem, and >>>>> attempt to show the mathematical mapping from the prior example to >>>>> the UTM example. I will not do this unless or until I have reached a >>>>> consensus on my prior point. >>>> >>>> You will not get consensus on this point, because you're wrong, and >>>> pretty much everyone here except you sees that quite clearly. >>> >>> Or, pretty much everyone here does not 100% completely grasp every >>> subtle nuance of the complete meaning of my statements. >> >> Or not. :-) What are the odds, dude? >> > I think that the odds that the fundamental concept of truth is broken are far > less than the odds of many people being confused for many decades. Yes, yes indeed, far more likely that Turing, Church, and the thousands of logicians, mathematicians, and theoretical computer scientists following in their wake have been, and remain, confused, than that you, Peter Olcott, should be confused. I don't know *why* I didn't see that.  0 cmenzel (185) 10/21/2006 1:16:12 AM "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message news:slrnejit6s.297d.cmenzel@philebus.tamu.edu... > On Fri, 20 Oct 2006 17:55:28 -0500, Peter Olcott <NoSpam@SeeScreen.com> > said: >> >> "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message >> news:slrnejhtaf.297d.cmenzel@philebus.tamu.edu... >>> On Fri, 20 Oct 2006 08:27:32 -0500, Peter Olcott >>> <NoSpam@SeeScreen.com> said: >>>> >>>> <sillybanter@gmail.com> wrote in message >>>> news:nGYZg.3795$4T6.1868@trnddc02...
>>>>>> Iff (if and only if) I can reach a consensus on this
>>>>>> point, I will proceed to a UTM version of the same problem, and
>>>>>> attempt to show the mathematical mapping from the prior example to
>>>>>> the UTM example. I will not do this unless or until I have reached a
>>>>>> consensus on my prior point.
>>>>>
>>>>> You will not get consensus on this point, because you're wrong, and
>>>>> pretty much everyone here except you sees that quite clearly.
>>>>
>>>> Or, pretty much everyone here does not 100% completely grasp every
>>>> subtle nuance of the complete meaning of my statements.
>>>
>>> Or not. :-)  What are the odds, dude?
>>>
>> I think that the odds that the fundamental concept of truth is broken are far
>> less than the odds of many people being confused for many decades.
>
> Yes, yes indeed, far more likely that Turing, Church, and the thousands
> of logicians, mathematicians, and theoretical computer scientists
> following in their wake have been, and remain, confused, than that you,
> Peter Olcott, should be confused.  I don't know *why* I didn't see that.
>
That sure does seem implausible doesn't it? I have found by careful analytical
reasoning the plausibility is possibly erroneous in at least some cases.

 0
NoSpam266 (508)
10/21/2006 1:41:21 AM
"Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
news:slrnejit6s.297d.cmenzel@philebus.tamu.edu...
> On Fri, 20 Oct 2006 17:55:28 -0500, Peter Olcott <NoSpam@SeeScreen.com>
> said:
>>
>> "Chris Menzel" <cmenzel@remove-this.tamu.edu> wrote in message
>> news:slrnejhtaf.297d.cmenzel@philebus.tamu.edu...
>>> On Fri, 20 Oct 2006 08:27:32 -0500, Peter Olcott
>>> <NoSpam@SeeScreen.com> said:
>>>>
>>>> <sillybanter@gmail.com> wrote in message
>>>> news:nGYZg.3795$4T6.1868@trnddc02... >>>>>> Iff (if and only if) I can reach a consensus on this >>>>>> point, I will proceed to a UTM version of the same problem, and >>>>>> attempt to show the mathematical mapping from the prior example to >>>>>> the UTM example. I will not do this unless or until I have reached a >>>>>> consensus on my prior point. >>>>> >>>>> You will not get consensus on this point, because you're wrong, and >>>>> pretty much everyone here except you sees that quite clearly. >>>> >>>> Or, pretty much everyone here does not 100% completely grasp every >>>> subtle nuance of the complete meaning of my statements. >>> >>> Or not. :-) What are the odds, dude? >>> >> I think that the odds that the fundamental concept of truth is broken are far >> less than the odds of many people being confused for many decades. > > Yes, yes indeed, far more likely that Turing, Church, and the thousands > of logicians, mathematicians, and theoretical computer scientists > following in their wake have been, and remain, confused, than that you, > Peter Olcott, should be confused. I don't know *why* I didn't see that. > Here is a reasonably possible scenario, and the one that I am proposing. It is not that all these people got the math wrong, they did not get the math wrong. It is the natural language conclusions that they derived from the mathematical conclusions that are incorrect. Specifically calling the HP undecidable, is the error. It might be undecidable in some artificially contrived sense that has nothing to do with whether or not a decision can be made, but, then this would be the error.  0 NoSpam266 (508) 10/21/2006 1:52:13 AM In sci.logic, Peter Olcott <NoSpam@SeeScreen.com> wrote on Fri, 20 Oct 2006 08:27:32 -0500 <994_g.31403$eZ4.17153@dukeread06>:
>
> <sillybanter@gmail.com> wrote in message news:nGYZg.3795$4T6.1868@trnddc02... >> In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote: >>> >>> <sillybanter@gmail.com> wrote in message news:SrLZg.5348$NK5.2906@trnddc08...
>>> > In comp.theory Peter Olcott <NoSpam@seescreen.com> wrote:
>>> >
>>> >> That seems to be a very precise English language statement that is
>>> >> most typically used to describe the results of the HP. It is this
>>> >> statement that I refute. I may be wrong, I have been wrong before,
>>> >> but, it is still this specific statement that I refute. The HP can
>>> >> be decided, yet the answer can not be restricted to YES or NO
>>> >> because the question is not a YES or NO question.
>>> >
>>> > There are certainly problems that are ill-formed, but the halting
>>> > problem is not one of those.  Deal with the real form of the halting
>>
>>> I think that I have shown in my prior response to you at least one
>>> example of a halting problem, that is only a problem because it is
>>> ill formed.
>>
>> No, you certainly haven't.  The halting problem is not ill-formed, and
>> has a well-defined answer for each and every input.  Including the one
>> that you think, for some reason, doesn't have a yes or no answer.
>>
>>> Iff (if and only if) I can reach a consensus on this
>>> point, I will proceed to a UTM version of the same problem, and
>>> attempt to show the mathematical mapping from the prior example to
>>> the UTM example. I will not do this unless or until I have reached a
>>> consensus on my prior point.
>>
>> You will not get consensus on this point, because you're wrong, and
>> pretty much everyone here except you sees that quite clearly.
>>
>> --
>>
>> Steve Stringer
>> sillybanter@gmail.com
>>
>
> Or, pretty much everyone here does not 100% completely grasp every subtle nuance
> of the complete meaning of my statements.
>

Probably not.  However, did you have an implementation
(Turing Machine, infinite-register pseudoassembly,
pseudocode, Java, SQL queries, etc.) that will in fact
solve the Halting Problem, complete with detection of the
MalignantSelfReferenceException?

An URL will do. :-)

--
Useless C++ Programming Idea #889123:
std::vector<...> v; for(int i = 0; i < v.size(); i++) v.erase(v.begin() + i);

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

 0
ewill5 (11075)
10/21/2006 2:26:59 AM
Peter Olcott says...

>Does tying you up, and taping your mouth shut make the problem
>undecidable for you, or do you still know that the program will
>halt, even though you can't tell anyone?

You are getting yourself tied up with your analogies. WillHalt is not
being "tied up" by anyone. It is perfectly free to answer the question:
Does LoopIfHalts(LoopIfHalts) halt, or not?

What's really going on has nothing whatsoever to do with being
"tied up" or having your output corrupted, or whatever. Those
analogies are completely bogus. What's really going on is this:

WillHalt is being asked to predict the behavior of another program,
LoopIfHalts. But what is LoopIfHalt doing? It's trying to predict
the behavior of WillHalt, so that it can do the opposite. Nobody
is tying anybody up, or taping anybody's mouth shut. It's all a
computational game.

A human analogy might be this: You and I are playing a game.
We each are trying to accomplish different things in this
game. What you are trying to do is to answer the question:
Will Daryl ever accomplsh what he is trying to do? You are
supposed to answer "yes" or "no".

What I'm being asked to do is to predict what Peter is
going to say, and then I'm supposed to say the opposite.
If I can figure out that you are going to say "yes", than
I'm supposed to say "no", and vice-versa.

After being given our instructions, we each are taken to
our respective isolation booths, to figure out our answers.
There is *no* interaction between us. I'm not allowed to
watch what you are doing, and you aren't allowed to watch
the other person in order to make our predictions.

knowledge about what I've been asked to do. We can assume, also
that you have complete knowledge about how my brain works. Similarly,
I have complete knowledge about what you've been asked to do, and
in any way "taping your mouth shut" or fooling with your outputs.
You aren't in the room with me, and I have no way to affect your
decision making in the slightest.

What is ill-defined about what we are asked to do? It's perfectly
well-defined. It's just very, very hard. As Yogi Berra said, prediction
is really hard, especially about the future.

If instead of human beings, we play the game with deterministic
computer programs, then the Daryl role becomes much easier, because
one program can perfectly simulate another program. The Daryl program
just has to start simulating the behavior of the Peter program. If
the simulation ever halts, then the Daryl program can check what

On the other hand, the Peter program has a much harder job. If
the answer to the question "Will the Daryl program ever produce
the correct answer?" is "no", then it would take forever to find
that out by simulation. For the Peter program to correctly answer
"no", it has to take a "shortcut" that's quicker than simulation.

That's the real moral of the proof of the unsolvability of the
halting problem: to predict what another program is going to do,
there are no foolproof shortcuts. Simulation is the best you
can do.

--
Daryl McCullough
Ithaca, NY

 0
10/21/2006 2:52:08 AM
Peter Olcott says...

>Here is a reasonably possible scenario, and the one that I am proposing. It is
>not that all these people got the math wrong, they did not get the math wrong.
>It is the natural language conclusions that they derived from the mathematical
>conclusions that are incorrect.

Yes, they could all be wrong, but they're not. The natural language
conclusion is exactly right: The halting problem is undecidable in
exactly the natural language sense that there is no computer program
that can correctly answer all instances of the question "Will program P
halt on input X?"

Here's an intuitive way to see why the undecidability of the halting
problem makes sense.

Suppose *you* are asked to answer the question: "Does program P halt
on input X?". How would you do it? Well, the obvious way to do it
would be to start simulating program P on input X. If your simulation
ever halts, then the answer is clearly "yes". But how would you ever
know that the answer is "no"? You can't find that out by simulation,
because the answer "no" means that such a simulation must go on forever.
To answer "no", you somehow have to find a "shortcut" that allows you
to see the effect of an infinite amount of computation in a finite
amount of time.

Sometimes there is such a shortcut; sometimes you can see that P
is getting itself into an infinite loop. But why would you think
that you can *always* find such a shortcut? If there is a shortcut
that allows you to figure out the effect of an infinite computation
in a finite amount of time, what's to prevent P from using that
shortcut?

The moral of the unsolvability of the halting problem is that
in some cases, the *only* way to figure out what a program is
going to do is to simulate it. There are no foolproof shortcuts.

>Specifically calling the HP undecidable, is the error. It might
>be undecidable in some artificially contrived sense that has
>nothing to do with whether or not a decision can be made, but,
>then this would be the error.

I think you have things exactly backwards. Your attempts to
solve the halting problem are artificially contrived, and have
nothing to do with whether or not a decision can be made.
In a very practical, real-world sense, the haling problem is
undecidable. This has implications for all sorts of things.
It means that there is no such thing as perfect data
compression. It means that there is no way to look at
a set of mathematical axioms and tell if they are consistent
or not. It means that there is no foolproof way to check the
correctness of computer programs (there will always be programs
that are correct, but there is no way to prove them correct
except by running them). It means that there is no perfect
optimizing compiler. It means that there is no way to decide
whether an arbitrary multinomial equation has integer solutions.
It means that there is no way to look at two arbitrary
context-free grammars and decide whether they produce the
same language. The undecidability of the halting problem
has profound consequences in almost all branches of mathematics
reference" as no relevance to solving any of these problems.

--
Daryl McCullough
Ithaca, NY

 0
10/21/2006 3:21:18 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehc20o06q3@drn.newsguy.com...
> Peter Olcott says...
>
>>Does tying you up, and taping your mouth shut make the problem
>>undecidable for you, or do you still know that the program will
>>halt, even though you can't tell anyone?
>
> You are getting yourself tied up with your analogies. WillHalt is not
> being "tied up" by anyone. It is perfectly free to answer the question:
> Does LoopIfHalts(LoopIfHalts) halt, or not?
>
> What's really going on has nothing whatsoever to do with being
> "tied up" or having your output corrupted, or whatever. Those
> analogies are completely bogus. What's really going on is this:
>
> WillHalt is being asked to predict the behavior of another program,
> LoopIfHalts. But what is LoopIfHalt doing? It's trying to predict
> the behavior of WillHalt, so that it can do the opposite. Nobody

No you are wrong, this is not what the specification of the problem entails.
LoopIfHalts() is never making any predictions what-so-ever. The reason that you
are not seeing what I am saying is that you continue to make these tiny little
errors, that make your whole conclusion come out wrong.

> is tying anybody up, or taping anybody's mouth shut. It's all a
> computational game.
>
> A human analogy might be this: You and I are playing a game.
> We each are trying to accomplish different things in this
> game. What you are trying to do is to answer the question:
> Will Daryl ever accomplsh what he is trying to do? You are
> supposed to answer "yes" or "no".
>
> What I'm being asked to do is to predict what Peter is
> going to say, and then I'm supposed to say the opposite.
> If I can figure out that you are going to say "yes", than
> I'm supposed to say "no", and vice-versa.
>
> After being given our instructions, we each are taken to
> our respective isolation booths, to figure out our answers.
> There is *no* interaction between us. I'm not allowed to
> watch what you are doing, and you aren't allowed to watch
> what I'm doing. Instead, we have to use our knowledge about
> the other person in order to make our predictions.
>
> knowledge about what I've been asked to do. We can assume, also
> that you have complete knowledge about how my brain works. Similarly,
> I have complete knowledge about what you've been asked to do, and
> I have complete knowledge about how your brain works. I'm not
> in any way "taping your mouth shut" or fooling with your outputs.
> You aren't in the room with me, and I have no way to affect your
> decision making in the slightest.
>
> What is ill-defined about what we are asked to do? It's perfectly
> well-defined. It's just very, very hard. As Yogi Berra said, prediction
> is really hard, especially about the future.
>
> If instead of human beings, we play the game with deterministic
> computer programs, then the Daryl role becomes much easier, because
> one program can perfectly simulate another program. The Daryl program
> just has to start simulating the behavior of the Peter program. If
> the simulation ever halts, then the Daryl program can check what
>
> On the other hand, the Peter program has a much harder job. If
> the answer to the question "Will the Daryl program ever produce
> the correct answer?" is "no", then it would take forever to find
> that out by simulation. For the Peter program to correctly answer
> "no", it has to take a "shortcut" that's quicker than simulation.
>
> That's the real moral of the proof of the unsolvability of the
> halting problem: to predict what another program is going to do,
> there are no foolproof shortcuts. Simulation is the best you
> can do.
>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/21/2006 3:21:55 AM
Peter Olcott says...

>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote

>> WillHalt is being asked to predict the behavior of another program,
>> LoopIfHalts. But what is LoopIfHalt doing? It's trying to predict
>> the behavior of WillHalt, so that it can do the opposite. Nobody
>
>No you are wrong, this is not what the specification of the problem
>entails.

I'm talking about the normal statement and proof of the unsolvability
of the halting problem. In that proof, we assume that there is a program
Halt(p,x) which is purported to have the following behavior:

If p is the code of a program which halts on input x, then
Halt(p,x) outputs true. Otherwise, Halt(p,x) outputs false.

So clearly Halt is being asked to predict the behavior of program p.

The way that LoopIfHalts is defined is as follows:

LoopIfHalts(x) checks if Halt(x,x) returns false. If
Halt(x,x) returns true, then LoopIfHalts goes into
an infinite loop.

So clearly, LoopIfHalts is dependent on the behavior of Halt,
and vice-versa.

>LoopIfHalts() is never making any predictions what-so-ever.

That's not true. It *first* must figure out whether WillHalt
returns true or false. You defined LoopIfHalts in terms of
WillHalt.

--
Daryl McCullough
Ithaca, NY

 0
10/21/2006 3:58:21 AM
Peter Olcott says...

>No you are wrong, this is not what the specification of the
>problem entails. LoopIfHalts() is never making any predictions
>what-so-ever. The reason that you are not seeing what I am
>saying is that you continue to make these tiny little
>errors, that make your whole conclusion come out wrong.

No, I have no trouble seeing what you are saying, but I
see that it is nonsense. You really don't know what you

The original proof of the unsolvability of the halting
problem was about Turing machines. It's not really important
that it be about Turing machines, but the clearest statement
uses programs that are *functional*. That means that the output
is a deterministic function of the inputs. No matter how the
function is called, it *always* returns the same outputs given
the same inputs.

Such a functional program is not allowed to throw exceptions,
and it is not allowed to have its output depend on the context
in which it is called.

It is clear that your trick cannot possibly work for such
programs. There can be no deterministic program Halt(p,x) such
that

If p is the source code for a program that halts on input x,
then Halt(p,x) returns true. Otherwise, Halt(p,x) returns false.

You agree with that right? The usual proof shows clearly that there
is no functional program Halt(p,x) that solves the halting problem?
Right?

Now, what you are proposing is a *non-functional* program.
It does *not* return the same output given the same inputs.
The output that it produces depends on the context in which
it is called. So the usual proof doesn't apply to your type
of program.

HOWEVER, it is clearly true that with ordinary programming languages,
anything that can be deterministically computed using non-functional
programs can also be computed using functional programs. The basic
idea is just to make all the dependencies of the non-functional
program explicit as arguments. So if there is no solution to the
halting problem using functional programs, then there is no solution,
period. Your excursion into nonfunctional programs makes *no* difference.
It makes the analysis more complicated, but it doesn't change the result.

--
Daryl McCullough
Ithaca, NY

 0
10/21/2006 4:50:58 AM
Peter Olcott wrote:
> In order to make it possible for me to make my point, I must insist that the
> conversation never digresses to tangents until the prerequisite point is made. I
> have already shown, and it is completely obvious that there is no possible
> correct YES or NO answer that WillHalt() can possibly provide.

Sure. I agree.

Let's dance.

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
 0
10/21/2006 5:31:20 AM
Peter Olcott schrieb:

> > But then your MalignantSelfReference()  is useless, since it would not
>
> No its not is proves the one prerequisite point so that we can then proceed to
> the next step. Once my point is proven within the specific context is this
> single isolated example, thenn (then and only then) we can proceed to generalize
> this point. There is no sense in generalizing any point that is not yet made.
Sorry, I am confused. What is your prerequisite point? I thought you
want to give a solution to the halting problem. The Halting Problem is
defined to give an answer for all programs, not just to recognize one
function and say YES or NO for this function.
Nevertheless, I am still waiting for your complete code with
MalignantSelfReference. Giving just a verbal story describing the
function is not enough. I am quite sure that such a funciton cannot
exist, and many people have given examples for funciton where your
magical MalignantSelfReference fails, which you ignored.

PS: If it help, make the assumption your point is taken (I don't
comply, but it doesn't matter) and generalize MalignantSelfReference

 0
10/21/2006 8:44:36 AM
Peter Olcott schrieb:
> int Greater(int X, int Y) {
>   if (X > Y)
>     return 1;  // decided and provided
> return 0;   // decided and provided
> }
>
> void Greater(int X, int Y) {
>   if (X > Y)
>     ;  // decided, yet not provided
> }

look up the basics. A decision function for a set, in this case the set
Greater = {(x,y) | x > y} is a boolean function return true for all
sets (x,y) \in Greater and false for all sets \not \in greater. Your
second function is nothing. In fact, the decision function is the
function ">", defined somehwhere else.

 0
10/21/2006 8:55:27 AM
Patricia Shanahan <pats@acm.org> writes:

> If you take the existence of a decision algorithm for the Halting
> problem as an axiom, while retaining the normal axioms that ultimately
> underly theory of computation, you end up with an inconsistent system of
> axioms. Even then, it is the set of axioms that is broken, not the
> fundamental concept of truth.

I think this illustrates why reasoned argument is futile in
this thread. The OP /does/ take the existence of a decision
algorthm for the halting problem as an axiom. Consequently,
working from his axioms he can reach any conclusion he
wishes.

--
Jón Fairbairn                                 Jon.Fairbairn@cl.cam.ac.uk
 0
10/21/2006 10:51:38 AM
"Peter Olcott" <NoSpam@SeeScreen.com> writes:

> Specifically calling the HP undecidable, is the error.

It least that terminology is a bit unfortunate, since HP is
semi-decidable. An error would be to infer from its not being
"totally" undecidable (like totality problem for TMs) that it's
decidable.

Best wishes!
Markus Triska
 0
triska (32)
10/21/2006 11:16:10 AM
Peter Olcott schrieb:

> > But what do you do if I feed in the source code of LoopIfHalts, where I
> > replaced the call to WillHalt with another function (as a source code
> > entity, not a mathematical function) which has the same behaviour (in
> > computational terms, both program compute the same function)? Can your
> > magic function MalignantSelfReference() detect this?
>
> It makes no sense at all to attempt to generalize any point that is not yet
> made. I must restrict all of my responses to the single isolated example that I
> have provided, because of the inherent prerequisite order of my points. Only
> after this example is fully analyzed would it make any sense to proceed beyond
> this example. If I can't prove my point within the context of this single
> isolated example, then every other point becomes completely moot.
It makes no sense discussing about a solution to a mathematically
formulated problem without having the proposed solution completely
available. If you want to solve the halting problem, formulate a
function which correctly decides if any program terminates on all
inputs. This must work with all programs, not just one example!
Anyway, as others remarked, the prove that you cannot implement halt is
not dependant on a specific halt-function but just assumes that there

 0
10/21/2006 11:34:28 AM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehc8vi0mee@drn.newsguy.com...
> Peter Olcott says...
>
>>No you are wrong, this is not what the specification of the
>>problem entails. LoopIfHalts() is never making any predictions
>>what-so-ever. The reason that you are not seeing what I am
>>saying is that you continue to make these tiny little
>>errors, that make your whole conclusion come out wrong.
>
> No, I have no trouble seeing what you are saying, but I
> see that it is nonsense. You really don't know what you

See that you just did it again. You don't even try to understand what I am
saying, you merely glance at a few words before forming your refutation. If you
really attempted to understand what I was saying you would not make such a
foolish mistake as saying that LoopIfHalts() predicts anything. I won't bother
to read any of the rest of what you said until you address this single point. We
must proceed exactly one micro point at a time, and refrain from diverging into
tangents.

>
> The original proof of the unsolvability of the halting
> problem was about Turing machines. It's not really important
> that it be about Turing machines, but the clearest statement
> uses programs that are *functional*. That means that the output
> is a deterministic function of the inputs. No matter how the
> function is called, it *always* returns the same outputs given
> the same inputs.
>
> Such a functional program is not allowed to throw exceptions,
> and it is not allowed to have its output depend on the context
> in which it is called.
>
> It is clear that your trick cannot possibly work for such
> programs. There can be no deterministic program Halt(p,x) such
> that
>
>  If p is the source code for a program that halts on input x,
>  then Halt(p,x) returns true. Otherwise, Halt(p,x) returns false.
>
> You agree with that right? The usual proof shows clearly that there
> is no functional program Halt(p,x) that solves the halting problem?
> Right?
>
> Now, what you are proposing is a *non-functional* program.
> It does *not* return the same output given the same inputs.
> The output that it produces depends on the context in which
> it is called. So the usual proof doesn't apply to your type
> of program.
>
> HOWEVER, it is clearly true that with ordinary programming languages,
> anything that can be deterministically computed using non-functional
> programs can also be computed using functional programs. The basic
> idea is just to make all the dependencies of the non-functional
> program explicit as arguments. So if there is no solution to the
> halting problem using functional programs, then there is no solution,
> period. Your excursion into nonfunctional programs makes *no* difference.
> It makes the analysis more complicated, but it doesn't change the result.
>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/21/2006 1:26:52 PM
"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote in message
news:ehc5st0fmv@drn.newsguy.com...
> Peter Olcott says...
>
>>"Daryl McCullough" <stevendaryl3016@yahoo.com> wrote
>
>>> WillHalt is being asked to predict the behavior of another program,
>>> LoopIfHalts. But what is LoopIfHalt doing? It's trying to predict
>>> the behavior of WillHalt, so that it can do the opposite. Nobody
>>
>>No you are wrong, this is not what the specification of the problem
>>entails.
>
> I'm talking about the normal statement and proof of the unsolvability
> of the halting problem.

That is off-topic, we can not correctly proceed to that topic until this topic
has been fully addressed. There is a required prerequisite order.

> In that proof, we assume that there is a program
> Halt(p,x) which is purported to have the following behavior:
>
>    If p is the code of a program which halts on input x, then
>    Halt(p,x) outputs true. Otherwise, Halt(p,x) outputs false.
>
> So clearly Halt is being asked to predict the behavior of program p.
>
> The way that LoopIfHalts is defined is as follows:
>
>    LoopIfHalts(x) checks if Halt(x,x) returns false. If
>    Halt(x,x) returns true, then LoopIfHalts goes into
>    an infinite loop.
>
> So clearly, LoopIfHalts is dependent on the behavior of Halt,
> and vice-versa.

Which is not at all the same thing as saying that LoopIfHalts() itself is
predictive. The only possible way for you to begin to understand what I am
saying is if we both begin to use English as if it was itself a mathematical
formalism. If we don't do this, then the truth will slip right past the
otherwise imprecision of natural language.

>
>>LoopIfHalts() is never making any predictions what-so-ever.
>
> That's not true. It *first* must figure out whether WillHalt
> returns true or false. You defined LoopIfHalts in terms of
> WillHalt.

The behavior of LoopIfHalts() is tied to the historical behavior of WillHalt()
after the fact of the execution of WillHalt(), thus not predictive at all.
Predictiveness is not transitive.

>
> --
> Daryl McCullough
> Ithaca, NY
>

 0
NoSpam266 (508)
10/21/2006 1:33:19 PM
"Aatu Koskensilta" <aatu.koskensilta@xortec.fi> wrote in message
news:Egi_g.10440SA.1402@reader1.news.jippii.net... > Peter Olcott wrote: >> In order to make it possible for me to make my point, I must insist that the >> conversation never digresses to tangents until the prerequisite point is >> made. I have already shown, and it is completely obvious that there is no >> possible correct YES or NO answer that WillHalt() can possibly provide. > > Sure. I agree. > > Let's dance. So can you see how this equally applies to the UTM versions of the HP? > > -- > Aatu Koskensilta (aatu.koskensilta@xortec.fi) > > "Wovon man nicht sprechen kann, daruber muss man schweigen" > - Ludwig Wittgenstein, Tractatus Logico-Philosophicus  0 NoSpam266 (508) 10/21/2006 1:35:39 PM "Jens Auer" <jens.muaddib@googlemail.com> wrote in message news:1161420276.228408.324100@h48g2000cwc.googlegroups.com... > > Peter Olcott schrieb: > >> > But then your MalignantSelfReference() is useless, since it would not >> >> No its not is proves the one prerequisite point so that we can then proceed >> to >> the next step. Once my point is proven within the specific context is this >> single isolated example, thenn (then and only then) we can proceed to >> generalize >> this point. There is no sense in generalizing any point that is not yet made. > Sorry, I am confused. What is your prerequisite point? I thought you > want to give a solution to the halting problem. The Halting Problem is > defined to give an answer for all programs, not just to recognize one > function and say YES or NO for this function. > Nevertheless, I am still waiting for your complete code with > MalignantSelfReference. Giving just a verbal story describing the > function is not enough. I am quite sure that such a funciton cannot > exist, If your claim is that you do not see how such a function could be written in generally, then this question would be off topic until the prerequisite point is fully made, meaning a consensus of agreement on the correct conclusion drawn from this single isolated example, otherwise: If you claim to not see that within the context of the single isolated example that I provided, it is completely obvious that the problem is specified such that LoopIfHalts() toggles the result of WillHalt() to falsify the result of WillHalt() (Malignant-Self-Reference (MSR)) you would either be dishonest or lack sufficient knowledge to effectively communicate on this topic. If you are going to require me to write a parser and knowledge base showing that a program could be written to determine the case of malignant self-reference just described, then I must ask you to first provide a map of your brain showing exactly how each neuron in said brain derives this absurd requirement. > and many people have given examples for funciton where your > magical MalignantSelfReference fails, which you ignored. > > PS: If it help, make the assumption your point is taken (I don't > comply, but it doesn't matter) and generalize MalignantSelfReference > and show us your definition. >  0 NoSpam266 (508) 10/21/2006 2:00:46 PM Peter Olcott wrote: > "Aatu Koskensilta" <aatu.koskensilta@xortec.fi> wrote in message > news:Egi_g.10440SA.1402@reader1.news.jippii.net...
>> Peter Olcott wrote:
>>> In order to make it possible for me to make my point, I must insist that the
>>> conversation never digresses to tangents until the prerequisite point is
>>> made. I have already shown, and it is completely obvious that there is no
>>> possible correct YES or NO answer that WillHalt() can possibly provide.
>> Sure. I agree.
>>
>> Let's dance.
>
> So can you see how this equally applies to the UTM versions of the HP?

What are "the UTM versions of HP"?

--
Aatu Koskensilta (aatu.koskensilta@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
- Ludwig Wittgenstein, Tractatus Logico-Philosophicus
 0
10/21/2006 2:05:49 PM
Peter Olcott says...

>See that you just did it again. You don't even try to understand what I am
>saying,

If you actually showed that *you* understood the mathematics
of the halting problem, then I would be more willing to pay
careful attention to what you have to say about it. But you
don't.

>you merely glance at a few words before forming your refutation.

Boy, if that's ever the pot calling the kettle black. You
are the one who is refuting a standard theorem without attempting
to understand it first.

You quit reading my post after the first line that you
disagree with, and then you accuse *me* of posting a
reply after merely glancing at a few words.

them. You are a liar and a hypocrite. You are too lazy to
actually study the subject that you claim to be providing new
insight about. You are a glory hog wanting credit without
doing the work.

--
Daryl McCullough
Ithaca, NY

 0
10/21/2006 2:07:29 PM
"J�n Fairbairn" <jon.fairbairn@cl.cam.ac.uk> wrote in message
news:wf3b9igcw5.fsf@calligramme.charmers...
> Patricia Shanahan <pats@acm.org> writes:
>
>> If you take the existence of a decision algorithm for the Halting
>> problem as an axiom, while retaining the normal axioms that ultimately
>> underly theory of computation, you end up with an inconsistent system of
>> axioms. Even then, it is the set of axioms that is broken, not the
>> fundamental concept of truth.
>
> I think this illustrates why reasoned argument is futile in
> this thread. The OP /does/ take the existence of a decision
> algorthm for the halting problem as an axiom. Consequently,
> working from his axioms he can reach any conclusion he
> wishes.
>
> --
> J�n Fairbairn                                 Jon.Fairbairn@cl.cam.ac.uk

The problem is the mathematical mapping between the conclusions based on the
mathematical formalisms and the higher level English language meanings. This
problem is caused by arbitrary constraints placed on the formalisms that do not
actually exist in the greater context. The only reason that the HP (at least the
isolated example that I provided) can not be solved, is that it is merely an
ill-formed question. The fact that ill-formed questions lack correct answers
should not be elevated to the level of a fundamental theory of computation. (if
my isolated example can be generalized).

 0
NoSpam266 (508)
10/21/2006 2:11:20 PM
"Markus Triska" <triska@gmx.at> wrote in message news:874ptxzzph.fsf@gmx.at...
> "Peter Olcott" <NoSpam@SeeScreen.com> writes:
>
>> Specifically calling the HP undecidable, is the error.
>
> It least that terminology is a bit unfortunate, since HP is
> semi-decidable. An error would be to infer from its not being
> "totally" undecidable (like totality problem for TMs) that it's
> decidable.
>
> Best wishes!
> Markus Triska

I provided one example that is very close in form to the original problem, that
is decidable. The only limitation is that the result of this decision can not be
provided as a Boolean return value to every caller. Perhaps if we do not form
the artificial contrivance of restricting the form of the result to Boolean, the
HP could actually be solved. If WillHalt() is free to provide its result in any
form what-so-ever, it could then possibly return the correct result using
whatever protocol that LoopIfHalts() is not corrupting.

 0
NoSpam266 (508)
10/21/2006 2:17:23 PM
Peter Olcott says...

The best description of you is to say that you are

>...either...dishonest or lack sufficient knowledge to
>effectively communicate on this topic.

I believe that both are true. You lack any knowledge
of the topic you are writing about, and you are dishonest.
Those are the usual earmarks of a crackpot. They lack
knowledge of the subject, they lack self-honesty
about their own understanding, and they lack the work
ethic necesary to actually understand a topic before
writing about it. That's you, Peter.

--
Daryl McCullough
Ithaca, NY

 0