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

Groups > sci.logic > #335832 > unrolled thread

Why do people here insist on denying these verified facts?

Back to article view | Back to sci.logic

Contents

  Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 09:31 -0500
    Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 10:42 -0400
      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 10:16 -0500
        Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 11:29 -0400
          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 11:12 -0500
            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 13:08 -0400
        Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-22 16:03 +0000
          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 11:18 -0500
            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 13:13 -0400
              Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 12:29 -0500
                Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 14:43 -0400
                  Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 13:49 -0500
                    Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 14:55 -0400
                      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 14:03 -0500
                        Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 15:19 -0400
                          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 14:35 -0500
                            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 15:43 -0400
                              Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 14:49 -0500
                                Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 16:08 -0400
                                  Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 18:59 -0500
                                    Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 20:19 -0400
                                      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 22:37 -0500
                                        Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 07:28 -0400
                                          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:36 -0500
                                            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 14:22 -0400
                            Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-22 20:01 +0000
                              Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 18:57 -0500
                                Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 20:07 -0400
                                  Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 19:09 -0500
                                    Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-22 20:26 -0400
                                      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-22 22:46 -0500
                                        Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 07:28 -0400
                                          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:37 -0500
                                            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-23 14:22 -0400
                        Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-28 09:54 -0500
                          Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-28 23:49 -0400
            Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-25 20:41 +0000
              Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-25 16:24 -0500
                Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-25 21:47 -0400
                Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-26 08:19 +0000
    Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:23 -0500

Page 1 of 3  [1] 2 3  Next page →

#335832 — Why do people here insist on denying these verified facts?

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/

To understand this analysis requires a sufficient knowledge of
the C programming language and what an x86 emulator does. HHH0
and HHH1 have this criteria as their algorithm:

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then

   H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > I don't think that is the shell game. PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.
 >

Ben only agrees that the criteria is met for the input. He
does not agree that the criteria has been meet for non-inputs.

Computable functions are the formalized analogue of the intuitive
notion of algorithms, in the sense that a function is computable if 
there exists an algorithm that can do the job of the function, i.e. 
*given an input of the function domain*
*it can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function

*That seems to say that non-inputs do not count*

*Here is the verified facts that everyone denies*
*Here is the verified facts that everyone denies*
*Here is the verified facts that everyone denies*
*Here is the verified facts that everyone denies*

void DDD()
{
   HHH0(DDD);
}

int main()
{
   Output("Input_Halts = ", HHH0(DDD));
   Output("Input_Halts = ", HHH1(DDD));
}

It is a verified fact that the behavior that finite string DDD
presents to HH0 is that when DDD correctly emulated by HH0
calls HH0(DDD) that *THIS CALL DOES NOT RETURN*

It is a verified fact that the behavior that finite string DDD
presents to HH1 is that when DDD correctly emulated by HH1
calls HH0(DDD) that *THIS CALL DOES RETURN*


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

#335836

On 6/22/24 10:31 AM, olcott wrote:
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
> 
> To understand this analysis requires a sufficient knowledge of
> the C programming language and what an x86 emulator does. HHH0
> and HHH1 have this criteria as their algorithm:

Which you just showed you don't have, since on comp.lang.c++ you thought 
that

x *= ++f * ++f;

had defined behavior for primative types for f.

> 
> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>    If simulating halt decider H correctly simulates its input D
>    until H correctly determines that its simulated D would never
>    stop running unless aborted then
> 
>    H can abort its simulation of D and correctly report that D
>    specifies a non-halting sequence of configurations.
> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

Which used the definition of "Correct Simulation" to mean a simulation 
that produces the EXACT results of the direct execution of the machine 
being simulated, which requires a simulation that will not "abort" its 
simulation, EVER (except by reaching a final state).

You Deciders do not do this, nor do they do this about an actual Correct 
Simulation per that definition of the input, so they can not use the 
second clause.

> 
> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>  > I don't think that is the shell game. PO really /has/ an H
>  > (it's trivial to do for this one case) that correctly determines
>  > that P(P) *would* never stop running *unless* aborted.
>  >
> 
> Ben only agrees that the criteria is met for the input. He
> does not agree that the criteria has been meet for non-inputs.

Ben only agrees that H correctly decides the exact criteria that you 
state, that no H can "correctly simuate" (per YOUR definition) the input 
to a final state. Thus, he is agreeing that you H is a POOP decider, for 
this input, but not that it is a HALTING decider for this input, since 
its criteria is not the Halting Criteria.

> 
> Computable functions are the formalized analogue of the intuitive
> notion of algorithms, in the sense that a function is computable if 
> there exists an algorithm that can do the job of the function, i.e. 
> *given an input of the function domain*
> *it can return the corresponding output*
> https://en.wikipedia.org/wiki/Computable_function
> 
> *That seems to say that non-inputs do not count*

But we aren't talking about "Non-Inputs", and in fact, YOUR arguement 
needs to look at the non-inputs, as it allows the input to change when 
you argue about other deciders.

The input is the finite string.

The MEANING of that finite string is defined by the PROBLEM. The decider 
gets to define the encoding, but not the meaning/behavior of the encoded 
items.

Halting DEFINES the meaning/behavior to be that of the directly run 
program represented by the input.
> 
> *Here is the verified facts that everyone denies*
> *Here is the verified facts that everyone denies*
> *Here is the verified facts that everyone denies*
> *Here is the verified facts that everyone denies*
> 
> void DDD()
> {
>    HHH0(DDD);
> }
> 
> int main()
> {
>    Output("Input_Halts = ", HHH0(DDD));
>    Output("Input_Halts = ", HHH1(DDD));
> }
> 
> It is a verified fact that the behavior that finite string DDD
> presents to HH0 is that when DDD correctly emulated by HH0
> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
> 
> It is a verified fact that the behavior that finite string DDD
> presents to HH1 is that when DDD correctly emulated by HH1
> calls HH0(DDD) that *THIS CALL DOES RETURN*
> 
> 


The problem is that the "behavior" that the finite string DDD presents 
to HH0, is DEFINED by the problem. And if that problem is the Halting 
Problem, that behavior is the behavior of the machine the input 
represents. If HH0 treats the input as having a different behavior, then 
HH0 just isn't a Halting Decider, but something else.

If HH0 is supposed to be a Halting decider, but uses a method that makes 
it see something other than that behavior, then it is just an incorrect 
Halting Decider, and its algorithm just creates an incorrect recreation 
of the property of the input it is supposed to be working on.


A bit of a side note, the actual "Input" to HH0, is a pointer to memory, 
and as such it passes a reference to ALL of memory considering the 
starting point to be that address, so your "Input" isn't actually the 
few bytes of DDD, but ALL of memory and a starting point. If you 
actually mean that the input is just those few bytes pointed to by the 
address, then the input is improperly formed and is NOT a proper 
representation of the input machine, becuase it is incomplete.

The fact you don't understand this, seems to imply you are lacking the 
basic knowledge to be talking about this sort of thing.

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

#335840

On 6/22/2024 9:42 AM, Richard Damon wrote:
> On 6/22/24 10:31 AM, olcott wrote:
>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>
>> To understand this analysis requires a sufficient knowledge of
>> the C programming language and what an x86 emulator does. HHH0
>> and HHH1 have this criteria as their algorithm:
> 
> Which you just showed you don't have, since on comp.lang.c++ you thought 
> that
> 
> x *= ++f * ++f;
> 
> had defined behavior for primative types for f.
> 
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>    If simulating halt decider H correctly simulates its input D
>>    until H correctly determines that its simulated D would never
>>    stop running unless aborted then
>>
>>    H can abort its simulation of D and correctly report that D
>>    specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
> 
> Which used the definition of "Correct Simulation" to mean a simulation 
> that produces the EXACT results of the direct execution of the machine 
> being simulated, which requires a simulation that will not "abort" its 
> simulation, EVER (except by reaching a final state).
> 

I have had enough of your deception trying to get away
with denying the semantics of the x86 programming language.
I really hope that you don't get condemned to Hell over this.

> You Deciders do not do this, nor do they do this about an actual Correct 
> Simulation per that definition of the input, so they can not use the 
> second clause.
> 
>>
>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>  > I don't think that is the shell game. PO really /has/ an H
>>  > (it's trivial to do for this one case) that correctly determines
>>  > that P(P) *would* never stop running *unless* aborted.
>>  >
>>
>> Ben only agrees that the criteria is met for the input. He
>> does not agree that the criteria has been meet for non-inputs.
> 
> Ben only agrees that H correctly decides the exact criteria that you 
> state, that no H can "correctly simuate" (per YOUR definition) the input 
> to a final state. 

And you happily deny the verified facts at the possible cost
of damnation in Hell.

> Thus, he is agreeing that you H is a POOP decider, for 
> this input, but not that it is a HALTING decider for this input, since 
> its criteria is not the Halting Criteria.
> 
>>
>> Computable functions are the formalized analogue of the intuitive
>> notion of algorithms, in the sense that a function is computable if 
>> there exists an algorithm that can do the job of the function, i.e. 
>> *given an input of the function domain*
>> *it can return the corresponding output*
>> https://en.wikipedia.org/wiki/Computable_function
>>
>> *That seems to say that non-inputs do not count*
> 
> But we aren't talking about "Non-Inputs", 

The D(D) that calls H(D,D) such that this call returns has
provably different behavior than D correctly simulated by H
is measured by the actual semantics of the x86 programming
language.

How the Hell does anyone feel that they can get away with
flatly contradicting the semantics of the x86 programming
language?

We are a herd and our first duty it to follow the herd
even if the herd leaps off a cliff.

> and in fact, YOUR arguement 
> needs to look at the non-inputs, as it allows the input to change when 
> you argue about other deciders.
> 
int sum(int x, int y){ return x + y; }
In other words sum(3,4) must consider the sum of 5 + 6?

> The input is the finite string.
> 
> The MEANING of that finite string is defined by the PROBLEM.

LIAR. You know that the meaning of the finite string
is defined by the semantics of the x86 language.

I might start wishing that you get a tiny taste of Hell
to set you on the correct path.

As Christ said as ye judge ye shall be judged so I do
wish the same thing upon myself. If I am on the wrong
path then I sincerely wish for the minimum adversity
required to definitely set me on the right path.

>  The decider 
> gets to define the encoding, but not the meaning/behavior of the encoded 
> items.
> 

When the x86 language is specified then the decider
has zero leeway in this.

> Halting DEFINES the meaning/behavior to be that of the directly run 
> program represented by the input.

That makes it contradict one of its own axioms, thus
conclusively proving that it is incorrect:

Computable functions are the formalized analogue of the
intuitive notion of algorithms, in the sense that a
function is computable if there exists an algorithm
that can do the job of the function, i.e.
*given an input of the function domain it*
*can return the corresponding output*
https://en.wikipedia.org/wiki/Computable_function

>>
>> *Here is the verified facts that everyone denies*
>> *Here is the verified facts that everyone denies*
>> *Here is the verified facts that everyone denies*
>> *Here is the verified facts that everyone denies*
>>
>> void DDD()
>> {
>>    HHH0(DDD);
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", HHH0(DDD));
>>    Output("Input_Halts = ", HHH1(DDD));
>> }
>>
>> It is a verified fact that the behavior that finite string DDD
>> presents to HH0 is that when DDD correctly emulated by HH0
>> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
>>
>> It is a verified fact that the behavior that finite string DDD
>> presents to HH1 is that when DDD correctly emulated by HH1
>> calls HH0(DDD) that *THIS CALL DOES RETURN*
>>
>>
> 
> 
> The problem is that the "behavior" that the finite string DDD presents 
> to HH0, is DEFINED by the problem. 

LIAR. It is defined by the semantics of the x86 language.

> And if that problem is the Halting 
> Problem, that behavior is the behavior of the machine the input 
> represents. If HH0 treats the input as having a different behavior, then 
> HH0 just isn't a Halting Decider, but something else.
> 
> If HH0 is supposed to be a Halting decider, but uses a method that makes 
> it see something other than that behavior, then it is just an incorrect 
> Halting Decider, and its algorithm just creates an incorrect recreation 
> of the property of the input it is supposed to be working on.
> 
> 
> A bit of a side note, the actual "Input" to HH0, is a pointer to memory, 
> and as such it passes a reference to ALL of memory considering the 
> starting point to be that address, so your "Input" isn't actually the 
> few bytes of DDD, but ALL of memory and a starting point. If you 
> actually mean that the input is just those few bytes pointed to by the 
> address, then the input is improperly formed and is NOT a proper 
> representation of the input machine, becuase it is incomplete.
> 
> The fact you don't understand this, seems to imply you are lacking the 
> basic knowledge to be talking about this sort of thing.
> 

The input to HHH0(DDD) includes itself.
The input to HHH1(DDD) DOES NOT include itself.

It is stipulated that correct emulation is defined by the
semantics of the x86 programming language and nothing else.

DDD correctly emulated by HHH0 correctly determines that
the call from the emulated DDD to HHH0 DOES NOT RETURN.

DDD correctly emulated by HHH1 correctly determines that
the call from the emulated DDD to HHH0 DOES RETURN.




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

#335841

On 6/22/24 11:16 AM, olcott wrote:
> On 6/22/2024 9:42 AM, Richard Damon wrote:
>> On 6/22/24 10:31 AM, olcott wrote:
>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>
>>> To understand this analysis requires a sufficient knowledge of
>>> the C programming language and what an x86 emulator does. HHH0
>>> and HHH1 have this criteria as their algorithm:
>>
>> Which you just showed you don't have, since on comp.lang.c++ you 
>> thought that
>>
>> x *= ++f * ++f;
>>
>> had defined behavior for primative types for f.
>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>    If simulating halt decider H correctly simulates its input D
>>>    until H correctly determines that its simulated D would never
>>>    stop running unless aborted then
>>>
>>>    H can abort its simulation of D and correctly report that D
>>>    specifies a non-halting sequence of configurations.
>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>> Which used the definition of "Correct Simulation" to mean a simulation 
>> that produces the EXACT results of the direct execution of the machine 
>> being simulated, which requires a simulation that will not "abort" its 
>> simulation, EVER (except by reaching a final state).
>>
> 
> I have had enough of your deception trying to get away
> with denying the semantics of the x86 programming language.
> I really hope that you don't get condemned to Hell over this.

And what in the actual detail of the x86 programming language says 
something diffferent than what I say?

I think YOU are the one in danger, as you LIE about what the x86 
assembly code says,

> 
>> You Deciders do not do this, nor do they do this about an actual 
>> Correct Simulation per that definition of the input, so they can not 
>> use the second clause.
>>
>>>
>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>  > I don't think that is the shell game. PO really /has/ an H
>>>  > (it's trivial to do for this one case) that correctly determines
>>>  > that P(P) *would* never stop running *unless* aborted.
>>>  >
>>>
>>> Ben only agrees that the criteria is met for the input. He
>>> does not agree that the criteria has been meet for non-inputs.
>>
>> Ben only agrees that H correctly decides the exact criteria that you 
>> state, that no H can "correctly simuate" (per YOUR definition) the 
>> input to a final state. 
> 
> And you happily deny the verified facts at the possible cost
> of damnation in Hell.
> 
>> Thus, he is agreeing that you H is a POOP decider, for this input, but 
>> not that it is a HALTING decider for this input, since its criteria is 
>> not the Halting Criteria.
>>
>>>
>>> Computable functions are the formalized analogue of the intuitive
>>> notion of algorithms, in the sense that a function is computable if 
>>> there exists an algorithm that can do the job of the function, i.e. 
>>> *given an input of the function domain*
>>> *it can return the corresponding output*
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> *That seems to say that non-inputs do not count*
>>
>> But we aren't talking about "Non-Inputs", 
> 
> The D(D) that calls H(D,D) such that this call returns has
> provably different behavior than D correctly simulated by H
> is measured by the actual semantics of the x86 programming
> language.
> 
> How the Hell does anyone feel that they can get away with
> flatly contradicting the semantics of the x86 programming
> language?
> 
> We are a herd and our first duty it to follow the herd
> even if the herd leaps off a cliff.
> 
>> and in fact, YOUR arguement needs to look at the non-inputs, as it 
>> allows the input to change when you argue about other deciders.
>>
> int sum(int x, int y){ return x + y; }
> In other words sum(3,4) must consider the sum of 5 + 6?
> 
>> The input is the finite string.
>>
>> The MEANING of that finite string is defined by the PROBLEM.
> 
> LIAR. You know that the meaning of the finite string
> is defined by the semantics of the x86 language.

Right, by what the DIRECT EXECUTION of that set of instruction will do.

Which means, for your input, in needs the instuctions of the decider it 
calls.

> 
> I might start wishing that you get a tiny taste of Hell
> to set you on the correct path.
> 
> As Christ said as ye judge ye shall be judged so I do
> wish the same thing upon myself. If I am on the wrong
> path then I sincerely wish for the minimum adversity
> required to definitely set me on the right path.
> 
>>  The decider gets to define the encoding, but not the meaning/behavior 
>> of the encoded items.
>>
> 
> When the x86 language is specified then the decider
> has zero leeway in this.

So, what in the x86 language shows what you claim?

> 
>> Halting DEFINES the meaning/behavior to be that of the directly run 
>> program represented by the input.
> 
> That makes it contradict one of its own axioms, thus
> conclusively proving that it is incorrect:
> 
> Computable functions are the formalized analogue of the
> intuitive notion of algorithms, in the sense that a
> function is computable if there exists an algorithm
> that can do the job of the function, i.e.
> *given an input of the function domain it*
> *can return the corresponding output*
> https://en.wikipedia.org/wiki/Computable_function

Who says Halting is a Computable Function?

THAT is part of your problem.

The question actually is, "IS Halting Computable?"

> 
>>>
>>> *Here is the verified facts that everyone denies*
>>> *Here is the verified facts that everyone denies*
>>> *Here is the verified facts that everyone denies*
>>> *Here is the verified facts that everyone denies*
>>>
>>> void DDD()
>>> {
>>>    HHH0(DDD);
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", HHH0(DDD));
>>>    Output("Input_Halts = ", HHH1(DDD));
>>> }
>>>
>>> It is a verified fact that the behavior that finite string DDD
>>> presents to HH0 is that when DDD correctly emulated by HH0
>>> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
>>>
>>> It is a verified fact that the behavior that finite string DDD
>>> presents to HH1 is that when DDD correctly emulated by HH1
>>> calls HH0(DDD) that *THIS CALL DOES RETURN*
>>>
>>>
>>
>>
>> The problem is that the "behavior" that the finite string DDD presents 
>> to HH0, is DEFINED by the problem. 
> 
> LIAR. It is defined by the semantics of the x86 language.

Right, as the results of the direfdt execution of the input, which means 
the input needs to contain ALL the instructions that will be executed.

> 
>> And if that problem is the Halting Problem, that behavior is the 
>> behavior of the machine the input represents. If HH0 treats the input 
>> as having a different behavior, then HH0 just isn't a Halting Decider, 
>> but something else.
>>
>> If HH0 is supposed to be a Halting decider, but uses a method that 
>> makes it see something other than that behavior, then it is just an 
>> incorrect Halting Decider, and its algorithm just creates an incorrect 
>> recreation of the property of the input it is supposed to be working on.
>>
>>
>> A bit of a side note, the actual "Input" to HH0, is a pointer to 
>> memory, and as such it passes a reference to ALL of memory considering 
>> the starting point to be that address, so your "Input" isn't actually 
>> the few bytes of DDD, but ALL of memory and a starting point. If you 
>> actually mean that the input is just those few bytes pointed to by the 
>> address, then the input is improperly formed and is NOT a proper 
>> representation of the input machine, becuase it is incomplete.
>>
>> The fact you don't understand this, seems to imply you are lacking the 
>> basic knowledge to be talking about this sort of thing.
>>
> 
> The input to HHH0(DDD) includes itself.
> The input to HHH1(DDD) DOES NOT include itself.

So?

> 
> It is stipulated that correct emulation is defined by the
> semantics of the x86 programming language and nothing else.

Right, so HHH0 needs to determine what the ACTUAL BEHAVIOR of its input 
is to be a Halt Decider, and that means it needs to figure out what it 
will itself do.

> 
> DDD correctly emulated by HHH0 correctly determines that
> the call from the emulated DDD to HHH0 DOES NOT RETURN.

Nope, It just determins that it doesn't know if the call will return.

> 
> DDD correctly emulated by HHH1 correctly determines that
> the call from the emulated DDD to HHH0 DOES RETURN.
> 
> 
> 
> 

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

#335843

On 6/22/2024 10:29 AM, Richard Damon wrote:
> On 6/22/24 11:16 AM, olcott wrote:
>> On 6/22/2024 9:42 AM, Richard Damon wrote:
>>> On 6/22/24 10:31 AM, olcott wrote:
>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>
>>>> To understand this analysis requires a sufficient knowledge of
>>>> the C programming language and what an x86 emulator does. HHH0
>>>> and HHH1 have this criteria as their algorithm:
>>>
>>> Which you just showed you don't have, since on comp.lang.c++ you 
>>> thought that
>>>
>>> x *= ++f * ++f;
>>>
>>> had defined behavior for primative types for f.
>>>
>>>>
>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>    If simulating halt decider H correctly simulates its input D
>>>>    until H correctly determines that its simulated D would never
>>>>    stop running unless aborted then
>>>>
>>>>    H can abort its simulation of D and correctly report that D
>>>>    specifies a non-halting sequence of configurations.
>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>> Which used the definition of "Correct Simulation" to mean a 
>>> simulation that produces the EXACT results of the direct execution of 
>>> the machine being simulated, which requires a simulation that will 
>>> not "abort" its simulation, EVER (except by reaching a final state).
>>>
>>
>> I have had enough of your deception trying to get away
>> with denying the semantics of the x86 programming language.
>> I really hope that you don't get condemned to Hell over this.
> 
> And what in the actual detail of the x86 programming language says 
> something diffferent than what I say?
> 
> I think YOU are the one in danger, as you LIE about what the x86 
> assembly code says,
> 
>>
>>> You Deciders do not do this, nor do they do this about an actual 
>>> Correct Simulation per that definition of the input, so they can not 
>>> use the second clause.
>>>
>>>>
>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>  > I don't think that is the shell game. PO really /has/ an H
>>>>  > (it's trivial to do for this one case) that correctly determines
>>>>  > that P(P) *would* never stop running *unless* aborted.
>>>>  >
>>>>
>>>> Ben only agrees that the criteria is met for the input. He
>>>> does not agree that the criteria has been meet for non-inputs.
>>>
>>> Ben only agrees that H correctly decides the exact criteria that you 
>>> state, that no H can "correctly simuate" (per YOUR definition) the 
>>> input to a final state. 
>>
>> And you happily deny the verified facts at the possible cost
>> of damnation in Hell.
>>
>>> Thus, he is agreeing that you H is a POOP decider, for this input, 
>>> but not that it is a HALTING decider for this input, since its 
>>> criteria is not the Halting Criteria.
>>>
>>>>
>>>> Computable functions are the formalized analogue of the intuitive
>>>> notion of algorithms, in the sense that a function is computable if 
>>>> there exists an algorithm that can do the job of the function, i.e. 
>>>> *given an input of the function domain*
>>>> *it can return the corresponding output*
>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>
>>>> *That seems to say that non-inputs do not count*
>>>
>>> But we aren't talking about "Non-Inputs", 
>>
>> The D(D) that calls H(D,D) such that this call returns has
>> provably different behavior than D correctly simulated by H
>> is measured by the actual semantics of the x86 programming
>> language.
>>
>> How the Hell does anyone feel that they can get away with
>> flatly contradicting the semantics of the x86 programming
>> language?
>>
>> We are a herd and our first duty it to follow the herd
>> even if the herd leaps off a cliff.
>>
>>> and in fact, YOUR arguement needs to look at the non-inputs, as it 
>>> allows the input to change when you argue about other deciders.
>>>
>> int sum(int x, int y){ return x + y; }
>> In other words sum(3,4) must consider the sum of 5 + 6?
>>
>>> The input is the finite string.
>>>
>>> The MEANING of that finite string is defined by the PROBLEM.
>>
>> LIAR. You know that the meaning of the finite string
>> is defined by the semantics of the x86 language.
> 
> Right, by what the DIRECT EXECUTION of that set of instruction will do.
> 
> Which means, for your input, in needs the instuctions of the decider it 
> calls.
> 
>>
>> I might start wishing that you get a tiny taste of Hell
>> to set you on the correct path.
>>
>> As Christ said as ye judge ye shall be judged so I do
>> wish the same thing upon myself. If I am on the wrong
>> path then I sincerely wish for the minimum adversity
>> required to definitely set me on the right path.
>>
>>>  The decider gets to define the encoding, but not the 
>>> meaning/behavior of the encoded items.
>>>
>>
>> When the x86 language is specified then the decider
>> has zero leeway in this.
> 
> So, what in the x86 language shows what you claim?
> 
>>
>>> Halting DEFINES the meaning/behavior to be that of the directly run 
>>> program represented by the input.
>>
>> That makes it contradict one of its own axioms, thus
>> conclusively proving that it is incorrect:
>>
>> Computable functions are the formalized analogue of the
>> intuitive notion of algorithms, in the sense that a
>> function is computable if there exists an algorithm
>> that can do the job of the function, i.e.
>> *given an input of the function domain it*
>> *can return the corresponding output*
>> https://en.wikipedia.org/wiki/Computable_function
> 
> Who says Halting is a Computable Function?
> 

That is the wrong question.
Halting is only computed from inputs to HHH0 that include
the call from DDD correctly emulated by HHH0 to HHH0(DDD)
such that this call DOES NOT RETURN.

> THAT is part of your problem.
> 
> The question actually is, "IS Halting Computable?"
> 
>>
>>>>
>>>> *Here is the verified facts that everyone denies*
>>>> *Here is the verified facts that everyone denies*
>>>> *Here is the verified facts that everyone denies*
>>>> *Here is the verified facts that everyone denies*
>>>>
>>>> void DDD()
>>>> {
>>>>    HHH0(DDD);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", HHH0(DDD));
>>>>    Output("Input_Halts = ", HHH1(DDD));
>>>> }
>>>>
>>>> It is a verified fact that the behavior that finite string DDD
>>>> presents to HH0 is that when DDD correctly emulated by HH0
>>>> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
>>>>
>>>> It is a verified fact that the behavior that finite string DDD
>>>> presents to HH1 is that when DDD correctly emulated by HH1
>>>> calls HH0(DDD) that *THIS CALL DOES RETURN*
>>>>
>>>>
>>>
>>>
>>> The problem is that the "behavior" that the finite string DDD 
>>> presents to HH0, is DEFINED by the problem. 
>>
>> LIAR. It is defined by the semantics of the x86 language.
> 
> Right, as the results of the direfdt execution of the input, which means 
> the input needs to contain ALL the instructions that will be executed.
> 

*WRONG*
Halting is only computed from inputs to HHH0 that include
the call from DDD correctly emulated by HHH0 to HHH0(DDD)
such that this call DOES NOT RETURN.

>>
>>> And if that problem is the Halting Problem, that behavior is the 
>>> behavior of the machine the input represents. If HH0 treats the input 
>>> as having a different behavior, then HH0 just isn't a Halting 
>>> Decider, but something else.
>>>
>>> If HH0 is supposed to be a Halting decider, but uses a method that 
>>> makes it see something other than that behavior, then it is just an 
>>> incorrect Halting Decider, and its algorithm just creates an 
>>> incorrect recreation of the property of the input it is supposed to 
>>> be working on.
>>>
>>>
>>> A bit of a side note, the actual "Input" to HH0, is a pointer to 
>>> memory, and as such it passes a reference to ALL of memory 
>>> considering the starting point to be that address, so your "Input" 
>>> isn't actually the few bytes of DDD, but ALL of memory and a starting 
>>> point. If you actually mean that the input is just those few bytes 
>>> pointed to by the address, then the input is improperly formed and is 
>>> NOT a proper representation of the input machine, becuase it is 
>>> incomplete.
>>>
>>> The fact you don't understand this, seems to imply you are lacking 
>>> the basic knowledge to be talking about this sort of thing.
>>>
>>
>> The input to HHH0(DDD) includes itself.
>> The input to HHH1(DDD) DOES NOT include itself.
> 
> So?
> 

Halting is only computed from inputs to HHH0 that include
the call from DDD correctly emulated by HHH0 to HHH0(DDD)
such that this call DOES NOT RETURN.

>>
>> It is stipulated that correct emulation is defined by the
>> semantics of the x86 programming language and nothing else.
> 
> Right, so HHH0 needs to determine what the ACTUAL BEHAVIOR of its input 
> is to be a Halt Decider, and that means it needs to figure out what it 
> will itself do.
> 
>>
>> DDD correctly emulated by HHH0 correctly determines that
>> the call from the emulated DDD to HHH0 DOES NOT RETURN.
> 
> Nope, It just determins that it doesn't know if the call will return.
> 

*WHY LIE ABOUT THIS* ???
*We can see the repeating state and HHH0 sees this too*
Begin Local Halt Decider Simulation   Execution Trace Stored at:15e2fa
[00002172][0015e2ea][0015e2ee] 55         push ebp      ; begin DDD
[00002173][0015e2ea][0015e2ee] 8bec       mov ebp,esp
[00002175][0015e2e6][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][0015e2e2][0000217f] e853f4ffff call 000015d2 ; call HHH0
New slave_stack at:198d1a
[00002172][001a8d12][001a8d16] 55         push ebp      ; begin DDD
[00002173][001a8d12][001a8d16] 8bec       mov ebp,esp
[00002175][001a8d0e][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001a8d0a][0000217f] e853f4ffff call 000015d2 ; call HHH0
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above does not have a separate recursive simulation detection
it simply uses its infinite recursion criteria:

if (current->Simplified_Opcode == CALL)
  if (current->Simplified_Opcode ==
      traced->Simplified_Opcode)                     // CALL
   if (current->Address == traced->Address)          // from same address
    if (current->Decode_Target ==
        traced->Decode_Target)                       // to Same Function
     if (Count_Conditional_Branch_Instructions == 0) // no escape
     {
       OutputString((char*)"Local Halt Decider: "
       "Infinite Recursion Detected Simulation Stopped\n\n");
       return 1;
     }

void Infinite_Recursion()
{
   Infinite_Recursion();
}

int main()
{
   Output("Input_Halts = ", HHH0(Infinite_Recursion));
}

_Infinite_Recursion()
[00002152] 55               push ebp
[00002153] 8bec             mov ebp,esp
[00002155] e8f8ffffff       call 00002152
[0000215a] 5d               pop ebp
[0000215b] c3               ret
Size in bytes:(0010) [0000215b]

Begin Local Halt Decider Simulation   Execution Trace Stored at:1138d2
[00002152][001138c2][001138c6] 55               push ebp
[00002153][001138c2][001138c6] 8bec             mov ebp,esp
[00002155][001138be][0000215a] e8f8ffffff       call 00002152
[00002152][001138ba][001138c2] 55               push ebp
[00002153][001138ba][001138c2] 8bec             mov ebp,esp
[00002155][001138b6][0000215a] e8f8ffffff       call 00002152
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

>>
>> DDD correctly emulated by HHH1 correctly determines that
>> the call from the emulated DDD to HHH0 DOES RETURN.
>>
>>
>>
>>
> 

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

#335845

On 6/22/24 12:12 PM, olcott wrote:
> On 6/22/2024 10:29 AM, Richard Damon wrote:
>> On 6/22/24 11:16 AM, olcott wrote:
>>> On 6/22/2024 9:42 AM, Richard Damon wrote:
>>>> On 6/22/24 10:31 AM, olcott wrote:
>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
>>>>>
>>>>> To understand this analysis requires a sufficient knowledge of
>>>>> the C programming language and what an x86 emulator does. HHH0
>>>>> and HHH1 have this criteria as their algorithm:
>>>>
>>>> Which you just showed you don't have, since on comp.lang.c++ you 
>>>> thought that
>>>>
>>>> x *= ++f * ++f;
>>>>
>>>> had defined behavior for primative types for f.
>>>>
>>>>>
>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>>    If simulating halt decider H correctly simulates its input D
>>>>>    until H correctly determines that its simulated D would never
>>>>>    stop running unless aborted then
>>>>>
>>>>>    H can abort its simulation of D and correctly report that D
>>>>>    specifies a non-halting sequence of configurations.
>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>>
>>>> Which used the definition of "Correct Simulation" to mean a 
>>>> simulation that produces the EXACT results of the direct execution 
>>>> of the machine being simulated, which requires a simulation that 
>>>> will not "abort" its simulation, EVER (except by reaching a final 
>>>> state).
>>>>
>>>
>>> I have had enough of your deception trying to get away
>>> with denying the semantics of the x86 programming language.
>>> I really hope that you don't get condemned to Hell over this.
>>
>> And what in the actual detail of the x86 programming language says 
>> something diffferent than what I say?
>>
>> I think YOU are the one in danger, as you LIE about what the x86 
>> assembly code says,
>>
>>>
>>>> You Deciders do not do this, nor do they do this about an actual 
>>>> Correct Simulation per that definition of the input, so they can not 
>>>> use the second clause.
>>>>
>>>>>
>>>>> On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
>>>>>  > I don't think that is the shell game. PO really /has/ an H
>>>>>  > (it's trivial to do for this one case) that correctly determines
>>>>>  > that P(P) *would* never stop running *unless* aborted.
>>>>>  >
>>>>>
>>>>> Ben only agrees that the criteria is met for the input. He
>>>>> does not agree that the criteria has been meet for non-inputs.
>>>>
>>>> Ben only agrees that H correctly decides the exact criteria that you 
>>>> state, that no H can "correctly simuate" (per YOUR definition) the 
>>>> input to a final state. 
>>>
>>> And you happily deny the verified facts at the possible cost
>>> of damnation in Hell.
>>>
>>>> Thus, he is agreeing that you H is a POOP decider, for this input, 
>>>> but not that it is a HALTING decider for this input, since its 
>>>> criteria is not the Halting Criteria.
>>>>
>>>>>
>>>>> Computable functions are the formalized analogue of the intuitive
>>>>> notion of algorithms, in the sense that a function is computable if 
>>>>> there exists an algorithm that can do the job of the function, i.e. 
>>>>> *given an input of the function domain*
>>>>> *it can return the corresponding output*
>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>
>>>>> *That seems to say that non-inputs do not count*
>>>>
>>>> But we aren't talking about "Non-Inputs", 
>>>
>>> The D(D) that calls H(D,D) such that this call returns has
>>> provably different behavior than D correctly simulated by H
>>> is measured by the actual semantics of the x86 programming
>>> language.
>>>
>>> How the Hell does anyone feel that they can get away with
>>> flatly contradicting the semantics of the x86 programming
>>> language?
>>>
>>> We are a herd and our first duty it to follow the herd
>>> even if the herd leaps off a cliff.
>>>
>>>> and in fact, YOUR arguement needs to look at the non-inputs, as it 
>>>> allows the input to change when you argue about other deciders.
>>>>
>>> int sum(int x, int y){ return x + y; }
>>> In other words sum(3,4) must consider the sum of 5 + 6?
>>>
>>>> The input is the finite string.
>>>>
>>>> The MEANING of that finite string is defined by the PROBLEM.
>>>
>>> LIAR. You know that the meaning of the finite string
>>> is defined by the semantics of the x86 language.
>>
>> Right, by what the DIRECT EXECUTION of that set of instruction will do.
>>
>> Which means, for your input, in needs the instuctions of the decider 
>> it calls.
>>
>>>
>>> I might start wishing that you get a tiny taste of Hell
>>> to set you on the correct path.
>>>
>>> As Christ said as ye judge ye shall be judged so I do
>>> wish the same thing upon myself. If I am on the wrong
>>> path then I sincerely wish for the minimum adversity
>>> required to definitely set me on the right path.
>>>
>>>>  The decider gets to define the encoding, but not the 
>>>> meaning/behavior of the encoded items.
>>>>
>>>
>>> When the x86 language is specified then the decider
>>> has zero leeway in this.
>>
>> So, what in the x86 language shows what you claim?
>>
>>>
>>>> Halting DEFINES the meaning/behavior to be that of the directly run 
>>>> program represented by the input.
>>>
>>> That makes it contradict one of its own axioms, thus
>>> conclusively proving that it is incorrect:
>>>
>>> Computable functions are the formalized analogue of the
>>> intuitive notion of algorithms, in the sense that a
>>> function is computable if there exists an algorithm
>>> that can do the job of the function, i.e.
>>> *given an input of the function domain it*
>>> *can return the corresponding output*
>>> https://en.wikipedia.org/wiki/Computable_function
>>
>> Who says Halting is a Computable Function?
>>
> 
> That is the wrong question.

No, it is exactly the right question.

You can't claim the Definition of Halting is in contradiction to the 
definition of a Computable Function unless you say that Halting needs to 
be Computable.

Since it isn't defined to be that, it doesn't need to be compatable with it.

> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.

HALTING, as properly defined is NOT comptable.

You are stuck in a circular argument where you are trying to define it 
to be computable by redefining what it is, which means you aren't 
actually talking about Halting.

> 
>> THAT is part of your problem.
>>
>> The question actually is, "IS Halting Computable?"
>>
>>>
>>>>>
>>>>> *Here is the verified facts that everyone denies*
>>>>> *Here is the verified facts that everyone denies*
>>>>> *Here is the verified facts that everyone denies*
>>>>> *Here is the verified facts that everyone denies*
>>>>>
>>>>> void DDD()
>>>>> {
>>>>>    HHH0(DDD);
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", HHH0(DDD));
>>>>>    Output("Input_Halts = ", HHH1(DDD));
>>>>> }
>>>>>
>>>>> It is a verified fact that the behavior that finite string DDD
>>>>> presents to HH0 is that when DDD correctly emulated by HH0
>>>>> calls HH0(DDD) that *THIS CALL DOES NOT RETURN*
>>>>>
>>>>> It is a verified fact that the behavior that finite string DDD
>>>>> presents to HH1 is that when DDD correctly emulated by HH1
>>>>> calls HH0(DDD) that *THIS CALL DOES RETURN*
>>>>>
>>>>>
>>>>
>>>>
>>>> The problem is that the "behavior" that the finite string DDD 
>>>> presents to HH0, is DEFINED by the problem. 
>>>
>>> LIAR. It is defined by the semantics of the x86 language.
>>
>> Right, as the results of the direfdt execution of the input, which 
>> means the input needs to contain ALL the instructions that will be 
>> executed.
>>
> 
> *WRONG*
> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.

Halting is NOT computable. PERIOD.

Your "Computable Function" is not Halting. PERIOD.

You are just being caught in your own lies.

> 
>>>
>>>> And if that problem is the Halting Problem, that behavior is the 
>>>> behavior of the machine the input represents. If HH0 treats the 
>>>> input as having a different behavior, then HH0 just isn't a Halting 
>>>> Decider, but something else.
>>>>
>>>> If HH0 is supposed to be a Halting decider, but uses a method that 
>>>> makes it see something other than that behavior, then it is just an 
>>>> incorrect Halting Decider, and its algorithm just creates an 
>>>> incorrect recreation of the property of the input it is supposed to 
>>>> be working on.
>>>>
>>>>
>>>> A bit of a side note, the actual "Input" to HH0, is a pointer to 
>>>> memory, and as such it passes a reference to ALL of memory 
>>>> considering the starting point to be that address, so your "Input" 
>>>> isn't actually the few bytes of DDD, but ALL of memory and a 
>>>> starting point. If you actually mean that the input is just those 
>>>> few bytes pointed to by the address, then the input is improperly 
>>>> formed and is NOT a proper representation of the input machine, 
>>>> becuase it is incomplete.
>>>>
>>>> The fact you don't understand this, seems to imply you are lacking 
>>>> the basic knowledge to be talking about this sort of thing.
>>>>
>>>
>>> The input to HHH0(DDD) includes itself.
>>> The input to HHH1(DDD) DOES NOT include itself.
>>
>> So?
>>
> 
> Halting is only computed from inputs to HHH0 that include
> the call from DDD correctly emulated by HHH0 to HHH0(DDD)
> such that this call DOES NOT RETURN.

Halting is NOT computable. PERIOD.

Your "Computable Function" is not Halting. PERIOD.

You are just being caught in your own lies.

> 
>>>
>>> It is stipulated that correct emulation is defined by the
>>> semantics of the x86 programming language and nothing else.
>>
>> Right, so HHH0 needs to determine what the ACTUAL BEHAVIOR of its 
>> input is to be a Halt Decider, and that means it needs to figure out 
>> what it will itself do.
>>
>>>
>>> DDD correctly emulated by HHH0 correctly determines that
>>> the call from the emulated DDD to HHH0 DOES NOT RETURN.
>>
>> Nope, It just determins that it doesn't know if the call will return.
>>
> 
> *WHY LIE ABOUT THIS* ???
> *We can see the repeating state and HHH0 sees this too*
> Begin Local Halt Decider Simulation   Execution Trace Stored at:15e2fa
> [00002172][0015e2ea][0015e2ee] 55         push ebp      ; begin DDD
> [00002173][0015e2ea][0015e2ee] 8bec       mov ebp,esp
> [00002175][0015e2e6][00002172] 6872210000 push 00002172 ; push DDD
> [0000217a][0015e2e2][0000217f] e853f4ffff call 000015d2 ; call HHH0

AND RIGHT HERE YOU VIOLATED YOUR DEFINITION OF "CORRECT SIMUATION"

Please show the reference in a x86 reference manual that says that this 
is what the call 0000015d2 does at the CPU LEVEL.

This is one of your CORE LIES.

> New slave_stack at:198d1a
> [00002172][001a8d12][001a8d16] 55         push ebp      ; begin DDD
> [00002173][001a8d12][001a8d16] 8bec       mov ebp,esp
> [00002175][001a8d0e][00002172] 6872210000 push 00002172 ; push DDD
> [0000217a][001a8d0a][0000217f] e853f4ffff call 000015d2 ; call HHH0
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> 
> The above does not have a separate recursive simulation detection
> it simply uses its infinite recursion criteria:

And isn't based on the CORRECT x86 SIMULATION of the input, so doesn't 
meet your criteria.

Showing you are just a pathetic liar.

Proves based on LIES are just LIES.

> 
> if (current->Simplified_Opcode == CALL)
>   if (current->Simplified_Opcode ==
>       traced->Simplified_Opcode)                     // CALL
>    if (current->Address == traced->Address)          // from same address
>     if (current->Decode_Target ==
>         traced->Decode_Target)                       // to Same Function
>      if (Count_Conditional_Branch_Instructions == 0) // no escape
>      {
>        OutputString((char*)"Local Halt Decider: "
>        "Infinite Recursion Detected Simulation Stopped\n\n");
>        return 1;
>      }
> 
> void Infinite_Recursion()
> {
>    Infinite_Recursion();
> }
> 
> int main()
> {
>    Output("Input_Halts = ", HHH0(Infinite_Recursion));
> }
> 
> _Infinite_Recursion()
> [00002152] 55               push ebp
> [00002153] 8bec             mov ebp,esp
> [00002155] e8f8ffffff       call 00002152
> [0000215a] 5d               pop ebp
> [0000215b] c3               ret
> Size in bytes:(0010) [0000215b]
> 
> Begin Local Halt Decider Simulation   Execution Trace Stored at:1138d2
> [00002152][001138c2][001138c6] 55               push ebp
> [00002153][001138c2][001138c6] 8bec             mov ebp,esp
> [00002155][001138be][0000215a] e8f8ffffff       call 00002152
> [00002152][001138ba][001138c2] 55               push ebp
> [00002153][001138ba][001138c2] 8bec             mov ebp,esp
> [00002155][001138b6][0000215a] e8f8ffffff       call 00002152
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> 
>>>
>>> DDD correctly emulated by HHH1 correctly determines that
>>> the call from the emulated DDD to HHH0 DOES RETURN.
>>>
>>>
>>>
>>>
>>
> 

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

#335842

Am Sat, 22 Jun 2024 10:16:18 -0500 schrieb olcott:
> On 6/22/2024 9:42 AM, Richard Damon wrote:
>> On 6/22/24 10:31 AM, olcott wrote:

> The D(D) that calls H(D,D) such that this call returns has provably
> different behavior than D correctly simulated by H is measured by the
> actual semantics of the x86 programming language.
[s/is/as?]
No, H of course needs to simulate the call to itself like any other.
x86 has nothing to do with that. A correct simulation has identical
behaviour to the real thing. Why should H simulate something that is
not its input?

>> The input is the finite string.
>> The MEANING of that finite string is defined by the PROBLEM.
Yes, DDD is coded to call the HHH0 deciding on it.
> LIAR. You know that the meaning of the finite string is defined by the
> semantics of the x86 language.

> As Christ said as ye judge ye shall be judged so I do wish the same
> thing upon myself. If I am on the wrong path then I sincerely wish for
> the minimum adversity required to definitely set me on the right path.
Thanks for the permission. Your minimum seems to be quite high.
Not sure I want to fulfill your wishes.

>> Halting DEFINES the meaning/behavior to be that of the directly run
>> program represented by the input.
> That makes it contradict one of its own axioms, thus conclusively
> proving that it is incorrect:
WTF? What contradiction? How can "halting" even be incorrect?

>> The problem is that the "behavior" that the finite string DDD presents
>> to HH0, is DEFINED by the problem.
> LIAR. It is defined by the semantics of the x86 language.
This is just silly. The x86 code of DDD is defined to call HH0.

>> And if that problem is the Halting Problem, that behavior is the
>> behavior of the machine the input represents. If HH0 treats the input
>> as having a different behavior, then HH0 just isn't a Halting Decider,
>> but something else.
>> If HH0 is supposed to be a Halting decider, but uses a method that
>> makes it see something other than that behavior, then it is just an
>> incorrect Halting Decider, and its algorithm just creates an incorrect
>> recreation of the property of the input it is supposed to be working
>> on.
Exactly. Like you say, it must follow the semantics of its input.

> The input to HHH0(DDD) includes itself.
> The input to HHH1(DDD) DOES NOT include itself.
Yes, both include HHH0. The second case is boring.

> DDD correctly emulated by HHH0 correctly determines that the call from
> the emulated DDD to HHH0 DOES NOT RETURN.
*incorrectly
> DDD correctly emulated by HHH1 correctly determines that the call from
> the emulated DDD to HHH0 DOES RETURN.

-- 
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik 
sind sie vollkommen nutzlos. --Wolfgang Mückenheim

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

#335844

On 6/22/2024 11:03 AM, joes wrote:
> Am Sat, 22 Jun 2024 10:16:18 -0500 schrieb olcott:
>> On 6/22/2024 9:42 AM, Richard Damon wrote:
>>> On 6/22/24 10:31 AM, olcott wrote:
> 
>> The D(D) that calls H(D,D) such that this call returns has provably
>> different behavior than D correctly simulated by H is measured by the
>> actual semantics of the x86 programming language.
> [s/is/as?]
> No, H of course needs to simulate the call to itself like any other.
> x86 has nothing to do with that. A correct simulation has identical
> behaviour to the real thing. Why should H simulate something that is
> not its input?
> 
>>> The input is the finite string.
>>> The MEANING of that finite string is defined by the PROBLEM.
> Yes, DDD is coded to call the HHH0 deciding on it.
>> LIAR. You know that the meaning of the finite string is defined by the
>> semantics of the x86 language.
> 
>> As Christ said as ye judge ye shall be judged so I do wish the same
>> thing upon myself. If I am on the wrong path then I sincerely wish for
>> the minimum adversity required to definitely set me on the right path.
> Thanks for the permission. Your minimum seems to be quite high.
> Not sure I want to fulfill your wishes.
> 
>>> Halting DEFINES the meaning/behavior to be that of the directly run
>>> program represented by the input.
>> That makes it contradict one of its own axioms, thus conclusively
>> proving that it is incorrect:
> WTF? What contradiction? How can "halting" even be incorrect?
> 
>>> The problem is that the "behavior" that the finite string DDD presents
>>> to HH0, is DEFINED by the problem.
>> LIAR. It is defined by the semantics of the x86 language.
> This is just silly. The x86 code of DDD is defined to call HH0.
> 
>>> And if that problem is the Halting Problem, that behavior is the
>>> behavior of the machine the input represents. If HH0 treats the input
>>> as having a different behavior, then HH0 just isn't a Halting Decider,
>>> but something else.
>>> If HH0 is supposed to be a Halting decider, but uses a method that
>>> makes it see something other than that behavior, then it is just an
>>> incorrect Halting Decider, and its algorithm just creates an incorrect
>>> recreation of the property of the input it is supposed to be working
>>> on.
> Exactly. Like you say, it must follow the semantics of its input.
> 
>> The input to HHH0(DDD) includes itself.
>> The input to HHH1(DDD) DOES NOT include itself.
> Yes, both include HHH0. The second case is boring.
> 
>> DDD correctly emulated by HHH0 correctly determines that the call from
>> the emulated DDD to HHH0 DOES NOT RETURN.
> *incorrectly
>> DDD correctly emulated by HHH1 correctly determines that the call from
>> the emulated DDD to HHH0 DOES RETURN.
> 

void DDD()
{
   HHH0(DDD);
}

The input to HHH0(DDD) includes itself.
The input to HHH1(DDD) DOES NOT include itself.

It is stipulated that correct emulation is defined by the
semantics of the x86 programming language and nothing else.

DDD correctly emulated by HHH0 correctly determines that
the call from the emulated DDD to HHH0 DOES NOT RETURN.

DDD correctly emulated by HHH1 correctly determines that
the call from the emulated DDD to HHH0 DOES RETURN.

The fact that DDD calls HHH0(DDD) and does not call HHH1(DDD)
changes the behavior of DDD correctly emulated by HHH0 relative
to DDD correctly emulated by HHH1.

_DDD()
[00002172] 55               push ebp
[00002173] 8bec             mov ebp,esp
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH0
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]



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

#335846

On 6/22/24 12:18 PM, olcott wrote:
> On 6/22/2024 11:03 AM, joes wrote:
>> Am Sat, 22 Jun 2024 10:16:18 -0500 schrieb olcott:
>>> On 6/22/2024 9:42 AM, Richard Damon wrote:
>>>> On 6/22/24 10:31 AM, olcott wrote:
>>
>>> The D(D) that calls H(D,D) such that this call returns has provably
>>> different behavior than D correctly simulated by H is measured by the
>>> actual semantics of the x86 programming language.
>> [s/is/as?]
>> No, H of course needs to simulate the call to itself like any other.
>> x86 has nothing to do with that. A correct simulation has identical
>> behaviour to the real thing. Why should H simulate something that is
>> not its input?
>>
>>>> The input is the finite string.
>>>> The MEANING of that finite string is defined by the PROBLEM.
>> Yes, DDD is coded to call the HHH0 deciding on it.
>>> LIAR. You know that the meaning of the finite string is defined by the
>>> semantics of the x86 language.
>>
>>> As Christ said as ye judge ye shall be judged so I do wish the same
>>> thing upon myself. If I am on the wrong path then I sincerely wish for
>>> the minimum adversity required to definitely set me on the right path.
>> Thanks for the permission. Your minimum seems to be quite high.
>> Not sure I want to fulfill your wishes.
>>
>>>> Halting DEFINES the meaning/behavior to be that of the directly run
>>>> program represented by the input.
>>> That makes it contradict one of its own axioms, thus conclusively
>>> proving that it is incorrect:
>> WTF? What contradiction? How can "halting" even be incorrect?
>>
>>>> The problem is that the "behavior" that the finite string DDD presents
>>>> to HH0, is DEFINED by the problem.
>>> LIAR. It is defined by the semantics of the x86 language.
>> This is just silly. The x86 code of DDD is defined to call HH0.
>>
>>>> And if that problem is the Halting Problem, that behavior is the
>>>> behavior of the machine the input represents. If HH0 treats the input
>>>> as having a different behavior, then HH0 just isn't a Halting Decider,
>>>> but something else.
>>>> If HH0 is supposed to be a Halting decider, but uses a method that
>>>> makes it see something other than that behavior, then it is just an
>>>> incorrect Halting Decider, and its algorithm just creates an incorrect
>>>> recreation of the property of the input it is supposed to be working
>>>> on.
>> Exactly. Like you say, it must follow the semantics of its input.
>>
>>> The input to HHH0(DDD) includes itself.
>>> The input to HHH1(DDD) DOES NOT include itself.
>> Yes, both include HHH0. The second case is boring.
>>
>>> DDD correctly emulated by HHH0 correctly determines that the call from
>>> the emulated DDD to HHH0 DOES NOT RETURN.
>> *incorrectly
>>> DDD correctly emulated by HHH1 correctly determines that the call from
>>> the emulated DDD to HHH0 DOES RETURN.
>>
> 
> void DDD()
> {
>    HHH0(DDD);
> }
> 
> The input to HHH0(DDD) includes itself.
> The input to HHH1(DDD) DOES NOT include itself.
> 
> It is stipulated that correct emulation is defined by the
> semantics of the x86 programming language and nothing else.

And thus, your emulation traces show that your "Simulating Halt 
Deciders" do not do a "Correct Simulation" as the ONLY correct 
simulation of the call instruction is the simulitation of the 
instructions of the routine called, which is NOT what you show.

So, YOU FIL.

> 
> DDD correctly emulated by HHH0 correctly determines that
> the call from the emulated DDD to HHH0 DOES NOT RETURN.

But doesn't "Correctly Emulate" the input, so it claim is just invalid.

> 
> DDD correctly emulated by HHH1 correctly determines that
> the call from the emulated DDD to HHH0 DOES RETURN.
> 
> The fact that DDD calls HHH0(DDD) and does not call HHH1(DDD)
> changes the behavior of DDD correctly emulated by HHH0 relative
> to DDD correctly emulated by HHH1.

Nope.

The correct emulation of the exact same code will always be the same.

What instruction was correctly emulated, be the intel x86 instruction 
specification that differed between the two emulations.

They say EXACTLY the same instruction sequence,

Your inability to answer this quesiton just shows that you are nothing 
but a pathetic ignorant pathological lying idiot.

> 
> _DDD()
> [00002172] 55               push ebp
> [00002173] 8bec             mov ebp,esp
> [00002175] 6872210000       push 00002172 ; push DDD
> [0000217a] e853f4ffff       call 000015d2 ; call HHH0
> [0000217f] 83c404           add esp,+04
> [00002182] 5d               pop ebp
> [00002183] c3               ret
> Size in bytes:(0018) [00002183]
> 
> 
> 

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

#335847

On 6/22/2024 12:13 PM, Richard Damon wrote:
> On 6/22/24 12:18 PM, olcott wrote:
>>
>> void DDD()
>> {
>>    HHH0(DDD);
>> }
>>
>> The input to HHH0(DDD) includes itself.
>> The input to HHH1(DDD) DOES NOT include itself.
>>
>> It is stipulated that correct emulation is defined by the
>> semantics of the x86 programming language and nothing else.
> 
> And thus, your emulation traces show that your "Simulating Halt 
> Deciders" do not do a "Correct Simulation" 

Apparently your ADD preventing you from paying close attention
to ALL of my words.

*Function names adapted to correspond to my updated paper*

void DDD()
{
   H0(DDD);
}

*When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*

*When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*

*When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*

*When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*

*When we stipulate that the only measure of a correct*
*emulation is the semantics of the x86 programming language*

then we see that when DDD is correctly emulated by H0 that
its call to H0(DDD) cannot possibly return.

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().


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

#335848

On 6/22/24 1:29 PM, olcott wrote:
> On 6/22/2024 12:13 PM, Richard Damon wrote:
>> On 6/22/24 12:18 PM, olcott wrote:
>>>
>>> void DDD()
>>> {
>>>    HHH0(DDD);
>>> }
>>>
>>> The input to HHH0(DDD) includes itself.
>>> The input to HHH1(DDD) DOES NOT include itself.
>>>
>>> It is stipulated that correct emulation is defined by the
>>> semantics of the x86 programming language and nothing else.
>>
>> And thus, your emulation traces show that your "Simulating Halt 
>> Deciders" do not do a "Correct Simulation" 
> 
> Apparently your ADD preventing you from paying close attention
> to ALL of my words.
> 
> *Function names adapted to correspond to my updated paper*
> 
> void DDD()
> {
>    H0(DDD);
> }
> 
> *When we stipulate that the only measure of a correct*
> *emulation is the semantics of the x86 programming language*
> 
> *When we stipulate that the only measure of a correct*
> *emulation is the semantics of the x86 programming language*
> 
> *When we stipulate that the only measure of a correct*
> *emulation is the semantics of the x86 programming language*
> 
> *When we stipulate that the only measure of a correct*
> *emulation is the semantics of the x86 programming language*
> 
> *When we stipulate that the only measure of a correct*
> *emulation is the semantics of the x86 programming language*
> 
> then we see that when DDD is correctly emulated by H0 that
> its call to H0(DDD) cannot possibly return.

Since your H0 has never demonstrated that is actually DOES the correct 
simulation per your stipulation, you have no grounds to make that claim. 
Maybe you can eventually fix this problem, but until you do, you can't 
call it a verified claim.

If H0 is assumed to actually do that, then we know that the correct 
simulation per your stipulation would show the call instruction, and 
then the instructions of H0, so even though you don't show them below as 
"part" of the input, they must be considered as part of it by reference 
(since the "input" to H0 is just an address in memory, and all of the 
memory is available, the state of all accessed memory is part of the input),

Note, per you stipulation, the ACTUAL behavior of the input, as the 
actual behavior of a complete correct emulation of the input, will show 
that DDD calls HHH(DDD) that will try to emulate the input for some 
time, then give up and return to DDD and halt, thus the correct behavior 
for a Halting Decider is that the input Halts.


You might be able to prove that there is no possible variant to H0 that 
could possible emulate its input (when made to refrence THAT NEW varient 
  of H0) to that final state, which just means that it is impossible for 
any such decider to prove that this form of input built on its self is 
halting, But if all of them do abort their emulation and return (so they 
are a decider) then all those input can be shown to be actually Halting, 
just unprovable by the decider they are built to fool. That doesn't make 
them non-haling, just shows that Halting isn't computable by this method.


> 
> _DDD()
> [00002172] 55               push ebp      ; housekeeping
> [00002173] 8bec             mov ebp,esp   ; housekeeping
> [00002175] 6872210000       push 00002172 ; push DDD
> [0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
> [0000217f] 83c404           add esp,+04
> [00002182] 5d               pop ebp
> [00002183] c3               ret
> Size in bytes:(0018) [00002183]
> 
> When we define H1 as identical to H0 except that DDD does not
> call H1 then we see that when DDD is correctly emulated by H1
> that its call to H0(DDD) does return. This is the same behavior
> as the directly executed DDD().
> 

Nope. If we fix your H0 and H1 to actually show the traces simulated, 
through H0, and actually get H0 to work as described, then we will see 
the two traces to be IDENTICAL up to the point that H0 decides to stop 
its simulation and return.

If you disagree, what instruction, correctly emulated by the two of 
them, creates a differing result to make the traces different, other 
than H0's trace stops.

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

#335850

On 6/22/2024 1:43 PM, Richard Damon wrote:
> On 6/22/24 1:29 PM, olcott wrote:
>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>
>>>> void DDD()
>>>> {
>>>>    HHH0(DDD);
>>>> }
>>>>
>>>> The input to HHH0(DDD) includes itself.
>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>
>>>> It is stipulated that correct emulation is defined by the
>>>> semantics of the x86 programming language and nothing else.
>>>
>>> And thus, your emulation traces show that your "Simulating Halt 
>>> Deciders" do not do a "Correct Simulation" 
>>
>> Apparently your ADD preventing you from paying close attention
>> to ALL of my words.
>>
>> *Function names adapted to correspond to my updated paper*
>>
>> void DDD()
>> {
>>    H0(DDD);
>> }
>>
>> *When we stipulate that the only measure of a correct*
>> *emulation is the semantics of the x86 programming language*
>>
>> *When we stipulate that the only measure of a correct*
>> *emulation is the semantics of the x86 programming language*
>>
>> *When we stipulate that the only measure of a correct*
>> *emulation is the semantics of the x86 programming language*
>>
>> *When we stipulate that the only measure of a correct*
>> *emulation is the semantics of the x86 programming language*
>>
>> *When we stipulate that the only measure of a correct*
>> *emulation is the semantics of the x86 programming language*
>>
>> then we see that when DDD is correctly emulated by H0 that
>> its call to H0(DDD) cannot possibly return.
> 
> Since your H0 has never demonstrated that is actually DOES the correct 
> simulation per your stipulation, 

Liar

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

#335854

On 6/22/24 2:49 PM, olcott wrote:
> On 6/22/2024 1:43 PM, Richard Damon wrote:
>> On 6/22/24 1:29 PM, olcott wrote:
>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>
>>>>> void DDD()
>>>>> {
>>>>>    HHH0(DDD);
>>>>> }
>>>>>
>>>>> The input to HHH0(DDD) includes itself.
>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>
>>>>> It is stipulated that correct emulation is defined by the
>>>>> semantics of the x86 programming language and nothing else.
>>>>
>>>> And thus, your emulation traces show that your "Simulating Halt 
>>>> Deciders" do not do a "Correct Simulation" 
>>>
>>> Apparently your ADD preventing you from paying close attention
>>> to ALL of my words.
>>>
>>> *Function names adapted to correspond to my updated paper*
>>>
>>> void DDD()
>>> {
>>>    H0(DDD);
>>> }
>>>
>>> *When we stipulate that the only measure of a correct*
>>> *emulation is the semantics of the x86 programming language*
>>>
>>> *When we stipulate that the only measure of a correct*
>>> *emulation is the semantics of the x86 programming language*
>>>
>>> *When we stipulate that the only measure of a correct*
>>> *emulation is the semantics of the x86 programming language*
>>>
>>> *When we stipulate that the only measure of a correct*
>>> *emulation is the semantics of the x86 programming language*
>>>
>>> *When we stipulate that the only measure of a correct*
>>> *emulation is the semantics of the x86 programming language*
>>>
>>> then we see that when DDD is correctly emulated by H0 that
>>> its call to H0(DDD) cannot possibly return.
>>
>> Since your H0 has never demonstrated that is actually DOES the correct 
>> simulation per your stipulation, 
> 
> Liar
> 

Then where is it?

Both your long PDF were traces of the main emulator showing the sequence 
from main to the decider and the steps the decider did to do its 
simulation. Really strange that you made the exact same error the second 
time.

NEVER (that I know of) have you posted a simulation where we see the 
decider starting at the first instruction of the input, and then into 
the instructions of the decider, as required by your stipulated definiton.

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

#335856

On 6/22/2024 1:55 PM, Richard Damon wrote:
> On 6/22/24 2:49 PM, olcott wrote:
>> On 6/22/2024 1:43 PM, Richard Damon wrote:
>>> On 6/22/24 1:29 PM, olcott wrote:
>>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>>    HHH0(DDD);
>>>>>> }
>>>>>>
>>>>>> The input to HHH0(DDD) includes itself.
>>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>>
>>>>>> It is stipulated that correct emulation is defined by the
>>>>>> semantics of the x86 programming language and nothing else.
>>>>>
>>>>> And thus, your emulation traces show that your "Simulating Halt 
>>>>> Deciders" do not do a "Correct Simulation" 
>>>>
>>>> Apparently your ADD preventing you from paying close attention
>>>> to ALL of my words.
>>>>
>>>> *Function names adapted to correspond to my updated paper*
>>>>
>>>> void DDD()
>>>> {
>>>>    H0(DDD);
>>>> }
>>>>
>>>> *When we stipulate that the only measure of a correct*
>>>> *emulation is the semantics of the x86 programming language*
>>>>
>>>> *When we stipulate that the only measure of a correct*
>>>> *emulation is the semantics of the x86 programming language*
>>>>
>>>> *When we stipulate that the only measure of a correct*
>>>> *emulation is the semantics of the x86 programming language*
>>>>
>>>> *When we stipulate that the only measure of a correct*
>>>> *emulation is the semantics of the x86 programming language*
>>>>
>>>> *When we stipulate that the only measure of a correct*
>>>> *emulation is the semantics of the x86 programming language*
>>>>
>>>> then we see that when DDD is correctly emulated by H0 that
>>>> its call to H0(DDD) cannot possibly return.
>>>
>>> Since your H0 has never demonstrated that is actually DOES the 
>>> correct simulation per your stipulation, 
>>
>> Liar
>>
> 
> Then where is it?
> 
When we stipulate that the only measure of a correct emulation
is the semantics of the x86 programming language then we see that
when DDD is correctly emulated by H0 that its call to H0(DDD)
cannot possibly return.

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]

When we define H1 as identical to H0 except that DDD does not
call H1 then we see that when DDD is correctly emulated by H1
that its call to H0(DDD) does return. This is the same behavior
as the directly executed DDD().

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

#335858

On 6/22/24 3:03 PM, olcott wrote:
> On 6/22/2024 1:55 PM, Richard Damon wrote:
>> On 6/22/24 2:49 PM, olcott wrote:
>>> On 6/22/2024 1:43 PM, Richard Damon wrote:
>>>> On 6/22/24 1:29 PM, olcott wrote:
>>>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    HHH0(DDD);
>>>>>>> }
>>>>>>>
>>>>>>> The input to HHH0(DDD) includes itself.
>>>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>>>
>>>>>>> It is stipulated that correct emulation is defined by the
>>>>>>> semantics of the x86 programming language and nothing else.
>>>>>>
>>>>>> And thus, your emulation traces show that your "Simulating Halt 
>>>>>> Deciders" do not do a "Correct Simulation" 
>>>>>
>>>>> Apparently your ADD preventing you from paying close attention
>>>>> to ALL of my words.
>>>>>
>>>>> *Function names adapted to correspond to my updated paper*
>>>>>
>>>>> void DDD()
>>>>> {
>>>>>    H0(DDD);
>>>>> }
>>>>>
>>>>> *When we stipulate that the only measure of a correct*
>>>>> *emulation is the semantics of the x86 programming language*
>>>>>
>>>>> *When we stipulate that the only measure of a correct*
>>>>> *emulation is the semantics of the x86 programming language*
>>>>>
>>>>> *When we stipulate that the only measure of a correct*
>>>>> *emulation is the semantics of the x86 programming language*
>>>>>
>>>>> *When we stipulate that the only measure of a correct*
>>>>> *emulation is the semantics of the x86 programming language*
>>>>>
>>>>> *When we stipulate that the only measure of a correct*
>>>>> *emulation is the semantics of the x86 programming language*
>>>>>
>>>>> then we see that when DDD is correctly emulated by H0 that
>>>>> its call to H0(DDD) cannot possibly return.
>>>>
>>>> Since your H0 has never demonstrated that is actually DOES the 
>>>> correct simulation per your stipulation, 
>>>
>>> Liar
>>>
>>
>> Then where is it?
>>
> When we stipulate that the only measure of a correct emulation
> is the semantics of the x86 programming language then we see that
> when DDD is correctly emulated by H0 that its call to H0(DDD)
> cannot possibly return.

But that isn't what H0 should be answering about.

Your definition defines the REPESENTATION of the input, to be x86 code.

The PROPERTY being measured is does the behavior reach a final state 
when the thing being represented is run, or when correctly simulated to 
the final state.

By these, DDD is a HALTING input.

So, the question of can H0 correctly simulate its input to the final 
state is just a strawman.

> 
> _DDD()
> [00002172] 55               push ebp      ; housekeeping
> [00002173] 8bec             mov ebp,esp   ; housekeeping
> [00002175] 6872210000       push 00002172 ; push DDD
> [0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
> [0000217f] 83c404           add esp,+04
> [00002182] 5d               pop ebp
> [00002183] c3               ret
> Size in bytes:(0018) [00002183]
> 
> When we define H1 as identical to H0 except that DDD does not
> call H1 then we see that when DDD is correctly emulated by H1
> that its call to H0(DDD) does return. This is the same behavior
> as the directly executed DDD().
> 

Right, because H1 continues past the point that H0 gave up.

Thus showing that the "Correct Simulation" (unconditionally, and thus 
OBJECTIVELY) of the input shows Halting Behavior.

H0 just INCORRECTLY determined that its input is non-halting due to bad 
logic.

It might be able to say that its input doesn't POOP correctly, but no 
one but you seems to care about that, and you really need to figure out 
how to formally define POOP, as I sort of understand what you are trying 
to say, but it gets sort of messy since it is talking about subjective 
measures.

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

#335860

On 6/22/2024 2:19 PM, Richard Damon wrote:
> On 6/22/24 3:03 PM, olcott wrote:
>> On 6/22/2024 1:55 PM, Richard Damon wrote:
>>> On 6/22/24 2:49 PM, olcott wrote:
>>>> On 6/22/2024 1:43 PM, Richard Damon wrote:
>>>>> On 6/22/24 1:29 PM, olcott wrote:
>>>>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>>    HHH0(DDD);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The input to HHH0(DDD) includes itself.
>>>>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>>>>
>>>>>>>> It is stipulated that correct emulation is defined by the
>>>>>>>> semantics of the x86 programming language and nothing else.
>>>>>>>
>>>>>>> And thus, your emulation traces show that your "Simulating Halt 
>>>>>>> Deciders" do not do a "Correct Simulation" 
>>>>>>
>>>>>> Apparently your ADD preventing you from paying close attention
>>>>>> to ALL of my words.
>>>>>>
>>>>>> *Function names adapted to correspond to my updated paper*
>>>>>>
>>>>>> void DDD()
>>>>>> {
>>>>>>    H0(DDD);
>>>>>> }
>>>>>>
>>>>>> *When we stipulate that the only measure of a correct*
>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>
>>>>>> *When we stipulate that the only measure of a correct*
>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>
>>>>>> *When we stipulate that the only measure of a correct*
>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>
>>>>>> *When we stipulate that the only measure of a correct*
>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>
>>>>>> *When we stipulate that the only measure of a correct*
>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>
>>>>>> then we see that when DDD is correctly emulated by H0 that
>>>>>> its call to H0(DDD) cannot possibly return.
>>>>>
>>>>> Since your H0 has never demonstrated that is actually DOES the 
>>>>> correct simulation per your stipulation, 
>>>>
>>>> Liar
>>>>
>>>
>>> Then where is it?
>>>
>> When we stipulate that the only measure of a correct emulation
>> is the semantics of the x86 programming language then we see that
>> when DDD is correctly emulated by H0 that its call to H0(DDD)
>> cannot possibly return.
> 
> But that isn't what H0 should be answering about.
> 

That you and others lack a sufficient understanding of the nuanced
details of the theory of computation is your mistake and not mine.

The correct measure of the behavior of the actual input is DDD
correctly simulated by H0 according to the definition of the
semantics of the x86 programming language.

That you and others keep referring to the behavior of non-inputs
is flat out stupid. That is not the way that actual computations
actually work.

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

#335861

On 6/22/24 3:35 PM, olcott wrote:
> On 6/22/2024 2:19 PM, Richard Damon wrote:
>> On 6/22/24 3:03 PM, olcott wrote:
>>> On 6/22/2024 1:55 PM, Richard Damon wrote:
>>>> On 6/22/24 2:49 PM, olcott wrote:
>>>>> On 6/22/2024 1:43 PM, Richard Damon wrote:
>>>>>> On 6/22/24 1:29 PM, olcott wrote:
>>>>>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>>>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>>    HHH0(DDD);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The input to HHH0(DDD) includes itself.
>>>>>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>>>>>
>>>>>>>>> It is stipulated that correct emulation is defined by the
>>>>>>>>> semantics of the x86 programming language and nothing else.
>>>>>>>>
>>>>>>>> And thus, your emulation traces show that your "Simulating Halt 
>>>>>>>> Deciders" do not do a "Correct Simulation" 
>>>>>>>
>>>>>>> Apparently your ADD preventing you from paying close attention
>>>>>>> to ALL of my words.
>>>>>>>
>>>>>>> *Function names adapted to correspond to my updated paper*
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    H0(DDD);
>>>>>>> }
>>>>>>>
>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>
>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>
>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>
>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>
>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>
>>>>>>> then we see that when DDD is correctly emulated by H0 that
>>>>>>> its call to H0(DDD) cannot possibly return.
>>>>>>
>>>>>> Since your H0 has never demonstrated that is actually DOES the 
>>>>>> correct simulation per your stipulation, 
>>>>>
>>>>> Liar
>>>>>
>>>>
>>>> Then where is it?
>>>>
>>> When we stipulate that the only measure of a correct emulation
>>> is the semantics of the x86 programming language then we see that
>>> when DDD is correctly emulated by H0 that its call to H0(DDD)
>>> cannot possibly return.
>>
>> But that isn't what H0 should be answering about.
>>
> 
> That you and others lack a sufficient understanding of the nuanced
> details of the theory of computation is your mistake and not mine.

No, it is that you don't have enough honest cells in your body to 
understand that you have to follow the requirements for something to say 
you are doing it.

> 
> The correct measure of the behavior of the actual input is DDD
> correctly simulated by H0 according to the definition of the
> semantics of the x86 programming language.

FRKM WHERE?

That is just YOUR LIE!!!!!

That makes everything you say to be about POOP, and no one wants your POOP.

> 
> That you and others keep referring to the behavior of non-inputs
> is flat out stupid. That is not the way that actual computations
> actually work.
> 

No, it is the actual DEFINED BEHAVIOR of the input. If that isn't the 
input, then you are just LYING about what you are doing.


YOU ARE JUST TOO STUPID TO UNDERSTAND THE MEANING OF THE WORDS YOU PARROT.

SHOW YOUR SOURCE THAT SAYS WHAT YOU CLAIM.

NO RELIABLE SOURCE (and not just from you) AND IT IS JUST A LIE.

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

#335863

On 6/22/2024 2:43 PM, Richard Damon wrote:
> On 6/22/24 3:35 PM, olcott wrote:
>> On 6/22/2024 2:19 PM, Richard Damon wrote:
>>> On 6/22/24 3:03 PM, olcott wrote:
>>>> On 6/22/2024 1:55 PM, Richard Damon wrote:
>>>>> On 6/22/24 2:49 PM, olcott wrote:
>>>>>> On 6/22/2024 1:43 PM, Richard Damon wrote:
>>>>>>> On 6/22/24 1:29 PM, olcott wrote:
>>>>>>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>>>>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>> void DDD()
>>>>>>>>>> {
>>>>>>>>>>    HHH0(DDD);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The input to HHH0(DDD) includes itself.
>>>>>>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>>>>>>
>>>>>>>>>> It is stipulated that correct emulation is defined by the
>>>>>>>>>> semantics of the x86 programming language and nothing else.
>>>>>>>>>
>>>>>>>>> And thus, your emulation traces show that your "Simulating Halt 
>>>>>>>>> Deciders" do not do a "Correct Simulation" 
>>>>>>>>
>>>>>>>> Apparently your ADD preventing you from paying close attention
>>>>>>>> to ALL of my words.
>>>>>>>>
>>>>>>>> *Function names adapted to correspond to my updated paper*
>>>>>>>>
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>>    H0(DDD);
>>>>>>>> }
>>>>>>>>
>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>
>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>
>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>
>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>
>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>
>>>>>>>> then we see that when DDD is correctly emulated by H0 that
>>>>>>>> its call to H0(DDD) cannot possibly return.
>>>>>>>
>>>>>>> Since your H0 has never demonstrated that is actually DOES the 
>>>>>>> correct simulation per your stipulation, 
>>>>>>
>>>>>> Liar
>>>>>>
>>>>>
>>>>> Then where is it?
>>>>>
>>>> When we stipulate that the only measure of a correct emulation
>>>> is the semantics of the x86 programming language then we see that
>>>> when DDD is correctly emulated by H0 that its call to H0(DDD)
>>>> cannot possibly return.
>>>
>>> But that isn't what H0 should be answering about.
>>>
>>
>> That you and others lack a sufficient understanding of the nuanced
>> details of the theory of computation is your mistake and not mine.
> 
> No, it is that you don't have enough honest cells in your body to 
> understand that you have to follow the requirements for something to say 
> you are doing it.
> 
>>
>> The correct measure of the behavior of the actual input is DDD
>> correctly simulated by H0 according to the definition of the
>> semantics of the x86 programming language.
> 
> FRKM WHERE?
> 
> That is just YOUR LIE!!!!!
> 

Now you are trying to get away with disbelieving in the
semantics of the x86 language and you can't even spell "from"

That you have the audacity to call me a liar over this
might condemn you to Hell (I sincerely hope not).

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

#335865

On 6/22/24 3:49 PM, olcott wrote:
> On 6/22/2024 2:43 PM, Richard Damon wrote:
>> On 6/22/24 3:35 PM, olcott wrote:
>>> On 6/22/2024 2:19 PM, Richard Damon wrote:
>>>> On 6/22/24 3:03 PM, olcott wrote:
>>>>> On 6/22/2024 1:55 PM, Richard Damon wrote:
>>>>>> On 6/22/24 2:49 PM, olcott wrote:
>>>>>>> On 6/22/2024 1:43 PM, Richard Damon wrote:
>>>>>>>> On 6/22/24 1:29 PM, olcott wrote:
>>>>>>>>> On 6/22/2024 12:13 PM, Richard Damon wrote:
>>>>>>>>>> On 6/22/24 12:18 PM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>> void DDD()
>>>>>>>>>>> {
>>>>>>>>>>>    HHH0(DDD);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> The input to HHH0(DDD) includes itself.
>>>>>>>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>>>>>>>>>
>>>>>>>>>>> It is stipulated that correct emulation is defined by the
>>>>>>>>>>> semantics of the x86 programming language and nothing else.
>>>>>>>>>>
>>>>>>>>>> And thus, your emulation traces show that your "Simulating 
>>>>>>>>>> Halt Deciders" do not do a "Correct Simulation" 
>>>>>>>>>
>>>>>>>>> Apparently your ADD preventing you from paying close attention
>>>>>>>>> to ALL of my words.
>>>>>>>>>
>>>>>>>>> *Function names adapted to correspond to my updated paper*
>>>>>>>>>
>>>>>>>>> void DDD()
>>>>>>>>> {
>>>>>>>>>    H0(DDD);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>>
>>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>>
>>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>>
>>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>>
>>>>>>>>> *When we stipulate that the only measure of a correct*
>>>>>>>>> *emulation is the semantics of the x86 programming language*
>>>>>>>>>
>>>>>>>>> then we see that when DDD is correctly emulated by H0 that
>>>>>>>>> its call to H0(DDD) cannot possibly return.
>>>>>>>>
>>>>>>>> Since your H0 has never demonstrated that is actually DOES the 
>>>>>>>> correct simulation per your stipulation, 
>>>>>>>
>>>>>>> Liar
>>>>>>>
>>>>>>
>>>>>> Then where is it?
>>>>>>
>>>>> When we stipulate that the only measure of a correct emulation
>>>>> is the semantics of the x86 programming language then we see that
>>>>> when DDD is correctly emulated by H0 that its call to H0(DDD)
>>>>> cannot possibly return.
>>>>
>>>> But that isn't what H0 should be answering about.
>>>>
>>>
>>> That you and others lack a sufficient understanding of the nuanced
>>> details of the theory of computation is your mistake and not mine.
>>
>> No, it is that you don't have enough honest cells in your body to 
>> understand that you have to follow the requirements for something to 
>> say you are doing it.
>>
>>>
>>> The correct measure of the behavior of the actual input is DDD
>>> correctly simulated by H0 according to the definition of the
>>> semantics of the x86 programming language.
>>
>> FROM WHERE?
>>
>> That is just YOUR LIE!!!!!
>>
> 
> Now you are trying to get away with disbelieving in the
> semantics of the x86 language and you can't even spell "from"
> 
> That you have the audacity to call me a liar over this
> might condemn you to Hell (I sincerely hope not).
> 

I call it a lie, because it IS one.

You claim a definition of the "Correct Answer" that has NO source but 
your own ignorant mind. That makes it a LIE, as there is a DIFFERENT 
definition that you refuse to use.

You claim you can show "behavior" by the definition of the x86 assembly 
language that is not there.

The ONLY correct simulation of the input by your stipulation needs to 
follow the address of the call instruction, but you don't include it as 
an explict part of your input, but it must be there or you can't do the 
simulation past the call instruction.

Once you do that, you NEVER get the "simulation" results you post, only 
something that looks a bit more like the long ones, but they are of the 
wrong simulation.

And, when we examine what the proper ones WOULD be, we see that H0 and 
H1 get EXACTLY the same trace to the point that H0 just gives up, so 
there is not difference.

So, where is my "Lie"?

Calling a false statement a Lie is not a Lie, even if the person 
beleives it, but only by a reckless disregard for the truth,

You have just shows yourself to be a pathetic ignorant pathological 
lying idiot that doesn't know what he is talking about.

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

#335868

On 6/22/2024 3:08 PM, Richard Damon wrote:
> On 6/22/24 3:49 PM, olcott wrote:
>> On 6/22/2024 2:43 PM, Richard Damon wrote:
>>> On 6/22/24 3:35 PM, olcott wrote:
>>>>
>>>> The correct measure of the behavior of the actual input is DDD
>>>> correctly simulated by H0 according to the definition of the
>>>> semantics of the x86 programming language.
>>>
>>> FROM WHERE?
>>>
>>> That is just YOUR LIE!!!!!
>>>
>>
>> Now you are trying to get away with disbelieving in the
>> semantics of the x86 language and you can't even spell "from"
>>
>> That you have the audacity to call me a liar over this
>> might condemn you to Hell (I sincerely hope not).
>>
> 
> I call it a lie, because it IS one.
> 
> You claim a definition of the "Correct Answer" that has NO source but 
> your own ignorant mind. That makes it a LIE, as there is a DIFFERENT 
> definition that you refuse to use.
> 
> You claim you can show "behavior" by the definition of the x86 assembly 
> language that is not there.
> 

Liar

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | sci.logic

csiph-web