XPost: sci.logic
On 5/22/24 5:19 PM, olcott wrote:
On 6/24/2022 2:53 AM, Malcolm McLean wrote:
On Thursday, 23 June 2022 at 23:44:12 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:
On Wednesday, 22 June 2022 at 16:50:31 UTC+1, Ben Bacarisse wrote:
Malcolm McLean <malcolm.ar...@gmail.com> writes:
On Wednesday, 22 June 2022 at 13:16:36 UTC+1, olcott wrote:
On 6/22/2022 2:55 AM, Malcolm McLean wrote:
On Wednesday, 22 June 2022 at 04:10:45 UTC+1, olcott wrote:
On 6/21/2022 9:52 PM, Richard Damon wrote:
Right, and P(P) reaches the ret instruction of H(P,P) returns >>>>>>>>>> 0, so H
was incorrect in its mapping, since the behavior of P(P) is the >>>>>>>>>> DEFINITION of the behavior of H(P,P),
Linz and others were aware that: A halt decider must compute >>>>>>>>> the mapping
from its inputs to an accept or reject state on the basis of >>>>>>>>> the actual
behavior that is actually specified by these inputs.
Linz and others made the false assumption that the actual
behavior that
is actually specified by the inputs to a simulating halt
decider is not
the same as the direct execution of these inputs. They were
unaware of
this because no one previously fully examined a simulating halt >>>>>>>>> decider
ever before.
especially if that is what P calls
and P is claimed to be built by the Linz template.
So, either P isn't built right, or H isn't built fight, or H >>>>>>>>>> is wrong.
You've dry-run P(P) and it doesn't halt. Additionally the halt >>>>>>>> decider H
reports it as non-halting. So it's reasonable to assume that H >>>>>>>> is correct.
However, when run, P(P) halts. So what are we to conclude? That >>>>>>>> "the
actual behaviour that is actually specified by the inputs to a >>>>>>>> simulating
halt decider is not the same as the direct execution of these
inputs"?
That is an actual immutable verified fact.
That's your conclusion from your observations and reasoning. You've >>>>>> dry-run P(P), and it doesn't halt. You've run H on P(P), and it
reports "non-halting". You've run P(P), and it halts. So one
explanation is the one you've given but, as I said, that explanation >>>>>> has rather far-reaching consequences.
There is only one explanation. What you call the "dry-run" is not that >>>>> same as the P(P). We've known this since the "line 15 commented out" >>>>> days. There are two computations -- one that is not stopped and one
that is, the "dry-run" and the run, the "simulation of the input to
H(P,P)" and P(P). All PO is doing is trying to find words that hide
what's going on.
I'm a scientists, not a mathematician.
The example I always use is that you are doing an energy budget for
tigers.
You work how much they use on running about, lactating, maintaining
their
body temperature, and so on.
Now let's say that you find that all results are within a few
percentage points
of a similar budget done for lions. You'd instantly accept this data.
Now let's say that the results are wildly different from a previous
budget done
for lions. You wouldn't just accept that data. You'd check. You'd
want to
understand the reasons tigers spend far less energy on movement than
lions.
Now let's say that the result show that tigers use more energy than
they
take in food. Would you instantly conclude that the law of
conservation of
energy must be incorrect?
The third is what PO is doing.
I have no idea what parts of this analogy map to the current situation.
PO has no contradictory results about anything. There's no conflict
with any established facts in anything he is doing.
He's dry-run P(P) and established that it doesn't halt. He's invoked H
on it
and H reports that it doesn't halt. He's run P(P) and it halts.
So something odd is going on there that needs an explanation.
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
*MUCH BETTER WORDS THAN ONE YEAR AGO*
typedef int (*ptr)(); // ptr is pointer to int function in C
00 int H(ptr p, ptr i);
01 int D(ptr p)
02 {
03 int Halt_Status = H(p, p);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 H(D,D);
12 return 0;
13 }
In the above case a simulator is an x86 emulator that correctly emulates
at least one of the x86 instructions of D in the order specified by the
x86 instructions of D.
This may include correctly emulating the x86 instructions of H in the
order specified by the x86 instructions of H thus calling H(D,D) in
recursive simulation.
It is trivial to see that for every H/D pair of the infinite
set of H/D pairs that match the above template that
D correctly simulated by H cannot possibly reach its own final
state at line 06 and halt because D correctly simulated by
H remains stuck in recursive simulation.
Deciders are only accountable for the behavior of their inputs
and are thus not allowed to report on the behavior of the computation
that they themselves are contained within.
No. "Behavior of their inputss" MEANS for Turing Machines that are
computing properties of Turing Machines (like Halt Deciders) have the
"behavior of their input" defined as the Behavior of the machine their
input represents/describes/specifies.
And, there is no rule that prohibits that machine given as a
representation from including a copy of the machine that is deciding on it.
Yes, you litterally can't phrase the question as being about "The
machine you are contained within", but you can give the description of
that machine and ask about it. The point is that Turing Machines don't
have that sort of "reference" to allow the use of the pronoun to
reference the machine, you need to actually give the machine (by an
encoding of it).
There is no Turing machine that can possibly take its actual
self as an input because actual Turing Machines are not allowed
as inputs to other Turing Machines.
But representations of them are, so we CAN ask Turing Machine about the behavior of a Turing Machine that includes a copy of itself.
*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*
*thus the behavior of D(D) executed from main() has always been moot*
No, because that is what DEFINES Halting.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)