Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: New test program (Succeeds V2)[ counter-example in C ? ]
13 views
Skip to first unread message
olcott
May 12, 2021, 4:44:47 PM5/12/21
to
On 5/12/2021 6:46 AM, Richard Damon wrote:
> On 5/11/21 11:27 PM, olcott wrote:
>>
>> There is no code in my entire system that is not simulated so how else
>> can I address a statement that is very simply factually incorrect?
>>
>> I don't want to get into any of the underlying technical details so that
>> the current implemenation can be endlessly nit picked to death. I only
>> want to verify that my architectural design is correct.
>
> And this is part of your issue. Either you are claiming that any 'x86'
> is just a Turing Equivalent, so top level code running as x86 code is
> the equivalent to the actual Turing Machines, or you are defining that
> you have some program that creates a 'Turing Complete' environment
> taking inputs of Machine Equivalents, and runs them as their Turing
> Equivalent.
Right now I am only evaluating the software engineering of a partial
halt decider written in C that examines x86 machine language execution
traces of a simulation of its input on the following basis:
Every partial halt decider H that that bases its halting decision
on simulating its input P until criteria (1)(2)(3) are met by the
execution trace of P correctly decides not halting on input P.
If the execution trace of function P() [i.e. the input to H] shows:
(1) Partial halt decider H is called twice in sequence from the same
machine address of P.
(2) with the same machine address parameters to H
(3) with no conditional branch or indexed jump instructions in P
then H correctly decides not halting on P.
The proof that I am correct is the impossibility of creating a
counter-example written in C that meets the (1)(2)(3) criteria, halts,
and H never stops simulating P.
http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
> On 5/11/21 11:27 PM, olcott wrote:
>>
>> There is no code in my entire system that is not simulated so how else
>> can I address a statement that is very simply factually incorrect?
>>
>> I don't want to get into any of the underlying technical details so that
>> the current implemenation can be endlessly nit picked to death. I only
>> want to verify that my architectural design is correct.
>
> And this is part of your issue. Either you are claiming that any 'x86'
> is just a Turing Equivalent, so top level code running as x86 code is
> the equivalent to the actual Turing Machines, or you are defining that
> you have some program that creates a 'Turing Complete' environment
> taking inputs of Machine Equivalents, and runs them as their Turing
> Equivalent.
Right now I am only evaluating the software engineering of a partial
halt decider written in C that examines x86 machine language execution
traces of a simulation of its input on the following basis:
Every partial halt decider H that that bases its halting decision
on simulating its input P until criteria (1)(2)(3) are met by the
execution trace of P correctly decides not halting on input P.
If the execution trace of function P() [i.e. the input to H] shows:
(1) Partial halt decider H is called twice in sequence from the same
machine address of P.
(2) with the same machine address parameters to H
(3) with no conditional branch or indexed jump instructions in P
then H correctly decides not halting on P.
The proof that I am correct is the impossibility of creating a
counter-example written in C that meets the (1)(2)(3) criteria, halts,
and H never stops simulating P.
http://www.liarparadox.org/Halting_problem_undecidability_and_infinite_recursion.pdf
--
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott
May 14, 2021, 12:12:26 PM5/14/21
to
On 5/14/2021 10:51 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 5/13/2021 6:55 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 5/13/2021 4:26 PM, Ben Bacarisse wrote:
>
>>>>> I know it's bizarre, after so
>>>>> many years or of you pretending to talk about the halting problem, but
>>>>> you are yet to agree with the trivial facts that
>>>>>
>>>>> (A1) For every instance of the halting problem that represents a finite
>>>>> computation, the correct answer is "yes".
>>>>> (A2) For every instance of the halting problem that does not represent
>>>>> a finite computation, the correct answer is "no".
>>>>
>>>> In computability theory and computational complexity theory, a
>>>> decision problem is a problem that can be posed as a yes-no question
>>>> of the input values. https://en.wikipedia.org/wiki/Decision_problem
>>>>
>>>> Does Turing machine P halt on its input I?
>>>>
>>>> The problem with that definition is that it is not sufficiently
>>>> granular to expressly take into account that the simulation of P(I)
>>>> was not allowed to complete because it specifies infinite execution.
>>>
>>> Great, that's clear, so please stop pretending that you are addressing
>>> the halting problem. Give your new problem a name, and start by
>>> explaining how anyone but you knows what the right answer is. That will
>>> sadly require (a) a model of computation within which proofs can be
>>> constructed; and (b) some mathematics to express the problem formally.
>>>
>>> You might also want say why anyone would be interesting in the
>>> not-quite-halting problem.
>>
>> It is still the basis for a unverisal halt decider thus directly
>> applies to the halting problem.
>
> No. Halts(H_Hat, H_Hat) == 0 is the wrong answer to the halting problem
> for the instance (H_Hat, H_Hat) because H_Hat(H_Hat) halts.
Even though it really really seems this way it actually turns out that
Halts(H_Hat, H_Hat) is an entirely different computation than
H_Hat(H_Hat) therefore the behavior of H_Hat(H_Hat) is not actually a
proxy for the halting decision of Halts(H_Hat, H_Hat) at all.
Like I repeated several times yesterday if you want to find out the
length of your car you really can't do this by measuring the height of
your house.
If we are trying to determine whether or not Halts decides its inputs
correctly we must base this on examining every single step of exactly
how Halts decides its actual inputs.
If no errors exist in the steps that Halts takes to decides its actual
inputs then Halts has decided these inputs correctly no matter how much
intuition says otherwise.
When the behavior of the input P to Halts correctly matches a correct
non-halting behavior pattern then Halts decides non-halting on P correctly.
> It's as
> simple as that. And you are not even being coy anymore. You are clear
> that you reject the very basis of the halting problem which is simply to
> determine if a computation is finite or not and to produce the correct
> answer based on that fact alone.
> olcott <No...@NoWhere.com> writes:
>
>> On 5/13/2021 6:55 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 5/13/2021 4:26 PM, Ben Bacarisse wrote:
>
>>>>> I know it's bizarre, after so
>>>>> many years or of you pretending to talk about the halting problem, but
>>>>> you are yet to agree with the trivial facts that
>>>>>
>>>>> (A1) For every instance of the halting problem that represents a finite
>>>>> computation, the correct answer is "yes".
>>>>> (A2) For every instance of the halting problem that does not represent
>>>>> a finite computation, the correct answer is "no".
>>>>
>>>> In computability theory and computational complexity theory, a
>>>> decision problem is a problem that can be posed as a yes-no question
>>>> of the input values. https://en.wikipedia.org/wiki/Decision_problem
>>>>
>>>> Does Turing machine P halt on its input I?
>>>>
>>>> The problem with that definition is that it is not sufficiently
>>>> granular to expressly take into account that the simulation of P(I)
>>>> was not allowed to complete because it specifies infinite execution.
>>>
>>> Great, that's clear, so please stop pretending that you are addressing
>>> the halting problem. Give your new problem a name, and start by
>>> explaining how anyone but you knows what the right answer is. That will
>>> sadly require (a) a model of computation within which proofs can be
>>> constructed; and (b) some mathematics to express the problem formally.
>>>
>>> You might also want say why anyone would be interesting in the
>>> not-quite-halting problem.
>>
>> It is still the basis for a unverisal halt decider thus directly
>> applies to the halting problem.
>
> No. Halts(H_Hat, H_Hat) == 0 is the wrong answer to the halting problem
> for the instance (H_Hat, H_Hat) because H_Hat(H_Hat) halts.
Even though it really really seems this way it actually turns out that
Halts(H_Hat, H_Hat) is an entirely different computation than
H_Hat(H_Hat) therefore the behavior of H_Hat(H_Hat) is not actually a
proxy for the halting decision of Halts(H_Hat, H_Hat) at all.
Like I repeated several times yesterday if you want to find out the
length of your car you really can't do this by measuring the height of
your house.
If we are trying to determine whether or not Halts decides its inputs
correctly we must base this on examining every single step of exactly
how Halts decides its actual inputs.
If no errors exist in the steps that Halts takes to decides its actual
inputs then Halts has decided these inputs correctly no matter how much
intuition says otherwise.
When the behavior of the input P to Halts correctly matches a correct
non-halting behavior pattern then Halts decides non-halting on P correctly.
> It's as
> simple as that. And you are not even being coy anymore. You are clear
> that you reject the very basis of the halting problem which is simply to
> determine if a computation is finite or not and to produce the correct
> answer based on that fact alone.
0 new messages