On 4/25/25 11:28 PM, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only
allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings from
a domain to a codomain, neither of which are required to be strings.
Functions don't involve finite string operations at all.

All Turing Machine based computation applies the
finite string transformations specified by the TM
language to the input finite string.

But you are missing that not all Functions are Turing Machine
Compuations, and don't need to be mappings of "Finite Strings" to
"Finite Strings". And we often ask Turing Machines to try to compute the mapping of such a function, with the added concept of a representation.

For instance, math "functions" are not based on Finite Strings, because
Numbers themselves are not a Finite String, but can be represented by them.

What distinguishes a computable function from other functions is that
it is possible to implement an algorithm which computes that function.
That algorithm might involve string operations, but the algorithm is
not the function anymore than the function is the algorithm.

The halting *function* is a mapping from the set of computations (not
strings) to the set of boolean values (also not strings). A given
computation maps to true if and only if it is finite.

Ultimately every semantic meaning that can be expressed in
language can be encoded as some type of relation between
finite strings.

From a set of basic facts all knowledge that can be expressed
in language can be derived. It is derived through semantic
logical entailment as the ONLY rule of inference.

Illrelevent to the point in question, and a claim you need to prove. IT
would seem that trying to limit your logical operator when to just
semantic logical entailment, when the field you are trying to represent
uses more operators

A halt *decider* (were such a thing possible) would be an algorithm
which computes the halting function. Such an algorithm (assuming we're
talking in terms of Turing Machines) would have to encode the elements
of the halting function's domain as strings, but the mapping it computes

would still be from the computations which those strings represent to
their associated boolean values.

André

It is an easily verified fact that when HHH applies
the finite string transformations specified by the
x86 language to its input DD that for each HHH/DD
pair no emulated DD can possibly reach its final
halt state.

But the fact that HHH's transformation doesn't reach the end doesn't
mean that the correct and complete set of transformations defined by
processor won't get there.

 _DD()
[00002133] 55         push ebp      ; housekeeping
[00002134] 8bec       mov ebp,esp   ; housekeeping
[00002136] 51         push ecx      ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404     add esp,+04
[00002144] 8945fc     mov [ebp-04],eax
[00002147] 837dfc00   cmp dword [ebp-04],+00
[0000214b] 7402       jz 0000214f
[0000214d] ebfe       jmp 0000214d
[0000214f] 8b45fc     mov eax,[ebp-04]
[00002152] 8be5       mov esp,ebp
[00002154] 5d         pop ebp
[00002155] c3         ret
Size in bytes:(0035) [00002155]

And the above is not a "program" as it uses and undefined term, HHH, so
it doesn't have behavior.

When you add your Halt7 as you stipulate, then you claim about "No
HHH/DD pair" is somewhat meaningless, as there is only one possible
HHH/DD pair, as HHH has be fully defined by your stipulations,

IF you try to make Halt7 now a variable, included implicitly as part of
the input, the each pair becomes a totally new input, and all you have
done is proven that all your possible machines fail to get to the end of
their particular input, but we can still corrcctly and complete emulate
every input from an HHH/DD pair that returns the answer 0 to see that
its DD does halt, and thus it was just wrong.

All you are doing is proving that you have fundamental misunderstandings
of the topics you are talking about, and are too stupid and ignorant to
see those errors.

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

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only
allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings from
a domain to a codomain, neither of which are required to be strings.
Functions don't involve finite string operations at all.

All Turing Machine based computation applies the
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing. You
keep conflating the two. The point of my post was to try to get you to
be more careful with your terminology.

André

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

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

On 2025-04-26 15:28, olcott wrote:

On 4/26/2025 4:03 PM, André G. Isaak wrote:

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only
allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings
from a domain to a codomain, neither of which are required to be
strings. Functions don't involve finite string operations at all.

All Turing Machine based computation applies the/
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing. You
keep conflating the two. The point of my post was to try to get you to
be more careful with your terminology.

André

Yes so I must correct my words to say

All Turing Machine based *Computable Functions* apply the

finite string transformations specified by the TM
language to the input finite string.

Which is just as mangled as your earlier usage. Maybe learn what these
things mean...

André

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

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

On 4/26/25 5:28 PM, olcott wrote:

On 4/26/2025 4:03 PM, André G. Isaak wrote:

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only
allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings
from a domain to a codomain, neither of which are required to be
strings. Functions don't involve finite string operations at all.

All Turing Machine based computation applies the/
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing. You
keep conflating the two. The point of my post was to try to get you to
be more careful with your terminology.

André

Yes so I must correct my words to say

All Turing Machine based *Computable Functions* apply the

finite string transformations specified by the TM
language to the input finite string.

No such thing.

"Computable Functions" are the mathematical concept of the abstract
mapping of an input to an output. They do not include the method to
produce that mapping, the mapping is just defined, and thus hot "Turing
Machine bases".

The point is that being "Computable", means there exist a Turing Machine (actualy typically a countable infinity of them) that compute that mapping.

This is your problem, you have a fundamental misunderstanding of what a "Function" or a "Computable Function" actually is, which is sort of
related to your inability to understand the difference between Truth and Knowledge, or what is a property of the input.

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

Op 27.apr.2025 om 00:33 schreef olcott:

On 4/26/2025 5:18 PM, André G. Isaak wrote:

On 2025-04-26 15:28, olcott wrote:

On 4/26/2025 4:03 PM, André G. Isaak wrote:

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only
allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings
from a domain to a codomain, neither of which are required to be
strings. Functions don't involve finite string operations at all.

All Turing Machine based computation applies the/
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing. You
keep conflating the two. The point of my post was to try to get you
to be more careful with your terminology.

André

Yes so I must correct my words to say

All Turing Machine based *Computable Functions* apply the

finite string transformations specified by the TM
language to the input finite string.

Which is just as mangled as your earlier usage. Maybe learn what these
things mean...

André

When HHH emulates DD once and then emulates itself
emulating DD according to the finite string transformation
rules specified by the x86 language then HHH

should also analyse Halt7.c and conclude that there is a conditional
abort, which makes the recursion finite and thus there is no need to
abort the simulation. But HHH fails to do this correct analysis and
prematurely aborts the simulation.

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

On 4/27/25 2:50 PM, olcott wrote:

On 4/27/2025 1:27 AM, Fred. Zwarts wrote:

Op 27.apr.2025 om 00:33 schreef olcott:

On 4/26/2025 5:18 PM, André G. Isaak wrote:

On 2025-04-26 15:28, olcott wrote:

On 4/26/2025 4:03 PM, André G. Isaak wrote:

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only >>>>>>>>> allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings >>>>>>>> from a domain to a codomain, neither of which are required to be >>>>>>>> strings. Functions don't involve finite string operations at all. >>>>>>>>

All Turing Machine based computation applies the/
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing.
You keep conflating the two. The point of my post was to try to
get you to be more careful with your terminology.

André

Yes so I must correct my words to say

All Turing Machine based *Computable Functions* apply the

finite string transformations specified by the TM
language to the input finite string.

Which is just as mangled as your earlier usage. Maybe learn what
these things mean...

André

When HHH emulates DD once and then emulates itself
emulating DD according to the finite string transformation
rules specified by the x86 language then HHH

should also analyse Halt7.c and conclude that there is a conditional
abort, which makes the recursion finite and thus there is no need to
abort the simulation. But HHH fails to do this correct analysis and
prematurely aborts the simulation.

Now it is clear that correct simulation requires that HHH(DD)
apply the finite string transformations specified by the x96
language to its input the nonsense about directed execution
is finally unequivocally refuted. The first part of the following
is proven to be correct.

Which means that it isn't allowed to stop it emuation.

What in the direct execution broke the rules?

The second part is self-evidently correct to several
C programmers, thus HHH is correct to reject DD as non-halting.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D

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

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

But since D calls the H that does abort and return 0, H can't prove that
the correct simulation of this input won't halt, since it does.

You are just proving your igorance of the topic, and that you are just a pathological liar that doesn't care about what is true as you just don't
care about what is actually true.

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

Op 27.apr.2025 om 20:50 schreef olcott:

On 4/27/2025 1:27 AM, Fred. Zwarts wrote:

Op 27.apr.2025 om 00:33 schreef olcott:

On 4/26/2025 5:18 PM, André G. Isaak wrote:

On 2025-04-26 15:28, olcott wrote:

On 4/26/2025 4:03 PM, André G. Isaak wrote:

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only >>>>>>>>> allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are mappings >>>>>>>> from a domain to a codomain, neither of which are required to be >>>>>>>> strings. Functions don't involve finite string operations at all. >>>>>>>>

All Turing Machine based computation applies the/
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing.
You keep conflating the two. The point of my post was to try to
get you to be more careful with your terminology.

André

Yes so I must correct my words to say

All Turing Machine based *Computable Functions* apply the

finite string transformations specified by the TM
language to the input finite string.

Which is just as mangled as your earlier usage. Maybe learn what
these things mean...

André

When HHH emulates DD once and then emulates itself
emulating DD according to the finite string transformation
rules specified by the x86 language then HHH

should also analyse Halt7.c and conclude that there is a conditional
abort, which makes the recursion finite and thus there is no need to
abort the simulation. But HHH fails to do this correct analysis and
prematurely aborts the simulation.

Now it is clear that correct simulation requires that HHH(DD)
apply the finite string transformations specified by the x96
language to its input the nonsense about directed execution
is finally unequivocally refuted. The first part of the following
is proven to be correct.

The second part is self-evidently correct to several
C programmers, thus HHH is correct to reject DD as non-halting.

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
    If simulating halt decider H correctly simulates its input D

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

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

No new information, no rebuttal. So it still stands: HHH fails to do
this correct analysis and prematurely aborts the simulation.

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

On 4/28/25 12:42 AM, olcott wrote:

On 4/27/2025 2:01 PM, dbush wrote:

On 4/27/2025 2:50 PM, olcott wrote:

On 4/27/2025 1:27 AM, Fred. Zwarts wrote:

Op 27.apr.2025 om 00:33 schreef olcott:

On 4/26/2025 5:18 PM, André G. Isaak wrote:

On 2025-04-26 15:28, olcott wrote:

On 4/26/2025 4:03 PM, André G. Isaak wrote:

On 2025-04-25 21:28, olcott wrote:

On 4/25/2025 5:28 PM, André G. Isaak wrote:

On 2025-04-25 10:31, olcott wrote:

Once we understand that Turing computable functions are only >>>>>>>>>>> allowed to derived their outputs by applying finite string >>>>>>>>>>> operations to their inputs then my claim about the behavior >>>>>>>>>>> of DD that HHH must report on is completely proven.

You're very confused here.

Computable functions are *functions*. That is, they are
mappings from a domain to a codomain, neither of which are >>>>>>>>>> required to be strings. Functions don't involve finite string >>>>>>>>>> operations at all.

All Turing Machine based computation applies the/
finite string transformations specified by the TM
language to the input finite string.

Turing machines and computable functions are not the same thing. >>>>>>>> You keep conflating the two. The point of my post was to try to >>>>>>>> get you to be more careful with your terminology.

André

Yes so I must correct my words to say

All Turing Machine based *Computable Functions* apply the

finite string transformations specified by the TM
language to the input finite string.

Which is just as mangled as your earlier usage. Maybe learn what
these things mean...

André

When HHH emulates DD once and then emulates itself
emulating DD according to the finite string transformation
rules specified by the x86 language then HHH

should also analyse Halt7.c and conclude that there is a conditional
abort, which makes the recursion finite and thus there is no need to
abort the simulation. But HHH fails to do this correct analysis and
prematurely aborts the simulation.

Now it is clear that correct simulation requires that HHH(DD)
apply the finite string transformations specified by the x96
language to its input the nonsense about directed execution

Shows that no H exists that satisfies these requirements, as proven by
Linz and others:


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

<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its input D

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

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

And *yet again* you lie by implying that Sipser agrees with you when
it has been repeatedly proven that he does not:

He must agree with me about correct simulation
as I have recently repeatedly proven.

No, he doesn't. You THINK you have proven it, but all that shows is that
you don't understand the basics of logic.

When DD is emulated by HHH once and then HHH emulates
itself emulating DD, then HHH has complete proof that
and infinite numbers of steps of DD emulated by HHH
could not cause DD to reaches its own final halt state.

No it doesn't.

IT seeems you think truth can be establish by false logic, and thus your
whole concept of "correct reasoning" is just a lie.

What "Known Facts" and "Truth Preserving" operations did you use to get
your proof?

Part of your problem is you don't understand that an essential part of
the definition of the x86 language is that the next instruction is alway executed until you reach the end of a program, and program don't just
stop running at a non-terminal instruction.

Or, does you computer just randomly halt and lock up all the time, and
you consider this just the defined behavior of it?

On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

I exchanged emails with him about this. He does not agree with

anything

substantive that PO has written. I won't quote him, as I don't have
permission, but he was, let's say... forthright, in his reply to me.
;

Your dishonesty knows no bounds.

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