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

Groups > comp.theory > #107616 > unrolled thread

Why do people here insist on denying these verified facts?

Back to article view | Back to comp.theory

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? joes <noreply@example.com> - 2024-06-25 09:20 +0000
                        Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-23 12:50 +0300
                          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:25 -0500
                            Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:31 +0300
                              Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-24 08:52 -0500
                                Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-24 19:20 -0400
                                Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:42 +0300
                                  Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-25 08:29 -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? Mikko <mikko.levanto@iki.fi> - 2024-06-26 10:41 +0300
                                      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-26 07:25 -0500
                                        Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:02 +0300
                                          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-27 12:18 -0500
                                            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
                                            Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-28 11:55 +0300
                                              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? Mikko <mikko.levanto@iki.fi> - 2024-06-29 10:44 +0300
            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? Mikko <mikko.levanto@iki.fi> - 2024-06-26 10:46 +0300
                  Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-26 07:45 -0500
                    Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-26 19:41 -0400
                    Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:06 +0300
                      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-27 14:19 -0500
                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? Mikko <mikko.levanto@iki.fi> - 2024-06-23 12:42 +0300
      Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-23 08:23 -0500
        Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-24 10:32 +0300
          Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-24 08:50 -0500
            Re: Why do people here insist on denying these verified facts? immibis <news@immibis.com> - 2024-06-24 16:03 +0200
              Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:48 +0300
                Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-25 08:19 -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? Mikko <mikko.levanto@iki.fi> - 2024-06-26 10:54 +0300
                    Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-26 07:53 -0500
                      Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-26 19:41 -0400
                      Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-27 10:18 +0300
                        Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-27 14:42 -0500
                          Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-27 19:57 -0400
                          Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-28 12:06 +0300
                            Re: Why do people here insist on denying these verified facts? olcott <polcott333@gmail.com> - 2024-06-28 10:07 -0500
                              Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-29 10:47 +0300
            Re: Why do people here insist on denying these verified facts? Richard Damon <richard@damon-family.org> - 2024-06-24 19:21 -0400
            Re: Why do people here insist on denying these verified facts? Mikko <mikko.levanto@iki.fi> - 2024-06-25 12:47 +0300
        Re: Why do people here insist on denying these verified facts? joes <noreply@example.com> - 2024-06-25 08:54 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#107658

On 6/22/24 7:59 PM, olcott wrote:
> 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
> 

You losing it Peter.

you need to show something, or you are just admitting you have lost.


You HAVE lost, since you have nothing to back your lies, and that has 
been reveiled, but not even trying is just giving up.

The ACTUAL CORRECT emulation of the proper input (which includes the 
code of the decide which is needed) shows that DDD will Halt since H0 
will decide on it and return, and thus DDD will halt.

H0's emulation might not get there, but that isn't the question, and 
H1's emulation, which will be identical to H0 up to the point H0 stops 
(if H0 did a correct emulation per your rules) so there is no ground to 
say the behavior was different.

H0 is just WRONG about halting.

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

#107661

On 6/22/2024 7:19 PM, Richard Damon wrote:
> On 6/22/24 7:59 PM, olcott wrote:
>> 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
>>
> 
> You losing it Peter.
> 
> you need to show something, or you are just admitting you have lost.
> 

Not at all. I have written it up much better now.
Because I had to write it up clearly enough that
people trying to get away with lying about it look
like ridiculous fools it finally has a change to
be accepted.

> 
> You HAVE lost, since you have nothing to back your lies, and that has 
> been reveiled, but not even trying is just giving up.
> 
> The ACTUAL CORRECT emulation of the proper input (which includes the 
> code of the decide which is needed) shows that DDD will Halt since H0 
> will decide on it and return, and thus DDD will halt.
> 

That is not the question.
The question is can the call to H0(DDD) made by DDD
correctly simulated by H0 return?

> H0's emulation might not get there, but that isn't the question, and 
> H1's emulation, which will be identical to H0 up to the point H0 stops 
> (if H0 did a correct emulation per your rules) so there is no ground to 
> say the behavior was different.
> 
> H0 is just WRONG about halting.

When you try and get away with conflating an aborted simulation
with terminating normally gullible fools might think you are right.

There are several people here that are not gullible fools.

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

#107668

On 6/22/24 11:37 PM, olcott wrote:
> On 6/22/2024 7:19 PM, Richard Damon wrote:
>> On 6/22/24 7:59 PM, olcott wrote:
>>> 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
>>>
>>
>> You losing it Peter.
>>
>> you need to show something, or you are just admitting you have lost.
>>
> 
> Not at all. I have written it up much better now.
> Because I had to write it up clearly enough that
> people trying to get away with lying about it look
> like ridiculous fools it finally has a change to
> be accepted.



> 
>>
>> You HAVE lost, since you have nothing to back your lies, and that has 
>> been reveiled, but not even trying is just giving up.
>>
>> The ACTUAL CORRECT emulation of the proper input (which includes the 
>> code of the decide which is needed) shows that DDD will Halt since H0 
>> will decide on it and return, and thus DDD will halt.
>>
> 
> That is not the question.
> The question is can the call to H0(DDD) made by DDD
> correctly simulated by H0 return?

No, as long as you are claiming that H0 is a Halt Decider, that isn't 
the question, but the question is "Does the Machine represented by the 
input Halt when run?"

And, if you are going to admit that H0 isn't a Halt Decider, then our 
question to you is Why do we care about H0?

You need to give us a reason to spend the effort to verify what you claim.

> 
>> H0's emulation might not get there, but that isn't the question, and 
>> H1's emulation, which will be identical to H0 up to the point H0 stops 
>> (if H0 did a correct emulation per your rules) so there is no ground 
>> to say the behavior was different.
>>
>> H0 is just WRONG about halting.
> 
> When you try and get away with conflating an aborted simulation
> with terminating normally gullible fools might think you are right.

So, are you going to admit that H0 isn't, and never will be, a Halt Decider>

> 
> There are several people here that are not gullible fools.
> 

But you are not one of them.

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

#107676

On 6/23/2024 6:28 AM, Richard Damon wrote:
> On 6/22/24 11:37 PM, olcott wrote:
>> On 6/22/2024 7:19 PM, Richard Damon wrote:
>>> On 6/22/24 7:59 PM, olcott wrote:
>>>> 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
>>>>
>>>
>>> You losing it Peter.
>>>
>>> you need to show something, or you are just admitting you have lost.
>>>
>>
>> Not at all. I have written it up much better now.
>> Because I had to write it up clearly enough that
>> people trying to get away with lying about it look
>> like ridiculous fools it finally has a change to
>> be accepted.
> 
> 
> 
>>
>>>
>>> You HAVE lost, since you have nothing to back your lies, and that has 
>>> been reveiled, but not even trying is just giving up.
>>>
>>> The ACTUAL CORRECT emulation of the proper input (which includes the 
>>> code of the decide which is needed) shows that DDD will Halt since H0 
>>> will decide on it and return, and thus DDD will halt.
>>>
>>
>> That is not the question.
>> The question is can the call to H0(DDD) made by DDD
>> correctly simulated by H0 return?
> 
> No, as long as you are claiming that H0 is a Halt Decider, that isn't 
> the question, but the question is "Does the Machine represented by the 
> input Halt when run?"
> 
> And, if you are going to admit that H0 isn't a Halt Decider, then our 
> question to you is Why do we care about H0?
> 
> You need to give us a reason to spend the effort to verify what you claim.
> 
>>
>>> H0's emulation might not get there, but that isn't the question, and 
>>> H1's emulation, which will be identical to H0 up to the point H0 
>>> stops (if H0 did a correct emulation per your rules) so there is no 
>>> ground to say the behavior was different.
>>>
>>> H0 is just WRONG about halting.
>>
>> When you try and get away with conflating an aborted simulation
>> with terminating normally gullible fools might think you are right.
> 
> So, are you going to admit that H0 isn't, and never will be, a Halt 
> Decider>
> 
>>
>> There are several people here that are not gullible fools.
>>
> 
> But you are not one of them.
> 
> 

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

According to the semantics of the x86 programming language
when DDD correctly emulated by H0 calls H0(DDD) this call
cannot possibly return.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

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

#107682

On 6/23/24 9:36 AM, olcott wrote:
> On 6/23/2024 6:28 AM, Richard Damon wrote:
>> On 6/22/24 11:37 PM, olcott wrote:
>>> On 6/22/2024 7:19 PM, Richard Damon wrote:
>>>> On 6/22/24 7:59 PM, olcott wrote:
>>>>> 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
>>>>>
>>>>
>>>> You losing it Peter.
>>>>
>>>> you need to show something, or you are just admitting you have lost.
>>>>
>>>
>>> Not at all. I have written it up much better now.
>>> Because I had to write it up clearly enough that
>>> people trying to get away with lying about it look
>>> like ridiculous fools it finally has a change to
>>> be accepted.
>>
>>
>>
>>>
>>>>
>>>> You HAVE lost, since you have nothing to back your lies, and that 
>>>> has been reveiled, but not even trying is just giving up.
>>>>
>>>> The ACTUAL CORRECT emulation of the proper input (which includes the 
>>>> code of the decide which is needed) shows that DDD will Halt since 
>>>> H0 will decide on it and return, and thus DDD will halt.
>>>>
>>>
>>> That is not the question.
>>> The question is can the call to H0(DDD) made by DDD
>>> correctly simulated by H0 return?
>>
>> No, as long as you are claiming that H0 is a Halt Decider, that isn't 
>> the question, but the question is "Does the Machine represented by the 
>> input Halt when run?"
>>
>> And, if you are going to admit that H0 isn't a Halt Decider, then our 
>> question to you is Why do we care about H0?
>>
>> You need to give us a reason to spend the effort to verify what you 
>> claim.
>>
>>>
>>>> H0's emulation might not get there, but that isn't the question, and 
>>>> H1's emulation, which will be identical to H0 up to the point H0 
>>>> stops (if H0 did a correct emulation per your rules) so there is no 
>>>> ground to say the behavior was different.
>>>>
>>>> H0 is just WRONG about halting.
>>>
>>> When you try and get away with conflating an aborted simulation
>>> with terminating normally gullible fools might think you are right.
>>
>> So, are you going to admit that H0 isn't, and never will be, a Halt 
>> Decider>
>>
>>>
>>> There are several people here that are not gullible fools.
>>>
>>
>> But you are not one of them.
>>
>>
> 
> _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]
> 
> According to the semantics of the x86 programming language
> when DDD correctly emulated by H0 calls H0(DDD) this call
> cannot possibly return.
> 
> Likewise according to the semantics of arithmetic for
> decimal integers: 2 + 3 = 5.
> 
> Anyone disagreeing with these two statements is WRONG.
> 



Now, if you REALLY mean just can H0 simulate this input to a final 
state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\.

First, if you ONLY have the bytes presented, then the answer becomes 
trivial, as H0 HAS to stop emulating when it gets to the call 
instruction, as there is no data at address 000015d2 defined to simulate.

This means you need to fix your problem statement to include the 
instructions of HHH0, and everything that it calls as part of the 
"input", or your question isn't the one you mean to be asking.

Of course, this means that each HHH0 that you try, is processing a 
DIFFERENT input, so you can't argue from one about the behavior of a 
different one.

Second, you forgot to specify what HHH0 has as requirements. Once you 
include its code, so can simulate it, the "non-pure" function tricks 
allow it to correctly simulate to the return instruction.

Reminder, you complain when we point out assumptions made on previous 
statements that you didn't want to carry forward, so you can't also 
complain about us forgetting about requirements that you didn't bring 
forward.

If you want to pull in the past, we can just point out that we KNOW you 
are talking about a Halt Decider, and that your question is the wrong 
question for a Halt decider.

So, your statement is wrong for two logical reasons as described above, 
so your statement that anyone who disagrees is wrong is just wrong.

You don't know how to properly state a problem.

The last point to make, is that this is NOT a "proof" but just an 
argument claiming something should be obviously true.

That may be a "proof" in the wild west of Philosophy, but it isn't in 
the realm of Formal Logic, which is what the field you are talking about is.

So, you are making a statement, that when fixed to correct the deficits 
in it, becomes a statement that might be plausably true, but not proven.

A proof can likely be made, but it seems that is beyond your ability 
since you didn't even try, Of course, without the second fix, the 
statement is just false, and without the first fix, the statment is 
meaningless, as of course you can't simulate to a return from a call 
that you are unable to simulate past.

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

#107649

Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
> 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:

> 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.
The correct measure is the behaviour of DDD itself. Any old simulator can
do it, but H0 specifically can't.

> 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.
The input is just DDD.

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

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

#107652

On 6/22/2024 3:01 PM, joes wrote:
> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>> 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:
> 
>> 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.
> The correct measure is the behaviour of DDD itself. Any old simulator can
> do it, but H0 specifically can't.
> 

H0 has libx86emu embedded within it.
Several decades of development effort went into that.

>> 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.
> The input is just DDD.
> 

The input is the machine language of DDD that calls H0(DDD)
in recursive emulation.

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

#107655

On 6/22/24 7:57 PM, olcott wrote:
> On 6/22/2024 3:01 PM, joes wrote:
>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>> 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:
>>
>>> 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.
>> The correct measure is the behaviour of DDD itself. Any old simulator can
>> do it, but H0 specifically can't.
>>
> 
> H0 has libx86emu embedded within it.
> Several decades of development effort went into that.

But does it use it right?

After all, part of your problem is that you try to change the quesiton, 
and the right answer to the wrong question can be the wrong answer for 
the right question.

Your inability to get the required trace out makes me think you aren't 
actually doing what you claim to be doing.
> 
>>> 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.
>> The input is just DDD.
>>
> 
> The input is the machine language of DDD that calls H0(DDD)
> in recursive emulation.
> 

No, it call H0(DDD) to decide on DDD.

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

#107656

On 6/22/2024 7:07 PM, Richard Damon wrote:
> On 6/22/24 7:57 PM, olcott wrote:
>> On 6/22/2024 3:01 PM, joes wrote:
>>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>>> 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:
>>>
>>>> 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.
>>> The correct measure is the behaviour of DDD itself. Any old simulator 
>>> can
>>> do it, but H0 specifically can't.
>>>
>>
>> H0 has libx86emu embedded within it.
>> Several decades of development effort went into that.
> 
> But does it use it right?
> 
> After all, part of your problem is that you try to change the quesiton, 
> and the right answer to the wrong question can be the wrong answer for 
> the right question.
> 
> Your inability to get the required trace out makes me think you aren't 
> actually doing what you claim to be doing.

It has been correct and proven correct for more than three
years yet damned liars here still deny it.

>>
>>>> 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.
>>> The input is just DDD.
>>>
>>
>> The input is the machine language of DDD that calls H0(DDD)
>> in recursive emulation.
>>
> 
> No, it call H0(DDD) to decide on 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]

#107659

On 6/22/24 8:09 PM, olcott wrote:
> On 6/22/2024 7:07 PM, Richard Damon wrote:
>> On 6/22/24 7:57 PM, olcott wrote:
>>> On 6/22/2024 3:01 PM, joes wrote:
>>>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>>>> 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:
>>>>
>>>>> 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.
>>>> The correct measure is the behaviour of DDD itself. Any old 
>>>> simulator can
>>>> do it, but H0 specifically can't.
>>>>
>>>
>>> H0 has libx86emu embedded within it.
>>> Several decades of development effort went into that.
>>
>> But does it use it right?
>>
>> After all, part of your problem is that you try to change the 
>> quesiton, and the right answer to the wrong question can be the wrong 
>> answer for the right question.
>>
>> Your inability to get the required trace out makes me think you aren't 
>> actually doing what you claim to be doing.
> 
> It has been correct and proven correct for more than three
> years yet damned liars here still deny it.

Then you could show the trace.

But you can't, so you are just a LIAR.

One issue is that three years ago, your were not as insistant on the x86 
simulation, which gave you a bit more room to argue about equivalences 
(which you could never actually establish). By x86, you HAVE to trace 
from the pathological program into the decider and then show the steps 
in the decider to try to show your claim.

The problem is that then the ability for the decider being simulated to 
decide to stop its own simulation becomes evident, so you can't show 
that it never will.

This breaks your "infinite recursion" claim, and your proof,

This is the problem with basing your story on a lie. it is hard to keep 
the lie hidden. WHich cause you to ned to stipulate things that box you 
away from what you want to try to prove, as they need to get to the lie, 
but you can't let it be seen.


> 
>>>
>>>>> 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.
>>>> The input is just DDD.
>>>>
>>>
>>> The input is the machine language of DDD that calls H0(DDD)
>>> in recursive emulation.
>>>
>>
>> No, it call H0(DDD) to decide on DDD.
>>
>>
>>
>>
> 

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

#107662

On 6/22/2024 7:26 PM, Richard Damon wrote:
> On 6/22/24 8:09 PM, olcott wrote:
>> On 6/22/2024 7:07 PM, Richard Damon wrote:
>>> On 6/22/24 7:57 PM, olcott wrote:
>>>> On 6/22/2024 3:01 PM, joes wrote:
>>>>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>>>>> 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:
>>>>>
>>>>>> 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.
>>>>> The correct measure is the behaviour of DDD itself. Any old 
>>>>> simulator can
>>>>> do it, but H0 specifically can't.
>>>>>
>>>>
>>>> H0 has libx86emu embedded within it.
>>>> Several decades of development effort went into that.
>>>
>>> But does it use it right?
>>>
>>> After all, part of your problem is that you try to change the 
>>> quesiton, and the right answer to the wrong question can be the wrong 
>>> answer for the right question.
>>>
>>> Your inability to get the required trace out makes me think you 
>>> aren't actually doing what you claim to be doing.
>>
>> It has been correct and proven correct for more than three
>> years yet damned liars here still deny it.
> 
> Then you could show the trace.
> 
> But you can't, so you are just a LIAR.
> 
> One issue is that three years ago, your were not as insistant on the x86 
> simulation, which gave you a bit more room to argue about equivalences 
> (which you could never actually establish). By x86, you HAVE to trace 
> from the pathological program into the decider and then show the steps 
> in the decider to try to show your claim.
> 

Anyone that understands this knows that the call to H0(DDD)
from DDD correctly simulated by H0 cannot possibly return.

That you have lied about this for three years makes you
look ridiculously foolish and might get you condemned to Hell.

Those that lie about climate change destroying the planet
for a few extra bucks probably do deserve 1000 years in Hell.
I myself would forgive you, yet not them.

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

> The problem is that then the ability for the decider being simulated to 
> decide to stop its own simulation becomes evident, so you can't show 
> that it never will.
> 

It is only the freaking ordinary infinite recursion behavior pattern.
I don't believe that you are too stupid to understand this.
If not stupid then evil.

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

#107669

On 6/22/24 11:46 PM, olcott wrote:
> On 6/22/2024 7:26 PM, Richard Damon wrote:
>> On 6/22/24 8:09 PM, olcott wrote:
>>> On 6/22/2024 7:07 PM, Richard Damon wrote:
>>>> On 6/22/24 7:57 PM, olcott wrote:
>>>>> On 6/22/2024 3:01 PM, joes wrote:
>>>>>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>>>>>> 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:
>>>>>>
>>>>>>> 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.
>>>>>> The correct measure is the behaviour of DDD itself. Any old 
>>>>>> simulator can
>>>>>> do it, but H0 specifically can't.
>>>>>>
>>>>>
>>>>> H0 has libx86emu embedded within it.
>>>>> Several decades of development effort went into that.
>>>>
>>>> But does it use it right?
>>>>
>>>> After all, part of your problem is that you try to change the 
>>>> quesiton, and the right answer to the wrong question can be the 
>>>> wrong answer for the right question.
>>>>
>>>> Your inability to get the required trace out makes me think you 
>>>> aren't actually doing what you claim to be doing.
>>>
>>> It has been correct and proven correct for more than three
>>> years yet damned liars here still deny it.
>>
>> Then you could show the trace.
>>
>> But you can't, so you are just a LIAR.
>>
>> One issue is that three years ago, your were not as insistant on the 
>> x86 simulation, which gave you a bit more room to argue about 
>> equivalences (which you could never actually establish). By x86, you 
>> HAVE to trace from the pathological program into the decider and then 
>> show the steps in the decider to try to show your claim.
>>
> 
> Anyone that understands this knows that the call to H0(DDD)
> from DDD correctly simulated by H0 cannot possibly return.

And who cares about that.

All that shows is that H0 correctly simulating this input does determine 
the actual behavior of the input.

Its correct simulation by H0 might not return, but its complete and 
correct simulation, as does its direct running does.

> 
> That you have lied about this for three years makes you
> look ridiculously foolish and might get you condemned to Hell.

Nope, might get you there, or you might have already had you ticket punched.



> 
> Those that lie about climate change destroying the planet
> for a few extra bucks probably do deserve 1000 years in Hell.
> I myself would forgive you, yet not them.

And I am not one of those, but it seems you like to use the same sort of 
logic, so you are supporting them.

> 
> _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]
> 
>> The problem is that then the ability for the decider being simulated 
>> to decide to stop its own simulation becomes evident, so you can't 
>> show that it never will.
>>
> 
> It is only the freaking ordinary infinite recursion behavior pattern.
> I don't believe that you are too stupid to understand this.
> If not stupid then evil.
> 

Nope. becasue there is a conditional operation in the loop, that which 
is in H0.

Your arguemnt is based on the LIE that H0 isn't responsible for 
correctly deciding on what H0 will do.

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

#107677

On 6/23/2024 6:28 AM, Richard Damon wrote:
> On 6/22/24 11:46 PM, olcott wrote:
>> On 6/22/2024 7:26 PM, Richard Damon wrote:
>>> On 6/22/24 8:09 PM, olcott wrote:
>>>> On 6/22/2024 7:07 PM, Richard Damon wrote:
>>>>> On 6/22/24 7:57 PM, olcott wrote:
>>>>>> On 6/22/2024 3:01 PM, joes wrote:
>>>>>>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>>>>>>> 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:
>>>>>>>
>>>>>>>> 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.
>>>>>>> The correct measure is the behaviour of DDD itself. Any old 
>>>>>>> simulator can
>>>>>>> do it, but H0 specifically can't.
>>>>>>>
>>>>>>
>>>>>> H0 has libx86emu embedded within it.
>>>>>> Several decades of development effort went into that.
>>>>>
>>>>> But does it use it right?
>>>>>
>>>>> After all, part of your problem is that you try to change the 
>>>>> quesiton, and the right answer to the wrong question can be the 
>>>>> wrong answer for the right question.
>>>>>
>>>>> Your inability to get the required trace out makes me think you 
>>>>> aren't actually doing what you claim to be doing.
>>>>
>>>> It has been correct and proven correct for more than three
>>>> years yet damned liars here still deny it.
>>>
>>> Then you could show the trace.
>>>
>>> But you can't, so you are just a LIAR.
>>>
>>> One issue is that three years ago, your were not as insistant on the 
>>> x86 simulation, which gave you a bit more room to argue about 
>>> equivalences (which you could never actually establish). By x86, you 
>>> HAVE to trace from the pathological program into the decider and then 
>>> show the steps in the decider to try to show your claim.
>>>
>>
>> Anyone that understands this knows that the call to H0(DDD)
>> from DDD correctly simulated by H0 cannot possibly return.
> 
> And who cares about that.
> 
> All that shows is that H0 correctly simulating this input does determine 
> the actual behavior of the input.
> 
> Its correct simulation by H0 might not return, but its complete and 
> correct simulation, as does its direct running does.
> 
>>
>> That you have lied about this for three years makes you
>> look ridiculously foolish and might get you condemned to Hell.
> 
> Nope, might get you there, or you might have already had you ticket 
> punched.
> 
> 
> 
>>
>> Those that lie about climate change destroying the planet
>> for a few extra bucks probably do deserve 1000 years in Hell.
>> I myself would forgive you, yet not them.
> 
> And I am not one of those, but it seems you like to use the same sort of 
> logic, so you are supporting them.
> 
>>
>> _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]
>>
>>> The problem is that then the ability for the decider being simulated 
>>> to decide to stop its own simulation becomes evident, so you can't 
>>> show that it never will.
>>>
>>
>> It is only the freaking ordinary infinite recursion behavior pattern.
>> I don't believe that you are too stupid to understand this.
>> If not stupid then evil.
>>
> 
> Nope. becasue there is a conditional operation in the loop, that which 
> is in H0.
> 
> Your arguemnt is based on the LIE that H0 isn't responsible for 
> correctly deciding on what H0 will do.

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

According to the semantics of the x86 programming language
when DDD correctly emulated by H0 calls H0(DDD) this call
cannot possibly return.

Likewise according to the semantics of arithmetic for
decimal integers: 2 + 3 = 5.

Anyone disagreeing with these two statements is WRONG.

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

#107683

On 6/23/24 9:37 AM, olcott wrote:
> On 6/23/2024 6:28 AM, Richard Damon wrote:
>> On 6/22/24 11:46 PM, olcott wrote:
>>> On 6/22/2024 7:26 PM, Richard Damon wrote:
>>>> On 6/22/24 8:09 PM, olcott wrote:
>>>>> On 6/22/2024 7:07 PM, Richard Damon wrote:
>>>>>> On 6/22/24 7:57 PM, olcott wrote:
>>>>>>> On 6/22/2024 3:01 PM, joes wrote:
>>>>>>>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>>>>>>>> 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:
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>> The correct measure is the behaviour of DDD itself. Any old 
>>>>>>>> simulator can
>>>>>>>> do it, but H0 specifically can't.
>>>>>>>>
>>>>>>>
>>>>>>> H0 has libx86emu embedded within it.
>>>>>>> Several decades of development effort went into that.
>>>>>>
>>>>>> But does it use it right?
>>>>>>
>>>>>> After all, part of your problem is that you try to change the 
>>>>>> quesiton, and the right answer to the wrong question can be the 
>>>>>> wrong answer for the right question.
>>>>>>
>>>>>> Your inability to get the required trace out makes me think you 
>>>>>> aren't actually doing what you claim to be doing.
>>>>>
>>>>> It has been correct and proven correct for more than three
>>>>> years yet damned liars here still deny it.
>>>>
>>>> Then you could show the trace.
>>>>
>>>> But you can't, so you are just a LIAR.
>>>>
>>>> One issue is that three years ago, your were not as insistant on the 
>>>> x86 simulation, which gave you a bit more room to argue about 
>>>> equivalences (which you could never actually establish). By x86, you 
>>>> HAVE to trace from the pathological program into the decider and 
>>>> then show the steps in the decider to try to show your claim.
>>>>
>>>
>>> Anyone that understands this knows that the call to H0(DDD)
>>> from DDD correctly simulated by H0 cannot possibly return.
>>
>> And who cares about that.
>>
>> All that shows is that H0 correctly simulating this input does 
>> determine the actual behavior of the input.
>>
>> Its correct simulation by H0 might not return, but its complete and 
>> correct simulation, as does its direct running does.
>>
>>>
>>> That you have lied about this for three years makes you
>>> look ridiculously foolish and might get you condemned to Hell.
>>
>> Nope, might get you there, or you might have already had you ticket 
>> punched.
>>
>>
>>
>>>
>>> Those that lie about climate change destroying the planet
>>> for a few extra bucks probably do deserve 1000 years in Hell.
>>> I myself would forgive you, yet not them.
>>
>> And I am not one of those, but it seems you like to use the same sort 
>> of logic, so you are supporting them.
>>
>>>
>>> _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]
>>>
>>>> The problem is that then the ability for the decider being simulated 
>>>> to decide to stop its own simulation becomes evident, so you can't 
>>>> show that it never will.
>>>>
>>>
>>> It is only the freaking ordinary infinite recursion behavior pattern.
>>> I don't believe that you are too stupid to understand this.
>>> If not stupid then evil.
>>>
>>
>> Nope. becasue there is a conditional operation in the loop, that which 
>> is in H0.
>>
>> Your arguemnt is based on the LIE that H0 isn't responsible for 
>> correctly deciding on what H0 will do.
> 
> _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]
> 
> According to the semantics of the x86 programming language
> when DDD correctly emulated by H0 calls H0(DDD) this call
> cannot possibly return.
> 
> Likewise according to the semantics of arithmetic for
> decimal integers: 2 + 3 = 5.
> 
> Anyone disagreeing with these two statements is WRONG.
> 


NOo, if you REALLY mean just can HHH0 simulate this input to a final 
state, the answer is WHO CARES.

But I will put out a few comments on errors in your presentation\.

First, if you ONLY have the bytes presented, then the answer becomes 
trivial, as H0 HAS to stop emulating when it gets to the call 
instruction, as there is no data at address 000015d2 defined to simulate.

This means you need to fix your problem statement to include the 
instructions of HHH0, and everything that it calls as part of the 
"input", or your question isn't the one you mean to be asking.

Of course, this means that each HHH0 that you try, is processing a 
DIFFERENT input, so you can't argue from one about the behavior of a 
different one.

Second, you forgot to specify what HHH0 has as requirements. Once you 
include its code, so can simulate it, the "non-pure" function tricks 
allow it to correctly simulate to the return instruction.

Reminder, you complain when we point out assumptions made on previous 
statements that you didn't want to carry forward, so you can't also 
complain about us forgetting about requirements that you didn't bring 
forward.

If you want to pull in the past, we can just point out that we KNOW you 
are talking about a Halt Decider, and that your question is the wrong 
question for a Halt decider.

So, your statement is wrong for two logical reasons as described above, 
so your statement that anyone who disagrees is wrong is just wrong.

You don't know how to properly state a problem.

The last point to make, is that this is NOT a "proof" but just an 
argument claiming something should be obviously true.

That may be a "proof" in the wild west of Philosophy, but it isn't in 
the realm of Formal Logic, which is what the field you are talking about is.

So, you are making a statement, that when fixed to correct the deficits 
in it, becomes a statement that might be plausably true, but not proven.

A proof can likely be made, but it seems that is beyond your ability 
since you didn't even try, Of course, without the second fix, the 
statement is just false, and without the first fix, the statment is 
meaningless, as of course you can't simulate to a return from a call 
that you are unable to simulate past.

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

#107776

Am Sat, 22 Jun 2024 18:57:49 -0500 schrieb olcott:
> On 6/22/2024 3:01 PM, joes wrote:
>> Am Sat, 22 Jun 2024 14:35:59 -0500 schrieb olcott:
>>> 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:

>> The correct measure is the behaviour of DDD itself. Any old simulator
>> can do it, but H0 specifically can't.
> H0 has libx86emu embedded within it.
> Several decades of development effort went into that.
libx86emu can naturally simulate buggy programs.

>>> 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.
>> The input is just DDD.
> The input is the machine language of DDD that calls H0(DDD)
> in recursive emulation.
Yes, of course. The input is not H0(DDD). The analyser does not directly
simulate itself, only because DDD calls it.

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

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

#107667

On 2024-06-22 19:03:13 +0000, olcott said:

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

Semantics of the x86 programming language does not specifiy emulation
or correctness of emulation.

-- 
Mikko

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

#107674

On 6/23/2024 4:50 AM, Mikko wrote:
> On 2024-06-22 19:03:13 +0000, olcott said:
> 
>> 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.
> 
> Semantics of the x86 programming language does not specifiy emulation
> or correctness of emulation.
> 

WRONG!

Otherwise we could say that for the decimal integers
2 + 3 = 17 and the semantics of arithmetic does not disagree.

The semantics of arithmetic agrees that for the decimal
integers 2 + 3 = 5.

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

#107715

On 2024-06-23 13:25:36 +0000, olcott said:

> On 6/23/2024 4:50 AM, Mikko wrote:
>> On 2024-06-22 19:03:13 +0000, olcott said:
>> 
>>> 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.
>> 
>> Semantics of the x86 programming language does not specifiy emulation
>> or correctness of emulation.
>> 
> 
> WRONG!

Unless you point where in Intel's documentation emulation or correctness
of emulation is specified you have no basis to say "WRONG".

> Otherwise we could say that for the decimal integers
> 2 + 3 = 17 and the semantics of arithmetic does not disagree.

I can believe you couls but I would not.

> The semantics of arithmetic agrees that for the decimal
> integers 2 + 3 = 5.

Intel's processors seem to agree, too. But I havn't checked every one.

-- 
Mikko

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

#107725

On 6/24/2024 2:31 AM, Mikko wrote:
> On 2024-06-23 13:25:36 +0000, olcott said:
> 
>> On 6/23/2024 4:50 AM, Mikko wrote:
>>> On 2024-06-22 19:03:13 +0000, olcott said:
>>>
>>>> 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.
>>>
>>> Semantics of the x86 programming language does not specifiy emulation
>>> or correctness of emulation.
>>>
>>
>> WRONG!
> 
> Unless you point where in Intel's documentation emulation or correctness
> of emulation is specified you have no basis to say "WRONG".
> 

Not at all. That is the same as saying that 2 + 3 = 5
is wrong until proven by PA.

>> Otherwise we could say that for the decimal integers
>> 2 + 3 = 17 and the semantics of arithmetic does not disagree.
> 
> I can believe you couls but I would not.
> 
>> The semantics of arithmetic agrees that for the decimal
>> integers 2 + 3 = 5.
> 
> Intel's processors seem to agree, too. But I havn't checked every one.
> 

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

The call from DDD to H0(DDD) when DDD is correctly emulated
by H0 cannot possibly 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]

#107739

On 6/24/24 9:52 AM, olcott wrote:
> On 6/24/2024 2:31 AM, Mikko wrote:
>> On 2024-06-23 13:25:36 +0000, olcott said:
>>
>>> On 6/23/2024 4:50 AM, Mikko wrote:
>>>> On 2024-06-22 19:03:13 +0000, olcott said:
>>>>
>>>>> 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.
>>>>
>>>> Semantics of the x86 programming language does not specifiy emulation
>>>> or correctness of emulation.
>>>>
>>>
>>> WRONG!
>>
>> Unless you point where in Intel's documentation emulation or correctness
>> of emulation is specified you have no basis to say "WRONG".
>>
> 
> Not at all. That is the same as saying that 2 + 3 = 5
> is wrong until proven by PA.
> 
>>> Otherwise we could say that for the decimal integers
>>> 2 + 3 = 17 and the semantics of arithmetic does not disagree.
>>
>> I can believe you couls but I would not.
>>
>>> The semantics of arithmetic agrees that for the decimal
>>> integers 2 + 3 = 5.
>>
>> Intel's processors seem to agree, too. But I havn't checked every one.
>>
> 
> _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]
> 
> The call from DDD to H0(DDD) when DDD is correctly emulated
> by H0 cannot possibly return.
> 

So? What do we care about your POOP?

It isn't the Halting criteria, so you are just admitting to using strawmen.

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.theory

csiph-web