Op 29.aug.2024 om 19:53 schreef olcott:

On 8/29/2024 12:39 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 15:44 schreef olcott:

On 8/29/2024 2:46 AM, Mikko wrote:

On 2024-08-28 11:51:51 +0000, olcott said:

On 8/28/2024 2:37 AM, Mikko wrote:

This group is for discussions about the theory of computation and
related
topics. Discussion about people is off-topic.

Try to point to the tiniest lack of clarity in this fully
specified concrete example.

void DDD()
{
   HHH(DDD);
   return;
}

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

HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.

For all the  years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.

Now that I point this out all that I get for "rebuttal" is bluster
and double talk.

The same thing applies to this more complex example that
is simply over-the-head of most reviewers:

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the group. >>>>

When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.

I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.

It looks more that you are the only person that does not understand
these details, but who thinks that his dreams are a nice substitute
for facts.

I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.

Olcott does not even understand what the semantics of the x86 language
is. He thinks that a finite string can have different behaviours
according to the semantics of the x86 language, depending on whether
it is directly executed, or simulated by different simulators, where
the semantics could be different for each simulator.

Pathological self-reference DOES CHANGE THE SEMANTICS.
"This sentence is not true" is neither true nor false
because it is not a truth bearer.

This sentence is not true: "This sentence is not true"
The exact same (finite string) sentence applied to a
copy of itself becomes true because the inner sentence
is not a truth-bearer.

You are changing the subject to irrelevant other subjects.
There is no pathological self-reference in HHH. HHH must decide about
its input, not about itself.
It is clear that you are completely confused, or distracting the
attention from the fact that you have been proven incorrect.

Fred thinks the when DDD is emulated by HHH according to
the semantics of the x86 language and this causes an
emulated HHH to not halt then the emulation is wrong.

Olcott has a strange problem with the English language. He is unable
to express himself. When he talks about what other people say, they
never recognize themselves in his words. When he talks about other
things he always expresses himself in self-contradictory ways. It is
not clear to me whether this is only a problem in expressing himself,
it looks as if he also has a problem in understanding English.

I never said such a thing.
I said that a finite string has a unique meaning according to the
semantics of the x86 language.

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

Anyone that studies linguistic meaning knows that context
does change the meaning. That you are ignorant of this
IS NOT MY MISTAKE !!!

Again an irrelevant change of subject. (Do you know the term 'straw men'?)
You try again to get away with changing the meaning of words.
The definition of the semantics of the x86 language does nowhere specify
that the interpretation of a finite string depends on the context.

That other language have such dependencies is irrelevant.

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

On 8/29/24 1:53 PM, olcott wrote:

On 8/29/2024 12:39 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 15:44 schreef olcott:

On 8/29/2024 2:46 AM, Mikko wrote:

On 2024-08-28 11:51:51 +0000, olcott said:

On 8/28/2024 2:37 AM, Mikko wrote:

This group is for discussions about the theory of computation and
related
topics. Discussion about people is off-topic.

Try to point to the tiniest lack of clarity in this fully
specified concrete example.

void DDD()
{
   HHH(DDD);
   return;
}

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

HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.

For all the  years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.

Now that I point this out all that I get for "rebuttal" is bluster
and double talk.

The same thing applies to this more complex example that
is simply over-the-head of most reviewers:

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the group. >>>>

When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.

I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.

It looks more that you are the only person that does not understand
these details, but who thinks that his dreams are a nice substitute
for facts.

I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.

Olcott does not even understand what the semantics of the x86 language
is. He thinks that a finite string can have different behaviours
according to the semantics of the x86 language, depending on whether
it is directly executed, or simulated by different simulators, where
the semantics could be different for each simulator.

Pathological self-reference DOES CHANGE THE SEMANTICS.
"This sentence is not true" is neither true nor false
because it is not a truth bearer.

This sentence is not true: "This sentence is not true"
The exact same (finite string) sentence applied to a
copy of itself becomes true because the inner sentence
is not a truth-bearer.

Fred thinks the when DDD is emulated by HHH according to
the semantics of the x86 language and this causes an
emulated HHH to not halt then the emulation is wrong.

Olcott has a strange problem with the English language. He is unable
to express himself. When he talks about what other people say, they
never recognize themselves in his words. When he talks about other
things he always expresses himself in self-contradictory ways. It is
not clear to me whether this is only a problem in expressing himself,
it looks as if he also has a problem in understanding English.

I never said such a thing.
I said that a finite string has a unique meaning according to the
semantics of the x86 language.

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

WRONG.

Anyone that studies linguistic meaning knows that context
does change the meaning. That you are ignorant of this
IS NOT MY MISTAKE !!!

But not ALL sentences change meaning based on the context. And, since
Deciders are deciding OBJECTIVE criteria, there can not be "context" to
the input.

If there needs to be, then the question is just mis-stated, or the input incorrect.

"Halting", as defined by the problem is PURELY objective, either a
program WILL halt or it will not.

If an input might or might not halt, it says it is not a program.

This is your problem of trying to remove the decider from the input, it
means you no longer have a program so it is incorrect to ask about the
halting of a non-program.

Of course, you are just too stupid to understand.

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

Op 29.aug.2024 om 20:39 schreef olcott:

On 8/29/2024 1:11 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 19:53 schreef olcott:

On 8/29/2024 12:39 PM, Fred. Zwarts wrote:

Olcott does not even understand what the semantics of
the x86 language is. He thinks that a finite string can
have different behaviours according to the semantics
of the x86 language, depending on whether it is directly
executed, or simulated by different simulators, where the
semantics could be different for each simulator.

Pathological self-reference DOES CHANGE THE SEMANTICS.
"This sentence is not true" is neither true nor false
because it is not a truth bearer.

This sentence is not true: "This sentence is not true"
The exact same (finite string) sentence applied to a
copy of itself becomes true because the inner sentence
is not a truth-bearer.

You are changing the subject to irrelevant other subjects.

I am provided a specific concrete counter-example that
correctly refutes your claim that finite strings have
the exact same meaning regardless of context.

It is incorrect to ignore context.
You are incorrect to ignore context.

Sometimes context is important, but in the case of the semantics of the
x86 language the counter example is irrelevant.
Your counter example is about a self reference, but in HHH there is no
self reference.
Maybe *your* HHH has a self-reference, because its own address is
programmed in it, but that is just an error in the programming of the code.
A correct decider processes its input, unaware of the fact whether that
input contains a copy of its own algorithm.
Saying that HHH cannot answer that because it is a self-reference is the
same as saying that the question "Does this person have blue eyes?"
cannot be answered because it contains a self-reference if the person
happens to be your twin brother.
The fact that the person is your twin brother and that you need eyes to
see the colour does not make it a self-reference.
Similarly, when HHH decided about its *input*, there is no
self-reference, even if the input uses the same algorithm as used inside
HHH.

You are incorrect that the context would change the semantics of the x86 language. The only evidence for your claim is an irrelevant counter-example.

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

On 2024-08-29 17:53:44 +0000, olcott said:

On 8/29/2024 12:39 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 15:44 schreef olcott:

On 8/29/2024 2:46 AM, Mikko wrote:

On 2024-08-28 11:51:51 +0000, olcott said:

On 8/28/2024 2:37 AM, Mikko wrote:

This group is for discussions about the theory of computation and related
topics. Discussion about people is off-topic.

Try to point to the tiniest lack of clarity in this fully
specified concrete example.

void DDD()
{
   HHH(DDD);
   return;
}

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

HHH computes the mapping from DDD to behavior that never reaches
its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.

For all the  years people said that this simulation is incorrect
never realizing that they were disagreeing with the semantics
of the x86 language.

Now that I point this out all that I get for "rebuttal" is bluster
and double talk.

The same thing applies to this more complex example that
is simply over-the-head of most reviewers:

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the group. >>>>

When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.

I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.

It looks more that you are the only person that does not understand
these details, but who thinks that his dreams are a nice substitute for
facts.

I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.

Olcott does not even understand what the semantics of the x86 language
is. He thinks that a finite string can have different behaviours
according to the semantics of the x86 language, depending on whether it
is directly executed, or simulated by different simulators, where the
semantics could be different for each simulator.

Pathological self-reference DOES CHANGE THE SEMANTICS.

No, it does not.

"This sentence is not true" is neither true nor false
because it is not a truth bearer.

Its meaning never changed.

--
Mikko

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

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem. It specifies the meanings
but not any finite strings to carry these meanings. The meanings
exist independently of any finite string. A solution or a partial
solution to the problem specifies how each of these meanings shall
be expressed with a finite string for other parts of the solution.

--
Mikko

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

On 8/30/24 8:32 AM, olcott wrote:

On 8/30/2024 3:02 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

On 8/29/2024 12:39 PM, Fred. Zwarts wrote:

Op 29.aug.2024 om 15:44 schreef olcott:

On 8/29/2024 2:46 AM, Mikko wrote:

On 2024-08-28 11:51:51 +0000, olcott said:

On 8/28/2024 2:37 AM, Mikko wrote:

This group is for discussions about the theory of computation
and related
topics. Discussion about people is off-topic.

Try to point to the tiniest lack of clarity in this fully
specified concrete example.

void DDD()
{
   HHH(DDD);
   return;
}

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

HHH computes the mapping from DDD to behavior that never reaches >>>>>>> its "return" statement on the basis of the x86 emulation of DDD
by HHH according to the semantics of the x86 language.

For all the  years people said that this simulation is incorrect >>>>>>> never realizing that they were disagreeing with the semantics
of the x86 language.

Now that I point this out all that I get for "rebuttal" is bluster >>>>>>> and double talk.

The same thing applies to this more complex example that
is simply over-the-head of most reviewers:

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Nice to see that you don't disagree.
But you should not use subject lines that are off-topic for the
group.

When a specific reviewer makes a specific mistake in
reviewing my work related to this group I must refer
to that specific reviewer's mistake to clear my name.

I could generalize it. No one person here besides myself
sufficiently understands the details of how a simulating
halt decider computes the mapping from an input finite
string to the behavior that this finite sting specifies.

It looks more that you are the only person that does not understand
these details, but who thinks that his dreams are a nice substitute
for facts.

I specifically referred to Ben because he got everything
else correctly. Most everyone else cannot even understand
that correct simulation is defined by HHH emulating DDD
according to the semantics of the x86 language.

Olcott does not even understand what the semantics of the x86
language is. He thinks that a finite string can have different
behaviours according to the semantics of the x86 language, depending
on whether it is directly executed, or simulated by different
simulators, where the semantics could be different for each simulator. >>>>

Pathological self-reference DOES CHANGE THE SEMANTICS.

No, it does not.

"This sentence is not true" is neither true nor false
because it is not a truth bearer.

Its meaning never changed.

I showed you the before any after, that was before
it changed this is the after"

*This sentence is not true: "This sentence is not true". is true*

It changed because of one level of indirection applied to
pathological self-reference.

But the PROGRAM has no "levels of indiretion", so that doesn't apply.

PROGRAMS are, by definition, self-contained, and thus need (and can't
use) references.

The copy of HHH in DDD doesn't say use whatever HHH is trying to decide
this, it is saying use the HHH that this DDD was built on, which can't
change if you try to give this input to another decider.

If you try to make it do so, it just shows that you system isn't
actually asking the question you claim it is, which *IS* part of the
problem with you setup.

The "input" "DDD" must be a complete and defined program, which means
that the HHH that is in the system is FIXED, and thus talking about some
other HHH being there is just a LIE that violates the rules of the system.

You are just proving that you are ignorant of the field you are talking
about and trying to be intentionally deceptive to pass off your lies,
but failing miserably because your deception is so obvious the main
person it is deceiving is YOU.

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

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

--
Mikko

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

Op 30.Aug.2024 OM 14:57 screech Wolcott:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

and all four of them are emulated by the world
class x86 emulator libx86emu

And the unmodified world class emulator showed that the input (DID based
on HEH) has a halting behaviour.

It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.

And after a few recursions HEH sees a 'special condition' which makes
that its stops the simulation.
This is a modification of the world class simulator, which makes the
simulation incorrect, because now it stops before the simulated input
could halt.
Since the unmodified world class simulator showed a halting behaviour,
the modified simulator must be incorrect.
It stops the simulation one cycle too soon.

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

On 8/30/24 8:57 AM, olcott wrote:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

WHERE?

Your failure to point to the instruction actually correctly emulated
that differed from that same instruction directly executed is just PROOF
that you statement is just a LIE.

and all four of them are emulated by the world
class x86 emulator libx86emu

It is easy to see that when the executed HHH emulates
DDD that it does this correctly when we look at the
execution trace and see the the first four instructions
of DDD are listed.

So why does HHH not show the CORRECT emulation of the call HHH instruction?

You keep on making this LIE, which just shows that you are nothing but a
stupid know-nothing pathological liar.

The *ONLY* correct x86 emulation of a "call HHH" instruction" is to be
followed by the emulation of the code of HHH.

PERIOD,

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

New slave_stack at:1038c4
Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc [00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD [0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)

But the following is *NOT* the "correct emulation" of the instruction above.

And thus, you are just PROVED to be a LIAR.

New slave_stack at:14e2ec
[00002172][0015e2e4][0015e2e8] 55         push ebp      ; housekeeping
[00002173][0015e2e4][0015e2e8] 8bec       mov ebp,esp   ; housekeeping
[00002175][0015e2e0][00002172] 6872210000 push 00002172 ; push DDD [0000217a][0015e2dc][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Then this emulated DDD calls an emulated HHH(DDD).
It is easy to see that when the executed HHH emulates
itself emulated DDD that it does this correctly when we
look at the execution trace and see the the first four
instructions of DDD are listed again.

Nope, just proves you don't know the meaning of the words you use, and
that you are so stupid you can not learn them.

Sorry, but that is just the FACTS of the universe, something you can't
just define away, because you are just a pitiful ignorant DYING man that
has destroyed his reputation for ALL TIME.

It specifies the meanings
but not any finite strings to carry these meanings. The meanings
exist independently of any finite string. A solution or a partial
solution to the problem specifies how each of these meanings shall
be expressed with a finite string for other parts of the solution.

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

Op 31.aug.2024 om 14:26 schreef olcott:

On 8/30/2024 8:22 AM, Mikko wrote:

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

int sum(int x, int y) { return x + y; }
And in the exact same way Bill wants to get the
sum of 5+6 from sum(3,2).

HHH must use its actual input as its basis
and it not allowed to use anything else.

HHH is given a finite string of a halting program.
But olcott wants it to process a modified input, where the abort code
has been removed.
That is not allowed. HHH should process its input, not a non-input.
Just as sum(3,2) is not allowed to modify the 3 into a 4 before it adds
the two numbers. But olcott seems to think that it is correct to write
sum as
int sum(int x, int y) { return (x+1) + y; }

DDD emulated by HHH according to the semantics of the x86
language cannot possibly stop running unless aborted and
cannot possibly reach its only final halt state no matter
what HHH does.

Exactly, showing that this is an incorrect simulation, no matter what
HHH does.

Therefore DDD never halts even if everyone> in the universe including

myself disagrees.

No. This proves that HHH is unable to see the halting behaviour of DDD
and makes a wild guess. An incorrect guess in this case.

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 of a
halting program.

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

On 8/31/24 8:26 AM, olcott wrote:

On 8/30/2024 8:22 AM, Mikko wrote:

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

int sum(int x, int y) { return x + y; }
And in the exact same way Bill wants to get the
sum of 5+6 from sum(3,2).

Which makes BILL wrong.

HHH must use its actual input as its basis
and it not allowed to use anything else.

Right, and not be Bill by thinking the inpus is something it isn't

DDD emulated by HHH according to the semantics of the x86
language cannot possibly stop running unless aborted and
cannot possibly reach its only final halt state no matter
what HHH does. Therefore DDD never halts even if everyone
in the universe including myself disagrees.

Which makes as much sense as Bills thought.

Your HHH does NOT correctly (and thus fully) emulate its input DDD
according to those semantics, and thus is just being your Bill above.

HHH can't do "whatever" or it isn't the HHH that is being discusses, but
it has fixed behavior. As such, you statement makes no sense.

Making HHH, post-hoc, a variable after defining your input DDD is just admitting that you are trying to setup a false system. You are just
proving how stupid your logic system is, that seems to allow constants
to vary and thus truth is no longer true.

Once HHH is changed to not be a fixed program, DDD is not longer a
program with behavior to be determined, yes "DDD never halts" because
"DDD" is no longer the sort of thing that can "halt".

You are just proving your utter STUPIDITY.

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

On 8/31/24 11:33 AM, olcott wrote:

On 8/31/2024 10:24 AM, Fred. Zwarts wrote:

Op 31.aug.2024 om 14:26 schreef olcott:

On 8/30/2024 8:22 AM, Mikko wrote:

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

int sum(int x, int y) { return x + y; }
And in the exact same way Bill wants to get the
sum of 5+6 from sum(3,2).

HHH must use its actual input as its basis
and it not allowed to use anything else.

HHH is given a finite string of a halting program.

ARE YOU FREAKING BRAIN DEAD?

HALTING ONLY MEANS REACHING A FINAL HALT STATE
AND DDD EMULATED BY HHH CANNOT POSSIBLY DO THIS.

But "not/non-halting" is also a technical term that means NEVER reaches
a final state, even after an unbounded number of steps.

Halting/Non-Halting is a property only of COMPLETE behavior of an entity.

DDD is NOT "non-halting" just because its simulation was aborted, to be non-halting, the COMPLETE behavior of this exact input (which includes
the HHH that it calls) will never reach a final state, but it does,
since the complete behavior will see the HHH that DDD calls eventually
also deciding, by the exact same conditions, to abort its operation and
return to its caller, which will then reach a final state.

The EMULATION didn't reach a final state, but that isn't "non-halting",
as that term is reserved in the field for COMPLETE behaviors, but to be
correct needs a longer term like not-yet-halted, or a simple didn't
reach the final state.

That, or you need to just admit that you aren't working in the field and nothing you say applies, at which point you can make up your own
meaning, and reveal how truthful you are by how clearly you define what
you are doing.

void DDD()
{
  HHH(DDD);
  return;
}

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

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

On 2024-08-31 12:26:15 +0000, olcott said:

On 8/30/2024 8:22 AM, Mikko wrote:

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

int sum(int x, int y) { return x + y; }
And in the exact same way Bill wants to get the
sum of 5+6 from sum(3,2).

If Bill wants to get the sum of 5 + 6 then there are two possibilites:
either you give him a tool that can give him the sum and instrunctions
of use of that tool; or you don't, in which case Bill may ask someone
else.

--
Mikko

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

On 9/2/24 9:28 AM, olcott wrote:

On 9/1/2024 6:13 AM, Mikko wrote:

On 2024-08-31 12:26:15 +0000, olcott said:

On 8/30/2024 8:22 AM, Mikko wrote:

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

int sum(int x, int y) { return x + y; }
And in the exact same way Bill wants to get the
sum of 5+6 from sum(3,2).

If Bill wants to get the sum of 5 + 6 then there are two possibilites:
either you give him a tool that can give him the sum and instrunctions
of use of that tool; or you don't, in which case Bill may ask someone
else.

Bill cannot get the sum of 5+6 from sum(3,2)
the same way that HHH cannot report on the
behavior of the directly executed DDD() on
the basis of DDD emulated by HHH where DDD and
HHH have a pathological relationship.

So you admit that HHH can't get the right answer

For three years people have tried to get away with
simply ignoring the elephant in the room of the
pathological relationship between DDD and HHH.

The problem you have is that the pathological relationship doesn't
change the correct answer to the acutal OBJECTIVE question, just makes
it impossible for this HHH to get the right answer.

And, DDD doesn't even have a real pathological relationship, like D did.

If you programed HHH to simple return 1, it would be correct, so there
ARE HHH that correctly answer the question, just not ones built with
your broken method.

They keep assuming that the behavior of DDD with
a pathological relationship to HHH must be the same
behavior as DDD having no pathological relationship
to HHH1 AGAINST THE VERIFIED FACTS.

But it IS and you are accepted that fafact by not showing the
instruciton that WAS correctly emulated that differed in behavior,

When someone contradicts the verified facts this is
the most certain way to determine that they are not
telling the truth.

Right, so *YOU* are the one prove to be the LIAR, as YOU are the one
that refuses to even look at the facts, because you have brainwashed
yourself.

it now seems like they may have been too indoctrinated
to pay close enough attention to see that their position
directly contradicts verified facts.

Nope, we point out the errors in your "analysis", but you can not handle
them.

We look a level deeper than what you talk about, and show the errors,
you can't go to that level because it shows your error

Because these things are so dead obvious to me it initially
seemed that they were contradicting the verified facts out
of sadistic pleasure of playing head games.

No, they are "dead obvious" to you because your brain is DEAD from
being throughly washed of all ability to reason. This is why you just
refuse to try to prove any of your assertions, because you subsconcious
knows that to try to do so will reveal your house of cards that your
lies are built on.

Sorry, all you are doing is proving how stupid and ignorant you are, and
that you just continue to LIE to try to cover that up.

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

On 2024-09-02 13:28:01 +0000, olcott said:

On 9/1/2024 6:13 AM, Mikko wrote:

On 2024-08-31 12:26:15 +0000, olcott said:

On 8/30/2024 8:22 AM, Mikko wrote:

On 2024-08-30 12:57:49 +0000, olcott said:

On 8/30/2024 3:11 AM, Mikko wrote:

On 2024-08-29 17:53:44 +0000, olcott said:

I just proved that the basic notion of finite strings
having unique meanings independently of their context
is incorrect.

The context is the halting problem.

The behavior of
the directly executed DDD and executed HHH
is different from the behavior of
the emulated DDD and the emulated HHH

The correct behaviour is the computation that the user wants to
ask about. If the input string specifies a different behaviour
then the input string is worng, not the behaviour.

int sum(int x, int y) { return x + y; }
And in the exact same way Bill wants to get the
sum of 5+6 from sum(3,2).

If Bill wants to get the sum of 5 + 6 then there are two possibilites:
either you give him a tool that can give him the sum and instrunctions
of use of that tool; or you don't, in which case Bill may ask someone
else.

Bill cannot get the sum of 5+6 from sum(3,2)

That's obvious. So your program is not useful without instrictions
for user.

--
Mikko

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