Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.theory > #105405 > unrolled thread

No decider is ever allowed to report on the behavior of the computation that itself is contained within

Back to article view | Back to comp.theory

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#105405 — No decider is ever allowed to report on the behavior of the computation that itself is contained within

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.

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.

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


-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [next] | [standalone]

#105409

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.

[toc] | [prev] | [next] | [standalone]

#105414 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

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.

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

The rule is the deciders operate on inputs and thus cannot possibly
operate on their own actual selves.

> Yes, you litterally can't phrase the question as being about "The 
> machine you are contained within", 

Everyone has always implicitly assumed this false assumption.

> but you can give the description of 
> that machine and ask about it. 

That is one level of indirection away from the actual machine and
provides the incorrect basis for saying that "this sentence is not true" 
is true on the basis of:
This sentence is not true: "This sentence is not true" is true.

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

When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

embedded_H is not operating on itself it is operating
one level of indirect reference away from its actual self.
*THIS CHANGES EVERYTHING*

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

I already proved otherwise. That you ignored or failed to
understand this proof does not mean that I didn't already
prove otherwise.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#105416 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

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, and that is the behavior the input 
SPECIFIED (per the definiton) it will HALT.

THAT is the behavior that it specifies.

It may be that H can not simulate to that point, but that is just a 
limitation in your design for H. I have shown you a design, which is 
implementable as a Turing Machine equivalent (at least if you assume you 
can handle the detection of the D(D) calling H(D,D) problem) that can 
get past that point. And for other versions of D where the is an answer 
that H could give and be correct, can actually prove that it has a 
corret answer.

This shows that you don't understand what you are talking about, and 
just p=spouting off your normal garbage.

> 
>> 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.
>>
> 
> The rule is the deciders operate on inputs and thus cannot possibly
> operate on their own actual selves.

Right, but they CAN operation on a description of themselves.

You forget, Deciders don't operation directly on machines, and since 
they ARE a machine, we can't give "themselves" to them, or ANY other 
machine as an input. What we can do is give a 
representation/description/specification that can just as easily be of 
what they are as any other machine.

> 
>> Yes, you litterally can't phrase the question as being about "The 
>> machine you are contained within", 
> 
> Everyone has always implicitly assumed this false assumption.

Nope. It seems only YOU think it is that question.

> 
>> but you can give the description of that machine and ask about it. 
> 
> That is one level of indirection away from the actual machine and
> provides the incorrect basis for saying that "this sentence is not true" 
> is true on the basis of:
> This sentence is not true: "This sentence is not true" is true.

Which is just red herring and shows you don't understand what the 
problems is.

This is why I have asked you to actually write out a FORMAL 
SPECIFICATION for what H is, what its input is, and what it is trying to 
decide on.

> 
>> 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).
>>
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> embedded_H is not operating on itself it is operating
> one level of indirect reference away from its actual self.
> *THIS CHANGES EVERYTHING*

It is operating on a description of itself.

It STILL Must give the same answer as H, and must pass that answer to 
H^, which will make that answer wrong.

Of course, all of this is beyound your understanding because it seems 
you STILL don't understand what it means to be a Turing Machine.

> 
>>>
>>> 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.
> 
> I already proved otherwise. That you ignored or failed to
> understand this proof does not mean that I didn't already
> prove otherwise.
> 

IMPOSSIBLE, becasuse the DEFINITION IS THE DEFINITION.

So, you are just admitting to being a LIAR that doesn't understand what 
things mean.

It is categorically impossible to prove a definition is "incorrect', at 
best you can prove a definition make the system inconsistant, but you 
haven't done that for halting either.

All you prove to be inconsistent, is your own logic.

[toc] | [prev] | [next] | [standalone]

#105418 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

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*

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#105420 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

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?

You just don't understand the maning of the words, because you never 
studied them, but are just GUESSING, and guessing wrong.

[toc] | [prev] | [next] | [standalone]

#105421 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

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*

*NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
*ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
*TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*

D of every H/D pair where D is correctly simulated
by H cannot possibly reach is own line 06 and halt.

The failure to provide a counter-example will be
construed as proof of this.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#105423 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

Op 23.mei.2024 om 04:52 schreef olcott:
> 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*
> 
> *NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
> *ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
> *TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*
> 
> D of every H/D pair where D is correctly simulated
> by H cannot possibly reach is own line 06 and halt.
> 
> The failure to provide a counter-example will be
> construed as proof of this.
> 
The failure to provide a counter example is not a proof.

[toc] | [prev] | [next] | [standalone]

#105430 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

On 5/23/2024 2:12 AM, Fred. Zwarts wrote:
> Op 23.mei.2024 om 04:52 schreef olcott:
>> 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*
>>
>> *NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
>> *ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
>> *TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*
>>
>> D of every H/D pair where D is correctly simulated
>> by H cannot possibly reach is own line 06 and halt.
>>
>> The failure to provide a counter-example will be
>> construed as proof of this.
>>
> The failure to provide a counter example is not a proof.

OK then Church-Turing is a wild guess.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#105437 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within

On 5/23/24 9:18 AM, olcott wrote:
> On 5/23/2024 2:12 AM, Fred. Zwarts wrote:
>> Op 23.mei.2024 om 04:52 schreef olcott:
>>> 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*
>>>
>>> *NO ONE KNEW THAT IS WAS THE WRONG QUESTION*
>>> *ONLY BECAUSE EVERYONE REJECTED A SIMULATING*
>>> *TERMINATION ANALYZER OUT-OF-HAND WITHOUT REVIEW*
>>>
>>> D of every H/D pair where D is correctly simulated
>>> by H cannot possibly reach is own line 06 and halt.
>>>
>>> The failure to provide a counter-example will be
>>> construed as proof of this.
>>>
>> The failure to provide a counter example is not a proof.
> 
> OK then Church-Turing is a wild guess.
> 

Which is why it is "Thesis", accepted as most probably true, but not 
proven, and not a Theorem, like the Halting Theorem, which HAS been 
conclusively proven.

You are just making it clear you don't understand the basics of logic.

[toc] | [prev] | [next] | [standalone]

#105425 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE)

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.

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

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

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.

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.

In your case, evidence is put before you, but you just can't understand 
it because you have closed your mind to to truth.

[toc] | [prev] | [next] | [standalone]

#105429 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE)

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.

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

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

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

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

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

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

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

[toc] | [prev] | [next] | [standalone]

#105436 — Re: No decider is allowed to report on the behavior of the computation that itself is contained within (LIE)

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.theory

csiph-web