XPost: sci.logic

Op 17.mrt.2025 om 16:21 schreef olcott:

On 3/17/2025 4:13 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 00:03 schreef olcott:

On 3/16/2025 3:26 PM, Fred. Zwarts wrote:

Op 16.mrt.2025 om 20:32 schreef olcott:

Only when the problem is defined to require H to return
a correct halt status value for an input that is actually
able to do the opposite of whatever value that H returns.

Read what I said: "all possible inputs". So, indeed, this input is
included. So we agree that no such algorithm exists.

Square_Root("This does not have a square root")

Irrelevant change of subject. No rebuttal.

It proves that there is such a thing as invalid inputs.
Invalid inputs are isomorphic to incorrect polar questions.

The logical law of polar questions copyright PL Olcott 2015 https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ

An incorrect polar question is any polar question such that both
yes and no are the wrong answer.

In the specific halting Problem instance of the HHH/DD
pair the halting problem question: Does your input halt?
has much more details:

What correct Boolean value can HHH return when DD is able
to do the opposite of whatever value that HHH returns?

Since both true and false are the wrong answer then this
specific HHH/DD problem instance IS AN IN CORRECT POLAR QUESTION.

I conclude that we agree that the answer on the question: "Does an
algorithm exist that for all possible inputs returns whether it
describes a halting program in direct execution" is 'No'.

Is it so difficult for Olcott to express his (dis)agreement?

I am not talking about simulations, but about direct execution.
I am correct that you think that the question whether an algoritme
exists that returns for all inputs whether the program described in the
input halts when executed directly cannot be answered with yes/no?

Is that
1) because you think that some programs in direct execution are neither halting, nor non-halting?
2) because you think that some programs in direct execution are both
halting and non-halting?
3) because you think that it is impossible to create such an algorithm?

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

XPost: sci.logic

Op 17.mrt.2025 om 18:19 schreef olcott:

On 3/17/2025 11:49 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 16:21 schreef olcott:

On 3/17/2025 4:13 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 00:03 schreef olcott:

On 3/16/2025 3:26 PM, Fred. Zwarts wrote:

Op 16.mrt.2025 om 20:32 schreef olcott:

Only when the problem is defined to require H to return
a correct halt status value for an input that is actually
able to do the opposite of whatever value that H returns.

Read what I said: "all possible inputs". So, indeed, this input is >>>>>> included. So we agree that no such algorithm exists.

Square_Root("This does not have a square root")

Irrelevant change of subject. No rebuttal.

It proves that there is such a thing as invalid inputs.
Invalid inputs are isomorphic to incorrect polar questions.

The logical law of polar questions copyright PL Olcott 2015
https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ

An incorrect polar question is any polar question such that both
yes and no are the wrong answer.

In the specific halting Problem instance of the HHH/DD
pair the halting problem question: Does your input halt?
has much more details:

What correct Boolean value can HHH return when DD is able
to do the opposite of whatever value that HHH returns?

Since both true and false are the wrong answer then this
specific HHH/DD problem instance IS AN IN CORRECT POLAR QUESTION.

I conclude that we agree that the answer on the question: "Does an
algorithm exist that for all possible inputs returns whether it
describes a halting program in direct execution" is 'No'.

Is it so difficult for Olcott to express his (dis)agreement?

I am not talking about simulations, but about direct execution.

THIS IS ALWAYS IMPOSSIBLE. NO TM CAN EVER
LOOK AT THE DIRECT EXECUTION OF ANOTHER TM.

You say "THIS IS ALWAYS IMPOSSIBLE". I understand that means a 'yes' to
my question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs returns whether it describes a halting
program in direct execution" is 'No'?

It seems very difficult for you to say 'yes, I agree", but I accept
"THIS IS ALWAYS IMPOSSIBLE" as a 'yes'.
Correct?

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

XPost: sci.logic

Op 17.mrt.2025 om 20:41 schreef olcott:

On 3/17/2025 1:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 18:19 schreef olcott:

On 3/17/2025 11:49 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 16:21 schreef olcott:

On 3/17/2025 4:13 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 00:03 schreef olcott:

On 3/16/2025 3:26 PM, Fred. Zwarts wrote:

Op 16.mrt.2025 om 20:32 schreef olcott:

Only when the problem is defined to require H to return
a correct halt status value for an input that is actually
able to do the opposite of whatever value that H returns.

Read what I said: "all possible inputs". So, indeed, this input >>>>>>>> is included. So we agree that no such algorithm exists.

Square_Root("This does not have a square root")

Irrelevant change of subject. No rebuttal.

It proves that there is such a thing as invalid inputs.
Invalid inputs are isomorphic to incorrect polar questions.

The logical law of polar questions copyright PL Olcott 2015
https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ

An incorrect polar question is any polar question such that both
yes and no are the wrong answer.

In the specific halting Problem instance of the HHH/DD
pair the halting problem question: Does your input halt?
has much more details:

What correct Boolean value can HHH return when DD is able
to do the opposite of whatever value that HHH returns?

Since both true and false are the wrong answer then this
specific HHH/DD problem instance IS AN IN CORRECT POLAR QUESTION.

I conclude that we agree that the answer on the question: "Does an >>>>>> algorithm exist that for all possible inputs returns whether it
describes a halting program in direct execution" is 'No'.

Is it so difficult for Olcott to express his (dis)agreement?

I am not talking about simulations, but about direct execution.

THIS IS ALWAYS IMPOSSIBLE. NO TM CAN EVER
LOOK AT THE DIRECT EXECUTION OF ANOTHER TM.

You say "THIS IS ALWAYS IMPOSSIBLE". I understand that means a 'yes'
to my question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs returns whether it describes a halting
program in direct execution" is 'No'?

It seems very difficult for you to say 'yes, I agree", but I accept
"THIS IS ALWAYS IMPOSSIBLE" as a 'yes'.
Correct?

It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.

No, of course it cannot monitor.
But does an algorithm exist that always determines in one way or another
that the program described in the finite string is a program that halts
when directly executed?
That is the question. And it seems you say 'No'. Because you said "THIS
IS ALWAYS IMPOSSIBLE".
If so, we agree that the answer on the question: "Does an algorithm
exist that for all possible inputs returns whether it describes a
halting program in direct execution" is 'No'.

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

XPost: sci.logic

On 3/17/25 11:21 AM, olcott wrote:

On 3/17/2025 4:13 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 00:03 schreef olcott:

On 3/16/2025 3:26 PM, Fred. Zwarts wrote:

Op 16.mrt.2025 om 20:32 schreef olcott:

Only when the problem is defined to require H to return
a correct halt status value for an input that is actually
able to do the opposite of whatever value that H returns.

Read what I said: "all possible inputs". So, indeed, this input is
included. So we agree that no such algorithm exists.

Square_Root("This does not have a square root")

Irrelevant change of subject. No rebuttal.

It proves that there is such a thing as invalid inputs.
Invalid inputs are isomorphic to incorrect polar questions.

But Tarski showed that x was a valid input, something you haven't even attempted to disprove, only tried to use a strawman, showing you don't understand how logic works.

The logical law of polar questions copyright PL Olcott 2015 https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ

An incorrect polar question is any polar question such that both
yes and no are the wrong answer.

In the specific halting Problem instance of the HHH/DD
pair the halting problem question: Does your input halt?
has much more details:

But that isn't the Halting question, so you are just showing that you
are working on a strawman.

And note, that if H and D are actually programs, the question does have
a correct answer, just not the one that H gives, so H is just incorrect.

And, when you try to change H to show the other answer is wrong, your
reveal your fraud by also changing the input, by lying about what the
input actually was.

What correct Boolean value can HHH return when DD is able
to do the opposite of whatever value that HHH returns?

The one it doesn't return.

Since both true and false are the wrong answer then this
specific HHH/DD problem instance IS AN IN CORRECT POLAR QUESTION.

No, the problem is HHH, being a specific program, can only return one of
the answers. Something you seem to be too stupid to understand, which
just blows apart the FRAUD that you have been trying to pass off.

I conclude that we agree that the answer on the question: "Does an
algorithm exist that for all possible inputs returns whether it
describes a halting program in direct execution" is 'No'.

Is it so difficult for Olcott to express his (dis)agreement?

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

XPost: sci.logic

On Mon, 17 Mar 2025 22:50:30 -0500, olcott wrote:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 4:31 PM, olcott wrote:

On 3/17/2025 3:14 PM, dbush wrote:

On 3/17/2025 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed
executed TM to its behavior and everyone saying this <is> the basis
for the halting problem is wrong.

Monitoring is not required.  The only thing that's required is to
report on the hypothetical case where the TM Y described as <Y> is
executed directly.

For example:

int H(void *M, void *I)
{
     return 1;
}

This correctly maps the behavior of all machines M with input I that
halt when executed directly.

How the right answer is derived is irrelevant.  What is relevant is
that the right answer is returned.

No TM halt decider X can possibly compute the mapping from the
behavior of the direct execution of another TM Y and thus must use a
proxy of whatever behavior that a finite string specifies.

So, you ADMIT the halting problem is impossible to be done by a TM.

Not when it is properly defined.
Termination analyzer HHH is not fooled by pathological input DD when HHH
is allowed to report on the actual behavior that DD actually specifies.

Then why do you continue to argue that it can be done, and try to do it
by lies and strawmen.

Note, the "behavior" that the finite string specifies, for a Halt
Deicder, *IS* the bahavior of the dirrectly executed machine, BY
DEFINITION.

Prior to my work no one had any idea that when a finite string is
emulated according to the exact semantics of its machine language that
this could possibly differ from the direct execution of this same
finite string.

And it can't

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

DDD emulated by HHH according to the semantics of the x86 language**
cannot possibly ever reach its own "ret" instruction and terminate
normally.

Since your HHH doesn't do the correct emulation, you statement is just
a lie.

When the behavior of DD is defined by the semantics of the x86 language
then everyone here has been wrong for two years to to say that this simulation is incorrect.

Are you really a despicable lying bastard, or do you simply not have a
clue about the x86 language?

Surely all lying bastards are despicable so calling one despicable is
probably wasted energy?

/Flibble

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

XPost: sci.logic

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the
directed executed TM to its behavior and everyone
saying this <is> the basis for the halting problem
is wrong.

Again, that looks like a strange way to say 'yes' to the following question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs returns whether it describes a halting
program in direct execution" is 'No'.
But your answer would be 'yes, we agree'. Correct?

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

XPost: sci.logic

Op 17.mrt.2025 om 23:10 schreef olcott:

On 3/17/2025 3:48 PM, dbush wrote:

On 3/17/2025 4:31 PM, olcott wrote:

On 3/17/2025 3:14 PM, dbush wrote:

On 3/17/2025 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the
directed executed TM to its behavior and everyone
saying this <is> the basis for the halting problem
is wrong.

Monitoring is not required.  The only thing that's required is to
report on the hypothetical case where the TM Y described as <Y> is
executed directly.

For example:

int H(void *M, void *I)
{
     return 1;
}

This correctly maps the behavior of all machines M with input I that
halt when executed directly.

How the right answer is derived is irrelevant.  What is relevant is
that the right answer is returned.

No TM halt decider X can possibly compute the
mapping from the behavior of the direct execution
of another TM Y

False.  This one does for all that halt:

int H(void *M, void *I)
{
      return 1;
}

The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.

So, the answer on the following question:
*Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs returns whether it describes a halting
program in direct execution" is 'No'?*
is 'yes, we agree'. Correct?

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

XPost: sci.logic

Op 17.mrt.2025 om 20:45 schreef olcott:

On 3/17/2025 2:41 PM, olcott wrote:

On 3/17/2025 1:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 18:19 schreef olcott:

On 3/17/2025 11:49 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 16:21 schreef olcott:

On 3/17/2025 4:13 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 00:03 schreef olcott:

On 3/16/2025 3:26 PM, Fred. Zwarts wrote:

Op 16.mrt.2025 om 20:32 schreef olcott:

Only when the problem is defined to require H to return
a correct halt status value for an input that is actually
able to do the opposite of whatever value that H returns.

Read what I said: "all possible inputs". So, indeed, this input >>>>>>>>> is included. So we agree that no such algorithm exists.

Square_Root("This does not have a square root")

Irrelevant change of subject. No rebuttal.

It proves that there is such a thing as invalid inputs.
Invalid inputs are isomorphic to incorrect polar questions.

The logical law of polar questions copyright PL Olcott 2015
https://groups.google.com/g/sci.lang/c/AO5Vlupeelo/m/nxJy7N2vULwJ

An incorrect polar question is any polar question such that both
yes and no are the wrong answer.

In the specific halting Problem instance of the HHH/DD
pair the halting problem question: Does your input halt?
has much more details:

What correct Boolean value can HHH return when DD is able
to do the opposite of whatever value that HHH returns?

Since both true and false are the wrong answer then this
specific HHH/DD problem instance IS AN IN CORRECT POLAR QUESTION.

I conclude that we agree that the answer on the question: "Does
an algorithm exist that for all possible inputs returns whether
it describes a halting program in direct execution" is 'No'.

Is it so difficult for Olcott to express his (dis)agreement?

I am not talking about simulations, but about direct execution.

THIS IS ALWAYS IMPOSSIBLE. NO TM CAN EVER
LOOK AT THE DIRECT EXECUTION OF ANOTHER TM.

You say "THIS IS ALWAYS IMPOSSIBLE". I understand that means a 'yes'
to my question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs returns whether it describes a halting
program in direct execution" is 'No'?

It seems very difficult for you to say 'yes, I agree", but I accept
"THIS IS ALWAYS IMPOSSIBLE" as a 'yes'.
Correct?

It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.

NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.

Is that again a strange way to say 'Yes, I agree'?
I am still not 100% sure, because I did not ask 'on basis of the direct execution'.
It seems very difficult for you to understand. So, I ask again in other
words:
Do we agree that the answer on the question: *"Does an algorithm exist
that for all possible inputs returns whether the input describes a
halting program when this input is used in direct execution?" is 'No'?*
So, the algorithm does not have to look at the direct execution of the
input, but it should determine what happens if the input is used for
direct execution.
I have a strong feeling that you think that is indeed impossible. So, we
agree. Correct?

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

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the mapping
from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what would
happen in the hypothetical case that a direct execution is done.

It can only do that when it assumes that the behavior specified by the
semantics of its input machine language exactly matches this behavior.
Its only basis is this input finite string.

i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.

A termination analyzer has no access to that. It doesn't even know that
DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

All that it can see is that DD is calling the same function twice in
sequence and there are no conditional branch instructions between the invocation of DD and this call that could possibly stop this from
endlessly repeating.

There is a conditional branch in part of DD.

--
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 18/03/2025 10:28, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has
only an infinite loop on the basis of the direct execution of Y. No >>>>>> TM can in any way monitor the direct execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed >>>> TM to its behavior and everyone saying this <is> the basis for the
halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the behavior of
the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH can
see.

If only it would simulate correctly... then it would see.

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider incorrect,
which is an option.

It is always impossible for any halt decider to directly report on the
actual behavior of the direct execution of any other TM. Most of the
time the halt decider lucks out and the behavior specified by the finite
string works as a proxy for the behavior of the direct execution.

lolno.

I don't see why not. If we're going to play the odds, 99 times
out of 100 int halts(void *prg void *dat) { return 1; } will get
it right. Halting Problem... SOLVED, and all without any of that
tedious mucking about with logic.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

Am Mon, 17 Mar 2025 20:18:37 -0500 schrieb olcott:

On 3/17/2025 7:48 PM, dbush wrote:

On 3/17/2025 8:44 PM, olcott wrote:

On 3/17/2025 7:22 PM, dbush wrote:

On 3/17/2025 8:18 PM, olcott wrote:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the
mapping from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what
would happen in the hypothetical case that a direct execution is >>>>>>>> done.

It can only do that when it assumes that the behavior specified by >>>>>>> the semantics of its input machine language exactly matches this >>>>>>> behavior. Its only basis is this input finite string.

i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor.

A termination analyzer has no access to that.

The input is required to be a complete description of the program
that can be used to determine its full behavior.  In the case of DD,
that description is the code of the function DD, the code of the
function HHH, and everything that HHH calls down to the OS level.

It does do that and this behavior does specify

Halting behavior when executed directly, which is what is to be
reported on as per the requirements:

*That have now been shown to be incorrect*
The requirements could only exist under the assumption that it is
impossible for the input finite string to specify behavior that differs
from the behavior of the direct execution.

It has always been incorrectly assumed that the input finite string is a perfect proxy for the behavior of the direct execution.

Oh yes, source code is deterministic.


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

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has
only an infinite loop on the basis of the direct execution of Y. No
TM can in any way monitor the direct execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed
TM to its behavior and everyone saying this <is> the basis for the
halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the behavior of
the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH can
see.

If only it would simulate correctly... then it would see.

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider incorrect,
which is an option.

It is always impossible for any halt decider to directly report on the
actual behavior of the direct execution of any other TM. Most of the
time the halt decider lucks out and the behavior specified by the finite string works as a proxy for the behavior of the direct execution.

lolno.

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

Am Mon, 17 Mar 2025 18:51:29 -0500 schrieb olcott:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

On 3/17/2025 3:48 PM, dbush wrote:

On 3/17/2025 4:31 PM, olcott wrote:

On 3/17/2025 3:14 PM, dbush wrote:

On 3/17/2025 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed
executed TM to its behavior and everyone saying this <is> the
basis for the halting problem is wrong.

Monitoring is not required.  The only thing that's required is to >>>>>> report on the hypothetical case where the TM Y described as <Y> is >>>>>> executed directly.
For example:
int H(void *M, void *I)
{
     return 1;
}
This correctly maps the behavior of all machines M with input I
that halt when executed directly.
How the right answer is derived is irrelevant.  What is relevant is >>>>>> that the right answer is returned.

No TM halt decider X can possibly compute the mapping from the
behavior of the direct execution of another TM Y

False.  This one does for all that halt:
int H(void *M, void *I)
{
      return 1;
}

The halt decider does not and cannot possibly compute the mapping from
the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what would
happen in the hypothetical case that a direct execution is done.

It can only do that when it assumes that the behavior specified by the semantics of its input machine language exactly matches this behavior.
Its only basis is this input finite string.

I should hope that the code matches the behaviour.

And because algorithms / Turing machines are deterministic, they will
do *exactly* the same thing *every* time they are directly executed.

It is a verified fact that an input finite string that specifies
recursive emulation does have different behavior than its direct
execution that does not specify recursive emulation.

If a string specifies recursive simulation, it does so whether
simulated or not. You could look at the simulation of it and just
disregard the outermost level.

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

XPost: sci.logic

On 3/17/25 11:53 PM, olcott wrote:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the
directed executed TM to its behavior and everyone
saying this <is> the basis for the halting problem
is wrong.

What makes it wrong?

The question was always, "CAN a TM be built to do this problem?"

That requires that a TM must do what no TM can ever do.
No TM can compute the mapping from an executing process.
Thus no TM can ever report on the behavior of the direct
execution of another TM.

Except that a TM can do that in many cases, that is the whole basis of Simulation. The existance of the UTM says that one TM can exact report
on the behavior of another, it is just that the way it reports
non-halting is by not halting itself.

We CAN easily build a TM that gets many machines right, detecting all
halting machines, and any machine that gets into a repeat state. It just
fails to answer for some non-repeating infinite behaviors.

And for lower rank computation structures, most were solved, that given
a sufficiently larger machine (often of the same structure, just more
states) you could solve the problem.

Thus, yt was a fair question to ask if we could get smart enough to
detect all the possible non-halting behaviors in this class of machines,
and in fact, that was the initial assumption, until Turing Found the
case that can not be solved.

It comes down to the problem with your logic, that you just don't allow
the asking of questions unless you know the answer, which is a very poor
sort of logic.

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

XPost: sci.logic

On Tue, 18 Mar 2025 21:40:30 -0500, olcott wrote:

On 3/18/2025 6:38 AM, Richard Damon wrote:

On 3/17/25 11:36 PM, olcott wrote:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 11:21 AM, olcott wrote:

On 3/17/2025 4:13 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 00:03 schreef olcott:

On 3/16/2025 3:26 PM, Fred. Zwarts wrote:

Op 16.mrt.2025 om 20:32 schreef olcott:

Only when the problem is defined to require H to return a
correct halt status value for an input that is actually able to >>>>>>>>> do the opposite of whatever value that H returns.

Read what I said: "all possible inputs". So, indeed, this input >>>>>>>> is included. So we agree that no such algorithm exists.

Square_Root("This does not have a square root")

Irrelevant change of subject. No rebuttal.

It proves that there is such a thing as invalid inputs. Invalid
inputs are isomorphic to incorrect polar questions.

But Tarski showed that x was a valid input,

He merely falsely assumed that it was a valid input.

He proved it was a valid input given the system.

This sentence is not true: "This sentence is not true". is true in the metalanguage and not true in the language.

Before you can reason about that letalone make an assertion about it you
must first actually state what "This sentence is not true" actually MEANS. Semantics are important; if it has no meaning then reasoning about it in
any context other than if it has meaning or not is a category error.

/Flibble

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

On 3/18/25 10:06 PM, olcott wrote:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the mapping >>>>>>> from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what would >>>>>> happen in the hypothetical case that a direct execution is done.

It can only do that when it assumes that the behavior specified by the >>>>> semantics of its input machine language exactly matches this behavior. >>>>> Its only basis is this input finite string.

i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.

A termination analyzer has no access to that. It doesn't even know that
DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

It has the x86 semantics encoded within it as its algorithm.

But it doesn't fully follow them, as it allows itself to deviate in its emulation by stopping.

All that it can see is that DD is calling the same function twice in
sequence and there are no conditional branch instructions between the
invocation of DD and this call that could possibly stop this from
endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS
NO CONDITIONAL BRANCH.

Which isn't the rule, so you have been caught in your lie.

Note, a call to HHH is NOT a call to DD, or even a call to a correct
emulator of DD, as your HHH doesn't do a correct emulation, but stops
short and returns 0.

When you include that fact in your "definitions", your logic is just
shown to be the lie that it has always been.

Sorry, you are just proving your utter stupidity.

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

On 3/18/25 10:16 PM, olcott wrote:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>> only an infinite loop on the basis of the direct execution of Y. No >>>>>>> TM can in any way monitor the direct execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed >>>>> TM to its behavior and everyone saying this <is> the basis for the
halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the behavior of
the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH can
see.

If only it would simulate correctly... then it would see.

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider incorrect,
which is an option.

It is always impossible for any halt decider to directly report on the
actual behavior of the direct execution of any other TM. Most of the
time the halt decider lucks out and the behavior specified by the finite >>> string works as a proxy for the behavior of the direct execution.

lolno.

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

If you think that DDD correctly simulated by HHH
that includes HHH correctly simulating itself
simulated DDD reaches its return instruction

How the F-ck does it do this?

But your HHH, as defined by the Halt7.c doesn't DO a correct simulation,
so you claim is just unsound.

Of course, if you start with the lie that now Halt7.c doesn't define
what HHH is, you have the problem that DDD then isn't a program, as its
HHH isn't defined.

A non-existent program that is only in the imagination of the Truth
Fairy can do what ever you want it to do, it just proves you are out of
touch with reality.

Your logic is basically one program can act as two different programs at
the same time, and thus you believe the Liar's Paradox is a valid
logical expression with a real truth value.

Sorry, you are just proving your stupidity.

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

Am Tue, 18 Mar 2025 21:06:38 -0500 schrieb olcott:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the mapping >>>>>>> from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what would >>>>>> happen in the hypothetical case that a direct execution is done.

It can only do that when it assumes that the behavior specified by
the semantics of its input machine language exactly matches this
behavior. Its only basis is this input finite string.

I would hope that the semantics of the code are the same as its behaviour.

i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.

A termination analyzer has no access to that. It doesn't even know
that DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

It has the x86 semantics encoded within it as its algorithm.

Yep, so it does in fact have "access".

All that it can see is that DD is calling the same function twice in
sequence and there are no conditional branch instructions between the
invocation of DD and this call that could possibly stop this from
endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS NO CONDITIONAL
BRANCH.

Yes there is, in HHH's abort check.

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

Am Tue, 18 Mar 2025 21:16:57 -0500 schrieb olcott:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed
executed TM to its behavior and everyone saying this <is> the basis
for the halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the behavior
of the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH can
see.

If only it would simulate correctly... then it would see.

^

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider incorrect,
which is an option.

It is always impossible for any halt decider to directly report on the
actual behavior of the direct execution of any other TM. Most of the
time the halt decider lucks out and the behavior specified by the
finite string works as a proxy for the behavior of the direct
execution.

lolno.

Deciders aren't chance-based.

void DDD()
{
HHH(DDD);
return;
}
If you think that DDD correctly simulated by HHH that includes HHH
correctly simulating itself simulated DDD reaches its return instruction
How the Fuck does it do this?

HHH doesn't simulate correctly.

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

XPost: sci.logic

Op 19.mrt.2025 om 02:22 schreef olcott:

On 3/18/2025 4:02 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the
directed executed TM to its behavior and everyone
saying this <is> the basis for the halting problem
is wrong.

Again, that looks like a strange way to say 'yes' to the following
question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs

(adding deleted context)
returns whether it describes a halting program in direct execution" is
'No'?

Please pay very close attention. I have shown that
Such an algorithm does not exist for ANY inputs.

Again no 'yes' or 'no'. But it looks like a hidden 'yes, I agree'. Correct?

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

Am Tue, 18 Mar 2025 20:22:38 -0500 schrieb olcott:

On 3/18/2025 4:02 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has
only an infinite loop on the basis of the direct execution of Y. No
TM can in any way monitor the direct execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed
TM to its behavior and everyone saying this <is> the basis for the
halting problem is wrong.

Again, that looks like a strange way to say 'yes' to the following
question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs

Please pay very close attention. I have shown that Such an algorithm
does not exist for ANY inputs.

There is an "algorithm" that returns the halting status of at least
one program: it always returns "halts" because there is at least one
halting program.

--
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 2025-03-19 02:06:38 +0000, olcott said:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the mapping >>>>>>> from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what would >>>>>> happen in the hypothetical case that a direct execution is done.

It can only do that when it assumes that the behavior specified by the >>>>> semantics of its input machine language exactly matches this behavior. >>>>> Its only basis is this input finite string.

i.e. the semantics of the x86 language when those actual instructions
are actually executed on an actual x86 processor.

A termination analyzer has no access to that. It doesn't even know that
DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

It has the x86 semantics encoded within it as its algorithm.

All that it can see is that DD is calling the same function twice in
sequence and there are no conditional branch instructions between the
invocation of DD and this call that could possibly stop this from
endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS
NO CONDITIONAL BRANCH.

If there is no relevant conditional branch then your aborting criterion
is not correct sensu Sipseri.

--
Mikko

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

Am Wed, 19 Mar 2025 10:46:29 -0500 schrieb olcott:

On 3/19/2025 3:50 AM, joes wrote:

Am Tue, 18 Mar 2025 21:06:38 -0500 schrieb olcott:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the
mapping from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what
would happen in the hypothetical case that a direct execution is >>>>>>>> done.

It can only do that when it assumes that the behavior specified by >>>>>>> the semantics of its input machine language exactly matches this >>>>>>> behavior. Its only basis is this input finite string.

I would hope that the semantics of the code are the same as its
behaviour.

^

i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor.

A termination analyzer has no access to that. It doesn't even know
that DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

It has the x86 semantics encoded within it as its algorithm.

Yep, so it does in fact have "access".

^

All that it can see is that DD is calling the same function twice in >>>>> sequence and there are no conditional branch instructions between
the invocation of DD and this call that could possibly stop this
from endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS NO CONDITIONAL
BRANCH.

Yes there is, in HHH's abort check.

The program under test DD is being tested by the test program HHH. It is incorrect to mix them together.

Shame that HHH is part of DD. Maybe HHH isn't up to the task.

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

Am Wed, 19 Mar 2025 10:52:11 -0500 schrieb olcott:

On 3/19/2025 3:54 AM, joes wrote:

Am Tue, 18 Mar 2025 21:16:57 -0500 schrieb olcott:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed
executed TM to its behavior and everyone saying this <is> the
basis for the halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the behavior >>>>> of the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH
can see.

If only it would simulate correctly... then it would see.

^

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider incorrect, >>>>>> which is an option.

It is always impossible for any halt decider to directly report on
the actual behavior of the direct execution of any other TM. Most of >>>>> the time the halt decider lucks out and the behavior specified by
the finite string works as a proxy for the behavior of the direct
execution.

lolno.

Deciders aren't chance-based.

^

void DDD()
{
HHH(DDD);
return;
}
If you think that DDD correctly simulated by HHH that includes HHH
correctly simulating itself simulated DDD reaches its return
instruction How the Fuck does it do this?

HHH doesn't simulate correctly.

Unless and until you show what a correct simulation is I will assume
that you are simply a liar.

The correct simulation is what HHH1 does, the same as the direct
execution, without aborting.

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

Am Wed, 19 Mar 2025 11:06:07 -0500 schrieb olcott:

On 3/19/2025 5:36 AM, joes wrote:

Am Tue, 18 Mar 2025 20:22:38 -0500 schrieb olcott:

On 3/18/2025 4:02 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed
executed TM to its behavior and everyone saying this <is> the basis
for the halting problem is wrong.

Again, that looks like a strange way to say 'yes' to the following
question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs

Please pay very close attention. I have shown that Such an algorithm
does not exist for ANY inputs.

There is an "algorithm" that returns the halting status of at least one
program: it always returns "halts" because there is at least one
halting program.

Intuitively, a decider should be a Turing machine that given an
input, halts and either accepts or rejects, relaying its answer in
one of many equivalent ways, such as halting at an ACCEPT or REJECT
state, or leaving its answer on the output tape. https://cs.stackexchange.com/questions/84433/what-is-decider
More precisely (with Rice's Theorem in mind) a decider is any Turing
machine that computes the mapping from its input finite string to an
accept or reject state on the basis of a semantic or syntactic property
of this input finite string.

Yep, I described a decider.

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

Am Wed, 19 Mar 2025 11:51:56 -0500 schrieb olcott:

On 3/19/2025 10:57 AM, joes wrote:

Am Wed, 19 Mar 2025 10:46:29 -0500 schrieb olcott:

On 3/19/2025 3:50 AM, joes wrote:

Am Tue, 18 Mar 2025 21:06:38 -0500 schrieb olcott:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

No one claimed it should.  What it must do is determine what >>>>>>>>>> would happen in the hypothetical case that a direct execution >>>>>>>>>> is done.

It can only do that when it assumes that the behavior specified >>>>>>>>> by the semantics of its input machine language exactly matches >>>>>>>>> this behavior. Its only basis is this input finite string.

I would hope that the semantics of the code are the same as its
behaviour.

^

A termination analyzer has no access to that. It doesn't even know >>>>>>> that DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

It has the x86 semantics encoded within it as its algorithm.

Yep, so it does in fact have "access".

^

All that it can see is that DD is calling the same function twice >>>>>>> in sequence and there are no conditional branch instructions
between the invocation of DD and this call that could possibly
stop this from endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS NO CONDITIONAL >>>>> BRANCH.

Yes there is, in HHH's abort check.

The program under test DD is being tested by the test program HHH. It
is incorrect to mix them together.

Shame that HHH is part of DD. Maybe HHH isn't up to the task.

I have said this AT LEAST FIFTY TIMES NOW PAY ATTENTION.

I am, I just disagree. Meanwhile you ignore my above replies.

The measure of the program under test halting is reaching its own "ret" instruction [final halt state] and terminating normally.

Which it does when simulated correctly (which HHH is incapable of).

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

Am Wed, 19 Mar 2025 17:09:38 -0500 schrieb olcott:

On 3/19/2025 12:58 PM, joes wrote:

Am Wed, 19 Mar 2025 10:52:11 -0500 schrieb olcott:

On 3/19/2025 3:54 AM, joes wrote:

Am Tue, 18 Mar 2025 21:16:57 -0500 schrieb olcott:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y >>>>>>>>>>> has only an infinite loop on the basis of the direct execution >>>>>>>>>>> of Y.
No TM can in any way monitor the direct execution of another >>>>>>>>>>> TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed >>>>>>>>> executed TM to its behavior and everyone saying this <is> the >>>>>>>>> basis for the halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the
behavior of the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH >>>>>>> can see.

If only it would simulate correctly... then it would see.

^

Anybody home?

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider
incorrect,
which is an option.

It is always impossible for any halt decider to directly report on >>>>>>> the actual behavior of the direct execution of any other TM. Most >>>>>>> of the time the halt decider lucks out and the behavior specified >>>>>>> by the finite string works as a proxy for the behavior of the
direct execution.

lolno.

Deciders aren't chance-based.

^

Thanks at least for logging your failure.

void DDD()
{
HHH(DDD);
return;
}
If you think that DDD correctly simulated by HHH that includes HHH
correctly simulating itself simulated DDD reaches its return
instruction How the Fuck does it do this?

HHH doesn't simulate correctly.

Unless and until you show what a correct simulation is I will assume
that you are simply a liar.

The correct simulation is what HHH1 does, the same as the direct
execution, without aborting.

You have to show how it is possible for HHH to do this.

That's the thing, it isn't - for HHH.

--
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 3/19/25 11:46 AM, olcott wrote:

On 3/19/2025 3:50 AM, joes wrote:

Am Tue, 18 Mar 2025 21:06:38 -0500 schrieb olcott:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly compute the mapping >>>>>>>>> from the actual behavior of an executing process.

No one claimed it should.  What it must do is determine what would >>>>>>>> happen in the hypothetical case that a direct execution is done. >>>>>>> It can only do that when it assumes that the behavior specified by >>>>>>> the semantics of its input machine language exactly matches this >>>>>>> behavior. Its only basis is this input finite string.

I would hope that the semantics of the code are the same as its
behaviour.

i.e. the semantics of the x86 language when those actual instructions >>>>>> are actually executed on an actual x86 processor.

A termination analyzer has no access to that. It doesn't even know
that DD is calling itself.

For sure a termination analyser has access to the x86 semantics.

It has the x86 semantics encoded within it as its algorithm.

Yep, so it does in fact have "access".

All that it can see is that DD is calling the same function twice in >>>>> sequence and there are no conditional branch instructions between the >>>>> invocation of DD and this call that could possibly stop this from
endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS NO CONDITIONAL
BRANCH.

Yes there is, in HHH's abort check.

The program under test DD is being tested by the test
program HHH. It is incorrect to mix them together.

But the program under test, DD, includes as part of it its own copy of
HHH, (or it isn't a program). That copy can be shared in memory with the
other version (and that just locks them to be the same, and since the
input is fixed, that fixes the decider that you can call HHH).

If HHH isn't part of DD, then DD just isn't a program and you can't
correctly emulate it past the call HHH instruction.

Sorry, you are just getting you self painted into the corner by all your
bad defintions that you aren't allowed to change from the original
system without revealing the fraud of your logic.

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

On 3/19/25 9:48 PM, olcott wrote:

On 3/19/2025 5:38 PM, joes wrote:

Am Wed, 19 Mar 2025 17:09:38 -0500 schrieb olcott:

On 3/19/2025 12:58 PM, joes wrote:

Am Wed, 19 Mar 2025 10:52:11 -0500 schrieb olcott:

On 3/19/2025 3:54 AM, joes wrote:

Am Tue, 18 Mar 2025 21:16:57 -0500 schrieb olcott:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y >>>>>>>>>>>>> has only an infinite loop on the basis of the direct execution >>>>>>>>>>>>> of Y.
No TM can in any way monitor the direct execution of another >>>>>>>>>>>>> TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed >>>>>>>>>>> executed TM to its behavior and everyone saying this <is> the >>>>>>>>>>> basis for the halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the
behavior of the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH >>>>>>>>> can see.

If only it would simulate correctly... then it would see.

^

Anybody home?

Nothing requires that the decider actually be able to do the >>>>>>>>>> computation, the failure to do so just make the decider
incorrect,
which is an option.

It is always impossible for any halt decider to directly report on >>>>>>>>> the actual behavior of the direct execution of any other TM. Most >>>>>>>>> of the time the halt decider lucks out and the behavior specified >>>>>>>>> by the finite string works as a proxy for the behavior of the >>>>>>>>> direct execution.

lolno.

Deciders aren't chance-based.

^

Thanks at least for logging your failure.

void DDD()
{
      HHH(DDD);
      return;
}
If you think that DDD correctly simulated by HHH that includes HHH >>>>>>> correctly simulating itself simulated DDD reaches its return
instruction How the Fuck does it do this?

HHH doesn't simulate correctly.

Unless and until you show what a correct simulation is I will assume >>>>> that you are simply a liar.

The correct simulation is what HHH1 does, the same as the direct
execution, without aborting.

You have to show how it is possible for HHH to do this.

That's the thing, it isn't - for HHH.

HHH cannot emulate DDD according to the semantics that
the x86 language specifies even though it has a world
class x86 emulator embedded within it?

It COULD, but it choses to not to by aborting its emulation based on
unsound logic and false premises.

When the full source code of the x86utm system proves
that HHH  does emulate itself emulating DDD disagreement
is foolish.

Nope, it ohly PARTIALLY emulates itself.

You seem to think that a half truth is a truth, when it is really a full
lie.

Anyone with a sufficient knowledge of the x86 language
can prove this to themselves without even looking at
the source-code. They only have to see that the
execution trace of DDD is exactly the execution trace
of DDD emulated by HHH and HHH emulating itself
emulating DDD.

Nope, you are just proving that you don't understand the x86 language,
and are too stupid to learn when your error is pointed out,

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

THIS IS NOT A CORRECT x86 EMULATION of the above instruction, it CAN'T
be as it is code at the wrong address.

[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

Sorry, but you are just proving how braindead you are and your total
inability to understand the actual meaning of the words you use,

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

Am Wed, 19 Mar 2025 20:08:09 -0500 schrieb olcott:

On 3/19/2025 1:04 PM, joes wrote:

Am Wed, 19 Mar 2025 11:51:56 -0500 schrieb olcott:

On 3/19/2025 10:57 AM, joes wrote:

Am Wed, 19 Mar 2025 10:46:29 -0500 schrieb olcott:

On 3/19/2025 3:50 AM, joes wrote:

Am Tue, 18 Mar 2025 21:06:38 -0500 schrieb olcott:

On 3/18/2025 5:22 AM, joes wrote:

Am Mon, 17 Mar 2025 19:18:52 -0500 schrieb olcott:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

No one claimed it should.  What it must do is determine what >>>>>>>>>>>> would happen in the hypothetical case that a direct execution >>>>>>>>>>>> is done.

It can only do that when it assumes that the behavior
specified by the semantics of its input machine language >>>>>>>>>>> exactly matches this behavior. Its only basis is this input >>>>>>>>>>> finite string.

I would hope that the semantics of the code are the same as its
behaviour.

^

A termination analyzer has no access to that. It doesn't even >>>>>>>>> know that DD is calling itself.

For sure a termination analyser has access to the x86 semantics. >>>>>>> It has the x86 semantics encoded within it as its algorithm.

Yep, so it does in fact have "access".

^

All that it can see is that DD is calling the same function
twice in sequence and there are no conditional branch
instructions between the invocation of DD and this call that >>>>>>>>> could possibly stop this from endlessly repeating.

There is a conditional branch in part of DD.

BETWEEN THE INVOCATION AND THE FUNCTION CALL THERE IS NO
CONDITIONAL BRANCH.

Yes there is, in HHH's abort check.

The program under test DD is being tested by the test program HHH.
It is incorrect to mix them together.

Shame that HHH is part of DD. Maybe HHH isn't up to the task.

I have said this AT LEAST FIFTY TIMES NOW PAY ATTENTION.

I am, I just disagree. Meanwhile you ignore my above replies.

^

The measure of the program under test halting is reaching its own
"ret" instruction [final halt state] and terminating normally.

Which it does when simulated correctly (which HHH is incapable of).

If you weren't just flat out lying you could and would show step by step
what a correct emulation of DD by HHH would be. I have been through this
too many hundreds of times to have any doubt that my reviewers are not
just flat out lying about this.

As I said, HHH can't do it. But you can just stick it into another
simulator that doesn't abort, or just run it.

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

Am Wed, 19 Mar 2025 20:48:13 -0500 schrieb olcott:

On 3/19/2025 5:38 PM, joes wrote:

Am Wed, 19 Mar 2025 17:09:38 -0500 schrieb olcott:

On 3/19/2025 12:58 PM, joes wrote:

Am Wed, 19 Mar 2025 10:52:11 -0500 schrieb olcott:

On 3/19/2025 3:54 AM, joes wrote:

Am Tue, 18 Mar 2025 21:16:57 -0500 schrieb olcott:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It means that everyone saying that the behavior must be the
behavior of the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that >>>>>>>>> HHH can see.

If only it would simulate correctly... then it would see.

^

Anybody home?

It is always impossible for any halt decider to directly report >>>>>>>>> on the actual behavior of the direct execution of any other TM. >>>>>>>>> Most of the time the halt decider lucks out and the behavior >>>>>>>>> specified by the finite string works as a proxy for the behavior >>>>>>>>> of the direct execution.

lolno.

Deciders aren't chance-based.

^

Thanks at least for logging your failure.

void DDD()
{
HHH(DDD);
return;
}
If you think that DDD correctly simulated by HHH that includes HHH >>>>>>> correctly simulating itself simulated DDD reaches its return
instruction How the Fuck does it do this?

HHH doesn't simulate correctly.

Unless and until you show what a correct simulation is I will assume >>>>> that you are simply a liar.

The correct simulation is what HHH1 does, the same as the direct
execution, without aborting.

You have to show how it is possible for HHH to do this.

That's the thing, it isn't - for HHH.

HHH cannot emulate DDD according to the semantics that the x86 language specifies even though it has a world class x86 emulator embedded within
it?

Right, because it aborts.

When the full source code of the x86utm system proves that HHH does
emulate itself emulating DDD disagreement is foolish.

Only partially.

Anyone with a sufficient knowledge of the x86 language can prove this to themselves without even looking at the source-code. They only have to
see that the execution trace of DDD is exactly the execution trace of
DDD emulated by HHH and HHH emulating itself emulating DDD.

It's not. DD doesn't just abort itself.

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

--
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 2025-03-19 22:14:27 +0000, olcott said:

On 3/19/2025 5:36 AM, joes wrote:

Am Tue, 18 Mar 2025 20:22:38 -0500 schrieb olcott:

On 3/18/2025 4:02 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>> only an infinite loop on the basis of the direct execution of Y. No >>>>>>> TM can in any way monitor the direct execution of another TM.

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed >>>>> TM to its behavior and everyone saying this <is> the basis for the
halting problem is wrong.

Again, that looks like a strange way to say 'yes' to the following
question:
Do we agree that the answer on the question: "Does an algorithm exist
that for all possible inputs

Please pay very close attention. I have shown that Such an algorithm
does not exist for ANY inputs.

There is an "algorithm" that returns the halting status of at least
one program: it always returns "halts" because there is at least one
halting program.

Every TM that halts used to be called a decider.

Halts with every input. A TM that halts with some inputs but not all
is not a decider.

Halting on any input was taken to mean that this input was accepted.
The way to reject an input was to get stuck in an infinite loop.

A TM that indicates rejection with an infinite loop is not a decider.
It can be called an acceptor.

It is possible to construct a halting acceptor but not a non-halting
acceptor.

--
Mikko

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

On 2025-03-19 22:09:38 +0000, olcott said:

On 3/19/2025 12:58 PM, joes wrote:

Am Wed, 19 Mar 2025 10:52:11 -0500 schrieb olcott:

On 3/19/2025 3:54 AM, joes wrote:

Am Tue, 18 Mar 2025 21:16:57 -0500 schrieb olcott:

On 3/18/2025 5:28 AM, joes wrote:

Am Mon, 17 Mar 2025 22:43:05 -0500 schrieb olcott:

On 3/17/2025 8:19 PM, Richard Damon wrote:

On 3/17/25 3:58 PM, olcott wrote:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed >>>>>>>>> executed TM to its behavior and everyone saying this <is> the >>>>>>>>> basis for the halting problem is wrong.

And what is wrong about it not being able to compute that?

It means that everyone saying that the behavior must be the behavior >>>>>>> of the direct execution is wrong.
The behavior that HHH reports on can only be the behavior that HHH >>>>>>> can see.

If only it would simulate correctly... then it would see.

^

Nothing requires that the decider actually be able to do the
computation, the failure to do so just make the decider incorrect, >>>>>>>> which is an option.

It is always impossible for any halt decider to directly report on >>>>>>> the actual behavior of the direct execution of any other TM. Most of >>>>>>> the time the halt decider lucks out and the behavior specified by >>>>>>> the finite string works as a proxy for the behavior of the direct >>>>>>> execution.

lolno.

Deciders aren't chance-based.

^

void DDD()
{
HHH(DDD);
return;
}
If you think that DDD correctly simulated by HHH that includes HHH
correctly simulating itself simulated DDD reaches its return
instruction How the Fuck does it do this?

HHH doesn't simulate correctly.

Unless and until you show what a correct simulation is I will assume
that you are simply a liar.

The correct simulation is what HHH1 does, the same as the direct
execution, without aborting.

You have to show how it is possible for HHH to do this.

It is your problem to show what your programs can and can't do.
But in this particular case it is already known that HHH cannot
tell that DDD halts.

--
Mikko

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

On 2025-03-21 04:12:27 +0000, olcott said:

On 3/20/2025 4:53 AM, Mikko wrote:

On 2025-03-19 22:14:27 +0000, olcott said:

On 3/19/2025 5:36 AM, joes wrote:

Am Tue, 18 Mar 2025 20:22:38 -0500 schrieb olcott:

On 3/18/2025 4:02 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>>>> only an infinite loop on the basis of the direct execution of Y. No >>>>>>>>> TM can in any way monitor the direct execution of another TM. >>>>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed >>>>>>> TM to its behavior and everyone saying this <is> the basis for the >>>>>>> halting problem is wrong.

Again, that looks like a strange way to say 'yes' to the following >>>>>> question:
Do we agree that the answer on the question: "Does an algorithm exist >>>>>> that for all possible inputs

Please pay very close attention. I have shown that Such an algorithm >>>>> does not exist for ANY inputs.

There is an "algorithm" that returns the halting status of at least
one program: it always returns "halts" because there is at least one
halting program.

Every TM that halts used to be called a decider.

Halts with every input. A TM that halts with some inputs but not all
is not a decider.

typedef void (*ptr)();
void Halts(ptr P);

// Doesn't actually decide jack shit
void Halts(ptr P)
{
return;
}

That is not a TM and, unlike a TM, does not indicate whther it
halted accepting or rejecting.

--
Mikko

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

XPost: sci.logic

On 3/20/25 11:52 PM, olcott wrote:

On 3/17/2025 8:25 PM, dbush wrote:

On 3/17/2025 9:18 PM, olcott wrote:

On 3/17/2025 7:48 PM, dbush wrote:

On 3/17/2025 8:44 PM, olcott wrote:

On 3/17/2025 7:22 PM, dbush wrote:

On 3/17/2025 8:18 PM, olcott wrote:

On 3/17/2025 7:00 PM, dbush wrote:

On 3/17/2025 7:51 PM, olcott wrote:

On 3/17/2025 5:15 PM, dbush wrote:

On 3/17/2025 6:10 PM, olcott wrote:

The halt decider does not and cannot possibly
compute the mapping from the actual behavior
of an executing process.

No one claimed it should.  What it must do is determine what >>>>>>>>>> would happen in the hypothetical case that a direct execution >>>>>>>>>> is done.

It can only do that when it assumes that the behavior
specified by the semantics of its input machine language
exactly matches this behavior. Its only basis is this
input finite string.

i.e. the semantics of the x86 language when those actual
instructions are actually executed on an actual x86 processor. >>>>>>>>

A termination analyzer has no access to that.

The input is required to be a complete description of the program
that can be used to determine its full behavior.  In the case of
DD, that description is the code of the function DD, the code of
the function HHH, and everything that HHH calls down to the OS level. >>>>>

It does do that and this behavior does specify

Halting behavior when executed directly, which is what is to be
reported on as per the requirements:

It has always been incorrectly assumed that the input
finite string is a perfect proxy for the behavior
of the direct execution.

False.  The input finite string is REQUIRED to be a perfect proxy for
direct execution, as per the requirements:

A keep providing the required single counter-example
proving that this is incorrect and you stupidly ignore it.

No, you keep on trying to claim a false definition and to use a
strawman, proving that you are just an ignorant fraudster.

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

On 2025-03-21 13:55:52 +0000, olcott said:

On 3/21/2025 3:34 AM, Mikko wrote:

On 2025-03-21 04:12:27 +0000, olcott said:

On 3/20/2025 4:53 AM, Mikko wrote:

On 2025-03-19 22:14:27 +0000, olcott said:

On 3/19/2025 5:36 AM, joes wrote:

Am Tue, 18 Mar 2025 20:22:38 -0500 schrieb olcott:

On 3/18/2025 4:02 AM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:58 schreef olcott:

On 3/17/2025 2:50 PM, Fred. Zwarts wrote:

Op 17.mrt.2025 om 20:41 schreef olcott:

It is impossible for one TM X to determine that another TM Y has >>>>>>>>>>> only an infinite loop on the basis of the direct execution of Y. No >>>>>>>>>>> TM can in any way monitor the direct execution of another TM. >>>>>>>>>>>

No, of course it cannot monitor.

Then it cannot possibly compute the mapping from the directed executed
TM to its behavior and everyone saying this <is> the basis for the >>>>>>>>> halting problem is wrong.

Again, that looks like a strange way to say 'yes' to the following >>>>>>>> question:
Do we agree that the answer on the question: "Does an algorithm exist >>>>>>>> that for all possible inputs

Please pay very close attention. I have shown that Such an algorithm >>>>>>> does not exist for ANY inputs.

There is an "algorithm" that returns the halting status of at least >>>>>> one program: it always returns "halts" because there is at least one >>>>>> halting program.

Every TM that halts used to be called a decider.

Halts with every input. A TM that halts with some inputs but not all
is not a decider.

typedef void (*ptr)();
void Halts(ptr P);

// Doesn't actually decide jack shit
void Halts(ptr P)
{
   return;
}

That is not a TM and, unlike a TM, does not indicate whther it
halted accepting or rejecting.

The original definition only required halting for every input.

Wrong. It also requires that a "decider" is a Turing machine.

--
Mikko

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