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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#335873

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]

#335876

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]

#335879

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]

#335884

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]

#335890

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]

#335864

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]

#335867

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]

#335870

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]

#335871

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]

#335874

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]

#335877

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]

#335880

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]

#335885

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]

#335891

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]

#336096

On 6/28/2024 3:55 AM, Mikko wrote:
> On 2024-06-27 17:18:23 +0000, olcott said:
> 
>> On 6/27/2024 2:02 AM, Mikko wrote:
>>> On 2024-06-26 12:25:28 +0000, olcott said:
>>>
>>>>
>>>> I will use your system of reasoning.
>>>> The semantics of decimal arithmetic prove that 2 + 3 = 5.
>>>
>>> You nave not shown the proof.
>>
>> That is a stupid thing to say.
> 

The details of common knowledge of self-evident truth
are never required to be provided, not even in patents.

When I say that this is proven by the semantics of the
x86 language then the entire semantics of the x86 language
is incorporated by reference.

> No, it is not. Sometimes it is important to say the obvious. Of course,
> other things should be said, too, though not necessarily at the same time.
> 
>> When you try to disagree with arithmetic that proves
>> you are a troll that wants to infinitely delay any and
>> all closure at the possible expense of life on Earth.
> 
> That "when" refers to 'never'.
> 

You just did do this:
 >>> You nave (typo for "have") not shown the proof.

>> The same system of reasoning that I use to show how
>> the input to H0(DD) does not halt.
> 
> True, but your reasoning is not good enough for serious use.
> 
We could say that this is true:
2 + 3 = 5 and get into an infinite debate about
exactly what the English word "this" means.

A dishonest deflection like Trump did on two key
questions last night. He also flat out lied in
most of his answers.

>> *Truth preserving operations applied to expressions of*
>> *language known to be true*
> 
> Yes, as long as you don't provide that you have proven nothing.
> 

If you don't sufficiently understand the x86 language then
we can stop right here. If you do then it is self-evident
that I am correct.

>> can stop all dangerous lies that can cause the end
>> of life on Earth and overturn Democracy with Fascism.
> 
> No, they can't. But they can help to figure out whom to trust.
> 
That human caused climate change is having drastic impact
on the climate is proven by verified facts

https://www.researchgate.net/publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts

People disagreeing are damned liars in that they have condemned
themselves to actual Hell if such a place exists.

>> The body of formal or natural expressions of language
>> that are {true on the basis of their verbal meaning}
>> form a semantic tautology of self-evident truth.
> 
> Which is not very helpful.
> 
It is the actual foundation of True(L,x) in my redefinition
of the analytic side of the analytic/synthetic distinction.
*True and unprovable has always been ridiculous nonsense*

True and provable in meta-mathematics corresponds to
untrue and unprovable in PA.
https://www.liarparadox.org/Wittgenstein.pdf

>> If you disagree that 2 + 3 = 5 then you are an ignoramus
>> or a liar.
> 
> That is a big if. But I know there are people who disagree with
> proven truths.
> 

Disagreeing with expressions that are
{true on the basis of their verbal meaning} that are proven
true on the basis of a sequence of truth preserving operations
from their verbal meaning cannot possibly be anything besides
incorrect.

The problem of induction prevents the same degree of logically
justified certainty for empirical knowledge.

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

#336109

On 6/28/24 10:54 AM, olcott wrote:
> On 6/28/2024 3:55 AM, Mikko wrote:
>> On 2024-06-27 17:18:23 +0000, olcott said:
>>
>>> On 6/27/2024 2:02 AM, Mikko wrote:
>>>> On 2024-06-26 12:25:28 +0000, olcott said:
>>>>
>>>>>
>>>>> I will use your system of reasoning.
>>>>> The semantics of decimal arithmetic prove that 2 + 3 = 5.
>>>>
>>>> You nave not shown the proof.
>>>
>>> That is a stupid thing to say.
>>
> 
> The details of common knowledge of self-evident truth
> are never required to be provided, not even in patents.

But that isn't part of Forma Logic.


> 
> When I say that this is proven by the semantics of the
> x86 language then the entire semantics of the x86 language
> is incorporated by reference.

And thus, stopping in the middle of the exectution is NOT allowed, so 
your emulatios that return are not "Correct Emulators"

> 
>> No, it is not. Sometimes it is important to say the obvious. Of course,
>> other things should be said, too, though not necessarily at the same 
>> time.
>>
>>> When you try to disagree with arithmetic that proves
>>> you are a troll that wants to infinitely delay any and
>>> all closure at the possible expense of life on Earth.
>>
>> That "when" refers to 'never'.
>>
> 
> You just did do this:
>  >>> You nave (typo for "have") not shown the proof.


Yes, you have NEVER shown a proof for any of your major claims, I think 
because you don;t understand how to do a proof.

> 
>>> The same system of reasoning that I use to show how
>>> the input to H0(DD) does not halt.
>>
>> True, but your reasoning is not good enough for serious use.
>>
> We could say that this is true:
> 2 + 3 = 5 and get into an infinite debate about
> exactly what the English word "this" means.
> 
> A dishonest deflection like Trump did on two key
> questions last night. He also flat out lied in
> most of his answers.

As is your deflection that we could get into a long diversion on the 
meaning of "this".

2 + 3 = 5 is easily provable by someone who understand the basic 
principles of number theory.

YOU can't prove your claims, because you don't understand the basic of 
Computation theory.

> 
>>> *Truth preserving operations applied to expressions of*
>>> *language known to be true*
>>
>> Yes, as long as you don't provide that you have proven nothing.
>>
> 
> If you don't sufficiently understand the x86 language then
> we can stop right here. If you do then it is self-evident
> that I am correct.

And it seems you don't either, due to your incorerct claims about it.

> 
>>> can stop all dangerous lies that can cause the end
>>> of life on Earth and overturn Democracy with Fascism.
>>
>> No, they can't. But they can help to figure out whom to trust.
>>
> That human caused climate change is having drastic impact
> on the climate is proven by verified facts
> 
> https://www.researchgate.net/publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts
> 
> People disagreeing are damned liars in that they have condemned
> themselves to actual Hell if such a place exists.

Just like YOU are a damned liar for saying that Halting is computable, 
and using the same techniques as the climate deniers to try to claim it.

> 
>>> The body of formal or natural expressions of language
>>> that are {true on the basis of their verbal meaning}
>>> form a semantic tautology of self-evident truth.
>>
>> Which is not very helpful.
>>
> It is the actual foundation of True(L,x) in my redefinition
> of the analytic side of the analytic/synthetic distinction.
> *True and unprovable has always been ridiculous nonsense*

Yes, you have "redefined" the meaning of truth, but refuse to see that 
this mean you have to start you logic system from your new definition 
and show what that can do.

To try to just change an existing system, just makes you a LIAR.

> 
> True and provable in meta-mathematics corresponds to
> untrue and unprovable in PA.
> https://www.liarparadox.org/Wittgenstein.pdf

Silly thing to say, that True <-> unTrue and Provable <-> unprovable.

Sounds like someone is on something.

Note, you claim shows up NO WHERE in the page you cite.

> 
>>> If you disagree that 2 + 3 = 5 then you are an ignoramus
>>> or a liar.
>>
>> That is a big if. But I know there are people who disagree with
>> proven truths.
>>
> 
> Disagreeing with expressions that are
> {true on the basis of their verbal meaning} that are proven
> true on the basis of a sequence of truth preserving operations
> from their verbal meaning cannot possibly be anything besides
> incorrect.
> 
> The problem of induction prevents the same degree of logically
> justified certainty for empirical knowledge.
> 

Nope, you just don't understand what you are talking about.

Note, "Formal Systems" only have in them the meanings put into them by 
their defintions. Trying to use meanings not in the system, is just LYING.

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

#335987

Am Sat, 22 Jun 2024 11:18:07 -0500 schrieb olcott:
> 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 input to HHH0(DDD) includes itself.
>>> The input to HHH1(DDD) DOES NOT include itself.
>> Yes, both include HHH0. The second case is boring.
Suppose DDD1 only called HHH1. How would HHH1 simulate it?

> 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 does not change behaviour depending on its simulator, that is an
error on the part of the simulator. 

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

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

#335990

On 6/25/2024 3:41 PM, joes wrote:
> Am Sat, 22 Jun 2024 11:18:07 -0500 schrieb olcott:
>> 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 input to HHH0(DDD) includes itself.
>>>> The input to HHH1(DDD) DOES NOT include itself.
>>> Yes, both include HHH0. The second case is boring.
> Suppose DDD1 only called HHH1. How would HHH1 simulate it?
> 
>> 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 does not change behaviour depending on its simulator, that is an
> error on the part of the simulator.
> 

No dumbo that is not it.
The input that calls its own simulator defines different
behavior than when it is simulated by a different simulator.

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

#335992

On 6/25/24 5:24 PM, olcott wrote:
> On 6/25/2024 3:41 PM, joes wrote:
>> Am Sat, 22 Jun 2024 11:18:07 -0500 schrieb olcott:
>>> 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 input to HHH0(DDD) includes itself.
>>>>> The input to HHH1(DDD) DOES NOT include itself.
>>>> Yes, both include HHH0. The second case is boring.
>> Suppose DDD1 only called HHH1. How would HHH1 simulate it?
>>
>>> 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 does not change behaviour depending on its simulator, that is an
>> error on the part of the simulator.
>>
> 
> No dumbo that is not it.
> The input that calls its own simulator defines different
> behavior than when it is simulated by a different simulator.
> 


And where does the behavior differ?

It shows the EXACT SAME BEHAVIOR up to the point it is aborted, and 
partial simulation do not show behavior after the point of aborting.

Both show that HHH0 did not return to DDD for the period that HHH0 
simulated it.


HHH1 shows that it will later. That is not DIFFERENT behavior, but a 
fuller description of the behavior.

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

#336016

Am Tue, 25 Jun 2024 16:24:34 -0500 schrieb olcott:
> On 6/25/2024 3:41 PM, joes wrote:
>> Am Sat, 22 Jun 2024 11:18:07 -0500 schrieb olcott:
>>> 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:

>> Suppose DDD1 only called HHH1. How would HHH1 simulate it?

>>> 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.
Those are different DDD's. All HHH's should give the same result.

>> DDD does not change behaviour depending on its simulator, that is an
>> error on the part of the simulator.
> The input that calls its own simulator defines different behavior than
> when it is simulated by a different simulator.
It's the other way around: the simulator that DDD calls can't simulate it.
Other simulators give the same result as when run directly. The behaviour
of DDD is fixed.
Every simulator running a program that calls that same simulator
makes a mistake.

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

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

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

Back to top | Article view | sci.logic

csiph-web