On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a
formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE FUNCTIONS"
for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I do
think it's the wrong thing to focus on (H could go consult the WWW
for all I care) but it is one way to try to pin PO's nonsense down
a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat is
correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is
not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure functions.
By re-framing the problem in terms of subroutines (and PO is not
alone in this -- see Strachey's oft-cited note) extra care is
needed.
My guess is that it is trickery like this that makes people worry
about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled [and
non-standard] code invoked from within the program. So the
program is not deciding about a program and its input but just
running a particular program.
<cut>
Another approach, using C, would have been to make H take the
source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then includes a
compiler and some way of running/emulating the compiled code, so
be it. ...
But there is a "halting problem" for functions entirely analogous
to the one for whole programs. When PO shifts from Turing machines
(about which he has nothing to say anymore, having exhausted all
avenues for confusion) to C-like code, it's not actually wrong to
do that, but the notion of what a computation is and what "halting"
means need to be carefully pinned down. I think people reach for
pure functions as a simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of its
inputs I will be able to post the code for H and P. Prior to that it
would have been rejected on the basis that it depended on static
local data. This only needs very slight code clean up.
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a theoretical
point of view, but PO has ditched all notions of a formal model of
computation, [...].
Yeah, but others seem to be insisting on "PURE FUNCTIONS" for no
good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I do think
it's the wrong thing to focus on (H could go consult the WWW for all I
care) but it is one way to try to pin PO's nonsense down a bit.
This program prints 1 (on my system) and halts because H_Hat(H_Hat)
"halts" (i.e. returns to main) even though H_Hat is correctly
constructed from H.
Except that your "H" is not the decider but merely a subroutine of
your program. A correctly constructed "H_Hat" is not based just on such a >> subroutine but on the entire program which contains "H". [I know you know >> all this, but it bears occasional repetition.]
Yes, but that's exactly why some people worry about pure functions. By re-framing the problem in terms of subroutines (and PO is not alone in
this -- see Strachey's oft-cited note) extra care is needed.
My guess is that it is trickery like this that makes people worry about
functions being pure.
Sure, but it's not really to do with purity as much as with replacing >> an input tape [or near equivalent] by compiled [and non-standard] code invoked
from within the program. So the program is not deciding about a program and >> its input but just running a particular program.
<cut>
Another approach, using C, would have been to make H take the source
code of a C program as a string,
That, for me, is what the HP /is/. If "H" then includes a compiler
and some way of running/emulating the compiled code, so be it. ...
But there is a "halting problem" for functions entirely analogous to the
one for whole programs. When PO shifts from Turing machines (about
which he has nothing to say anymore, having exhausted all avenues for confusion) to C-like code, it's not actually wrong to do that, but the
notion of what a computation is and what "halting" means need to be
carefully pinned down. I think people reach for pure functions as a
simple way to deal with some of that.
rather than elide the issue of
representation by using a code pointer but PO rejected any notion of
"encoding" as being "extraneous complexity" for years and he still does
not understand the concept.
... Such a solution may be complex, but it's not "extraneous"!
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a
formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE FUNCTIONS"
for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I do
think it's the wrong thing to focus on (H could go consult the WWW
for all I care) but it is one way to try to pin PO's nonsense down
a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat is
correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is
not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure
functions. By re-framing the problem in terms of subroutines (and
PO is not alone in this -- see Strachey's oft-cited note) extra
care is needed.
My guess is that it is trickery like this that makes people
worry about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled
[and non-standard] code invoked from within the program. So the
program is not deciding about a program and its input but just
running a particular program.
<cut>
Another approach, using C, would have been to make H take the
source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then includes
a compiler and some way of running/emulating the compiled code,
so be it. ...
But there is a "halting problem" for functions entirely analogous
to the one for whole programs. When PO shifts from Turing
machines (about which he has nothing to say anymore, having
exhausted all avenues for confusion) to C-like code, it's not
actually wrong to do that, but the notion of what a computation
is and what "halting" means need to be carefully pinned down. I
think people reach for pure functions as a simple way to deal
with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of
its inputs I will be able to post the code for H and P. Prior to
that it would have been rejected on the basis that it depended on
static local data. This only needs very slight code clean up.
The only agreement (among ourselves, excluding yourself) is that
your H is not a halt decider; your H should be renamed to S as all
it is is a simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely analogous
to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people agree
that a halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior of its
inputs
Yet are totally unaware that they contradict themselves when they say
that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated
input to H(P,P) has different halting behavior than the directly
executed P(P) and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the
return value of H.
When H(P,P) is executed the correctly emulated P cannot possibly
reach the point where its behavior depends on H.
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a
formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE FUNCTIONS"
for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I do
think it's the wrong thing to focus on (H could go consult the WWW
for all I care) but it is one way to try to pin PO's nonsense down
a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat is
correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is
not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure functions.
By re-framing the problem in terms of subroutines (and PO is not
alone in this -- see Strachey's oft-cited note) extra care is
needed.
My guess is that it is trickery like this that makes people worry
about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled [and
non-standard] code invoked from within the program. So the
program is not deciding about a program and its input but just
running a particular program.
<cut>
Another approach, using C, would have been to make H take the
source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then includes a
compiler and some way of running/emulating the compiled code, so
be it. ...
But there is a "halting problem" for functions entirely analogous
to the one for whole programs. When PO shifts from Turing machines
(about which he has nothing to say anymore, having exhausted all
avenues for confusion) to C-like code, it's not actually wrong to
do that, but the notion of what a computation is and what "halting"
means need to be carefully pinned down. I think people reach for
pure functions as a simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of its
inputs I will be able to post the code for H and P. Prior to that it
would have been rejected on the basis that it depended on static
local data. This only needs very slight code clean up.
The only agreement (among ourselves, excluding yourself) is that your H
is not a halt decider; your H should be renamed to S as all it is is a simulation detector.
/Flibble
On Sun, 12 Jun 2022 16:18:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a
formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE FUNCTIONS"
for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I do
think it's the wrong thing to focus on (H could go consult the WWW
for all I care) but it is one way to try to pin PO's nonsense down
a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat is >>>>>>> correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is
not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure
functions. By re-framing the problem in terms of subroutines (and
PO is not alone in this -- see Strachey's oft-cited note) extra
care is needed.
My guess is that it is trickery like this that makes people
worry about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled
[and non-standard] code invoked from within the program. So the
program is not deciding about a program and its input but just
running a particular program.
<cut>
Another approach, using C, would have been to make H take the
source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then includes
a compiler and some way of running/emulating the compiled code,
so be it. ...
But there is a "halting problem" for functions entirely analogous
to the one for whole programs. When PO shifts from Turing
machines (about which he has nothing to say anymore, having
exhausted all avenues for confusion) to C-like code, it's not
actually wrong to do that, but the notion of what a computation
is and what "halting" means need to be carefully pinned down. I
think people reach for pure functions as a simple way to deal
with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of
its inputs I will be able to post the code for H and P. Prior to
that it would have been rejected on the basis that it depended on
static local data. This only needs very slight code clean up.
The only agreement (among ourselves, excluding yourself) is that
your H is not a halt decider; your H should be renamed to S as all
it is is a simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely analogous
to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people agree
that a halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior of its
inputs
Yet are totally unaware that they contradict themselves when they say
that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated
input to H(P,P) has different halting behavior than the directly
executed P(P) and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the
return value of H.
When H(P,P) is executed the correctly emulated P cannot possibly
reach the point where its behavior depends on H.
If P would have halted then your H would get the answer wrong, ergo H
is not a halt decider as it has total disregard for the actual
behaviour of P.
/Flibble
On 6/12/2022 4:26 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 16:18:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a >>>>>>> formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE
FUNCTIONS" for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I
do think it's the wrong thing to focus on (H could go consult
the WWW for all I care) but it is one way to try to pin PO's
nonsense down a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat
is correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is
not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure
functions. By re-framing the problem in terms of subroutines
(and PO is not alone in this -- see Strachey's oft-cited note)
extra care is needed.
My guess is that it is trickery like this that makes people
worry about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled
[and non-standard] code invoked from within the program. So
the program is not deciding about a program and its input but
just running a particular program.
<cut>
Another approach, using C, would have been to make H take the
source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then
includes a compiler and some way of running/emulating the
compiled code, so be it. ...
But there is a "halting problem" for functions entirely
analogous to the one for whole programs. When PO shifts from
Turing machines (about which he has nothing to say anymore,
having exhausted all avenues for confusion) to C-like code,
it's not actually wrong to do that, but the notion of what a
computation is and what "halting" means need to be carefully
pinned down. I think people reach for pure functions as a
simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of
its inputs I will be able to post the code for H and P. Prior to
that it would have been rejected on the basis that it depended on
static local data. This only needs very slight code clean up.
The only agreement (among ourselves, excluding yourself) is that
your H is not a halt decider; your H should be renamed to S as all
it is is a simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely
analogous to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people agree
that a halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior of its
inputs
Yet are totally unaware that they contradict themselves when they
say that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated
input to H(P,P) has different halting behavior than the directly
executed P(P) and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the
return value of H.
When H(P,P) is executed the correctly emulated P cannot possibly
reach the point where its behavior depends on H.
If P would have halted then your H would get the answer wrong, ergo
H is not a halt decider as it has total disregard for the actual
behaviour of P.
/Flibble
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and
thus not the behavior of P(P).
On Sun, 12 Jun 2022 16:38:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:26 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 16:18:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a >>>>>>>>> formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE
FUNCTIONS" for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I
do think it's the wrong thing to focus on (H could go consult
the WWW for all I care) but it is one way to try to pin PO's
nonsense down a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat >>>>>>>>> is correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is >>>>>>>> not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure
functions. By re-framing the problem in terms of subroutines
(and PO is not alone in this -- see Strachey's oft-cited note)
extra care is needed.
My guess is that it is trickery like this that makes people
worry about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled
[and non-standard] code invoked from within the program. So
the program is not deciding about a program and its input but
just running a particular program.
<cut>
Another approach, using C, would have been to make H take the >>>>>>>>> source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then
includes a compiler and some way of running/emulating the
compiled code, so be it. ...
But there is a "halting problem" for functions entirely
analogous to the one for whole programs. When PO shifts from
Turing machines (about which he has nothing to say anymore,
having exhausted all avenues for confusion) to C-like code,
it's not actually wrong to do that, but the notion of what a
computation is and what "halting" means need to be carefully
pinned down. I think people reach for pure functions as a
simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of
its inputs I will be able to post the code for H and P. Prior to
that it would have been rejected on the basis that it depended on
static local data. This only needs very slight code clean up.
The only agreement (among ourselves, excluding yourself) is that
your H is not a halt decider; your H should be renamed to S as all
it is is a simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely
analogous to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people agree
that a halt decider must compute the mapping from its inputs to an
accept or reject state on the basis of the actual behavior of its
inputs
Yet are totally unaware that they contradict themselves when they
say that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated
input to H(P,P) has different halting behavior than the directly
executed P(P) and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the
return value of H.
When H(P,P) is executed the correctly emulated P cannot possibly
reach the point where its behavior depends on H.
If P would have halted then your H would get the answer wrong, ergo
H is not a halt decider as it has total disregard for the actual
behaviour of P.
/Flibble
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and
thus not the behavior of P(P).
Correct analysis of its input, P, necessitates correct analysis of
the behaviour of P;
ignoring what P does means you are not deciding
anything regarding P including whether or not it halts.
/Flibble
On 6/12/2022 4:43 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 16:38:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:26 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 16:18:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions
of a formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE
FUNCTIONS" for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter.
I do think it's the wrong thing to focus on (H could go
consult the WWW for all I care) but it is one way to try to
pin PO's nonsense down a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though
H_Hat is correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" >>>>>>>> is not based just on such a subroutine but on the entire
program which contains "H". [I know you know all this, but
it bears occasional repetition.]
Yes, but that's exactly why some people worry about pure
functions. By re-framing the problem in terms of subroutines
(and PO is not alone in this -- see Strachey's oft-cited note) >>>>>>> extra care is needed.
My guess is that it is trickery like this that makes people >>>>>>>>> worry about functions being pure.
Sure, but it's not really to do with purity as much
as with replacing an input tape [or near equivalent] by
compiled [and non-standard] code invoked from within the
program. So the program is not deciding about a program and >>>>>>>> its input but just running a particular program.
<cut>
Another approach, using C, would have been to make H take
the source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then
includes a compiler and some way of running/emulating the
compiled code, so be it. ...
But there is a "halting problem" for functions entirely
analogous to the one for whole programs. When PO shifts from
Turing machines (about which he has nothing to say anymore,
having exhausted all avenues for confusion) to C-like code,
it's not actually wrong to do that, but the notion of what a
computation is and what "halting" means need to be carefully
pinned down. I think people reach for pure functions as a
simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function
of its inputs I will be able to post the code for H and P.
Prior to that it would have been rejected on the basis that it
depended on static local data. This only needs very slight
code clean up.
The only agreement (among ourselves, excluding yourself) is that
your H is not a halt decider; your H should be renamed to S as
all it is is a simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely
analogous to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people
agree that a halt decider must compute the mapping from its
inputs to an accept or reject state on the basis of the actual
behavior of its inputs
Yet are totally unaware that they contradict themselves when they
say that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated
input to H(P,P) has different halting behavior than the directly
executed P(P) and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the
return value of H.
When H(P,P) is executed the correctly emulated P cannot possibly
reach the point where its behavior depends on H.
If P would have halted then your H would get the answer wrong,
ergo H is not a halt decider as it has total disregard for the
actual behaviour of P.
/Flibble
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and
thus not the behavior of P(P).
Correct analysis of its input, P, necessitates correct analysis of
the behaviour of P;
Because P was intentionally defined to have a pathological
relationship to H the behavior of the correctly emulated input to
H(P,P) has different behavior than the directly executed P(P).
In every other case where no such pathological relationship was
intentionally defined the correctly emulated input to H(X,Y) will
have the exact same behavior as the directly executed X(Y).
Prior to my key insight of applying simulating halt decider to
pathological inputs no one knew that the correctly emulated input to
H(P,P) could have different behavior that the directly executed P(P)
so the textbook accounts of the HP simply referred to the behavior of
P(P).
On Sun, 12 Jun 2022 17:03:31 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:43 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 16:38:43 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:26 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 16:18:03 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions >>>>>>>>>>> of a formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE
FUNCTIONS" for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. >>>>>>>>> I do think it's the wrong thing to focus on (H could go
consult the WWW for all I care) but it is one way to try to
pin PO's nonsense down a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though
H_Hat is correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" >>>>>>>>>> is not based just on such a subroutine but on the entire
program which contains "H". [I know you know all this, but >>>>>>>>>> it bears occasional repetition.]
Yes, but that's exactly why some people worry about pure
functions. By re-framing the problem in terms of subroutines >>>>>>>>> (and PO is not alone in this -- see Strachey's oft-cited note) >>>>>>>>> extra care is needed.
My guess is that it is trickery like this that makes people >>>>>>>>>>> worry about functions being pure.
Sure, but it's not really to do with purity as much
as with replacing an input tape [or near equivalent] by
compiled [and non-standard] code invoked from within the
program. So the program is not deciding about a program and >>>>>>>>>> its input but just running a particular program.
<cut>
Another approach, using C, would have been to make H take >>>>>>>>>>> the source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then
includes a compiler and some way of running/emulating the
compiled code, so be it. ...
But there is a "halting problem" for functions entirely
analogous to the one for whole programs. When PO shifts from >>>>>>>>> Turing machines (about which he has nothing to say anymore,
having exhausted all avenues for confusion) to C-like code,
it's not actually wrong to do that, but the notion of what a >>>>>>>>> computation is and what "halting" means need to be carefully >>>>>>>>> pinned down. I think people reach for pure functions as a
simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function
of its inputs I will be able to post the code for H and P.
Prior to that it would have been rejected on the basis that it >>>>>>>> depended on static local data. This only needs very slight
code clean up.
The only agreement (among ourselves, excluding yourself) is that >>>>>>> your H is not a halt decider; your H should be renamed to S as
all it is is a simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely
analogous to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people
agree that a halt decider must compute the mapping from its
inputs to an accept or reject state on the basis of the actual
behavior of its inputs
Yet are totally unaware that they contradict themselves when they
say that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated
input to H(P,P) has different halting behavior than the directly
executed P(P) and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the
return value of H.
When H(P,P) is executed the correctly emulated P cannot possibly
reach the point where its behavior depends on H.
If P would have halted then your H would get the answer wrong,
ergo H is not a halt decider as it has total disregard for the
actual behaviour of P.
/Flibble
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and
thus not the behavior of P(P).
Correct analysis of its input, P, necessitates correct analysis of
the behaviour of P;
Because P was intentionally defined to have a pathological
relationship to H the behavior of the correctly emulated input to
H(P,P) has different behavior than the directly executed P(P).
In every other case where no such pathological relationship was
intentionally defined the correctly emulated input to H(X,Y) will
have the exact same behavior as the directly executed X(Y).
Prior to my key insight of applying simulating halt decider to
pathological inputs no one knew that the correctly emulated input to
H(P,P) could have different behavior that the directly executed P(P)
so the textbook accounts of the HP simply referred to the behavior of
P(P).
Except you don't handle the case of a non-pathological program, N, which calls H but then halts.
Also your "simulating halt decider" will never return an answer for a
program that doesn't halt but is non-pathological. This is a problem
with simulation in general rather than with your mess specifically.
/Flibble
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and thus
not the behavior of P(P).
H2(sum,3,4) will report on the behavior of sum(3,4) because sum was not intentionally defined to have a pathological relationship with H2.
H(P,P) will not report on the behavior of P(P) because P was
intentionally defined to have a pathological relationship to H.
H must compute the mapping from, its actual inputs to an accept or
reject state on the basis of the actual behavior actually specified by
its inputs.
On 6/12/22 5:38 PM, olcott wrote:
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and thus
not the behavior of P(P).
Which, by the DEFINITION of a Halt Decider, the behavior of the input to H(P,P) is the behavior of P(P), or H or P haven't been defined right.
*THE FOLLOWING CRITERIA ALWAYS WORKS*
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual input as measured by the correct x86 emulation or UTM simulation of this input by H.
On 6/12/2022 6:16 PM, Richard Damon wrote:
This "definition" was based on a false assumption that the behavior of
On 6/12/22 5:38 PM, olcott wrote:
int sum(int x, int y)
{
return x + y;
}
sum(3,4) must return 7 and not the sum of 7 + 9;
H(P,P) must report on the actual behavior of its actual input and
thus not the behavior of P(P).
Which, by the DEFINITION of a Halt Decider, the behavior of the input
to H(P,P) is the behavior of P(P), or H or P haven't been defined right.
the correctly emulated input to H(P,P) must be the same as the behavior
of the directly executed P(P). Once the assumption is proven false then
the "definition" based on this assumption is also refuted.
Before my research no one was aware of the possibility that the
correctly simulated input to H(P,P) could possibly have behavior that is different than the directly executed P(P).
Because P was intentionally defined to have a pathological relationship
to H the behavior of the correctly emulated input to H(P,P) has
different behavior than the directly executed P(P).
In every other case where no such pathological relationship was
intentionally defined the correctly emulated input to H(X,Y) will have
the exact same behavior as the directly executed X(Y).
Prior to my key insight of applying simulating halt decider to
pathological inputs no one knew that the correctly emulated input to
H(P,P) could have different behavior that the directly executed P(P) so
the textbook accounts of the HP simply referred to the behavior of P(P).
On 6/12/2022 4:06 PM, Mr Flibble wrote:
On Sun, 12 Jun 2022 15:30:47 -0500
olcott <NoOne@NoWhere.com> wrote:
On 6/12/2022 3:02 PM, Ben Bacarisse wrote:
Andy Walker <anw@cuboid.co.uk> writes:
On 11/06/2022 21:10, Ben Bacarisse wrote:
There's nothing interesting about pure functions from a
theoretical point of view, but PO has ditched all notions of a
formal model of computation, [...].
Yeah, but others seem to be insisting on "PURE FUNCTIONS"
for no good reason that I can discern.
OK, but I've also seen such insistence when it might matter. I do
think it's the wrong thing to focus on (H could go consult the WWW
for all I care) but it is one way to try to pin PO's nonsense down
a bit.
This program prints 1 (on my system) and halts because
H_Hat(H_Hat) "halts" (i.e. returns to main) even though H_Hat is
correctly constructed from H.
Except that your "H" is not the decider but merely a
subroutine of your program. A correctly constructed "H_Hat" is
not based just on such a subroutine but on the entire program
which contains "H". [I know you know all this, but it bears
occasional repetition.]
Yes, but that's exactly why some people worry about pure functions.
By re-framing the problem in terms of subroutines (and PO is not
alone in this -- see Strachey's oft-cited note) extra care is
needed.
My guess is that it is trickery like this that makes people worry
about functions being pure.
Sure, but it's not really to do with purity as much as
with replacing an input tape [or near equivalent] by compiled [and
non-standard] code invoked from within the program. So the
program is not deciding about a program and its input but just
running a particular program.
<cut>
Another approach, using C, would have been to make H take the
source code of a C program as a string,
That, for me, is what the HP /is/. If "H" then includes a
compiler and some way of running/emulating the compiled code, so
be it. ...
But there is a "halting problem" for functions entirely analogous
to the one for whole programs. When PO shifts from Turing machines
(about which he has nothing to say anymore, having exhausted all
avenues for confusion) to C-like code, it's not actually wrong to
do that, but the notion of what a computation is and what "halting"
means need to be carefully pinned down. I think people reach for
pure functions as a simple way to deal with some of that.
Finally mutual agreement on one key point.
Now that H(P,P)==0 is derived on the basis of a pure function of its
inputs I will be able to post the code for H and P. Prior to that it
would have been rejected on the basis that it depended on static
local data. This only needs very slight code clean up.
The only agreement (among ourselves, excluding yourself) is that your H
is not a halt decider; your H should be renamed to S as all it is is a
simulation detector.
/Flibble
(1) But there is a "halting problem" for functions entirely analogous
to the one for whole programs.
(2) When PO shifts from Turing machines to C-like code, it's not
actually wrong to do that.
(3) The notion of what a computation is and what "halting"
means need to be carefully pinned down.
Points of mutual agreement between myself and Ben.
One of the key points of disagreement seems to be that people agree that
a halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior of its inputs
Yet are totally unaware that they contradict themselves when they say
that H(P,P) must report on the behavior of P(P).
When I prove to them THAT the behavior of the correctly emulated input
to H(P,P) has different halting behavior than the directly executed P(P)
and WHY this behavior is different
When P(P) is executed its behavior conditionally depends on the return
value of H.
When H(P,P) is executed the correctly emulated P cannot possibly reach
the point where its behavior depends on H.
They utterly disregard these verified facts because they simply don't
believe them.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 107:31:02 |
| Calls: | 6,662 |
| Calls today: | 4 |
| Files: | 12,209 |
| Messages: | 5,335,491 |