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

Groups > comp.theory > #107139 > unrolled thread

H(D,D) cannot even be asked about the behavior of D(D) V2

Back to article view | Back to comp.theory

Contents

  H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-14 22:07 -0500
    Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-14 23:40 -0400
      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-14 22:53 -0500
        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 06:56 -0400
          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-15 08:32 -0500
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 joes <noreply@example.com> - 2024-06-15 11:57 +0000
          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-15 07:30 -0500
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Python <python@invalid.org> - 2024-06-15 14:57 +0200
              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-15 08:17 -0500
                Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
    Re: H(D,D) cannot even be asked about the behavior of D(D) V2 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-15 11:08 +0200
      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-15 07:14 -0500
        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-15 16:15 +0200
          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-15 09:28 -0500
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 10:41 -0400
    Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Mikko <mikko.levanto@iki.fi> - 2024-06-15 15:19 +0300
      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-15 08:14 -0500
        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-15 09:52 -0400
        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Mikko <mikko.levanto@iki.fi> - 2024-06-16 10:50 +0300
          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-16 07:44 -0500
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 joes <noreply@example.com> - 2024-06-16 14:16 +0000
              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Python <python@invalid.org> - 2024-06-16 16:38 +0200
              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-16 09:41 -0500
                Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Alan Mackenzie <acm@muc.de> - 2024-06-16 15:02 +0000
                  Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-16 12:44 -0500
                    Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 14:06 -0400
                      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-16 13:10 -0500
                        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 14:33 -0400
                          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-16 13:50 -0500
                            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 15:01 -0400
                              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:33 -0500
                                Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-17 18:54 -0400
                    Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Alan Mackenzie <acm@muc.de> - 2024-06-16 21:06 +0000
                      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 17:36 -0400
                      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 André G. Isaak <agisaak@gm.invalid> - 2024-06-16 15:58 -0600
                        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Python <python@invalid.org> - 2024-06-17 00:21 +0200
                          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 19:26 -0400
                            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 André G. Isaak <agisaak@gm.invalid> - 2024-06-16 18:33 -0600
                            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 André G. Isaak <agisaak@gm.invalid> - 2024-06-16 18:44 -0600
                              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 21:12 -0400
                              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:19 -0500
                                Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-17 18:55 -0400
                            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:17 -0500
                              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-17 19:11 -0400
                        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:14 -0500
                      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:14 -0500
                      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:43 -0500
                        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 16:13 +0200
                          Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 09:33 -0500
                            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-17 16:48 +0200
                        Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-17 19:13 -0400
                    Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Mikko <mikko.levanto@iki.fi> - 2024-06-17 10:39 +0300
                      Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:13 -0500
                Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 13:30 -0400
              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Mikko <mikko.levanto@iki.fi> - 2024-06-17 10:36 +0300
                Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:13 -0500
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Richard Damon <richard@damon-family.org> - 2024-06-16 13:30 -0400
            Re: H(D,D) cannot even be asked about the behavior of D(D) V2 Mikko <mikko.levanto@iki.fi> - 2024-06-17 10:32 +0300
              Re: H(D,D) cannot even be asked about the behavior of D(D) V2 olcott <polcott333@gmail.com> - 2024-06-17 08:12 -0500

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

#107175

On 6/15/24 9:14 AM, olcott wrote:
> On 6/15/2024 7:19 AM, Mikko wrote:
>> On 2024-06-15 03:07:14 +0000, olcott said:
>>
>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>  > On 6/13/24 11:32 AM, olcott wrote:
>>>  >>
>>>  >> It is contingent upon you to show the exact steps of how H computes
>>>  >> the mapping from the x86 machine language finite string input to
>>>  >> H(D,D) using the finite string transformation rules specified by
>>>  >> the semantics of the x86 programming language that reaches the
>>>  >> behavior of the directly executed D(D)
>>>  >>
>>>  >
>>>  > Why? I don't claim it can.
>>>
>>> _D()
>>> [00000cfc](01) 55          push ebp
>>> [00000cfd](02) 8bec        mov ebp,esp
>>> [00000cff](03) 8b4508      mov eax,[ebp+08]
>>> [00000d02](01) 50          push eax       ; push D
>>> [00000d03](03) 8b4d08      mov ecx,[ebp+08]
>>> [00000d06](01) 51          push ecx       ; push D
>>> [00000d07](05) e800feffff  call 00000b0c  ; call H
>>> [00000d0c](03) 83c408      add esp,+08
>>> [00000d0f](02) 85c0        test eax,eax
>>> [00000d11](02) 7404        jz 00000d17
>>> [00000d13](02) 33c0        xor eax,eax
>>> [00000d15](02) eb05        jmp 00000d1c
>>> [00000d17](05) b801000000  mov eax,00000001
>>> [00000d1c](01) 5d          pop ebp
>>> [00000d1d](01) c3          ret
>>> Size in bytes:(0034) [00000d1d]
>>>
>>> If there is no mapping from the input to H(D,D) to the behavior
>>> of D(D) then H is not even being asked about the behavior of D(D).
>>> H has no obligation to answer questions *THAT IT IS NOT BEING ASKED*
>>
>> The halting problem specification does not say that a halt decider
>> can be asked questions. 
> 
> *It assumes that you already know that*
> In computability theory and computational complexity theory, a
> decision problem is a computational problem that can be posed
> as a yes–no question of the input values.
> https://en.wikipedia.org/wiki/Decision_problem


So, you agree that H doesn't need to "Understand" the question asked, 
just give the answer.

And, the yes-no question posed to a Halt Decider is: "Does the Machine 
represented by your input Halt when run?", so that is the question that 
H is supposed to answer.

And since D(D) will halt since H(D,D) returns 0, we can show that the 
mapping of (D,D) is to Yes, it halts, so H was wrong to say no.

> 
> Likewise algebra textbooks assume that you already know
> arithmetic.
> 
>> It requires that a description of a Turing
>> macine and a description of an input to that Turing machine can
>> be given as an input.
>>
> 
> Yes and the above x86 machine code is the x86 equivalent
> of a Turing Machine description.
> This input DOES NOT MAP TO THE BEHAVIOR OF D(D)

Nope. it needs (and you implicitly include) all the machine code in the 
program, that of H and everthing it calls.

If you claim that is the only machine code, then you don't have a 
properly constructed D.

> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (g) goto (d) with one more level of simulation
> 
> Two complete simulations show a pair of identical TMD's are
> simulating a pair of identical inputs. We can see this thus
> proving recursive simulation.
> 

Nope, because you ignore the fact that all the simulations that were 
simulatd were CONDITIONALLY simulated, and that those simulation WILL 
terminate their simulation and return to the simulated D and that will halt.

You might be able to show that no version H can simulate the input based 
on it to the end, but that isn't the question being asked.

The question is does THIS input, with THIS SPECIFIED D, which has been 
pair with a particular H, will halt when run.

This is why the input NEEDS to include the code of the H it is built on, 
as that is part of the definition of D.

You are just showing you don't understand the problem you are talking 
about, but instead you have taken off to fight a strawman.

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

#107260

On 2024-06-15 13:14:57 +0000, olcott said:

> On 6/15/2024 7:19 AM, Mikko wrote:
>> On 2024-06-15 03:07:14 +0000, olcott said:
>> 
>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>  > On 6/13/24 11:32 AM, olcott wrote:
>>>  >>
>>>  >> It is contingent upon you to show the exact steps of how H computes
>>>  >> the mapping from the x86 machine language finite string input to
>>>  >> H(D,D) using the finite string transformation rules specified by
>>>  >> the semantics of the x86 programming language that reaches the
>>>  >> behavior of the directly executed D(D)
>>>  >>
>>>  >
>>>  > Why? I don't claim it can.
>>> 
>>> _D()
>>> [00000cfc](01) 55          push ebp
>>> [00000cfd](02) 8bec        mov ebp,esp
>>> [00000cff](03) 8b4508      mov eax,[ebp+08]
>>> [00000d02](01) 50          push eax       ; push D
>>> [00000d03](03) 8b4d08      mov ecx,[ebp+08]
>>> [00000d06](01) 51          push ecx       ; push D
>>> [00000d07](05) e800feffff  call 00000b0c  ; call H
>>> [00000d0c](03) 83c408      add esp,+08
>>> [00000d0f](02) 85c0        test eax,eax
>>> [00000d11](02) 7404        jz 00000d17
>>> [00000d13](02) 33c0        xor eax,eax
>>> [00000d15](02) eb05        jmp 00000d1c
>>> [00000d17](05) b801000000  mov eax,00000001
>>> [00000d1c](01) 5d          pop ebp
>>> [00000d1d](01) c3          ret
>>> Size in bytes:(0034) [00000d1d]
>>> 
>>> If there is no mapping from the input to H(D,D) to the behavior
>>> of D(D) then H is not even being asked about the behavior of D(D).
>>> H has no obligation to answer questions *THAT IT IS NOT BEING ASKED*
>> 
>> The halting problem specification does not say that a halt decider
>> can be asked questions.
> 
> *It assumes that you already know that*

What assumes? Why would it assume anything about me?

> In computability theory and computational complexity theory, a
> decision problem is a computational problem that can be posed
> as a yes–no question of the input values.
> https://en.wikipedia.org/wiki/Decision_problem

That's true. But a decider cannot be asked a question. Whenever a
decider is run it answers the question it is made to answer. The
input to the decider is a part of the question but is not itself
a question.

However, every decision problem can be presented differently,
whithout posing a qeustion.

-- 
Mikko

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

#107268

On 6/16/2024 2:50 AM, Mikko wrote:
> On 2024-06-15 13:14:57 +0000, olcott said:
> 
>> On 6/15/2024 7:19 AM, Mikko wrote:
>>> On 2024-06-15 03:07:14 +0000, olcott said:
>>>
>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>  > On 6/13/24 11:32 AM, olcott wrote:
>>>>  >>
>>>>  >> It is contingent upon you to show the exact steps of how H computes
>>>>  >> the mapping from the x86 machine language finite string input to
>>>>  >> H(D,D) using the finite string transformation rules specified by
>>>>  >> the semantics of the x86 programming language that reaches the
>>>>  >> behavior of the directly executed D(D)
>>>>  >>
>>>>  >
>>>>  > Why? I don't claim it can.
>>>>
>>>> _D()
>>>> [00000cfc](01) 55          push ebp
>>>> [00000cfd](02) 8bec        mov ebp,esp
>>>> [00000cff](03) 8b4508      mov eax,[ebp+08]
>>>> [00000d02](01) 50          push eax       ; push D
>>>> [00000d03](03) 8b4d08      mov ecx,[ebp+08]
>>>> [00000d06](01) 51          push ecx       ; push D
>>>> [00000d07](05) e800feffff  call 00000b0c  ; call H
>>>> [00000d0c](03) 83c408      add esp,+08
>>>> [00000d0f](02) 85c0        test eax,eax
>>>> [00000d11](02) 7404        jz 00000d17
>>>> [00000d13](02) 33c0        xor eax,eax
>>>> [00000d15](02) eb05        jmp 00000d1c
>>>> [00000d17](05) b801000000  mov eax,00000001
>>>> [00000d1c](01) 5d          pop ebp
>>>> [00000d1d](01) c3          ret
>>>> Size in bytes:(0034) [00000d1d]
>>>>
>>>> If there is no mapping from the input to H(D,D) to the behavior
>>>> of D(D) then H is not even being asked about the behavior of D(D).
>>>> H has no obligation to answer questions *THAT IT IS NOT BEING ASKED*
>>>
>>> The halting problem specification does not say that a halt decider
>>> can be asked questions.
>>
>> *It assumes that you already know that*
> 
> What assumes? Why would it assume anything about me?
> 
>> In computability theory and computational complexity theory, a
>> decision problem is a computational problem that can be posed
>> as a yes–no question of the input values.
>> https://en.wikipedia.org/wiki/Decision_problem
> 
> That's true. But a decider cannot be asked a question.

The input to a decider is isomorphic to a yes or no question.

> Whenever a
> decider is run it answers the question it is made to answer.

Not necessarily. Just because everyone falsely assumes that D
correctly simulated by H must have the same behavior as the
directly executed D(D) does not make this false assumption true.

>  The
> input to the decider is a part of the question but is not itself
> a question.
> 

The combination of the input and the algorithm is the question.
H is only asked about the behavior of D correctly simulated by H
and is not asked about the behavior of the directly executed D(D).

Just because everyone assumes that they must be the same does not
make this assumption correct.

> However, every decision problem can be presented differently,
> whithout posing a qeustion.
> 

That is incorrect. Also it must be a yes / no question.
If you ask a decider what it the value of 5 * 6, it stops
being a decider.

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

#107275

Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
> On 6/16/2024 2:50 AM, Mikko wrote:
>> On 2024-06-15 13:14:57 +0000, olcott said:
>>> On 6/15/2024 7:19 AM, Mikko wrote:
>>>> On 2024-06-15 03:07:14 +0000, olcott said:
>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>  > On 6/13/24 11:32 AM, olcott wrote:

>> Whenever a decider is run it answers the question it is made to answer.
> Not necessarily. Just because everyone falsely assumes that D correctly
> simulated by H must have the same behavior as the directly executed D(D)
> does not make this false assumption true.
You still need to explain how you can call a simulation that differs from
the behaviour of its input "correct".

> H is only asked about the behavior of D simulated by H and is
> not asked about the behavior of the directly executed D(D).
If H is a simulator, it must simulate the execution of D(D).
H does not compute the answer to "What does H say about its input?",
since it could answer anything then.
It makes no sense to call a wrong answer the correct answer to a different
question.

-- 
joes

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

#107276

Le 16/06/2024 à 16:16, joes a écrit :
> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>> On 6/16/2024 2:50 AM, Mikko wrote:
>>> On 2024-06-15 13:14:57 +0000, olcott said:
>>>> On 6/15/2024 7:19 AM, Mikko wrote:
>>>>> On 2024-06-15 03:07:14 +0000, olcott said:
>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>   > On 6/13/24 11:32 AM, olcott wrote:
> 
>>> Whenever a decider is run it answers the question it is made to answer.
>> Not necessarily. Just because everyone falsely assumes that D correctly
>> simulated by H must have the same behavior as the directly executed D(D)
>> does not make this false assumption true.
> You still need to explain how you can call a simulation that differs from
> the behaviour of its input "correct".
> 
>> H is only asked about the behavior of D simulated by H and is
>> not asked about the behavior of the directly executed D(D).
> If H is a simulator, it must simulate the execution of D(D).
> H does not compute the answer to "What does H say about its input?",
> since it could answer anything then.
> It makes no sense to call a wrong answer the correct answer to a different
> question.
> 

Exactly. Olcott is bringing the motto "It is not a bug it is a feature"
into theory of computing.

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

#107277

On 6/16/2024 9:16 AM, joes wrote:
> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>> On 6/16/2024 2:50 AM, Mikko wrote:
>>> On 2024-06-15 13:14:57 +0000, olcott said:
>>>> On 6/15/2024 7:19 AM, Mikko wrote:
>>>>> On 2024-06-15 03:07:14 +0000, olcott said:
>>>>>> On 6/13/2024 8:24 PM, Richard Damon wrote:
>>>>>>   > On 6/13/24 11:32 AM, olcott wrote:
> 
>>> Whenever a decider is run it answers the question it is made to answer.
>> Not necessarily. Just because everyone falsely assumes that D correctly
>> simulated by H must have the same behavior as the directly executed D(D)
>> does not make this false assumption true.

> You still need to explain how you can call a simulation that differs from
> the behaviour of its input "correct".
> 

I have proven it many times and this proof is simply over
everyone's heads. When I ask what your C programming skill
level is, this *is not* a rhetorical question.

00   typedef void (*ptr)(); // pointer to void function
01
02   int H0(ptr P);
03
04   void DDD()
05   {
06     H0(DDD);
07     return;
08   }
09
10   int main()
11   {
12     H0(DDD);
13   }

Line 12 main()
   invokes H0(DDD); that simulates DDD()

*REPEAT UNTIL outer H0 aborts*
   Line 06 simulated DDD()
   invokes simulated H0(DDD); that simulates DDD()

DDD correctly simulated by H0 never reaches its own "return"
instruction and halts.

>> H is only asked about the behavior of D simulated by H and is
>> not asked about the behavior of the directly executed D(D). >>
> If H is a simulator, it must simulate the execution of D(D).

I have proven this to be a false assumption and people
maintain this false assumption entirely on the basis
that my proof is over their heads.

> H does not compute the answer to "What does H say about its input?",
> since it could answer anything then.
> It makes no sense to call a wrong answer the correct answer to a different
> question.
> 

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

#107278

olcott <polcott333@gmail.com> wrote:
> On 6/16/2024 9:16 AM, joes wrote:
>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>> On 6/16/2024 2:50 AM, Mikko wrote:

>>>> Whenever a decider is run it answers the question it is made to answer.
>>> Not necessarily. Just because everyone falsely assumes that D correctly
>>> simulated by H must have the same behavior as the directly executed D(D)
>>> does not make this false assumption true.

>> You still need to explain how you can call a simulation that differs from
>> the behaviour of its input "correct".

Indeed, you do.

> I have proven it many times and this proof is simply over
> everyone's heads.

Nonsense!  How about, instead of "proving", actually explaining?  If a
simulation differs from its original, it's not a simulation; it's just a
random program.

> When I ask what your C programming skill level is, this *is not* a
> rhetorical question.

The question has nothing to do with C programming.

[ .... ]

>> If H is a simulator, it must simulate the execution of D(D).

> I have proven this to be a false assumption ....

It isn't an assumption, it's a definition.

> .... and people maintain this false assumption entirely on the basis
> that my proof is over their heads.

Most of the people on this newgroup, apart from yourself, are experts on
the subject.  Nothing you can conjure up is going to be "over their
heads".  They've seen it all before.

>> H does not compute the answer to "What does H say about its input?",
>> since it could answer anything then.
>> It makes no sense to call a wrong answer the correct answer to a different
>> question.

Indeed.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#107286

On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
> olcott <polcott333@gmail.com> wrote:
>> On 6/16/2024 9:16 AM, joes wrote:
>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>> On 6/16/2024 2:50 AM, Mikko wrote:
> 
>>>>> Whenever a decider is run it answers the question it is made to answer.
>>>> Not necessarily. Just because everyone falsely assumes that D correctly
>>>> simulated by H must have the same behavior as the directly executed D(D)
>>>> does not make this false assumption true.
> 
>>> You still need to explain how you can call a simulation that differs from
>>> the behaviour of its input "correct".
> 
> Indeed, you do.
> 
>> I have proven it many times and this proof is simply over
>> everyone's heads.
> 
> Nonsense!  How about, instead of "proving", actually explaining?  If a
> simulation differs from its original, it's not a simulation; it's just a
> random program.
> 
>> When I ask what your C programming skill level is, this *is not* a
>> rhetorical question.
> 
> The question has nothing to do with C programming.
> 

typedef void (*ptr)(); // pointer to void function
int H(ptr P, ptr I);

int D(int (*x)())
{
   int Halt_Status = H(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Unless I make every single detail 100% explicit false
assumptions always slip though the cracks. The ONLY way
to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
programming language.

There cannot possibly be any H that correctly emulates
the x86 machine code of D according to the semantics
of the x86 programming language such that the emulated
D ever reaches its own emulated final state at machine
address [00001f58].

_D()
[00001f33] 55         push ebp
[00001f34] 8bec       mov ebp,esp
[00001f36] 51         push ecx
[00001f37] 8b4508     mov eax,[ebp+08]
[00001f3a] 50         push eax        ; push D
[00001f3b] 8b4d08     mov ecx,[ebp+08]
[00001f3e] 51         push ecx        ; push D
[00001f3f] e87ff7ffff call 000016c3   ; call H(D,D)
[00001f44] 83c408     add esp,+08
[00001f47] 8945fc     mov [ebp-04],eax
[00001f4a] 837dfc00   cmp dword [ebp-04],+00
[00001f4e] 7402       jz 00001f52
[00001f50] ebfe       jmp 00001f50
[00001f52] 8b45fc     mov eax,[ebp-04]
[00001f55] 8be5       mov esp,ebp
[00001f57] 5d         pop ebp
[00001f58] c3         ret
Size in bytes:(0038) [00001f58]

Once the above is understood (people quit denying verified facts).
thenn (then and only then) I can show how this applies to Turing
machines.

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

#107287

On 6/16/24 1:44 PM, olcott wrote:
> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>> olcott <polcott333@gmail.com> wrote:
>>> On 6/16/2024 9:16 AM, joes wrote:
>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>
>>>>>> Whenever a decider is run it answers the question it is made to 
>>>>>> answer.
>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>> correctly
>>>>> simulated by H must have the same behavior as the directly executed 
>>>>> D(D)
>>>>> does not make this false assumption true.
>>
>>>> You still need to explain how you can call a simulation that differs 
>>>> from
>>>> the behaviour of its input "correct".
>>
>> Indeed, you do.
>>
>>> I have proven it many times and this proof is simply over
>>> everyone's heads.
>>
>> Nonsense!  How about, instead of "proving", actually explaining?  If a
>> simulation differs from its original, it's not a simulation; it's just a
>> random program.
>>
>>> When I ask what your C programming skill level is, this *is not* a
>>> rhetorical question.
>>
>> The question has nothing to do with C programming.
>>
> 
> typedef void (*ptr)(); // pointer to void function
> int H(ptr P, ptr I);
> 
> int D(int (*x)())
> {
>    int Halt_Status = H(x, x);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> Unless I make every single detail 100% explicit false
> assumptions always slip though the cracks. The ONLY way
> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
> programming language.
> 
> There cannot possibly be any H that correctly emulates
> the x86 machine code of D according to the semantics
> of the x86 programming language such that the emulated
> D ever reaches its own emulated final state at machine
> address [00001f58].
> 

Which is just a strawman, as the requirement on H is NOT to answer about 
"D correctly simulated by H" but about "the program represented by the 
input directly executed", or equivalently, simulated by an actual UTM, 
which is a simulator that NEVER stops until it reaches a final state.

For this input, D(D), since H(D,D) returns 0, D(D) will Halt, so H is 
just wrong by definition, and you by the attempt to use a strawman.

> _D()
> [00001f33] 55         push ebp
> [00001f34] 8bec       mov ebp,esp
> [00001f36] 51         push ecx
> [00001f37] 8b4508     mov eax,[ebp+08]
> [00001f3a] 50         push eax        ; push D
> [00001f3b] 8b4d08     mov ecx,[ebp+08]
> [00001f3e] 51         push ecx        ; push D
> [00001f3f] e87ff7ffff call 000016c3   ; call H(D,D)
> [00001f44] 83c408     add esp,+08
> [00001f47] 8945fc     mov [ebp-04],eax
> [00001f4a] 837dfc00   cmp dword [ebp-04],+00
> [00001f4e] 7402       jz 00001f52
> [00001f50] ebfe       jmp 00001f50
> [00001f52] 8b45fc     mov eax,[ebp-04]
> [00001f55] 8be5       mov esp,ebp
> [00001f57] 5d         pop ebp
> [00001f58] c3         ret
> Size in bytes:(0038) [00001f58]
> 
> Once the above is understood (people quit denying verified facts).
> thenn (then and only then) I can show how this applies to Turing
> machines.
> 

No, YOU are the one denying DEFINED FACTS.

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

#107288

On 6/16/2024 1:06 PM, Richard Damon wrote:
> On 6/16/24 1:44 PM, olcott wrote:
>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>> olcott <polcott333@gmail.com> wrote:
>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>>
>>>>>>> Whenever a decider is run it answers the question it is made to 
>>>>>>> answer.
>>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>>> correctly
>>>>>> simulated by H must have the same behavior as the directly 
>>>>>> executed D(D)
>>>>>> does not make this false assumption true.
>>>
>>>>> You still need to explain how you can call a simulation that 
>>>>> differs from
>>>>> the behaviour of its input "correct".
>>>
>>> Indeed, you do.
>>>
>>>> I have proven it many times and this proof is simply over
>>>> everyone's heads.
>>>
>>> Nonsense!  How about, instead of "proving", actually explaining?  If a
>>> simulation differs from its original, it's not a simulation; it's just a
>>> random program.
>>>
>>>> When I ask what your C programming skill level is, this *is not* a
>>>> rhetorical question.
>>>
>>> The question has nothing to do with C programming.
>>>
>>
>> typedef void (*ptr)(); // pointer to void function
>> int H(ptr P, ptr I);
>>
>> int D(int (*x)())
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> Unless I make every single detail 100% explicit false
>> assumptions always slip though the cracks. The ONLY way
>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>> programming language.
>>
>> There cannot possibly be any H that correctly emulates
>> the x86 machine code of D according to the semantics
>> of the x86 programming language such that the emulated
>> D ever reaches its own emulated final state at machine
>> address [00001f58].
>>
> 
> Which is just a strawman, as the requirement on H is NOT to answer about 
> "D correctly simulated by H" but about "the program represented by the 
> input directly executed", or equivalently, simulated by an actual UTM, 
> which is a simulator that NEVER stops until it reaches a final state.
> 

This is simply over-your-head.
I am very glad of that because the alternative would
possibly condemn your soul to Hell.

> For this input, D(D), since H(D,D) returns 0, D(D) will Halt, so H is 
> just wrong by definition, and you by the attempt to use a strawman.
> 
>> _D()
>> [00001f33] 55         push ebp
>> [00001f34] 8bec       mov ebp,esp
>> [00001f36] 51         push ecx
>> [00001f37] 8b4508     mov eax,[ebp+08]
>> [00001f3a] 50         push eax        ; push D
>> [00001f3b] 8b4d08     mov ecx,[ebp+08]
>> [00001f3e] 51         push ecx        ; push D
>> [00001f3f] e87ff7ffff call 000016c3   ; call H(D,D)
>> [00001f44] 83c408     add esp,+08
>> [00001f47] 8945fc     mov [ebp-04],eax
>> [00001f4a] 837dfc00   cmp dword [ebp-04],+00
>> [00001f4e] 7402       jz 00001f52
>> [00001f50] ebfe       jmp 00001f50
>> [00001f52] 8b45fc     mov eax,[ebp-04]
>> [00001f55] 8be5       mov esp,ebp
>> [00001f57] 5d         pop ebp
>> [00001f58] c3         ret
>> Size in bytes:(0038) [00001f58]
>>
>> Once the above is understood (people quit denying verified facts).
>> thenn (then and only then) I can show how this applies to Turing
>> machines.
>>
> 
> No, YOU are the one denying DEFINED FACTS.

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

#107289

On 6/16/24 2:10 PM, olcott wrote:
> On 6/16/2024 1:06 PM, Richard Damon wrote:
>> On 6/16/24 1:44 PM, olcott wrote:
>>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>>> olcott <polcott333@gmail.com> wrote:
>>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>>>
>>>>>>>> Whenever a decider is run it answers the question it is made to 
>>>>>>>> answer.
>>>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>>>> correctly
>>>>>>> simulated by H must have the same behavior as the directly 
>>>>>>> executed D(D)
>>>>>>> does not make this false assumption true.
>>>>
>>>>>> You still need to explain how you can call a simulation that 
>>>>>> differs from
>>>>>> the behaviour of its input "correct".
>>>>
>>>> Indeed, you do.
>>>>
>>>>> I have proven it many times and this proof is simply over
>>>>> everyone's heads.
>>>>
>>>> Nonsense!  How about, instead of "proving", actually explaining?  If a
>>>> simulation differs from its original, it's not a simulation; it's 
>>>> just a
>>>> random program.
>>>>
>>>>> When I ask what your C programming skill level is, this *is not* a
>>>>> rhetorical question.
>>>>
>>>> The question has nothing to do with C programming.
>>>>
>>>
>>> typedef void (*ptr)(); // pointer to void function
>>> int H(ptr P, ptr I);
>>>
>>> int D(int (*x)())
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>>> Unless I make every single detail 100% explicit false
>>> assumptions always slip though the cracks. The ONLY way
>>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>>> programming language.
>>>
>>> There cannot possibly be any H that correctly emulates
>>> the x86 machine code of D according to the semantics
>>> of the x86 programming language such that the emulated
>>> D ever reaches its own emulated final state at machine
>>> address [00001f58].
>>>
>>
>> Which is just a strawman, as the requirement on H is NOT to answer 
>> about "D correctly simulated by H" but about "the program represented 
>> by the input directly executed", or equivalently, simulated by an 
>> actual UTM, which is a simulator that NEVER stops until it reaches a 
>> final state.
>>
> 
> This is simply over-your-head.
> I am very glad of that because the alternative would
> possibly condemn your soul to Hell.

Whats over my head? That the definition of a Halt Decider beihg that it 
decides on the behavior of the program represented by the input halting 
when run?

That seems beyound YOUR understanding, so you just keep on lying about it.

Since you don't seem to actually believe in Hell, why should you care, 
after all, "Hell" isn't in the parts about "God's Love" which is the 
only parts you will accept.

Now, the fact that he says that for those who reject his words, there 
will be a judgement, you better be pretty sure you can ignore those 
other parts.

> 
>> For this input, D(D), since H(D,D) returns 0, D(D) will Halt, so H is 
>> just wrong by definition, and you by the attempt to use a strawman.
>>
>>> _D()
>>> [00001f33] 55         push ebp
>>> [00001f34] 8bec       mov ebp,esp
>>> [00001f36] 51         push ecx
>>> [00001f37] 8b4508     mov eax,[ebp+08]
>>> [00001f3a] 50         push eax        ; push D
>>> [00001f3b] 8b4d08     mov ecx,[ebp+08]
>>> [00001f3e] 51         push ecx        ; push D
>>> [00001f3f] e87ff7ffff call 000016c3   ; call H(D,D)
>>> [00001f44] 83c408     add esp,+08
>>> [00001f47] 8945fc     mov [ebp-04],eax
>>> [00001f4a] 837dfc00   cmp dword [ebp-04],+00
>>> [00001f4e] 7402       jz 00001f52
>>> [00001f50] ebfe       jmp 00001f50
>>> [00001f52] 8b45fc     mov eax,[ebp-04]
>>> [00001f55] 8be5       mov esp,ebp
>>> [00001f57] 5d         pop ebp
>>> [00001f58] c3         ret
>>> Size in bytes:(0038) [00001f58]
>>>
>>> Once the above is understood (people quit denying verified facts).
>>> thenn (then and only then) I can show how this applies to Turing
>>> machines.
>>>
>>
>> No, YOU are the one denying DEFINED FACTS.
> 

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

#107290

On 6/16/2024 1:33 PM, Richard Damon wrote:
> On 6/16/24 2:10 PM, olcott wrote:
>> On 6/16/2024 1:06 PM, Richard Damon wrote:
>>> On 6/16/24 1:44 PM, olcott wrote:
>>>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>>>>
>>>>>>>>> Whenever a decider is run it answers the question it is made to 
>>>>>>>>> answer.
>>>>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>>>>> correctly
>>>>>>>> simulated by H must have the same behavior as the directly 
>>>>>>>> executed D(D)
>>>>>>>> does not make this false assumption true.
>>>>>
>>>>>>> You still need to explain how you can call a simulation that 
>>>>>>> differs from
>>>>>>> the behaviour of its input "correct".
>>>>>
>>>>> Indeed, you do.
>>>>>
>>>>>> I have proven it many times and this proof is simply over
>>>>>> everyone's heads.
>>>>>
>>>>> Nonsense!  How about, instead of "proving", actually explaining?  If a
>>>>> simulation differs from its original, it's not a simulation; it's 
>>>>> just a
>>>>> random program.
>>>>>
>>>>>> When I ask what your C programming skill level is, this *is not* a
>>>>>> rhetorical question.
>>>>>
>>>>> The question has nothing to do with C programming.
>>>>>
>>>>
>>>> typedef void (*ptr)(); // pointer to void function
>>>> int H(ptr P, ptr I);
>>>>
>>>> int D(int (*x)())
>>>> {
>>>>    int Halt_Status = H(x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return Halt_Status;
>>>> }
>>>>
>>>> Unless I make every single detail 100% explicit false
>>>> assumptions always slip though the cracks. The ONLY way
>>>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>>>> programming language.
>>>>
>>>> There cannot possibly be any H that correctly emulates
>>>> the x86 machine code of D according to the semantics
>>>> of the x86 programming language such that the emulated
>>>> D ever reaches its own emulated final state at machine
>>>> address [00001f58].
>>>>
>>>
>>> Which is just a strawman, as the requirement on H is NOT to answer 
>>> about "D correctly simulated by H" but about "the program represented 
>>> by the input directly executed", or equivalently, simulated by an 
>>> actual UTM, which is a simulator that NEVER stops until it reaches a 
>>> final state.
>>>
>>
>> This is simply over-your-head.
>> I am very glad of that because the alternative would
>> possibly condemn your soul to Hell.
> 
> Whats over my head? That the definition of a Halt Decider beihg that it 
> decides on the behavior of the program represented by the input halting 
> when run?
> 

void DD0()
{
   HH0(DD0);
}

int main()
{
   HH0(DD0);
}

That the machine language finite string input DD0
to any simulating halt decider HH0(DD0) cannot
possibly even ask about the behavior of DD0().

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

#107291

On 6/16/24 2:50 PM, olcott wrote:
> On 6/16/2024 1:33 PM, Richard Damon wrote:
>> On 6/16/24 2:10 PM, olcott wrote:
>>> On 6/16/2024 1:06 PM, Richard Damon wrote:
>>>> On 6/16/24 1:44 PM, olcott wrote:
>>>>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>>>>>
>>>>>>>>>> Whenever a decider is run it answers the question it is made 
>>>>>>>>>> to answer.
>>>>>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>>>>>> correctly
>>>>>>>>> simulated by H must have the same behavior as the directly 
>>>>>>>>> executed D(D)
>>>>>>>>> does not make this false assumption true.
>>>>>>
>>>>>>>> You still need to explain how you can call a simulation that 
>>>>>>>> differs from
>>>>>>>> the behaviour of its input "correct".
>>>>>>
>>>>>> Indeed, you do.
>>>>>>
>>>>>>> I have proven it many times and this proof is simply over
>>>>>>> everyone's heads.
>>>>>>
>>>>>> Nonsense!  How about, instead of "proving", actually explaining?  
>>>>>> If a
>>>>>> simulation differs from its original, it's not a simulation; it's 
>>>>>> just a
>>>>>> random program.
>>>>>>
>>>>>>> When I ask what your C programming skill level is, this *is not* a
>>>>>>> rhetorical question.
>>>>>>
>>>>>> The question has nothing to do with C programming.
>>>>>>
>>>>>
>>>>> typedef void (*ptr)(); // pointer to void function
>>>>> int H(ptr P, ptr I);
>>>>>
>>>>> int D(int (*x)())
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return Halt_Status;
>>>>> }
>>>>>
>>>>> Unless I make every single detail 100% explicit false
>>>>> assumptions always slip though the cracks. The ONLY way
>>>>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>>>>> programming language.
>>>>>
>>>>> There cannot possibly be any H that correctly emulates
>>>>> the x86 machine code of D according to the semantics
>>>>> of the x86 programming language such that the emulated
>>>>> D ever reaches its own emulated final state at machine
>>>>> address [00001f58].
>>>>>
>>>>
>>>> Which is just a strawman, as the requirement on H is NOT to answer 
>>>> about "D correctly simulated by H" but about "the program 
>>>> represented by the input directly executed", or equivalently, 
>>>> simulated by an actual UTM, which is a simulator that NEVER stops 
>>>> until it reaches a final state.
>>>>
>>>
>>> This is simply over-your-head.
>>> I am very glad of that because the alternative would
>>> possibly condemn your soul to Hell.
>>
>> Whats over my head? That the definition of a Halt Decider beihg that 
>> it decides on the behavior of the program represented by the input 
>> halting when run?
>>
> 
> void DD0()
> {
>    HH0(DD0);
> }
> 
> int main()
> {
>    HH0(DD0);
> }
> 
> That the machine language finite string input DD0
> to any simulating halt decider HH0(DD0) cannot
> possibly even ask about the behavior of DD0().
> 

Because it doesn't NEED to.

By being called a "Halt Decider", HH0 DEFINES what question it is being 
asked, the only question are the parameters of the question, which is 
What is the Program and input to decide on.

You are just showing you are absoluting IGNORANT of what you talk about, 
and have been just LYING about it for years.

I'm sorry, but I think your "license to do logic" has been revoked, and 
you are being punished for attempted murder on logic.

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

#107323

On 6/16/2024 2:01 PM, Richard Damon wrote:
> On 6/16/24 2:50 PM, olcott wrote:
>> On 6/16/2024 1:33 PM, Richard Damon wrote:
>>> On 6/16/24 2:10 PM, olcott wrote:
>>>> On 6/16/2024 1:06 PM, Richard Damon wrote:
>>>>> On 6/16/24 1:44 PM, olcott wrote:
>>>>>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>>>>>>
>>>>>>>>>>> Whenever a decider is run it answers the question it is made 
>>>>>>>>>>> to answer.
>>>>>>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>>>>>>> correctly
>>>>>>>>>> simulated by H must have the same behavior as the directly 
>>>>>>>>>> executed D(D)
>>>>>>>>>> does not make this false assumption true.
>>>>>>>
>>>>>>>>> You still need to explain how you can call a simulation that 
>>>>>>>>> differs from
>>>>>>>>> the behaviour of its input "correct".
>>>>>>>
>>>>>>> Indeed, you do.
>>>>>>>
>>>>>>>> I have proven it many times and this proof is simply over
>>>>>>>> everyone's heads.
>>>>>>>
>>>>>>> Nonsense!  How about, instead of "proving", actually explaining? 
>>>>>>> If a
>>>>>>> simulation differs from its original, it's not a simulation; it's 
>>>>>>> just a
>>>>>>> random program.
>>>>>>>
>>>>>>>> When I ask what your C programming skill level is, this *is not* a
>>>>>>>> rhetorical question.
>>>>>>>
>>>>>>> The question has nothing to do with C programming.
>>>>>>>
>>>>>>
>>>>>> typedef void (*ptr)(); // pointer to void function
>>>>>> int H(ptr P, ptr I);
>>>>>>
>>>>>> int D(int (*x)())
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)
>>>>>>      HERE: goto HERE;
>>>>>>    return Halt_Status;
>>>>>> }
>>>>>>
>>>>>> Unless I make every single detail 100% explicit false
>>>>>> assumptions always slip though the cracks. The ONLY way
>>>>>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>>>>>> programming language.
>>>>>>
>>>>>> There cannot possibly be any H that correctly emulates
>>>>>> the x86 machine code of D according to the semantics
>>>>>> of the x86 programming language such that the emulated
>>>>>> D ever reaches its own emulated final state at machine
>>>>>> address [00001f58].
>>>>>>
>>>>>
>>>>> Which is just a strawman, as the requirement on H is NOT to answer 
>>>>> about "D correctly simulated by H" but about "the program 
>>>>> represented by the input directly executed", or equivalently, 
>>>>> simulated by an actual UTM, which is a simulator that NEVER stops 
>>>>> until it reaches a final state.
>>>>>
>>>>
>>>> This is simply over-your-head.
>>>> I am very glad of that because the alternative would
>>>> possibly condemn your soul to Hell.
>>>
>>> Whats over my head? That the definition of a Halt Decider beihg that 
>>> it decides on the behavior of the program represented by the input 
>>> halting when run?
>>>
>>
>> void DDD()
>> {
>>    H0(DDD);
>> }
>>
>> int main()
>> {
>>    H0(DDD);
>> }
>>
>> That the machine language finite string input DD0
>> to any simulating halt decider HH0(DD0) cannot
>> possibly even ask about the behavior of DD0().
>>
> 
> Because it doesn't NEED to.
> 

I am happy that I found out you are not a liar.
You just don't understand these thing very well.

If a decider is being asked if N > 5?
and the programmer expects the answer to a different question
then the programmer is incorrect.

If the programmer expects H0(DDD) to report on the
behavior of DDD(DDD), then the programmer is incorrect.

> By being called a "Halt Decider", HH0 DEFINES what question it is being 
> asked, the only question are the parameters of the question, which is 
> What is the Program and input to decide on.
> 

H0(DDD) does correctly report on the behavior that its
input specifies and does not report on the behavior that
its input does not specify.

> You are just showing you are absoluting IGNORANT of what you talk about, 
> and have been just LYING about it for years.
> 

No the whole actual issue is that you have always been somewhat
more clueless than I ever expected.

That an input finite string of machine code must be mapped to
the behavior that it specifies through a sequence of finite
string transformation rules according to the semantics of the
x86 language is totally over your head.

Mapping finite strings to behavior is not looking up how
to get to Florida in Google maps.

> I'm sorry, but I think your "license to do logic" has been revoked, and 
> you are being punished for attempted murder on logic.

When you don't have a slight clue about what I said you try
to get away with masking your own ignorance with rhetoric.
*That surely works on dumb bunnies and other clueless wonders*

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

#107339

On 6/17/24 9:33 AM, olcott wrote:
> On 6/16/2024 2:01 PM, Richard Damon wrote:
>> On 6/16/24 2:50 PM, olcott wrote:
>>> On 6/16/2024 1:33 PM, Richard Damon wrote:
>>>> On 6/16/24 2:10 PM, olcott wrote:
>>>>> On 6/16/2024 1:06 PM, Richard Damon wrote:
>>>>>> On 6/16/24 1:44 PM, olcott wrote:
>>>>>>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>>>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
>>>>>>>>
>>>>>>>>>>>> Whenever a decider is run it answers the question it is made 
>>>>>>>>>>>> to answer.
>>>>>>>>>>> Not necessarily. Just because everyone falsely assumes that D 
>>>>>>>>>>> correctly
>>>>>>>>>>> simulated by H must have the same behavior as the directly 
>>>>>>>>>>> executed D(D)
>>>>>>>>>>> does not make this false assumption true.
>>>>>>>>
>>>>>>>>>> You still need to explain how you can call a simulation that 
>>>>>>>>>> differs from
>>>>>>>>>> the behaviour of its input "correct".
>>>>>>>>
>>>>>>>> Indeed, you do.
>>>>>>>>
>>>>>>>>> I have proven it many times and this proof is simply over
>>>>>>>>> everyone's heads.
>>>>>>>>
>>>>>>>> Nonsense!  How about, instead of "proving", actually explaining? 
>>>>>>>> If a
>>>>>>>> simulation differs from its original, it's not a simulation; 
>>>>>>>> it's just a
>>>>>>>> random program.
>>>>>>>>
>>>>>>>>> When I ask what your C programming skill level is, this *is not* a
>>>>>>>>> rhetorical question.
>>>>>>>>
>>>>>>>> The question has nothing to do with C programming.
>>>>>>>>
>>>>>>>
>>>>>>> typedef void (*ptr)(); // pointer to void function
>>>>>>> int H(ptr P, ptr I);
>>>>>>>
>>>>>>> int D(int (*x)())
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> Unless I make every single detail 100% explicit false
>>>>>>> assumptions always slip though the cracks. The ONLY way
>>>>>>> to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>>>>>>> programming language.
>>>>>>>
>>>>>>> There cannot possibly be any H that correctly emulates
>>>>>>> the x86 machine code of D according to the semantics
>>>>>>> of the x86 programming language such that the emulated
>>>>>>> D ever reaches its own emulated final state at machine
>>>>>>> address [00001f58].
>>>>>>>
>>>>>>
>>>>>> Which is just a strawman, as the requirement on H is NOT to answer 
>>>>>> about "D correctly simulated by H" but about "the program 
>>>>>> represented by the input directly executed", or equivalently, 
>>>>>> simulated by an actual UTM, which is a simulator that NEVER stops 
>>>>>> until it reaches a final state.
>>>>>>
>>>>>
>>>>> This is simply over-your-head.
>>>>> I am very glad of that because the alternative would
>>>>> possibly condemn your soul to Hell.
>>>>
>>>> Whats over my head? That the definition of a Halt Decider beihg that 
>>>> it decides on the behavior of the program represented by the input 
>>>> halting when run?
>>>>
>>>
>>> void DDD()
>>> {
>>>    H0(DDD);
>>> }
>>>
>>> int main()
>>> {
>>>    H0(DDD);
>>> }
>>>
>>> That the machine language finite string input DD0
>>> to any simulating halt decider HH0(DD0) cannot
>>> possibly even ask about the behavior of DD0().
>>>
>>
>> Because it doesn't NEED to.
>>
> 
> I am happy that I found out you are not a liar.
> You just don't understand these thing very well.
> 
> If a decider is being asked if N > 5?
> and the programmer expects the answer to a different question
> then the programmer is incorrect.
Right, just like if H0 does anything but report on the behavior of the 
machine described by its inout, then H0's prograam is just incorrect.


> 
> If the programmer expects H0(DDD) to report on the
> behavior of DDD(DDD), then the programmer is incorrect.

No, sinee that is DOCUMENTED DEFINITION of it, since H0 is called a Halt 
Decider.

> 
>> By being called a "Halt Decider", HH0 DEFINES what question it is 
>> being asked, the only question are the parameters of the question, 
>> which is What is the Program and input to decide on.
>>
> 
> H0(DDD) does correctly report on the behavior that its
> input specifies and does not report on the behavior that
> its input does not specify.

So, are you admitting to LYING that H0 is a Halt Decider, or are you 
LYING that you correctly programmed H0?

If H0 is a Halt Decider, the DEFINITION of the "bahavior of its input" 
is the behavior of the program the input describes, which in this case 
is DDD().

> 
>> You are just showing you are absoluting IGNORANT of what you talk 
>> about, and have been just LYING about it for years.
>>
> 
> No the whole actual issue is that you have always been somewhat
> more clueless than I ever expected.

No, you have just been a pathological liar, that just seems to forget 
the defintion of the problem he claims to be working on.

> 
> That an input finite string of machine code must be mapped to
> the behavior that it specifies through a sequence of finite
> string transformation rules according to the semantics of the
> x86 language is totally over your head.

No, it CAN only go to what can be found by a sequence of finite string 
transforms, but to be correct, it must go to the mapping of the function 
it is defined to be computing, which is Halting, which maps the input to 
the behavior of the machine described by the input.

> 
> Mapping finite strings to behavior is not looking up how
> to get to Florida in Google maps.

Right, but for a Halt Decider, it IS the uncomputable mapping to the 
behavior of the program represented by the input.

> 
>> I'm sorry, but I think your "license to do logic" has been revoked, 
>> and you are being punished for attempted murder on logic.
> 
> When you don't have a slight clue about what I said you try
> to get away with masking your own ignorance with rhetoric.
> *That surely works on dumb bunnies and other clueless wonders*
> 

Nope, You re judt showing that you totally don't understadn the basic 
rules of logic, and thus, it is shown that everyone must just ignore 
what you "claim" to be true, as you have shown that it most likely is not.

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

#107293

olcott <polcott333@gmail.com> wrote:
> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>> olcott <polcott333@gmail.com> wrote:
>>> On 6/16/2024 9:16 AM, joes wrote:
>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>> On 6/16/2024 2:50 AM, Mikko wrote:

>>>>>> Whenever a decider is run it answers the question it is made to answer.
>>>>> Not necessarily. Just because everyone falsely assumes that D correctly
>>>>> simulated by H must have the same behavior as the directly executed D(D)
>>>>> does not make this false assumption true.

>>>> You still need to explain how you can call a simulation that differs from
>>>> the behaviour of its input "correct".

>> Indeed, you do.

>>> I have proven it many times and this proof is simply over
>>> everyone's heads.

>> Nonsense!  How about, instead of "proving", actually explaining?  If a
>> simulation differs from its original, it's not a simulation; it's just a
>> random program.

>>> When I ask what your C programming skill level is, this *is not* a
>>> rhetorical question.

>> The question has nothing to do with C programming.

> typedef void (*ptr)(); // pointer to void function
> int H(ptr P, ptr I);

> int D(int (*x)())
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return Halt_Status;
> }

> Unless I make every single detail 100% explicit false
> assumptions always slip though the cracks.

No.  Every single detail just obfuscates and hides the facts.  The
problem is you have been talking absurdities for so long you have
probably come to believe them.  Nobody else is fooled.

> The ONLY way to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
> programming language.

No, that's just a convenient means for obfuscation and expressing
strawmen.

> There cannot possibly be any H that correctly emulates
> the x86 machine code of D according to the semantics
> of the x86 programming language such that the emulated
> D ever reaches its own emulated final state at machine
> address [00001f58].

Emulation, Simulation.  By definition a simulator does the same as what
it's simulating.  If it doesn't, it's not a simulator.  Everybody else
understands that.  Why don't you?

Are you saying above that simulators are impossible?  Everybody else has
understood for a long time that they're not sensible, here.  But
impossible?

[ .... ]

> Once the above is understood (people quit denying verified facts).

You're lying again.  There are no verified facts in the above (which I
snipped).

> thenn (then and only then) I can show how this applies to Turing
> machines.

If you'd've simply stuck to turing machines all along, you could have
avoided a lot of the confusion you've got yourself into.  Why not start
talking about turing machines now?

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#107294

On 6/16/24 5:06 PM, Alan Mackenzie wrote:
> olcott <polcott333@gmail.com> wrote:
>> On 6/16/2024 10:02 AM, Alan Mackenzie wrote:
>>> olcott <polcott333@gmail.com> wrote:
>>>> On 6/16/2024 9:16 AM, joes wrote:
>>>>> Am Sun, 16 Jun 2024 07:44:41 -0500 schrieb olcott:
>>>>>> On 6/16/2024 2:50 AM, Mikko wrote:
> 
>>>>>>> Whenever a decider is run it answers the question it is made to answer.
>>>>>> Not necessarily. Just because everyone falsely assumes that D correctly
>>>>>> simulated by H must have the same behavior as the directly executed D(D)
>>>>>> does not make this false assumption true.
> 
>>>>> You still need to explain how you can call a simulation that differs from
>>>>> the behaviour of its input "correct".
> 
>>> Indeed, you do.
> 
>>>> I have proven it many times and this proof is simply over
>>>> everyone's heads.
> 
>>> Nonsense!  How about, instead of "proving", actually explaining?  If a
>>> simulation differs from its original, it's not a simulation; it's just a
>>> random program.
> 
>>>> When I ask what your C programming skill level is, this *is not* a
>>>> rhetorical question.
> 
>>> The question has nothing to do with C programming.
> 
>> typedef void (*ptr)(); // pointer to void function
>> int H(ptr P, ptr I);
> 
>> int D(int (*x)())
>> {
>>    int Halt_Status = H(x, x);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
> 
>> Unless I make every single detail 100% explicit false
>> assumptions always slip though the cracks.
> 
> No.  Every single detail just obfuscates and hides the facts.  The
> problem is you have been talking absurdities for so long you have
> probably come to believe them.  Nobody else is fooled.
> 
>> The ONLY way to make EVERY SINGLE DETAIL 100% EXPLICIT is the x86
>> programming language.
> 
> No, that's just a convenient means for obfuscation and expressing
> strawmen.
> 
>> There cannot possibly be any H that correctly emulates
>> the x86 machine code of D according to the semantics
>> of the x86 programming language such that the emulated
>> D ever reaches its own emulated final state at machine
>> address [00001f58].
> 
> Emulation, Simulation.  By definition a simulator does the same as what
> it's simulating.  If it doesn't, it's not a simulator.  Everybody else
> understands that.  Why don't you?
> 
> Are you saying above that simulators are impossible?  Everybody else has
> understood for a long time that they're not sensible, here.  But
> impossible?
> 
> [ .... ]
> 
>> Once the above is understood (people quit denying verified facts).
> 
> You're lying again.  There are no verified facts in the above (which I
> snipped).
> 
>> thenn (then and only then) I can show how this applies to Turing
>> machines.
> 
> If you'd've simply stuck to turing machines all along, you could have
> avoided a lot of the confusion you've got yourself into.  Why not start
> talking about turing machines now?
> 

Because he just doesn't understand Turing Machines, so can't show what 
he want there. Also, Turing Machines don't allow him to "Cheat" the way 
he did with H and D being intermixed the way they are. Which may be why 
he has so much problem with Turing Machines, since he doesn't understand 
the restrictions that apply to what a Computation can do, so he gets 
frustrated when they don't let him do the things he needs to do, since 
they aren't actually computations.

So, he wants to do his proof with his non-equivalent machines, and then 
try to bamboozle us into thinking he can show that they are actually the 
equivalent the the Turing Machines.


And, the bigger issue is he really doesn't care about the Halting 
Problem itself, just that it is stepping stone that provided a path to 
Godel and Tarski for proofs that drive a stake in the heart of his idea 
about truth. Proofs he doesn't understand, so can't actually refute, but 
he thinks if he can show a problem with the halting problem proof, then 
he has made an attack on those other problems.

Also, his real attack on the Halting Problem is based on the somewhat 
hidden claim that there is something fundamentally wrong with the 
formation of the Halting Problem, and that allows him to redefine the 
problem, which it doesn't.

If he really wanted to work on that track, his first step needs to be to 
actually demonstrate an actual inconsistance that the Halting Problem 
generates, on the level of Russel's Naive Set Theory paradox, to provide 
grounds for wanting to re-establish the ground rules for the field. The 
problem is he knows his attempts at this didn't go well, but he won't 
admit it, so he just want to assume that we accept the proof, but we 
don't which is why ther is so much argument about "The Correct 
SImulation of D by H" as he thinks he is authorized to use that, when he 
isn't.

At best, he could talk about PO-halting (Which I call Peter Olcotts 
Other Problem, or POOP for short), but that doesn't help with his bigger 
goal.

His latest tactic of claiming that H can't understand the question is 
just more of his weirdness, showing how little he understand what 
Computations are. I think he somehow thinks "AI" can be the savior of 
the world.

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

#107295

On 2024-06-16 15:06, Alan Mackenzie wrote:

> If you'd've simply stuck to turing machines all along, you could have
> avoided a lot of the confusion you've got yourself into.  Why not start
> talking about turing machines now?

Olcott has made it clear that he has absolutely no idea what Turing 
Machines are or how they work. He likes bringing them up (even insisting 
on calling his C programs "TMs" or "UTMs"), but there's no possibility 
that he will start discussing actual Turing machines. They're entirely 
outside of his purview.

André

-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

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

#107296

Le 16/06/2024 à 23:58, André G. Isaak a écrit :
> On 2024-06-16 15:06, Alan Mackenzie wrote:
> 
>> If you'd've simply stuck to turing machines all along, you could have
>> avoided a lot of the confusion you've got yourself into.  Why not start
>> talking about turing machines now?
> 
> Olcott has made it clear that he has absolutely no idea what Turing 
> Machines are or how they work. He likes bringing them up (even insisting 
> on calling his C programs "TMs" or "UTMs"), but there's no possibility 
> that he will start discussing actual Turing machines. They're entirely 
> outside of his purview.
> 
> André
> 

A couple of years ago he was asked to provide Turing Machine emulator in
C. He bragged about delivering it in a few hours (which is realisting
for any decent programmer btw).

Guess what? He failed.

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

#107297

On 6/16/24 6:21 PM, Python wrote:
> Le 16/06/2024 à 23:58, André G. Isaak a écrit :
>> On 2024-06-16 15:06, Alan Mackenzie wrote:
>>
>>> If you'd've simply stuck to turing machines all along, you could have
>>> avoided a lot of the confusion you've got yourself into.  Why not start
>>> talking about turing machines now?
>>
>> Olcott has made it clear that he has absolutely no idea what Turing 
>> Machines are or how they work. He likes bringing them up (even 
>> insisting on calling his C programs "TMs" or "UTMs"), but there's no 
>> possibility that he will start discussing actual Turing machines. 
>> They're entirely outside of his purview.
>>
>> André
>>
> 
> A couple of years ago he was asked to provide Turing Machine emulator in
> C. He bragged about delivering it in a few hours (which is realisting
> for any decent programmer btw).
> 
> Guess what? He failed.
> 
> 

Actually, if I remember right, he was asked to write a Turing Machine, 
and was shown an on-line Turing Emulator, but he didn't like how it 
worked, (it didn't understand a "full ASCII" tape) so he desided to 
write his own, and failed.

Yes, a few hours is probably a reasonable design time for a simple 
"batch mode" Turing machine emultor (read a data file with the State 
Machine description and the starting tape, and then print a trace of it 
running, maybe including a simple loop detector to stop the obviously 
non-halting machines.

Of course, fancy graphics could make it a bottomless pit.

I likely wouldn't choose C to do it in, but it is do able.

(A RASP emulator would want a language with bignum support, but that 
isn't needed for a Turing Machine.

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

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

Back to top | Article view | comp.theory

csiph-web