Am Tue, 25 Mar 2025 15:50:33 -0500 schrieb olcott:

On 3/25/2025 3:05 PM, dbush wrote:

On 3/25/2025 3:47 PM, olcott wrote:

On 3/25/2025 2:32 PM, dbush wrote:

On 3/25/2025 3:24 PM, olcott wrote:

Cannot possibly derive any outputs not computed from their inputs.

Correct, algorithms can only compute computable mathematical
function.

A Turing machine halt decider

Does not exist because the required mapping is not computable:
Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

cannot possibly report on the behavior of any directly executing
process. No Turing machine can every do this. This has always been
beyond what any Turing machine can ever do.

Strawman: reporting on an executing process is not a requirement.

YOU JUST SAID THAT IT WAS YOU KEEP MINDLESSLY REPEATING THAT IT IS

I never said it had to actually watch an executing process, only report
what would happen if it did run.

*It has been conclusively proven as a verified*
*fact many hundreds of times over several years*
That the behavior that the finite string input specifies is not perfect
proxy for the behavior of the underlying directly executed machine.

A TM can be completely specified in a finite string.

--
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, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

Cannot possibly derive any outputs not computed from their inputs.

In particular, your HHH does not compute the behaviour of its input.

A Turing machine halt decider cannot possibly report on the behavior of
any directly executing process.
No Turing machine can every do this. This has always been beyond what
any Turing machine can ever do.
The best that any Turing machine halt decider can possibly do is
determine the behavior that an input finite string specifies.

Which iiis... surprise, whatever happens when you run it. You are
basically saying that simulators can make shit up.

When an input finite string specifies a pathological relationship with
its simulating halt decider the actual behavior that pathological relationship derives must be reported because THAT IS THE BEHAVIOR THAT
IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That doesn't
make that correct.

--
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/25/25 3:24 PM, olcott wrote:

Cannot possibly derive any outputs not computed from
their inputs.

Right, but the problem might require that.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.
No Turing machine can every do this. This has always
been beyond what any Turing machine can ever do.

Sure it can for many inputs, because it can simulate some to completion
and some to a repeat state, proving that they will not halt.

The problem is this doesn't

The best that any Turing machine halt decider can
possibly do is determine the behavior that an input
finite string specifies.

But that behavior is specified to be the behavior of the actual machine
it represents, or equivalently, the behavior of the UTM that interprets it.

Remember, a UTM, by its definition, exactly reproduces *ALL* the
behavior of the Turing Machine described by its input.

When we make these things 100% concrete in a language
that has been fully operational for many years...

Your problem is that those things HAVE been concrete for like 80 years,
you just don;t

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

Which is NOT a "Program" since it doesn't include the definitioin of HHH.

When an input finite string specifies a pathological
relationship with its simulating halt decider the actual
behavior that pathological relationship derives must
be reported because THAT IS THE BEHAVIOR THAT IS SPECIFIED
BY THIS INPUT FINITE STRING.

But the program doesn't HAVE a "it's decider", only a decider that it
was designed to cofound by being contrary, and does so by purely legal
methods.

Note, the behavior of YOUR finite string is "Categpry Error" as it isn't
a program.

Add the code for HHH to it, and its behavior is determied by UTM(DD)
which will be halting if HHH(DD) returns 0 or just aborts its execution,
and non-halting if HHH(DD) return 1 or loops forver.

THus, it is clear that there can be no correct answer from however you
had defined HHH (which must have been defined BEFORE we could create the
DD) but there *IS* a correct answer that other deciders could return,
they just need to answer the opposite of HHH(DD).

Sorry, you are just proving you don't understand what you are talking about.

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

On 3/25/25 5:42 PM, olcott wrote:

On 3/25/2025 4:02 PM, dbush wrote:

On 3/25/2025 4:50 PM, olcott wrote:

On 3/25/2025 3:05 PM, dbush wrote:

On 3/25/2025 3:47 PM, olcott wrote:

On 3/25/2025 2:32 PM, dbush wrote:

On 3/25/2025 3:24 PM, olcott wrote:

Cannot possibly derive any outputs not computed from
their inputs.

Correct, algorithms can only compute computable mathematical
function.

A Turing machine halt decider

Does not exist because the required mapping is not computable:


Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes
the following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

cannot possibly report
on the behavior of any directly executing process.
No Turing machine can every do this. This has always
been beyond what any Turing machine can ever do.

Strawman: reporting on an executing process is not a requirement.

YOU JUST SAID THAT IT WAS
YOU KEEP MINDLESSLY REPEATING THAT IT IS

On 3/25/2025 2:32 PM, dbush wrote:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>

I never said it had to actually watch an executing process, only
report what would happen if it did run.

*It has been conclusively proven as a verified*
*fact many hundreds of times over several years*
That the behavior that the finite string input specifies

Is

NOT ALWAYS

Yes, ALWAYS, for a Halt Decider.

the behavior of directly executing the described Turing machine.

WHEN THIS FINITE STRING DEFINES A PATHOLOGICAL
RELATIONSHIP WITH ITS SIMULATING TERMINATION ANALYZER.

And where are you getting this rule from?

It seems out your arse because it is just your POOP.

I can't help but believe that ALL of my reviewers are
flat out dishonest on this one point.

We aren't, it is YOU who is the dishonest one, but are too stupid to see
your stupid errors.

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

On 3/25/25 5:46 PM, olcott wrote:

On 3/25/2025 4:12 PM, joes wrote:

Am Tue, 25 Mar 2025 15:50:33 -0500 schrieb olcott:

On 3/25/2025 3:05 PM, dbush wrote:

On 3/25/2025 3:47 PM, olcott wrote:

On 3/25/2025 2:32 PM, dbush wrote:

On 3/25/2025 3:24 PM, olcott wrote:

Cannot possibly derive any outputs not computed from their inputs. >>>>>> Correct, algorithms can only compute computable mathematical

function.

A Turing machine halt decider

Does not exist because the required mapping is not computable:
Given any algorithm (i.e. a fixed immutable sequence of instructions) >>>>>> X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

cannot possibly report on the behavior of any directly executing >>>>>>> process. No Turing machine can every do this. This has always been >>>>>>> beyond what any Turing machine can ever do.

Strawman: reporting on an executing process is not a requirement.

YOU JUST SAID THAT IT WAS YOU KEEP MINDLESSLY REPEATING THAT IT IS

I never said it had to actually watch an executing process, only report >>>> what would happen if it did run.

*It has been conclusively proven as a verified*
*fact many hundreds of times over several years*
That the behavior that the finite string input specifies is not perfect
proxy for the behavior of the underlying directly executed machine.

A TM can be completely specified in a finite string.

That has different behavior when it is simulated by a UTM
that defines a pathological relationship to this UTM than
a UTM where no such pathological relationship exists.

Really, you mean a REAL UTM, not yor fake UTM?

How can an input have pathology to a UTM, since the only goal of a UTM
is to accurately recreate the behavior of the input, so an infinite
recursion loop is not "pathological" but the behavior of the machine.

Of course, when the machine being called isn't actually a UTM, but a
program trying to play one on TV and then getting an answer to a
question, it gets tripped up by believing that it actually was a UTM
when it wasn't.

Of course your problem is you don't understand what a UTM actually is,
think a partial emulator can be a UTM, when it isn't.

You are just proving your utter stupidity and ignorance.

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

On 3/25/25 3:47 PM, olcott wrote:

On 3/25/2025 2:32 PM, dbush wrote:

On 3/25/2025 3:24 PM, olcott wrote:

Cannot possibly derive any outputs not computed from
their inputs.

Correct, algorithms can only compute computable mathematical function.

A Turing machine halt decider

Does not exist because the required mapping is not computable:


Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the
following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

cannot possibly report
on the behavior of any directly executing process.
No Turing machine can every do this. This has always
been beyond what any Turing machine can ever do.

Strawman: reporting on an executing process is not a requirement.

YOU JUST SAID THAT IT WAS
YOU KEEP MINDLESSLY REPEATING THAT IT IS

Right, we don't neefd to see the executing process, and it never needs
to be executed to have the behavior, the mapping just is what it is.

Something you seem to stupid to understand.

On 3/25/2025 2:32 PM, dbush wrote:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly

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

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

--
Mikko

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

Op 25.mrt.2025 om 20:24 schreef olcott:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.
No Turing machine can every do this. This has always
been beyond what any Turing machine can ever do.

So if we ask the question:
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed?'
We agree that the answer is 'no'.
Correct?

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

Am Tue, 25 Mar 2025 16:42:09 -0500 schrieb olcott:

On 3/25/2025 4:02 PM, dbush wrote:

On 3/25/2025 4:50 PM, olcott wrote:

On 3/25/2025 3:05 PM, dbush wrote:

On 3/25/2025 3:47 PM, olcott wrote:

On 3/25/2025 2:32 PM, dbush wrote:

On 3/25/2025 3:24 PM, olcott wrote:

cannot possibly report on the behavior of any directly executing >>>>>>> process. No Turing machine can every do this. This has always been >>>>>>> beyond what any Turing machine can ever do.

Strawman: reporting on an executing process is not a requirement.

YOU JUST SAID THAT IT WAS YOU KEEP MINDLESSLY REPEATING THAT IT IS
On 3/25/2025 2:32 PM, dbush wrote:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed
directly

I never said it had to actually watch an executing process, only
report what would happen if it did run.

*It has been conclusively proven as a verified*
*fact many hundreds of times over several years*
That the behavior that the finite string input specifies

Is

NOT ALWAYS

Should be.

the behavior of directly executing the described Turing machine.

Then the simulator is broken.

--
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/26/25 12:25 PM, olcott wrote:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

No it doesn't. Where do you get that from, since the DEFINITION of the
behavior is that of the direct execution of the program it represents.

Simulating termination analyzers only report on the
behavior that their input specifies.

WHich *IS* the behavior of the direct execution of the program the input specified.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

No, it doesn't

Source for your claim?

Or are you just going to by defautl admit your source is your own
fraudulent ideas.

Simulating termination analyzers only report on the
behavior that their input specifies.

Which is DEFINED to be the behavior of the program the input represents.

PERIOD.

HOW MANY TIMES DO I HAVE TO REPEAT THIS BEFORE
YOU NOTICE THAT I SAID IT AT LEAST ONCE?

Your problem is that you statements are just lies, which people ignore
and point you to the correct meaning of the words.

Of course, it seems you are just too stupid to see that because you have brainwashed yourself into believing your lies over the defined truth.

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

On 2025-03-26 16:25:49 +0000, olcott said:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

Irrelevant to the fact that it is Turing computable whether the direct exectuion of a Turing machine is longer that two steps.

--
Mikko

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

Op 26.mrt.2025 om 17:25 schreef olcott:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

If an analyser has a pathological relation with this input, it is wrong
to choose this analyser for this input. In particular when there are
analysers that do not have this relationship with this input.

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

Op 27.mrt.2025 om 18:41 schreef olcott:

On 3/27/2025 5:33 AM, Fred. Zwarts wrote:

Op 26.mrt.2025 om 17:25 schreef olcott:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

If an analyser has a pathological relation with this input, it is
wrong to choose this analyser for this input. In particular when there
are analysers that do not have this relationship with this input.

It is the input that specifies the pathological relationship.
This means that you are saying that the analyzer should reject
this input.

Yes, reject because it cannot analyse correctly.
It is not very interesting to know whether an analyser reports that it
is unable to analyse the problem correctly.
It is interesting to know:
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed?'
This question seems undecidable for Olcott.

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

On 3/27/25 1:41 PM, olcott wrote:

On 3/27/2025 5:33 AM, Fred. Zwarts wrote:

Op 26.mrt.2025 om 17:25 schreef olcott:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

If an analyser has a pathological relation with this input, it is
wrong to choose this analyser for this input. In particular when there
are analysers that do not have this relationship with this input.

It is the input that specifies the pathological relationship.
This means that you are saying that the analyzer should reject
this input.

No, he means that if the analyser can't correctly determine the behavior
of the input, which is an OBJECTIVE property (and thus not dependent on
the decider it is given to) then the fact that it assumes it knows what
the input does means it is wrong.

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

On 3/27/25 7:37 PM, olcott wrote:

On 3/27/2025 2:52 PM, Fred. Zwarts wrote:

Op 27.mrt.2025 om 18:41 schreef olcott:

On 3/27/2025 5:33 AM, Fred. Zwarts wrote:

Op 26.mrt.2025 om 17:25 schreef olcott:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine >>>>>> is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

If an analyser has a pathological relation with this input, it is
wrong to choose this analyser for this input. In particular when
there are analysers that do not have this relationship with this input. >>>

It is the input that specifies the pathological relationship.
This means that you are saying that the analyzer should reject
this input.

Yes, reject because it cannot analyse correctly.

Oh so you disagree with the semantics of the x86 language?

No, it is YOU who does, as you think the x86 language somewhere has a definition that the call to some address starts an x86 level emulator.

It has no such thing, a call instruction only transfers execution to the subroutine called.

Even at a meta-logic level of emulation, a call to an emulator only
become equivalent to calling the program emulated if the emulator is
actually a COMPLETE and correct emulator, no aborting allowed.

Sorry, you are just proving that all your logic is based on FRAUD and lies.

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

On 2025-03-27 17:44:11 +0000, olcott said:

On 3/27/2025 5:12 AM, Mikko wrote:

On 2025-03-26 16:25:49 +0000, olcott said:

On 3/26/2025 2:44 AM, Mikko wrote:

On 2025-03-25 19:24:07 +0000, olcott said:

Cannot possibly derive any outputs not computed from
their inputs.

A Turing machine halt decider cannot possibly report
on the behavior of any directly executing process.

It can if that report is a computable function of their inputs.
For example, whether the direct execution of another Turing machine
is longer than 2 steps is Turing computable.

When an input to a simulating termination analyzer
defines a pathological relationship to its simulating
termination analyzer this changes the behavior of this
input relative to its direct execution.

Irrelevant to the fact that it is Turing computable whether the direct
exectuion of a Turing machine is longer that two steps.

That would be a syntactic rather than semantic property
of the input thus off topic for these posts.

The subject line says that the topic is Turing computable functions.
What I wrote is about Turing computable functions and is a relevant
comment to the posting it was a reply to. Therefore it was on-topic.

--
Mikko

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