From Newsgroup: comp.ai.philosophy

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

_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]
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match the
steps of D directly executed, until H just gives up and guesses.

By your defintions, the ONLY correct simulation of D by H MUST follow
the call H into the instructions of H, and then continue there forever
until H either gives up simulating, or it happens to simulate the return
from H to D (which doesn't look like it will ever happen).

This is the ONLY thing that matches your definition of Correct Simulation.

And that means that you definition of the "Input" is shown to be
incorrect (or insufficient for H to do what it needs to do). The input
CAN NOT be just those instructions shown below, but must include the
contents of ALL the memory used by the program.

And this comes out naturally, because to ask about the program
represented by the input, the input needs to represent a FULL PROGRAM,
which includes ALL of the algorithm used by the code, so ALL of the program.

Thus, the input "D", includes its copy of H that was DEFINED by Linz and Sipser to be part of the machine, and when you do your logic, you can't
change that code.

If this means that you can't do your imagining of different Hs, then you
can't do that operation.

Any H you imagine being given the same input as this H, must see the
code for that original H, not the new hypothetical H you are imagining.

Which sort of blows you your whole argument.

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match the
steps of D directly executed, until H just gives up and guesses.

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

That you call this a guess seems disingenuous at least and dishonest
at most. it is as if you are denying mathematical induction.

By your defintions, the ONLY correct simulation of D by H MUST follow
the call H into the instructions of H, and then continue there forever
until H either gives up simulating, or it happens to simulate the return from H to D (which doesn't look like it will ever happen).

Yes and when I say 2 + 3 = 5 you are not free to disagree and be
correct.

This is the ONLY thing that matches your definition of Correct Simulation.

The x86 language defines the semantics of correct simulation that
you denigrate this to my opinion seems disingenuous at least and
dishonest at most.

And that means that you definition of the "Input" is shown to be
incorrect (or insufficient for H to do what it needs to do). The input
CAN NOT be just those instructions shown below, but must include the contents of ALL the memory used by the program.

It is the sequence of x86 instructions specified by the machine
language of D that is being examined. We cannot simply ignore
the recursive simulation effect of the call from D to H(D,D).
That D makes this call is what make D correctly simulated by H
fail to halt.

And this comes out naturally, because to ask about the program
represented by the input, the input needs to represent a FULL PROGRAM,
which includes ALL of the algorithm used by the code, so ALL of the
program.

That D calls H in recursive simulation is what makes D correctly
simulated by H never halt. H is merely watching what D does
until it see that D correctly simulated by H cannot possibly halt
on the basis of something just like mathematical induction.

We can directly see that 1,2,3...N recursive simulations do
not result in D correctly simulated by H reaching its simulated
final state of [00000d1d].

Thus, the input "D", includes its copy of H that was DEFINED by Linz and Sipser to be part of the machine, and when you do your logic, you can't change that code.

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

When embedded_H is a UTM we can see that Ĥ ⟨Ĥ⟩ never halts.

This by itself proves that the same thing applies when embedded_H
is based on a UTM that stops simulating and rejects its input at
any point after it sees

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.

If this means that you can't do your imagining of different Hs, then you can't do that operation.

Any H you imagine being given the same input as this H, must see the
code for that original H, not the new hypothetical H you are imagining.

Which sort of blows you your whole argument.

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

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match the
steps of D directly executed, until H just gives up and guesses.

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about Halting,

Remember, your analysis was done with the input CHANGING with H, which
means any N used different than what your H actually uses, is INVALID
for discussing what THIS D does.

IF you did it right, and asked what would an H that simulated farther
THIS input, which means D calls the original H, then if that simulates
father, it WOULD see the simulated ORIGINAL H abort and return to D and
D halt.

But this H can't do that, so it can't see it.

So, you not only ask the wrong question, but you ask it of the wrong input.

That you call this a guess seems disingenuous at least and dishonest
at most. it is as if you are denying mathematical induction.

But the D that Linz talks about has its own copy of H, as is needed to
make it an actual computation, and thus doesn't change when you think
about different machines simuating it.

By your defintions, the ONLY correct simulation of D by H MUST follow
the call H into the instructions of H, and then continue there forever
until H either gives up simulating, or it happens to simulate the
return from H to D (which doesn't look like it will ever happen).

Yes and when I say 2 + 3 = 5 you are not free to disagree and be
correct.

Just like you don't get to change the code of D, including the fact that
it calls the ORIGINAL H, an d isn't a template anymore, and thatthe
criteria *IS* does it halt when directly run, and not about "the correct simulation by H" which isn't even a valid criteria.

This is the ONLY thing that matches your definition of Correct
Simulation.

The x86 language defines the semantics of correct simulation that
you denigrate this to my opinion seems disingenuous at least and
dishonest at most.

Right, which means the ONLY "correct simulation" of D simulates the call
to H and the code in H, so the correct simulation by H is EXACTLY the
same as the direct execution up to the point when H gives up and stops,
so you claim that they differ is just a LIE.

And that means that you definition of the "Input" is shown to be
incorrect (or insufficient for H to do what it needs to do). The input
CAN NOT be just those instructions shown below, but must include the
contents of ALL the memory used by the program.

It is the sequence of x86 instructions specified by the machine
language of D that is being examined. We cannot simply ignore
the recursive simulation effect of the call from D to H(D,D).
That D makes this call is what make D correctly simulated by H
fail to halt.

No, we done ignore them, we simulate through them.

Note, somehow you think thaT H only needs to simulate the instruction in
the C function of D, but that is INCORRCT, and if you try to use that defintion, H must stop as soon as it gets to the call H and can not
proceeed.

The problem here is that, to be the needed input, the input actually
needs to include all the code that D uses, including H and everyting
that H calls, or the input is just incorrect.

And this comes out naturally, because to ask about the program
represented by the input, the input needs to represent a FULL PROGRAM,
which includes ALL of the algorithm used by the code, so ALL of the
program.

That D calls H in recursive simulation is what makes D correctly
simulated by H never halt. H is merely watching what D does
until it see that D correctly simulated by H cannot possibly halt
on the basis of something just like mathematical induction.

Nope, That only holds if H is defined to never abort.

You are just proving you don't understand what you are talking about and
are just being a pathological liar with a total and reckless disregard
for the truth.

We can directly see that 1,2,3...N recursive simulations do
not result in D correctly simulated by H reaching its simulated
final state of [00000d1d].

Nope, and in fact it seems that EVERYT simulation that you have done
that tries to go past those first 7 instuctions violate you definition
of a "Correct Simulation" and thus ALL You logic is just wrong.

Thus, the input "D", includes its copy of H that was DEFINED by Linz
and Sipser to be part of the machine, and when you do your logic, you
can't change that code.

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

When embedded_H is a UTM we can see that Ĥ ⟨Ĥ⟩ never halts.

And if embedded_H is a UTM< then so is H, and then H fails to be a decider.

So either H / embedded_H *IS* programmed to abort it simulation at some
point, so that H (H^) (H^) can go to qn, and thus H^ (H^) will also have
its embedded_H abort its simulation and go to qn and thus H^ (H^) Halts,
or H (H^) (H^) just never answers.

Both are wrong.

This by itself proves that the same thing applies when embedded_H
is based on a UTM that stops simulating and rejects its input at
any point after it sees

There is no sucn thing. You are effectively basing you argument on the
puppy that *IS* a 15 story office building.

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.

But not infinite.

So, you are just wrong, and proving you are stupid as you don't
understand what a UTM is.

If this means that you can't do your imagining of different Hs, then
you can't do that operation.

Any H you imagine being given the same input as this H, must see the
code for that original H, not the new hypothetical H you are imagining.

Which sort of blows you your whole argument.

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match the
steps of D directly executed, until H just gives up and guesses.

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about Halting,

It is the mathematical induction that says this.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match the
steps of D directly executed, until H just gives up and guesses.

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about Halting,

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

You haven't shown the required pieces for an inductive proof.

I doubt you even know what you need to do, let alone be able to do it.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match
the steps of D directly executed, until H just gives up and guesses. >>>>>

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about Halting,

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n. https://en.wikipedia.org/wiki/Mathematical_induction

It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

*We directly see this is true for every N thus no assumption needed*
It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

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

You haven't shown the required pieces for an inductive proof.

I doubt you even know what you need to do, let alone be able to do it.

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/24 8:05 PM, olcott wrote:

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match
the steps of D directly executed, until H just gives up and guesses. >>>>>>

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about Halting, >>>>

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n. https://en.wikipedia.org/wiki/Mathematical_induction

Ok, so you can parrot to words.

It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Which means you consider that D has been bound to that first H, so you
have instruciton to simulate in the call H.

*We directly see this is true for every N thus no assumption needed*
It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Nope, because to do the first step, you had to bind the definition of
the first H to D, and thus can not change it.

If we simulate THAT input for one more step, it will see the FIRST H
decide to abort and return.

If you don't bind the first H, yo can't do the first step.

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

You haven't shown the required pieces for an inductive proof.

I doubt you even know what you need to do, let alone be able to do it.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/2024 7:13 PM, Richard Damon wrote:

On 6/15/24 8:05 PM, olcott wrote:

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges >>>>>>>> from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match >>>>>>> the steps of D directly executed, until H just gives up and guesses. >>>>>>>

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N
recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about
Halting,

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n.
https://en.wikipedia.org/wiki/Mathematical_induction

Ok, so you can parrot to words.

It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Which means you consider that D has been bound to that first H, so you
have instruciton to simulate in the call H.

*We directly see this is true for every N thus no assumption needed*
It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Nope, because to do the first step, you had to bind the definition of
the first H to D, and thus can not change it.

So infinite sets are permanently beyond your grasp.
The above D simulated by any H has the same property
of never reaching its own simulated machine address
at [00000d1d].

What I mistook for dishonestly is simply a lack
of comprehension.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/24 8:48 PM, olcott wrote:

On 6/15/2024 7:13 PM, Richard Damon wrote:

On 6/15/24 8:05 PM, olcott wrote:

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges >>>>>>>>> from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match >>>>>>>> the steps of D directly executed, until H just gives up and
guesses.

When we can see that D correctly simulated by H cannot possibly
reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N >>>>>>> recursive simulations then we can abort the simulated input and
correctly report that D correctly simulated by H DOES NOT HALT.

Nope. Because an aborted simulation doesn't say anything about
Halting,

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n.
https://en.wikipedia.org/wiki/Mathematical_induction

Ok, so you can parrot to words.

It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Which means you consider that D has been bound to that first H, so you
have instruciton to simulate in the call H.

*We directly see this is true for every N thus no assumption needed*
It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Nope, because to do the first step, you had to bind the definition of
the first H to D, and thus can not change it.

So infinite sets are permanently beyond your grasp.
The above D simulated by any H has the same property
of never reaching its own simulated machine address
at [00000d1d].

What I mistook for dishonestly is simply a lack
of comprehension.

But it isn't an infinite set.

We don't ask an infinite set a question, or give a decider an infinite
set of inputs.

We can pose the same question to an infinite set of machines, but we
judge each of them individually.

I thought you finally caught on that Linz is talking about taking *A*
Turing Machine H that is assumed to be a Halt Decider, and building for
it *AN* input H^ that he shows creates an impossible situation, so that
H could not exist.

You are just trying to obfuscate things by throwing in "infinte sets"
but we still need to process them each individually.

Yes, we can do that in parallel, but in individual problem units.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/2024 8:19 PM, Richard Damon wrote:

On 6/15/24 8:48 PM, olcott wrote:

On 6/15/2024 7:13 PM, Richard Damon wrote:

On 6/15/24 8:05 PM, olcott wrote:

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.

After that the behavior of D correctly simulated by H diverges >>>>>>>>>> from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY
match the steps of D directly executed, until H just gives up >>>>>>>>> and guesses.

When we can see that D correctly simulated by H cannot possibly >>>>>>>> reach its simulated final state at machine address [00000d1d]
after one recursive simulation and the same applies for 2,3,...N >>>>>>>> recursive simulations then we can abort the simulated input and >>>>>>>> correctly report that D correctly simulated by H DOES NOT HALT. >>>>>>>

Nope. Because an aborted simulation doesn't say anything about
Halting,

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n.
https://en.wikipedia.org/wiki/Mathematical_induction

Ok, so you can parrot to words.

It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Which means you consider that D has been bound to that first H, so
you have instruciton to simulate in the call H.

*We directly see this is true for every N thus no assumption needed*
It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Nope, because to do the first step, you had to bind the definition of
the first H to D, and thus can not change it.

So infinite sets are permanently beyond your grasp.
The above D simulated by any H has the same property
of never reaching its own simulated machine address
at [00000d1d].

What I mistook for dishonestly is simply a lack
of comprehension.

But it isn't an infinite set.

Sure it is you are just clueless.
I mistook your ignorance for deception.

We don't ask an infinite set a question, or give a decider an infinite
set of inputs.

Yes we do and this is simply over your head.

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

The second ⊢* wildcard specifies this infinite set.

We can pose the same question to an infinite set of machines, but we
judge each of them individually.

I thought you finally caught on that Linz is talking about taking *A*
Turing Machine H that is assumed to be a Halt Decider, and building for
it *AN* input H^ that he shows creates an impossible situation, so that
H could not exist.

You are just trying to obfuscate things by throwing in "infinte sets"
but we still need to process them each individually.

Yes, we can do that in parallel, but in individual problem units.

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

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.ai.philosophy

On 6/15/24 9:42 PM, olcott wrote:

On 6/15/2024 8:19 PM, Richard Damon wrote:

On 6/15/24 8:48 PM, olcott wrote:

On 6/15/2024 7:13 PM, Richard Damon wrote:

On 6/15/24 8:05 PM, olcott wrote:

On 6/15/2024 6:37 PM, Richard Damon wrote:

On 6/15/24 7:30 PM, olcott wrote:

On 6/15/2024 6:01 PM, Richard Damon wrote:

On 6/15/24 5:56 PM, olcott wrote:

On 6/15/2024 11:33 AM, Richard Damon wrote:

On 6/15/24 12:22 PM, olcott wrote:

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.

The first six steps of this mapping are when instructions >>>>>>>>>>> at the machine address range of [00000cfc] to [00000d06] >>>>>>>>>>> are simulated/executed.

After that the behavior of D correctly simulated by H diverges >>>>>>>>>>> from the behavior of D(D) because the call to H(D,D) by D >>>>>>>>>>> correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY >>>>>>>>>> match the steps of D directly executed, until H just gives up >>>>>>>>>> and guesses.

When we can see that D correctly simulated by H cannot possibly >>>>>>>>> reach its simulated final state at machine address [00000d1d] >>>>>>>>> after one recursive simulation and the same applies for 2,3,...N >>>>>>>>> recursive simulations then we can abort the simulated input and >>>>>>>>> correctly report that D correctly simulated by H DOES NOT HALT. >>>>>>>>

Nope. Because an aborted simulation doesn't say anything about >>>>>>>> Halting,

It is the mathematical induction that says this.

WHAT "Mathematical Induction"?

A proof by induction consists of two cases. The first, the base
case, proves the statement for n = 0 without assuming any knowledge
of other cases. The second case, the induction step, proves that
if the statement holds for any given case n = k then it must also
hold for the next case n = k + 1 These two steps establish that the
statement holds for every natural number n.
https://en.wikipedia.org/wiki/Mathematical_induction

Ok, so you can parrot to words.

It is true that after one recursive simulation of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Which means you consider that D has been bound to that first H, so
you have instruciton to simulate in the call H.

*We directly see this is true for every N thus no assumption needed* >>>>> It is true that after N recursive simulations of D correctly
simulated by H that D does not reach its simulated final state
at machine address [00000d1d].

Nope, because to do the first step, you had to bind the definition
of the first H to D, and thus can not change it.

So infinite sets are permanently beyond your grasp.
The above D simulated by any H has the same property
of never reaching its own simulated machine address
at [00000d1d].

What I mistook for dishonestly is simply a lack
of comprehension.

But it isn't an infinite set.

Sure it is you are just clueless.
I mistook your ignorance for deception.

Nope, because each H that you want to claim is a halt decider must INDIVIDUALLY meed the requirement

We don't ask an infinite set a question, or give a decider an infinite
set of inputs.

Yes we do and this is simply over your head.

No, you ask each one individually.

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

The second ⊢* wildcard specifies this infinite set.

Nope, it specifies and ARBITRAY path.

We have been over this before, as you are just being ignorant.

Read the book again. He uses the singular form of words in the description.

You are just proving you don't understand basic English.

But oof course, you have already admitted to being a liar, so a fewm mor
won't matter.

We can pose the same question to an infinite set of machines, but we
judge each of them individually.

I thought you finally caught on that Linz is talking about taking *A*
Turing Machine H that is assumed to be a Halt Decider, and building
for it *AN* input H^ that he shows creates an impossible situation, so
that H could not exist.

You are just trying to obfuscate things by throwing in "infinte sets"
but we still need to process them each individually.

Yes, we can do that in parallel, but in individual problem units.

--- Synchronet 3.20a-Linux NewsLink 1.114