On 7/19/24 10:18 AM, olcott wrote:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in >>>>>>>>>>> your argument because you have misdefined what the input is. >>>>>>>>>>>

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is >>>>>>>>> not a string of bytes, but an address (00002163). This points >>>>>>>>> to the starting of the code of DDD. But a simulation needs a >>>>>>>>> program, not a function calling undefined other functions.
Therefore, all functions called by DDD (such as HHH) are
included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite
string. When you say that a finite string *is not* a finite
string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of another. >>>>>>>> It is the fact that DDD calls HHH(DDD) in recursive emulation
that makes it impossible for DDD correctly emulated by HHH to halt. >>>>>>>
Everyone disagrees with this entirely on the basis of the strawman >>>>>>>> deception (damned lie) that some other DDD somewhere else has
different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts
because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD
are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has
already been aborted is the same as the state of being hungry
changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not
change.

*WRONG*
https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

My compiler can accept assembly language
that can derive self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as
if the program were in a read-only memory, and typical compilers
compile so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code
while it is running when it has access to its own TM description
and it is only simulated by a UTM. In this case it can modify
itself so that its input is no longer contradictory.

But TMs DON'T have access to their own code, BY DEFINITION.

Please show how you encode the modifying instruction?

The problem is that TMs have TOTAL separation between "code space" and
"data space" and thus have ZERO ability to actually change their own code.

They CAN do the same thing that non-self-modifying code can do to act
like self-modifying code. Every spot in the algorithm that would have
been modified in code, is replaced by a piece of conditional code that
looks at what the most recent option selected for that piece of code,
and does that, and the points that would change the code, change the
memory where that option is stored.

Note, this also shows that "self-modifying code" doesn't actually change
the "behavior" of the program, but is only one method to send a notice
to the future to select what behavior that path should have. And that
path selection is just part of the program operation so isn't "changing"
it at all.

Note, if the modification persist after the running of the code and
affect future runs, then it is an illegal use of "static" memory to
affect behavior, making the code unpure and thus not a computation.

When a Self-Modifying Turing Machine can change itself to become
any other Turing Machine then it can eliminate the pathological
relationship to its input.

Since a "Self-Modifying Turing Machine" is less real than a Purple
Faerie Dust Powered Unicorn, your "theory" is proven to be just a
fantastic LIE.

My first paper is based on a decider that changes itself
so that it can always get the correct answer.

Self Modifying Turing Machine (SMTM) Solution to the Halting Problem
(concrete example) August 2016

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

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

Am Fri, 19 Jul 2024 09:18:05 -0500 schrieb olcott:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Can't. Since programs are unchanging, their properties can not
change.

Your complier cannot produce self-modifying code.

My compiler can accept assembly language that can derive
self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as if
the program were in a read-only memory, and typical compilers compile
so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code while it is running when it has access to its own TM description and it is only
simulated by a UTM. In this case it can modify itself so that its input
is no longer contradictory.

Oh no. A running TM cannot change its transition table. Even then,
its description would include the selfmodification.
Being simulated does not change anything, as the simulated machine
is not aware of that.

When a Self-Modifying Turing Machine can change itself to become any
other Turing Machine then it can eliminate the pathological relationship
to its input.

I think not, because the selfmodification is built into it. It is
different from the version that doesn't have that.

--
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 7/19/24 12:02 PM, olcott wrote:

On 7/19/2024 10:53 AM, joes wrote:

Am Fri, 19 Jul 2024 09:18:05 -0500 schrieb olcott:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Can't. Since programs are unchanging, their properties can not >>>>>>>> change.

Your complier cannot produce self-modifying code.

My compiler can accept assembly language that can derive
self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as if >>>> the program were in a read-only memory, and typical compilers compile
so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code while it is >>> running when it has access to its own TM description and it is only
simulated by a UTM. In this case it can modify itself so that its input
is no longer contradictory.

Oh no. A running TM cannot change its transition table.

A Self-Modifying Turing Machine is defined as a Turing
Machine Description that has access to its own tape
location on the UTM that is simulating it.

But Turing Machines don't have access to their description.

And your "UTM" isn't actually a UTM, as a UTM, by its definition,
doesn't give the Turing Machine Description on the tape access to that
part of the tape, as that isn't how Turing Machines work.

And that description on the tape isn't the description of an actual
Turing Machine, as you seem to presume the thing thinks it has access to
its description.

SO, NOTHING in that system is what you claimed it to be.

Now, you COULD define a Turing Machine that is something similar to a
UTM, but not constrained to be exactly one that processes an input that
has a description of an algorithm in a way similar to how you would
describe it to a UTM, but with the understanding that it will be able to
access its own description, and then interpret that part of the input as
it processes the data.

The first big problem is that Turing Machines (and things that work by
similar rules are you "self-Modifying Turing Machine Description") are
slow at manipulating complicated data, and thus there is the difficulty
of maintaining a valid description (at least valid enough to let the
actual interpreter keep running correctly) on the tape while updating
the description.

The second thing to point out is all this does is prove that since what
we now have is an ACTUAL STANDARD TM processing this tape, and said TM
could be prepended with code to insert onto the tape the representation
of the "self-modifying machine description", all you have done is
demonstart that your idea of a "Self-Modifying Turing Machine" can't
actually do anything that a "normal" TM couldn't do, but may have lost
some of the basic properties that simplify how we can prove things with
them, means you concept isn't actually that useful.

Even then,
its description would include the selfmodification.
Being simulated does not change anything, as the simulated machine
is not aware of that.

When a Self-Modifying Turing Machine can change itself to become any
other Turing Machine then it can eliminate the pathological relationship >>> to its input.

I think not, because the selfmodification is built into it. It is
different from the version that doesn't have that.

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

On 2024-07-19 10:02, olcott wrote:

A Self-Modifying Turing Machine is defined as a Turing
Machine Description that has access to its own tape
location on the UTM that is simulating it.

Umm. Maybe explain how that's supposed to work...

A TM has no idea whether it is being run directly or being run in a UTM.
And even if it is being run in a UTM, it certainly does NOT have access
to the machine description which is present on the UTM's tape.

There's lots of examples of UTMs available on the web. Maybe you should actually try playing around with some of them so you can learn how
actual UTMs work. Hint: It's not how you think.

André

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

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

On 2024-07-19 19:10, olcott wrote:

On 7/19/2024 7:44 PM, André G. Isaak wrote:

On 2024-07-19 10:02, olcott wrote:

A Self-Modifying Turing Machine is defined as a Turing
Machine Description that has access to its own tape
location on the UTM that is simulating it.

Umm. Maybe explain how that's supposed to work...

A TM has no idea whether it is being run directly or being run in a
UTM. And even if it is being run in a UTM, it certainly does NOT have
access to the machine description which is present on the UTM's tape.

A self-modifying TM knows that it is only simulated by a UTM

How exactly is it supposed to know that? Please explain using ACTUAL
Turing Machines, not C code.

and knows where it is located on the UTM tape.

And how exactly would it have access to that? A TM emulated by a UTM has
no access to the UTM's tape.

There's lots of examples of UTMs available on the web. Maybe you
should actually try playing around with some of them so you can learn
how actual UTMs work. Hint: It's not how you think.

Once again, you should head the above advice. Apparently you have no
clue how actual UTMs work.

André

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

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

On 7/19/24 9:10 PM, olcott wrote:

On 7/19/2024 7:44 PM, André G. Isaak wrote:

On 2024-07-19 10:02, olcott wrote:

A Self-Modifying Turing Machine is defined as a Turing
Machine Description that has access to its own tape
location on the UTM that is simulating it.

Umm. Maybe explain how that's supposed to work...

A TM has no idea whether it is being run directly or being run in a
UTM. And even if it is being run in a UTM, it certainly does NOT have
access to the machine description which is present on the UTM's tape.

A self-modifying TM knows that it is only simulated by a UTM
and knows where it is located on the UTM tape.

But the UTM doesn't expost the discription of the Turing Machine to the
Turing Machine it is emulating.

It CAN'T, and be a UTM, as a UTM needs to EXACTLY reproduce the behavior
of the machine desceribed on its tape, and that machine doesn't have its description anywhere on the tape it can access.


You are just showing your utter ignorance of what you are talking about.

You can sort of imagine it is like a pure "Harvard Architecture"
computer where the code space is in an entirely different memory space
to the data space, and the processor can't write to the code space.

There's lots of examples of UTMs available on the web. Maybe you
should actually try playing around with some of them so you can learn
how actual UTMs work. Hint: It's not how you think.

André

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

On 2024-07-19 14:18:05 +0000, olcott said:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>>>>> argument because you have misdefined what the input is.

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a >>>>>>>>> string of bytes, but an address (00002163). This points to the starting
of the code of DDD. But a simulation needs a program, not a function >>>>>>>>> calling undefined other functions. Therefore, all functions called by >>>>>>>>> DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite
string. When you say that a finite string *is not* a finite
string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of another. >>>>>>>> It is the fact that DDD calls HHH(DDD) in recursive emulation
that makes it impossible for DDD correctly emulated by HHH to halt. >>>>>>>
Everyone disagrees with this entirely on the basis of the strawman >>>>>>>> deception (damned lie) that some other DDD somewhere else has
different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts
because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD
are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has
already been aborted is the same as the state of being hungry
changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not change. >>>>>>

*WRONG*
https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

My compiler can accept assembly language
that can derive self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as
if the program were in a read-only memory, and typical compilers
compile so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code
while it is running when it has access to its own TM description
and it is only simulated by a UTM. In this case it can modify
itself so that its input is no longer contradictory.

An actual Turing machine cannot change itself. A machine that can change
itself is not a Turing machine.

If you are interested in self-modifying machines you may want to study LOTOS.

When a Self-Modifying Turing Machine can change itself to become
any other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

--
Mikko

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

On 7/19/24 10:41 PM, olcott wrote:

On 7/19/2024 9:05 PM, André G. Isaak wrote:

On 2024-07-19 19:10, olcott wrote:

On 7/19/2024 7:44 PM, André G. Isaak wrote:

On 2024-07-19 10:02, olcott wrote:

A Self-Modifying Turing Machine is defined as a Turing
Machine Description that has access to its own tape
location on the UTM that is simulating it.

Umm. Maybe explain how that's supposed to work...

A TM has no idea whether it is being run directly or being run in a
UTM. And even if it is being run in a UTM, it certainly does NOT
have access to the machine description which is present on the UTM's
tape.

A self-modifying TM knows that it is only simulated by a UTM

How exactly is it supposed to know that? Please explain using ACTUAL
Turing Machines, not C code.

How could an emulated x86 program change its own code?
It simply needs to know its own machine address.

But you said *TURING MACHINE* so this is just a dishonest change of
topic dodge.

I gues this is just another of your Diagonalizatin proof claim where you
will either just try to ignore your claim or admit that you don't have one.

Until you answer, we will just need to assume that anything you claim
about Turing Machines is just a ignorant dishnest lie.

and knows where it is located on the UTM tape.

And how exactly would it have access to that? A TM emulated by a UTM
has no access to the UTM's tape.

It is typically understood that a a simulated Turing machine
description is not provided access to the UTM tape. This is
not the same as an analytical impossibility.

And How does it do that.

What do you put in the code (or data) that tells it that it must be a
simulated machine and can't be an actual runing program?

We never did it this way before therefore it is impossible
is not the way that reality actually works.

Assuming things that are definitionally impossible is a good way to show
that you logic is just a LIE.

There's lots of examples of UTMs available on the web. Maybe you
should actually try playing around with some of them so you can
learn how actual UTMs work. Hint: It's not how you think.

Once again, you should head the above advice. Apparently you have no
clue how actual UTMs work.

They are essentially isomorphic to x86 emulators.

Which shows you don't know what "isomorphic" means.


I suppose this shows that you are isomorphic to a stupid liar.

André

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

On 7/20/24 9:03 AM, olcott wrote:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in >>>>>>>>>>>>> your argument because you have misdefined what the input is. >>>>>>>>>>>>>

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input >>>>>>>>>>> is not a string of bytes, but an address (00002163). This >>>>>>>>>>> points to the starting of the code of DDD. But a simulation >>>>>>>>>>> needs a program, not a function calling undefined other
functions. Therefore, all functions called by DDD (such as >>>>>>>>>>> HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite >>>>>>>>>> string. When you say that a finite string *is not* a finite >>>>>>>>>> string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of
another.
It is the fact that DDD calls HHH(DDD) in recursive emulation >>>>>>>>>> that makes it impossible for DDD correctly emulated by HHH to >>>>>>>>>> halt.

Everyone disagrees with this entirely on the basis of the
strawman
deception (damned lie) that some other DDD somewhere else has >>>>>>>>>> different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts >>>>>>>>> because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD >>>>>>>>> are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has >>>>>>>>> already been aborted is the same as the state of being hungry >>>>>>>>> changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not >>>>>>>> change.

*WRONG*
https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

My compiler can accept assembly language
that can derive self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as
if the program were in a read-only memory, and typical compilers
compile so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code
while it is running when it has access to its own TM description
and it is only simulated by a UTM. In this case it can modify
itself so that its input is no longer contradictory.

An actual Turing machine cannot change itself. A machine that can change
itself is not a Turing machine.

If you are interested in self-modifying machines you may want to study
LOTOS.

When a Self-Modifying Turing Machine can change itself to become
any other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

Which is IMPOSSIBLE by the definition of a UTM, which MUST execute the
program EXACTLY as it would act when directly run, and since the "code"
of the Turing Machine isn't on its tape, it can't have access to it.

Since you have been told this a number of times, it just shows that you
mind is incapable of understanding how Turing Machines actually work.

This same idea can be implemented as an emulated x86 program
that knows its own machine address. Self-modifying code is
not a new idea. Applying this to TMs is a new idea.

INVALID LOGIC.

The fact that an emulated x86 program can do that doesn't mean that a
Turing Machine can do that.

You just don't understand what you are talking about, and by acting like
you do, you just make yourself into a pathological liar.

Everyone here is acting like unconventional new ideas are
impossible because they are unconventional and new.

No, they are impossible because of the definitions of the system.

SOmething it seems you have decided to not learn or are just ignoring,
which make you into an ignorant pathological liar.

That is simply not the way that reality actually works. If
that was the way that reality works then technology would
never progress.

Technology works by looking at what is actually possible. Not by trying
to figure out what is logically and phyisically impossible.

You are just demonstrating your total ignorance.

To analyze your signature:

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

We can add and ignorance shoots wildly at targets that are not there,
and hurts many innocent bystanders.

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

On 7/20/24 10:23 AM, olcott wrote:

On 7/20/2024 3:53 AM, Fred. Zwarts wrote:

Op 19.jul.2024 om 16:49 schreef olcott:

void Infinite_Loop()
{
   HERE: goto HERE;
}

int main()
{
   HHH(Infinite_Loop);
}

Irrelevant, because you do not understand the difference between
Infinite_Loop and Finite_Recursion.

*Until you understand that this is true*
*we cannot have an honest dialogue*

Until you understand that you logic defies the meaning of the words, you
won't get anywhere.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

int main()
{
  DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

Right, and because HHH thus DOES abort its emulation of DDD, that makes
the DDD that calls it, and thus ALL DDD non-halting programs.

HHH, by definition, does what HHH does, and thus asking what would
happen to a different input is irrelevent.

Of course, part of your problem is you claimed desription of DDD is in
fact just a LIE as it doesn't include all the code of DDD, so you are
just LYING that your DDD, as represented, is a program to decide on.

All you are proving is your utter stupidity and ignorance of what you
talk about, and that you have decided to make yourself in to a
pathological liar.

You system which ties the decider to the input just breaks the logic you
want to use.

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

Op 20.jul.2024 om 16:25 schreef olcott:

On 7/20/2024 4:15 AM, Mikko wrote:

On 2024-07-19 14:49:46 +0000, olcott said:

On 7/19/2024 4:14 AM, Mikko wrote:

On 2024-07-18 14:18:51 +0000, olcott said:

When you are hungry you remain hungry until you eat.
   Before HHH(DDD) aborts its emulation the directly
   executed DDD() cannot possibly halt.

After you eat you are no longer hungry.
   After HHH(DDD) aborts its emulation the directly
   executed DDD() halts.

If DDD does not halt it indicates that HHH is faulty. Therefore the
interesting question is whether DDD halts, not when DDD halts.

This time I made a typo that is much worse than my usual typos.
Pro "when DDD halts" lege "when HHH halts".

*By your same reasoning*
If Infinite_Loop() does not halt HHH is faulty.

No, the reasoning must be differ. Infinite_Loop can be proven to halt
by a simple inspection of a short code. Similar simple inspection of
DDD reveals that DDD does halt if HHH halts but not whether HHH halts.
Therefore the interesting question, needed to complete the proof, is
whether HHH halts. If that can be determined the question about DDD
is easy.

In other words if Infinite_Loop()  is an actual infinite
loop then this is all the fault of HHH.

Nothing is the fault of HHH. If a program is faulty it is the fault
of the author of the program. Usually an infinite loop is a fault
but that depends on the purpose and specification of the program.
Sometimes a program is faulty if it does terminate.

*Until you understand that this is true*
*we cannot have an honest dialogue*

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

int main()
{
  DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

And when it aborts, it aborts one cycle too soon, making the simulation incomplete and, therefore, incorrect.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

Op 20.jul.2024 om 16:23 schreef olcott:

On 7/20/2024 3:53 AM, Fred. Zwarts wrote:

Op 19.jul.2024 om 16:49 schreef olcott:

void Infinite_Loop()
{
   HERE: goto HERE;
}

int main()
{
   HHH(Infinite_Loop);
}

Irrelevant, because you do not understand the difference between
Infinite_Loop and Finite_Recursion.

*Until you understand that this is true*
*we cannot have an honest dialogue*

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

int main()
{
  DDD();
}

Calls HHH(DDD) that must abort the emulation of its input
or {HHH, emulated DDD and executed DDD} never stop running.

And when it aborts, it aborts too soon, making the simulation incorrect.

DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott could not point to an error, but prefers to ignore it. So, I will
repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

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

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

On 7/19/2024 2:49 AM, Mikko wrote:

On 2024-07-17 13:22:09 +0000, olcott said:

On 7/17/2024 2:32 AM, Mikko wrote:

On 2024-07-16 14:04:18 +0000, olcott said:

On 7/16/2024 6:53 AM, Richard Damon wrote:

On 7/15/24 10:51 PM, olcott wrote:

On 7/15/2024 2:40 PM, olcott wrote:

On 7/15/2024 2:30 PM, Fred. Zwarts wrote:

Op 15.jul.2024 om 04:33 schreef olcott:

On 7/14/2024 9:04 PM, Richard Damon wrote:

On 7/14/24 9:27 PM, olcott wrote:

Any input that must be aborted to prevent the non termination >>>>>>>>>>>>>> of simulating termination analyzer HHH necessarily specifies >>>>>>>>>>>>>> non-halting behavior or it would never need to be aborted. >>>>>>>>>>>>>

Excpet, as I have shown, it doesn't.

Your problem is you keep on ILEGALLY changing the input in your >>>>>>>>>>>>> argument because you have misdefined what the input is. >>>>>>>>>>>>>

_DDD()
[00002163] 55         push ebp      ; housekeeping >>>>>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping >>>>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

The input *is* the machine address of this finite
string of bytes: 558bec6863210000e853f4ffff83c4045dc3

It seems that you do not understand x86 language. The input is not a
string of bytes, but an address (00002163). This points to the starting
of the code of DDD. But a simulation needs a program, not a function
calling undefined other functions. Therefore, all functions called by
DDD (such as HHH) are included in the code to simulate.

*The input is the machine address of this finite*
*string of bytes: 558bec6863210000e853f4ffff83c4045dc3*

You are talking about the behavior specified by that finite >>>>>>>>>> string. When you say that a finite string *is not* a finite >>>>>>>>>> string you are disagreeing with the law of identity.

Every rebuttal to my work disagrees with one tautology of another. >>>>>>>>>> It is the fact that DDD calls HHH(DDD) in recursive emulation >>>>>>>>>> that makes it impossible for DDD correctly emulated by HHH to halt. >>>>>>>>>
Everyone disagrees with this entirely on the basis of the strawman >>>>>>>>>> deception (damned lie) that some other DDD somewhere else has >>>>>>>>>> different behavior.

*They disagree with the following*

In other words the fact that the directly executed DDD halts >>>>>>>>> because the HHH(DDD) that it calls has already aborted its
simulation proves these these two different instances of DDD >>>>>>>>> are in different process states.

BUT must have the same behavior.

The state of needing to abort the input changes after it has >>>>>>>>> already been aborted is the same as the state of being hungry >>>>>>>>> changes after you have had something to eat.

Can't. Since programs are unchanging, their properties can not change. >>>>>>>>

*WRONG*
https://en.wikipedia.org/wiki/Self-modifying_code

Your complier cannot produce self-modifying code.

My compiler can accept assembly language
that can derive self-modifying code.

Using non-standard extensions of the language may indeed permit that
unless the program is loaded to a read-only memory. The compiler is
designed so that ordinary programs can be loaded to read-only memory.
Some operating systems prevent programs from modifying themselves as
if the program were in a read-only memory, and typical compilers
compile so that the program can be run under such operating systems.

The bottom line is that an actual TM can modify its own code
while it is running when it has access to its own TM description
and it is only simulated by a UTM. In this case it can modify
itself so that its input is no longer contradictory.

An actual Turing machine cannot change itself. A machine that can change
itself is not a Turing machine.

If you are interested in self-modifying machines you may want to study LOTOS.

When a Self-Modifying Turing Machine can change itself to become
any other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not. A TM description describes a TM that does not change itself.
If it is executed as self-modifying that exectuion is not simulation, as
a simulation does not do what the simulated does not do. A simulator that simulates a self-modifying automaton is not an UTM.

--
Mikko

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

On 7/21/24 9:58 AM, olcott wrote:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become
any other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

No, you haven't, because ot "invent" something you need to actually come
up with a way to actually do it.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

But if X CAN NOT do Y by the definitions, then assuming it can is just incorrect reasoning.

If it is executed as self-modifying that exectuion is not simulation, as
a simulation does not do what the simulated does not do. A simulator that
simulates a self-modifying automaton is not an UTM.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

But it doesn't actually change its behavior when it does that, as the modification it makes were fully predictable from the code and the data,
and thus teh "behavior" always included it.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

But it can't be by the definition of the terms. You just don't
understand what you are talking about because it is beyond your level of understanding.

Note, if anything, *I* (not you) have invented the Self-Modifying Turing Machine by describing how you could ACTUALLY do it, with the proper terminology, but I will give you a hint, I have seen the concept in the
past MANY years ago, so it isn't something new you have invented. Of
course the people who described it, also described what it does and
doesn't do, and as I pointed out, doesn't actually allow you to do
things that you can't do with (non-modifiable) Turing Machines.

For "Random Access" machines, Self-modifying code can sometimes simplify algorithms or reduce the code space needed to express something, and
some processors were designed based on it to save processor complexity.
The JSR (Jump to SubRoutine, or Jump and Save Return) would store the
return address at the target address of the instruction and then
continue at the word following, and to return the subroutine would jump
to the address just before that which contained a JMP instruction, whose address field got filled in by the JSR instruction. Thus, the processor
has no need for a built in call stack or a register dedicated for that
purpose (since those machines often had very few registers, maybe just
an accumlator and a program counter).

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

Am Sun, 21 Jul 2024 08:58:56 -0500 schrieb olcott:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

A self modifying TM is merely a TM description that is simulated by a
UTM and has access to itself on the UTM tape.

Please explain how the two machines don't overwrite each other.
Or how the simulated one manages to break out and change the "UTM".

If it is executed as self-modifying that exectuion is not simulation,
as a simulation does not do what the simulated does not do. A simulator
that simulates a self-modifying automaton is not an UTM.

When a simulated Turing Machine Description is provided access to itself
on the UTM tape it can do the same thing.

The description on the tape is not running. It can't have access to its
own hardware.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

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

On 7/21/24 2:33 PM, joes wrote:

Am Sun, 21 Jul 2024 08:58:56 -0500 schrieb olcott:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

A self modifying TM is merely a TM description that is simulated by a
UTM and has access to itself on the UTM tape.

Please explain how the two machines don't overwrite each other.
Or how the simulated one manages to break out and change the "UTM".

I think the self-modifying-Turing-Machine doesn't change the "UTM" (that
can't actually be a UTM) but changes its "description" on the tape that
lives with its input tape.

Of course, PO describes it with wrong words that makes it fundamentally incorrect.

I suspect that the biggest issue trying to implement something like that
is figuring an encoding for the "description" that allows for the slow manipulation of it that would be inherent in being updated by a Turing
Machine like program, while still keeping it parseable enough for the
engine to keep running it.

There would surely need to be extensive "rules" about what intermediate encodings are allowed to exist or not exist on the tape in that region.

Also, unlike how it seem Olcott view it, the emulated machine would not
be "directly" accessing the actual tape of the master machine, but would
be seeing an emulated virtual tape.

If it is executed as self-modifying that exectuion is not simulation,
as a simulation does not do what the simulated does not do. A simulator
that simulates a self-modifying automaton is not an UTM.

When a simulated Turing Machine Description is provided access to itself
on the UTM tape it can do the same thing.

The description on the tape is not running. It can't have access to its
own hardware.

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

On 2024-07-21 13:58:56 +0000, olcott said:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become
any other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

The term "Turing machine" is already reserved and your "invention"
is not one of the machines that are called "Turing macnines".

Besides, you have not shown the "invention" so there is no
basis to claim that you have invented anything.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

That is a different situation. If someting is not understood one can be
wrong about it. But even a very superficial understanding of Turing
machines suffices for determination that a machine that modifis itself
is not a Turing machine.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

Your false claim about my understanding reveals that you are a liar.
Thank you, but we already knew.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

It is not a Turing machine desription if it describes a self-modification.

--
Mikko

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

On 2024-07-22 14:51:57 +0000, olcott said:

On 7/22/2024 3:26 AM, Mikko wrote:

On 2024-07-21 13:58:56 +0000, olcott said:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become >>>>>>> any other Turing Machine then it can eliminate the pathological
relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

The term "Turing machine" is already reserved and your "invention"
is not one of the machines that are called "Turing macnines".

Besides, you have not shown the "invention" so there is no
basis to claim that you have invented anything.

A Self-Modifying Turing Machine is merely a conventional Turing Machine Description x that is being simulated by a conventional Universal Turing Machine y such that x is provided access to itself on y's tape.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

That is a different situation. If someting is not understood one can be
wrong about it. But even a very superficial understanding of Turing
machines suffices for determination that a machine that modifis itself
is not a Turing machine.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

Your false claim about my understanding reveals that you are a liar.
Thank you, but we already knew.

*Ad Hominem attacks are the first resort of clueless wonders*

Anyone with sufficient software engineering skill can write a
C function that changes its own machine code while it is running.
That you say that I am lying about this is ridiculously stupid
on your part.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

It is not a Turing machine desription if it describes a self-modification. >>

WRONG!

It is not [the conventional notion of] a Turing machine description if
it describes a self-modification, [yet self-modification is by no means impossible].

The input language of an UTM does not contain any expression that could
denote self-modification. In that sense self-modification is inpossible.
It you want to describe a self-modifying machine you need a different description language. If you want to simulate a self-modifying machine
you need a simulator that can understand a description language for descriptions of self-modifying machines.

If the self-modifying machine can be simulated by a Turing machine it
cannot compute anything a Turing machine cannot compute.

--
Mikko

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

On 7/23/24 10:19 AM, olcott wrote:

On 7/23/2024 1:40 AM, Mikko wrote:

On 2024-07-22 14:51:57 +0000, olcott said:

On 7/22/2024 3:26 AM, Mikko wrote:

On 2024-07-21 13:58:56 +0000, olcott said:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become >>>>>>>>> any other Turing Machine then it can eliminate the pathological >>>>>>>>> relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

The term "Turing machine" is already reserved and your "invention"
is not one of the machines that are called "Turing macnines".

Besides, you have not shown the "invention" so there is no
basis to claim that you have invented anything.

A  Self-Modifying Turing Machine is merely a conventional Turing Machine >>> Description x that is being simulated by a conventional Universal Turing >>> Machine y such that x is provided access to itself on y's tape.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

That is a different situation. If someting is not understood one can be >>>> wrong about it. But even a very superficial understanding of Turing
machines suffices for determination that a machine that modifis itself >>>> is not a Turing machine.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

Your false claim about my understanding reveals that you are a liar.
Thank you, but we already knew.

*Ad Hominem attacks are the first resort of clueless wonders*

Anyone with sufficient software engineering skill can write a
C function that changes its own machine code while it is running.
That you say that I am lying about this is ridiculously stupid
on your part.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

It is not a Turing machine desription if it describes a
self-modification.

WRONG!

It is not [the conventional notion of] a Turing machine description
if it describes a self-modification, [yet self-modification is by no
means
impossible].

The input language of an UTM does not contain any expression that could
denote self-modification.

Tape head move, write value. The new idea is that the TM
description has access to its own location on the UTM tape,
unconventional not impossible.

Of course it is, by the definition of a UTM and a Turing machine.

You are just proving you don't know what you are talking about.

 In that sense self-modification is inpossible.

Not all all in my paper the SMTM merely gets rid of the infinite
loop as the accept state.

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

Google has lots of hits for [self modifying Turing machine]

It you want to describe a self-modifying machine you need a different
description language. If you want to simulate a self-modifying machine
you need a simulator that can understand a description language for
descriptions of self-modifying machines.

In my example in my paper the tape head simply moves to
the state transition to an infinite loop and writes
final accept state.

But where is that on the actual tape of the actual Turing Machine?

Changing this
[002]["e"]----->(001, 003) // Transitions to (qa)

Into this:
[002]["e"]----->(001, 1234) // Recognizes "the"

If the self-modifying machine can be simulated by a Turing machine it
cannot compute anything a Turing machine cannot compute.

It gets rid of the infinite loop at its accept state.

Nope, it show that you don't understand what you are doing.

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

On 2024-07-23 14:19:10 +0000, olcott said:

On 7/23/2024 1:40 AM, Mikko wrote:

On 2024-07-22 14:51:57 +0000, olcott said:

On 7/22/2024 3:26 AM, Mikko wrote:

On 2024-07-21 13:58:56 +0000, olcott said:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become >>>>>>>>> any other Turing Machine then it can eliminate the pathological >>>>>>>>> relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

The term "Turing machine" is already reserved and your "invention"
is not one of the machines that are called "Turing macnines".

Besides, you have not shown the "invention" so there is no
basis to claim that you have invented anything.

A  Self-Modifying Turing Machine is merely a conventional Turing Machine >>> Description x that is being simulated by a conventional Universal Turing >>> Machine y such that x is provided access to itself on y's tape.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

That is a different situation. If someting is not understood one can be >>>> wrong about it. But even a very superficial understanding of Turing
machines suffices for determination that a machine that modifis itself >>>> is not a Turing machine.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

Your false claim about my understanding reveals that you are a liar.
Thank you, but we already knew.

*Ad Hominem attacks are the first resort of clueless wonders*

Anyone with sufficient software engineering skill can write a
C function that changes its own machine code while it is running.
That you say that I am lying about this is ridiculously stupid
on your part.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

It is not a Turing machine desription if it describes a self-modification. >>>>

WRONG!

It is not [the conventional notion of] a Turing machine description if
it describes a self-modification, [yet self-modification is by no means
impossible].

The input language of an UTM does not contain any expression that could
denote self-modification.

Tape head move, write value. The new idea is that the TM
description has access to its own location on the UTM tape,
unconventional not impossible.

And not a Turing machine. And there must be a way to indicate in the description of the machine when the head shall move to the code of the
machine. How is that done? And how is the code interpreted when it is
partially updated?

In that sense self-modification is inpossible.

Not all all in my paper the SMTM merely gets rid of the infinite
loop as the accept state.

As the input language of a UTM does not permit self-modification,
a UTM cannot simulate a self-modifying program. If you want to
simulate a self-modifying program you need a simulator that is not
a UTM.

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

Not concrete enough to prove anything important.

Google has lots of hits for [self modifying Turing machine]

Most of which don't mention "self modifying Turing machine" and those
that do don't claim that it is a Turing machine.

It you want to describe a self-modifying machine you need a different
description language. If you want to simulate a self-modifying machine
you need a simulator that can understand a description language for
descriptions of self-modifying machines.

In my example in my paper the tape head simply moves to
the state transition to an infinite loop and writes
final accept state.

Then a part of the tape must be reserved for the transitions and is
not available for other purposes as it is in a Turing machine.
Can your machine add more states or transition rules to the description?

Changing this
[002]["e"]----->(001, 003) // Transitions to (qa)

Into this:
[002]["e"]----->(001, 1234) // Recognizes "the"

If the self-modifying machine can be simulated by a Turing machine it
cannot compute anything a Turing machine cannot compute.

It gets rid of the infinite loop at its accept state.

Not a very impressive application. An ordinary finite state automaton
with four states can solve the same problem.

--
Mikko

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

On 7/25/24 10:05 AM, olcott wrote:

On 7/25/2024 4:40 AM, Mikko wrote:

On 2024-07-23 14:19:10 +0000, olcott said:

On 7/23/2024 1:40 AM, Mikko wrote:

On 2024-07-22 14:51:57 +0000, olcott said:

On 7/22/2024 3:26 AM, Mikko wrote:

On 2024-07-21 13:58:56 +0000, olcott said:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become >>>>>>>>>>> any other Turing Machine then it can eliminate the pathological >>>>>>>>>>> relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

The term "Turing machine" is already reserved and your "invention" >>>>>> is not one of the machines that are called "Turing macnines".

Besides, you have not shown the "invention" so there is no
basis to claim that you have invented anything.

A  Self-Modifying Turing Machine is merely a conventional Turing
Machine
Description x that is being simulated by a conventional Universal
Turing
Machine y such that x is provided access to itself on y's tape.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

That is a different situation. If someting is not understood one
can be
wrong about it. But even a very superficial understanding of Turing >>>>>> machines suffices for determination that a machine that modifis
itself
is not a Turing machine.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

Your false claim about my understanding reveals that you are a liar. >>>>>> Thank you, but we already knew.

*Ad Hominem attacks are the first resort of clueless wonders*

Anyone with sufficient software engineering skill can write a
C function that changes its own machine code while it is running.
That you say that I am lying about this is ridiculously stupid
on your part.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

It is not a Turing machine desription if it describes a
self-modification.

WRONG!

It is not [the conventional notion of] a Turing machine description
if it describes a self-modification, [yet self-modification is by
no means
impossible].

The input language of an UTM does not contain any expression that could >>>> denote self-modification.

Tape head move, write value. The new idea is that the TM
description has access to its own location on the UTM tape,
unconventional not impossible.

And not a Turing machine.

It is an ordinary UTM and an ordinary TM description that is simulated
in the conventional way and the UTM provides the portion of its own tape having this same TM description and the input data to this TMD as the
tape for this TMD. Not at all impossible merely a new idea that no one
ever thought of before.

Which is a contradiction of terms, proving your stupidity.

I am going to stop here because this is a mandatory prerequisite.
Once you agree that you fully understand that all of the above
is correct we can move on to the next point.

That seems right, it is a mandatory prerequiste to believe inconsistant statements to understand what you are saying.

YOU ARE JUST PROVING YOU ARE AN IDIOT.

And there must be a way to indicate in the
description of the machine when the head shall move to the code of the
machine. How is that done? And how is the code interpreted when it is
partially updated?

In that sense self-modification is inpossible.

Not all all in my paper the SMTM merely gets rid of the infinite
loop as the accept state.

As the input language of a UTM does not permit self-modification,
a UTM cannot simulate a self-modifying program. If you want to
simulate a self-modifying program you need a simulator that is not
a UTM.

https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example

Not concrete enough to prove anything important.

Google has lots of hits for [self modifying Turing machine]

Most of which don't mention "self modifying Turing machine" and those
that do don't claim that it is a Turing machine.

It you want to describe a self-modifying machine you need a different
description language. If you want to simulate a self-modifying machine >>>> you need a simulator that can understand a description language for
descriptions of self-modifying machines.

In my example in my paper the tape head simply moves to
the state transition to an infinite loop and writes
final accept state.

Then a part of the tape must be reserved for the transitions and is
not available for other purposes as it is in a Turing machine.
Can your machine add more states or transition rules to the description?

Changing this
[002]["e"]----->(001, 003) // Transitions to (qa)

Into this:
[002]["e"]----->(001, 1234) // Recognizes "the"

If the self-modifying machine can be simulated by a Turing machine it
cannot compute anything a Turing machine cannot compute.

It gets rid of the infinite loop at its accept state.

Not a very impressive application. An ordinary finite state automaton
with four states can solve the same problem.

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

On 2024-07-25 14:05:29 +0000, olcott said:

On 7/25/2024 4:40 AM, Mikko wrote:

On 2024-07-23 14:19:10 +0000, olcott said:

On 7/23/2024 1:40 AM, Mikko wrote:

On 2024-07-22 14:51:57 +0000, olcott said:

On 7/22/2024 3:26 AM, Mikko wrote:

On 2024-07-21 13:58:56 +0000, olcott said:

On 7/21/2024 4:52 AM, Mikko wrote:

On 2024-07-20 13:03:50 +0000, olcott said:

On 7/20/2024 4:01 AM, Mikko wrote:

On 2024-07-19 14:18:05 +0000, olcott said:

When a Self-Modifying Turing Machine can change itself to become >>>>>>>>>>> any other Turing Machine then it can eliminate the pathological >>>>>>>>>>> relationship to its input.

It never was a Turing machine.

A self modifying TM is merely a TM description that is
simulated by a UTM and has access to itself on the UTM
tape.

No, it is not.

I invented it thus that is the specification of my invention.

The term "Turing machine" is already reserved and your "invention" >>>>>> is not one of the machines that are called "Turing macnines".

Besides, you have not shown the "invention" so there is no
basis to claim that you have invented anything.

A  Self-Modifying Turing Machine is merely a conventional Turing Machine >>>>> Description x that is being simulated by a conventional Universal Turing >>>>> Machine y such that x is provided access to itself on y's tape.

A TM description describes a TM that does not change itself.

X is not typically understood to do Y therefore it is
impossible for X to do Y is incorrect reasoning.

That is a different situation. If someting is not understood one can be >>>>>> wrong about it. But even a very superficial understanding of Turing >>>>>> machines suffices for determination that a machine that modifis itself >>>>>> is not a Turing machine.

That you fail to understand that an emulated x86 program can
modify itself to change its own behavior as long as it knows
its own machine address is merely ignorance on your part.

Your false claim about my understanding reveals that you are a liar. >>>>>> Thank you, but we already knew.

*Ad Hominem attacks are the first resort of clueless wonders*

Anyone with sufficient software engineering skill can write a
C function that changes its own machine code while it is running.
That you say that I am lying about this is ridiculously stupid
on your part.

When a simulated Turing Machine Description is provided
access to itself on the UTM tape it can do the same thing.
Rigid minded people incorrectly conflate unconventional
for impossible.

It is not a Turing machine desription if it describes a self-modification.

WRONG!

It is not [the conventional notion of] a Turing machine description if >>>>> it describes a self-modification, [yet self-modification is by no means >>>>> impossible].

The input language of an UTM does not contain any expression that could >>>> denote self-modification.

Tape head move, write value. The new idea is that the TM
description has access to its own location on the UTM tape,
unconventional not impossible.

And not a Turing machine.

It is an ordinary UTM and an ordinary TM description that is simulated
in the conventional way and the UTM provides the portion of its own tape having this same TM description and the input data to this TMD as the
tape for this TMD. Not at all impossible merely a new idea that no one
ever thought of before.

A cat that flies is not an ordinary cat, and a simulator that simulates
a self modifying machine is not an ordianry UTM. If you disagree you
disagree with Common Language and if you disagree with Common Language
you cannot discuss or be understood.

--
Mikko

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