XPost: sci.logic

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt. That HHH aborts its
emulation at some point or never aborts its emulation
cannot possibly change this.

No, you are just showing your ignorance.

It is IMPOSSIBLE to "Correctly Emulate" this input per the semantics
of the x86 instruction set as given, as it referncee undefined memory.

I already stipulated that the memory IS DEFINED with an
x86 emulator. Also you have seen that I have proven this. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

And if you assume that stipulation for the emulation, then you are
stipulating that the contents of ALL THE MEMORY is "part of the input".

Also, by stipulating that it is a x86 emulator, do you mean an actually complete emulator that fully emulates the input, or is it possible your PARTIAL/CONDITIONAL emulator that only emulates part of the behavior of
the input.

If it is the later, then you can not just replace the call to the PARTIAL/CONDITIONAL emulator with the "unconditional" emulation that it
just doesn't perform (since its emulation is conditional).

Thus even if you relax the requirement of the emulation from being based
on the semantic of the (which prevents doing the subsitution, since that
isn't in the semantic of the x86) you can't do it at the functional
level as a conditional emualation is not the same as an unconditional emulation.

Also, since you have agreed that the "input" consists of ALL the
contents of memory (or at least all that has HHH in it) that means that
each of your different HHHs are looking at DIFFERENT inputs, and you
can't talk about one of them showing another one is right, since they
are working on different input.

That just blows are your work out of the water.

The fact that THIS HHH stops at some point before seeing the return,
doesn't mean that if you give THIS INPUT to another decider that
simulates longer, that it can't see that return, thus your "needed to"
argument has broken, because the alternate deciders need to be given the
EXACT SAME input, and thus they need to be put in some other unused
location of memory to allow the original HHH to stay at its designated
address.

In fact, we can even see if we put another copy of the code of HHH, that
has been fully renamed to HHH1 it will see that DDD calls HHH(DDD) and
that HHH will return (since it never sees DDD calling HHH1, it never
needs to activate the self-simulation code).

Thus, we show that HHH didn't decide right, and even that it isn't an
actual Computation

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt. That HHH aborts its
emulation at some point or never aborts its emulation
cannot possibly change this.

No, you are just showing your ignorance.

It is IMPOSSIBLE to "Correctly Emulate" this input per the semantics
of the x86 instruction set as given, as it referncee undefined memory. >>>>

I already stipulated that the memory IS DEFINED with an
x86 emulator. Also you have seen that I have proven this.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

And if you assume that stipulation for the emulation, then you are
stipulating that the contents of ALL THE MEMORY is "part of the input".

Also, by stipulating that it is a x86 emulator, do you mean an
actually complete emulator that fully emulates the input,

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

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

Liar. *It is forbidden from fully emulating non-halting inputs*
Liar. *It is forbidden from fully emulating non-halting inputs*
Liar. *It is forbidden from fully emulating non-halting inputs*

Says what?

The DEFINITION of a UTM says that it WILL simulate the representation of
a non-hatling machine forever.

Yes, A DECIDER can't do something that takes forever to make its
decision, but that requirement doesn't change the meaning of what it
needs to determine.

The impossibility is just one of the reasons that Halting isn't a
computable problem, which is a perfectly fine results.

    until H correctly determines that its simulated D would never
    stop running unless aborted

    until H correctly determines that its simulated D would never
    stop running unless aborted

    until H correctly determines that its simulated D would never
    stop running unless aborted

But only after it CORRECTLY DETERMINES the result of the CORRECT (and
complete) SIMULATION of the input will never halt.

Since D(D) will halt, it is impossible to correctly determine that a
complete simulaiton of it will not halt.

You "Logic" tries to lie by changing the input from D to D' when you
replace H with H' that doesn't abort its simulation, which just means
you LIED about looking that the same input.

That is how ALL your logic seems to be based, you stack one lie on top
of another.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

On 04/07/2024 13:53, Richard Damon wrote:

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

[...]

Can someone please explain to me why a discussion of the Halting Problem
is using Intel assembly laguage?

--
---------------------------
| BBB b \ Barbara at LivingHistory stop co stop uk
| B B aa rrr b |
| BBB a a r bbb | ,008015L080180,022036,029037
| B B a a r b b | ,047045,L014114L4.
| BBB aa a r bbb |
-----------------------------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-09 06:09:02 +0000, Barb Knox said:

On 04/07/2024 13:53, Richard Damon wrote:

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

[...]

Can someone please explain to me why a discussion of the Halting
Problem is using Intel assembly laguage?

For some people the both Halting Problem and Intel assembly language
are a litte mysterious. Therefore they may think they are related.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic
To: polcott333@gmail.com

You see two crazy lovebirds, Richard
Damon and olcott, in some chirping competition.

Otherwise brainless nonsense.

Barb Knox schrieb:

On 04/07/2024 13:53, Richard Damon wrote:

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

[...]

Can someone please explain to me why a discussion of the Halting Problem
is using Intel assembly laguage?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: sci.logic

Barb Knox <Barb@sig.below> writes:

On 04/07/2024 13:53, Richard Damon wrote:

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

[...]

Can someone please explain to me why a discussion of the Halting Problem is using Intel assembly laguage?

Short answer: PO does not understand any of the formal models of
computation and he's been able to persuade people to keep talking to him despite that rather severe limitation.

It's also worth pointing out that this discussion is not about the
Halting Problem. PO has been quite clear -- this is a discussion of a
decision problem (although he does not really understand that term) in
which false is the correct result for at least one halting computation.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-09 14:31:17 +0000, olcott said:

On 7/9/2024 1:48 AM, Mikko wrote:

On 2024-07-09 06:09:02 +0000, Barb Knox said:

On 04/07/2024 13:53, Richard Damon wrote:

On 7/3/24 9:30 PM, olcott wrote:

On 7/3/2024 8:12 PM, Richard Damon wrote:

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

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

[...]

Can someone please explain to me why a discussion of the Halting
Problem is using Intel assembly laguage?

For some people the both Halting Problem and Intel assembly language
are a litte mysterious. Therefore they may think they are related.

The x86utm operating system is a proxy for a UTM and uses C
functions as proxies for Turing Machines and the x86 language
as a proxy for the Turing Machine description language.

The C language and all versions of x86 instruction set are so complcated
that it is harder to prove anything about them.

This provides the means to make every single detail of the
halting problem 100% concrete thus totally eliminating any
false assumptions.

That provides the means to introduce false assumptions without making them
too obvious.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Wed, 10 Jul 2024 08:35:51 -0500 schrieb olcott:

On 7/10/2024 2:06 AM, Mikko wrote:

On 2024-07-09 14:31:17 +0000, olcott said:

The C language and all versions of x86 instruction set are so
complcated that it is harder to prove anything about them.

*C is about the simplest full programming language that exists*
Once you understands sequence, selection, iteration and function calls
you know the essence of the whole language.

Then why not use some untyped pseudocode?

All that you need to understand is that the first four instructions of
DDD correctly emulated by HHH do some housekeeping and then call
HHH(DDD) with no conditional branch escape from endless repetition.
*The C code says this even more simply*
void DDD()
{
HHH(DDD);
}

Ah, there we go. Nothing about x86 semantics.
This program halts exactly iff HHH halts.

--
Am Fri, 28 Jun 2024 16:52:17 -0500 schrieb olcott:
Objectively I am a genius.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-07-10 13:35:51 +0000, olcott said:

On 7/10/2024 2:06 AM, Mikko wrote:

On 2024-07-09 14:31:17 +0000, olcott said:

The x86utm operating system is a proxy for a UTM and uses C
functions as proxies for Turing Machines and the x86 language
as a proxy for the Turing Machine description language.

The C language and all versions of x86 instruction set are so complcated
that it is harder to prove anything about them.

*C is about the simplest full programming language that exists*

No, it is not. The machine language of a simple processor, for exmaple
Elliot 903, is much simpler. Its definition needs a page or two but the definition of the C language is a book.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)