Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #105436
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Newsgroups | comp.theory, sci.logic |
| Subject | Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE) |
| Date | 2024-05-23 21:44 -0400 |
| Organization | i2pn2 (i2pn.org) |
| Message-ID | <v2ore7$1tsmo$2@i2pn2.org> (permalink) |
| References | (14 earlier) <v2m9u6$1ievj$3@dont-email.me> <v2ma6a$1qo0t$5@i2pn2.org> <v2mb28$1io97$1@dont-email.me> <v2n9bj$1qo0t$6@i2pn2.org> <v2ni33$1pfk4$1@dont-email.me> |
Cross-posted to 2 groups.
On 5/23/24 9:58 AM, olcott wrote:
> On 5/23/2024 6:29 AM, Richard Damon wrote:
>> On 5/22/24 10:52 PM, olcott wrote:
>>> On 5/22/2024 9:38 PM, Richard Damon wrote:
>>>> On 5/22/24 10:33 PM, olcott wrote:
>>>>> On 5/22/2024 9:27 PM, Richard Damon wrote:
>>>>>> On 5/22/24 10:07 PM, olcott wrote:
>>>>>>> On 5/22/2024 6:01 PM, Richard Damon wrote:
>>>>>>>> On 5/22/24 5:19 PM, olcott wrote:
>>>>>>>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> Only specifies and no matter how many times you deny it,
>>>>>>> it remains a verified fact that:
>>>>>>> the input to H
>>>>>>> the input to H
>>>>>>> the input to H
>>>>>>> the input to H
>>>>>>> the input to H
>>>>>>> the input to H
>>>>>>> the input to H
>>>>>>> specifies that it never reaches its own final state and halts.
>>>>>>
>>>>>> No since when the input is run,
>>>>>
>>>>> *That has nothing to do with*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>>
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>> *The behavior that the input to H specifies*
>>>>>
>>>>
>>>> Sure it does.
>>>>
>>>> What else does the question: Does the program described to the
>>>> decider halt mean other than that?
>>>
>>> *That is the FREAKING WRONG QUESTION*
>>
>> Then you aren't talking about the HALTING PROBLEM.
>>
>> You don't get to tell people the problem they want to solve is the
>> wrong problem, and it is a LIE to say some other different problem
>> answers the one they have.
>>
>>>
>>> *NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
>>> *ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
>>> *TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*
>>
>> NO, because your "Termination Analyzers" don't solve the problem that
>> was being asked of the Halting Decider.
>>
>
> It is an easily verified that for every H/D pair that D correctly
> simulated by H cannot possibly reach its own line 06 and halt because
> every D correctly simulated by H remains stuck in recursive simulation.
Then do so!
>
> *Simply lying about this DOES NOT HELP*
> The failure to provide a VALID counter-example will be construed
> as YOU KNOW YOU ARE LYING ABOUT THIS until a valid counter-example
> is provided. Your prior counter-example proved to be invalid,
> yet at least it existed.
Nope. Note, I have not denied that with your new conditions it might be
possible that you are right. The problem is you leave enough sloppyness
in your definitions it is unclear exactly what you are stating, and if
you understand what that would actually mean.
I put a detailed set of starting question on your new thread asking you
to confirm the implications of what seems to be your definitions.
Please confirm that you understand that, or try to change you question
to remove the problems.
>
>>>
>>> D of every H/D pair where D is correctly simulated
>>> by H cannot possibly reach is own line 06 and halt.
>>
>> And who cares abot that, if it can be true but when we actually run
>> D(D) it halts.
>>
>
> That violates this definition:
> CORRECT SIMULATION DEFINED
> 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.
>
And does your current example of H do this? The only simulations looked
at are the ACTUAL instructions that would have been executed if D(D) was
run, and NOT ever switching to looking at the "execution" of the
instructions that the simulated simulator is looking at?
>>>
>>> The failure to provide a counter-example will be
>>> construed as proof of this.
>>>
>>
>> Your last claim == proof that you don't understand how logic works.
>>
>
> The complete non-existence of a counter-example is proof.
> We use this as sufficient proof of Church-Turing.
Nope.
Not till you PROVE that there can not exist a counter-example.
Since you still haven't firmed up your definitions and agreed to the
affect of your deviation from "traditional" definitions will do, it is
unclear what you are actually trying to claim.
Note, "Church-Turing" is a THESIS, not a THEOREM, which means that while
it is generally accepted as probably true, it is acknowledged that it
hasn't been proven.
>
>> You have wasted your last 20 years, because you just didn't understand
>> what you were talking about.
>>
>> You have turned yourself into a pathological liar because you have
>> taught yourself to ignore things that disagree with you, and you
>> pretend they don't exist, and then you think you can correctly say
>> they don't, when it is just a lie.
>>
>
> Whenever you point out the details of why you think I am incorrect
> I show your mistake.
Nope, you change your definitions,
>
>> Your are worse then the election deniers. You refuse to look at the
>> evidence. At least there claim has a possibility of having a chance to
>> be logically true, since absence of proof is not a proof of absence,
>> and there could be a deep state lying machine hiding the evidence.
>>
>
> Prior to Pythagoras there was a universal consensus that
> the Earth was flat.
So?
>
>> In your case, evidence is put before you, but you just can't
>> understand it because you have closed your mind to to truth.
>
> I just proved that you are wrong about *CORRECT SIMULATION* ignoring
> this proof is not any sort of rebuttal what-so-ever.
>
Nope. You are just stipulating that for you arguement you are going to
use a NON-STANDARD definition for them field, and thus break any
opertunity to use what Computation Theory says about simulations and
their relationship to Halting, which means that even if you CAN proven
that H can't correctly simulate its input to a final state, that just
says that it can't simulate its input to a final state, but NOTHING
about the input being non-halting, so pretty worthless for trying to
show you can decide halting, when you begin by DEFINING that you
technique is not able to prove non-halting because you walled off that
part of the field by a non-standard stipulated definition.
Back to comp.theory | Previous | Next — Previous in thread | Find similar | Unroll thread
No decider is ever allowed to report on the behavior of the computation that itself is contained within olcott <polcott333@gmail.com> - 2024-05-22 16:19 -0500
Re: No decider is ever allowed to report on the behavior of the computation that itself is contained within Richard Damon <richard@damon-family.org> - 2024-05-22 19:01 -0400
Re: No decider is allowed to report on the behavior of the computation that itself is contained within olcott <polcott333@gmail.com> - 2024-05-22 21:07 -0500
Re: No decider is allowed to report on the behavior of the computation that itself is contained within Richard Damon <richard@damon-family.org> - 2024-05-22 22:27 -0400
Re: No decider is allowed to report on the behavior of the computation that itself is contained within olcott <polcott333@gmail.com> - 2024-05-22 21:33 -0500
Re: No decider is allowed to report on the behavior of the computation that itself is contained within Richard Damon <richard@damon-family.org> - 2024-05-22 22:38 -0400
Re: No decider is allowed to report on the behavior of the computation that itself is contained within olcott <polcott333@gmail.com> - 2024-05-22 21:52 -0500
Re: No decider is allowed to report on the behavior of the computation that itself is contained within "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-23 09:12 +0200
Re: No decider is allowed to report on the behavior of the computation that itself is contained within olcott <polcott333@gmail.com> - 2024-05-23 08:18 -0500
Re: No decider is allowed to report on the behavior of the computation that itself is contained within Richard Damon <richard@damon-family.org> - 2024-05-23 21:44 -0400
Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE) Richard Damon <richard@damon-family.org> - 2024-05-23 07:29 -0400
Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE) olcott <polcott333@gmail.com> - 2024-05-23 08:58 -0500
Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE) Richard Damon <richard@damon-family.org> - 2024-05-23 21:44 -0400
csiph-web