Re: Experts would agree that my reviewers are incorrect

[Mr Flibble]

On Tue, 24 May 2022 09:40:02 -0500
olcott <No...@NoWhere.com> wrote:

> All of the recent discussions are simply disagreement with an easily
> verifiable fact. Any smart software engineer with a sufficient
> technical background can easily confirm that H(P,P)==0 is correct:
>
> Where H is a C function that correctly emulates its input pair of
> finite strings of the x86 machine code of function P and criterion
> for returning 0 is that the simulated P would never reach its "ret"
> instruction.

The only reason P "never" reaches its "ret" instruction is because you
have introduced an infinite recursion that does not exist in the proofs
you are trying to refute, i.e. your H is erroneous.

/Flibble

[olcott]

For the time being I am only referring to when the C function named H
determines whether ore not its correct x86 emulation of the machine
language of P would ever reach the "ret" instruction of P in 0 to
infinity number of steps of correct x86 emulation.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]


--
Copyright 2022 Pete Olcott

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

[Mr Flibble]

On Tue, 24 May 2022 16:12:13 -0500
olcott <No...@NoWhere.com> wrote:

> On 5/24/2022 3:54 PM, Mr Flibble wrote:
> > On Tue, 24 May 2022 09:40:02 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
> >> All of the recent discussions are simply disagreement with an
> >> easily verifiable fact. Any smart software engineer with a
> >> sufficient technical background can easily confirm that H(P,P)==0
> >> is correct:
> >>
> >> Where H is a C function that correctly emulates its input pair of
> >> finite strings of the x86 machine code of function P and criterion
> >> for returning 0 is that the simulated P would never reach its "ret"
> >> instruction.
> >
> > The only reason P "never" reaches its "ret" instruction is because
> > you have introduced an infinite recursion that does not exist in
> > the proofs you are trying to refute, i.e. your H is erroneous.
> >
> > /Flibble
> >
>
> For the time being I am only referring to when the C function named H
> determines whether ore not its correct x86 emulation of the machine
> language of P would ever reach the "ret" instruction of P in 0 to
> infinity number of steps of correct x86 emulation.

You can't have it both ways: either H is supposed to be a decider or it
isn't; if it is a decider then it fails at that as you have introduced
an infinite recursion; if it isn't a decider and is merely a tool for
refuting the proofs then it fails at that too as the proofs you are
trying to refute do not contain an infinite recursion.

/Flibble

[olcott]

You have to actually stick with the words that I actually said as the
basis of any rebuttal.

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

When you evaluate what I said according to those exact words instead of
rephrasing them as the deception of the strawman error then they are
proved to be correct.

[Mr Flibble]

On Tue, 24 May 2022 16:34:12 -0500

You are now merely trying to obfuscate what H is; I wonder why you
do that? Is it because you realize you are wrong as far as the Halting
Problem and its proofs are concerned?

/Flibble

[olcott]

In software engineering terms:
H(P,P) correctly determines that its input never reaches its "ret"
instruction.

I can translate this to computer science terms yet will not do that
until after the software engineering has been accepted.

[Mr Flibble]

On Tue, 24 May 2022 16:51:50 -0500

As far as I can tell you have only shown that that is the case for the
limited scenario that involves you introducing a specious infinite
recursion, an infinite recursion not present in the proofs you are
attempting to refute.

>
> I can translate this to computer science terms yet will not do that
> until after the software engineering has been accepted.

Weasel words.

/Flibble

[olcott]

The concept of a halt decider that determines the halt status of its
input on the basis of watching the behavior of this input while it
simulates this input is novel yet not specious.

H(P,P) correctly determines that its input never reaches its "ret"

instruction. This is a verified fact that several God damned liars deny.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]


>>

>> I can translate this to computer science terms yet will not do that
>> until after the software engineering has been accepted.
>
> Weasel words.
>
> /Flibble
>

[Mr Flibble]

On Tue, 24 May 2022 17:04:15 -0500

Novel? I sincerely doubt that the idea of using a simulator to
attempt to solve the halting problem was your idea. The simulation
approach was always doomed to failure; you think differently due to
your misunderstanding of the proofs you are attempting to refute.

/Flibble

[olcott]

Linz disregards the simulation ONLY approach on the basis that some
inputs never stop running. It never occurs to Linz to simulate the input
and compare the behavior of this input to known infinite behavior
patterns. To the best of my knowledge this is my brand new idea.

My work on this has been published for a year:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

[Mr Flibble]

On Tue, 24 May 2022 17:25:40 -0500

The only pattern you have shown to detect is the erroneous infinite
recursion that you have yourself introduced; there are actually O(2^n)
patterns (n = machine "memory" size) and you have not shown that you
have a general solution for detecting every such pattern.

/Flibble

[olcott]

It is not erroneous infinite recursion it is the actual nested
simulation that does occur when one uses a simulating halt decider.

> there are actually O(2^n)
> patterns (n = machine "memory" size) and you have not shown that you
> have a general solution for detecting every such pattern.
>
> /Flibble
>

[Richard Damon]

On 5/24/22 10:40 AM, olcott wrote:
> All of the recent discussions are simply disagreement with an easily
> verifiable fact. Any smart software engineer with a sufficient technical
> background can easily confirm that H(P,P)==0 is correct:

This is an incorrect statement, showable by the fact that NO "Smart
Software Engineers" have agreed with you, thus you prove your claim to
be a lie.

It has been shown that it is easy to verify that H(P,P) is NOT correct,
when you actually use the DEFINITIONS that apply, which you fail to do.

>
> Where H is a C function that correctly emulates its input pair of finite
> strings of the x86 machine code of function P and criterion for
> returning 0 is that the simulated P would never reach its "ret"
> instruction.

No, H does NOT correctly emulate its input, as it aborts it before it
reaches its end, so you claim is just a lie, showing that you don't know
what you are talking about.

The fact that YOU have previously posted a CORRECT trace of the input to
H(P,P) showing that it halts, is proof that you are wrong.

>
> (1) Good software engineering proves that H(P,P)==0 is correct.

WHAT "Good software engineering?" Faulty traces?

>
> The only other remaining objection is whether or not a halt decider must
> compute the mapping of its input finite strings to an accept or reject
> state on the basis of the actual behavior actually specified by its
> input OR SOME OTHER MEASURE.

Since the DEFINITION of the behavior of the input to H(P,P), is the
behaior of P(P), which can be verified with UTM(P,P) (and actual correct
emulatior with the same input) shows you are wrong.

>
> A decider must compute the mapping from its inputs finite strings to an
> accept of reject state. A computable function must compute the mapping
> of from inputs finite strings to its corresponding output.
> https://en.wikipedia.org/wiki/Computable_function

Right, and to be a "Something" decider, that mapping must be the
"Something" function, and the Halting FUnction is based the behavior of
a machine applied to an input. The attempted Halt Decider being given a
representation of these to decide on.

>
> (2) Good computer science shows that a halt decider must
> compute the mapping from its input finite strings to an accept or
> reject state on the basis of the actual behavior actually specified by
> its input. Since P(P) is not an input to H(P,P) it is excluded.
>
>

Except that the representation of it IS the input, and the fact that
UTM(P,P) can get the desired behavior show that it can be the behavior
of that input. The problem is that H can do it in finite time, and so
fails to be a decider.

>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

A bunch of lies and faulty logic.

[Richard Damon]

And you P is incomplete, as you haven't include its copy of H.

A proper simulation of this input is an abort at the call 000011a2 for
going to an undefined memory location.

Remember, Computations aren't allowed to depend on ANYTHING other than
their defined input. Thus P gets ONE parameter, the machine it is to
work on.

In YOUR case, you seem to have a second parameter, the function "H" at
address 000011a2, so your P isn't the P of Linz, etc.

You have shown a basic inability to follow the requrements.

[Richard Damon]

Since you have posted a trace which shows this happening, you know this
is a lie.

Yes, H can't simulate to there, but a CORRECT simulator can.

>
> When you evaluate what I said according to those exact words instead of
> rephrasing them as the deception of the strawman error then they are
> proved to be correct.
>
>

Nope, you are proved to be a liar.

[Richard Damon]

No, it doesn't, because it doesn't use sound logic. It assumes the H
that P calls will never abort, when it will (since this one does)

Olcott is thus proven to be a Liar or an idiot.

[olcott]

People that are sufficiently technically competent would be able to
understand:

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

This absolutely includes Dennis he is rated in the top 0.04% on Stack
Exchange.

[olcott]

H makes no mistakes in its simulation. Every instruction that H
simulates is exactly what the x86 source-code for P specifies.

The only possible way for a simulator to actually be incorrect is that
its simulation diverges from what the x86 source-code of P specifies.

That Simulate(P,P) does not have the same halting behavior as the
correct simulation of the input to H(P,P) does not mean that either one
of them is incorrect.

In both cases both simulations are correct because they each simulate
exactly what the x86 source-code of P specifies.

>>
>> When you evaluate what I said according to those exact words instead
>> of rephrasing them as the deception of the strawman error then they
>> are proved to be correct.
>>
>>
>
> Nope, you are proved to be a liar.

[Richard Damon]

Yes, but it doesn't complete the simulation because it INCORRECTLY
decides that the input would be non-halting.

Because of the design of P, this is true for ANY Halt Decider that trys
to decide on the version of P built on it. (Other Halt Deciders can
possibly get it correct).

THe problem is that there is NO rule that H can use to correctly decide
on this input (the P built on this H, being applied to a description of
itself).

>
> The only possible way for a simulator to actually be incorrect is that
> its simulation diverges from what the x86 source-code of P specifies.

Nope, it needs to diverge from the behavior of the PROGRAM given to it,
and the subroutine P is not a "Program".

Either the decider needs to reject P as not a program because it doens't
include a copy of the function H that is calls, or it needs to consider
that function H as part of its input.

If we include that H as part of its input, then that H must have a
SPECIFIC algorithm, and a CORRECT simulation of that input, INCLUDING
THAT H, will ALWAYS Halt if H(P,P) returns 0.

>
> That Simulate(P,P) does not have the same halting behavior as the
> correct simulation of the input to H(P,P) does not mean that either one
> of them is incorrect.

WRONG. It is the EXACT SAME INPUT, so as far as program simuation, they
need to generate the exact same results.

The problem is H doesn't consider its own code correctly, and thus is
INCORRECT.

>
> In both cases both simulations are correct because they each simulate
> exactly what the x86 source-code of P specifies.

the source code of P & H (or it needs to say the P isn't a program)

You just don't seem to understand what a PROGRAM is, it seems.

Are you sure your a programmer?

[Richard Damon]

But it does:

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9...@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

[olcott]

On 5/25/2022 8:14 AM, Ben wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> There then seems to be confusion between "nested simulation" and
>> "recursion" which isn't confined to PO. It's not clear exactly what is
>> going on because we don't have the source of H and questions about how
>> H distinguishes its own output from the output of the program it is
>> simulating haven't been answered.
>
> What is your take on why PO is hiding H? Even the instructions of H are
> never shown in a trace. I ask because you are invariably generous in
> your replies and I wonder what the generous interpretation of hiding
> the one thing, H itself, that would answer all question immediately is.
>

As I have said many hundreds of times you can verify that I am correct
on the basis of what I provided.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

In fact you actually only need much less than I provided to prove that I
am correct. The following can be correctly determined entirely on the
basis of the above x86 source-code for P.

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

If you don't understand this then you won't understand something that is
1000-fold more complicated.

If I show you something that is 1000-fold more complicated now you will
have hundreds of other totally extraneous distractions that prevent you
from paying attention to my simple proof. You will confuse your own lack
of understanding of this complexity as dozens of more errors that must
be investigated before we can go back to the simple proof.

Because this simplest proof so obviously proves my point it seems
unreasonable for me to believe that others do not fully understand it.
Thus when they disagree with it I can't believe that they don't know
they are lying.

[olcott]

On 5/25/2022 6:01 AM, Richard Damon wrote:
> On 5/24/22 11:00 PM, olcott wrote:
>> On 5/24/2022 9:54 PM, Richard Damon wrote:
>>> On 5/24/22 10:50 PM, olcott wrote:
>>>> On 5/24/2022 9:39 PM, Dennis Bush wrote:
>>>>> On Tuesday, May 24, 2022 at 10:34:43 PM UTC-4, olcott wrote:
>>>>>> On 5/24/2022 9:30 PM, Dennis Bush wrote:
>>>>>>> On Tuesday, May 24, 2022 at 10:28:14 PM UTC-4, olcott wrote:
>>>>>>>> On 5/24/2022 9:20 PM, Dennis Bush wrote:
>>>>>>>>> On Tuesday, May 24, 2022 at 10:16:10 PM UTC-4, olcott wrote:
>>>>>>>>>> On 5/24/2022 9:08 PM, Dennis Bush wrote:
>>>>>>>>>>> On Tuesday, May 24, 2022 at 10:03:59 PM UTC-4, olcott wrote:
>>>>>>>>>>>> On 5/24/2022 8:56 PM, Dennis Bush wrote:

>>>>>>>>>>>>> Ha3(N,5) makes no mistakes in its simulation. Every
>>>>>>>>>>>>> instruction that Ha3 simulates is exactly what the x86
>>>>>>>>>>>>> source code for N specifies. Therefore, according to you,
>>>>>>>>>>>>> Ha3(N,5)==0 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Oh, you disagree? Then the fact that Ha makes no mistakes
>>>>>>>>>>>>> in its simulation doesn't mean that it's correct.

>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only possible way for a simulator to actually be
>>>>>>>>>>>>>> incorrect is that
>>>>>>>>>>>>>> its simulation diverges from what the x86 source-code of P
>>>>>>>>>>>>>> specifies.
>>>>>>>>>>>>>

>>>>>>>>>>>>> Or it aborts a halting computation, incorrectly thinking
>>>>>>>>>>>>> that it is a non-halting computation. Which is exactly what
>>>>>>>>>>>>> happens with Ha(Pa,Pa).

>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That Simulate(P,P) does not have the same halting behavior
>>>>>>>>>>>>>> as the
>>>>>>>>>>>>>> correct simulation of the input to H(P,P) does not mean
>>>>>>>>>>>>>> that either one
>>>>>>>>>>>>>> of them is incorrect.
>>>>>>>>>>>>>

>>>>>>>>>>>>> Ha(Pa,Pa), by the definition of the halting problem, does
>>>>>>>>>>>>> not perform a correct simulation of its input.

>>>>>>>>>>>> It is an easily verified fact that the correct x86 emulation
>>>>>>>>>>>> of the
>>>>>>>>>>>> input to H(P,P) would never reach the "ret" instruction of P
>>>>>>>>>>>

>>>>>>>>>>> It is an easily verified fact that Ha(Pa,Pa)==0 is not
>>>>>>>>>>> correct because it aborts too soon as demonstrated by
>>>>>>>>>>> Hb(Pa,Pa)==1
>>>>>>>>>> By this same despicable liar reasoning we can know that Fluffy
>>>>>>>>>> is not
>>>>>>>>>> a white cat entirely on the basis that Rover is a black dog.
>>>>>>>>>>
>>>>>>>>>> It is the actual behavior that the x86 source-code of P
>>>>>>>>>> specifies to
>>>>>>>>>> H(P,P) and H1(P,P)
>>>>>>>>>> that determines whether or not its simulation by H
>>>>>>>>>> and H1 is correct.
>>>>>>>>>
>>>>>>>>> Then by this same logic you agree that
>>>>>>>> You continue to be a liar.
>>>>>>>
>>>>>>> So no rebuttal, which means you're unable to. Which means you
>>>>>>> admit I'm right.
>>>>>>>
>>>>>>> So what are you going to do with yourself now that you're no
>>>>>>> longer working on the halting problem?
>>>>>> Escalate the review to a higher caliber reviewer.
>>>>>>
>>>>>> Now that I have all of the objections boiled down to simply
>>>>>> disagreeing
>>>>>> with two verifiable facts higher caliber reviewers should confirm
>>>>>> that I
>>>>>> am correct.
>>>>>
>>>>> The verifiable fact that everyone (except you) can see is that
>>>>> Hb(Pa,Pa)==1 proves that Ha(Pa,Pa)==0 is wrong,
>>>>
>>>> Shows that they are not basing their decision on the execution trace
>>>> that is actually specified by the x86 source-code of P.
>>>>
>>>> There is no Ha(Pa,Pa) or Hb(Pa,Pa) these are actually named H(P,P)
>>>> and H1(P,P). You can't even manage to tell the truth about the names
>>>> of functions.
>>>>
>>>
>>> The names really make that much difference?
>> H(P,P) and H1(P,P) are fully operational C functions that can be
>> executed showing every detail of their correct simulation of their
>> inputs.
>>
>> Ha(Pa,Pa) and Hb(Pa,Pa) are vague ideas that cannot possibly be pinned
>> down to specifics. The only place that Dennis can hide his deception
>> is in deliberate vagnueness.
>>
>
> So, you don't understand what peeople are saying. For you it is just
> that you are right and others are wrong.

Ha(Pa,Pa) is fully operational code named H(P,P)
Hb(Pa,Pa) is fully operational code named H1(P,P)

I can prove that the actual behavior of the correct x86 emulation of
actual input to H(P,P) never reaches its "ret" instruction with a full
execution trace of P.

I can prove that the actual behavior of the correct x86 emulation of
actual input to H1(P,P) reaches its "ret" instruction with a full
execution trace of P.

I can prove that both of these execution traces are correct on the basis
of the behavior that is specified by the x86 source-code for P.

We can't do any of these things with the purely imaginary Ha(Pa,Pa) and
Hb(Pa,Pa). Dennis wants to keep things vague so that his deceptive and
fake rebuttal is not exposed for what it is.

Halting problem undecidability and infinitely nested simulation (V5)
https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

[olcott]

On 5/25/2022 9:35 AM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 10:31:41 AM UTC-4, olcott wrote:
>> On 5/25/2022 9:20 AM, Dennis Bush wrote:

>>> Now create Ha3, Ha7 and N, and produce traces of Ha3(N,5) and Ha7(N,5) and tell us what you see.
>>>
>> If H(P,P) is proven to be correct then there is no need to look at
>> anything else. I am not writing a paper about every program that can
>> possibly ever be written. I am wring a paper about H(P,P). Once
>> H(P,P)==0 is proven to be correct then all of the HP proof are refuted.
>
> If your proof of H(P,P)==0 being correct also concludes that Ha3(N,5)==0 is correct, then you have an invalid proof as it creates nonsense results.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

It is an easily verified fact that the correct x86 emulation of the
input to H(P,P) would never reach the "ret" instruction of P in 0 to
infinity steps of the correct x86 emulation of P by H.

This can be verified entirely on the basis of the x86 source-code for P
by anyone that is sufficiently technically competent.

Even people that are not very bright can tell That H must emulate the
first 7 instructions of P.

Because we know that H(P,P) emulates the first 7 instructions of P we
know that when P calls H(P,P) that H emulates the first 7 instructions
of P.


Begin Local Halt Decider Simulation Execution Trace Stored at:212352

H emulates the first 7 instructions of P
...[00001352][0021233e][00212342] 55 push ebp // enter P
...[00001353][0021233e][00212342] 8bec mov ebp,esp
...[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
...[00001358][0021233a][00001352] 50 push eax // push P
...[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][00212336][00001352] 51 push ecx // push P
...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

The emulated H emulates the first 7 instructions of P
...[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
...[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
...[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
...[00001358][0025cd62][00001352] 50 push eax // push P
...[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
...[0000135c][0025cd5e][00001352] 51 push ecx // push P
...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H

It is clear that the emulated P would never reach its "ret" instruction
and the emulation would never stop unless aborted.

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[olcott]

On 5/25/2022 1:42 PM, Dennis Bush wrote:
> On Wednesday, May 25, 2022 at 2:38:40 PM UTC-4, olcott wrote:
>> On 5/25/2022 1:36 PM, Dennis Bush wrote:
>>> On Wednesday, May 25, 2022 at 2:34:42 PM UTC-4, olcott wrote:
>>>> On 5/25/2022 1:28 PM, Dennis Bush wrote:
>>>>> On Wednesday, May 25, 2022 at 2:20:41 PM UTC-4, olcott wrote:
>>>>>> On 5/25/2022 10:01 AM, Dennis Bush wrote:

>>>>>>> It is an easily verified fact that the correct x86 emulation of the input to Ha3(N,5) would never reach the "ret" instruction of N in 0 to infinity steps of the correct x86 emulation of N by Ha3.
>>>>>>>
>>>>>> God damned liars always change the subject when they know that that have
>>>>>> been correctly refuted.
>>>>>
>>>>> Wrong on both counts.
>>>> Liar
>>>
>>> Then why am I wrong?
>> It seems to me that you are wrong because you are hard-wired to be a liar.
>
> No explanation. That you means you admit that I'm right that Ha(Pa,Pa)==0 (which you refer to as H(P,P)==0) is wrong and that your last 18 years of work have been for naught.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Any brain-dead moron knows that a correct x86 emulation of the input to
H(P,P) would result in the first seven instructions of P being emulated.

The same extremely stupid person would also know that when P calls
H(P,P) that the same first seven instructions of P would be emulated again.

It might take an actual moron (that is not brain dead) to be able to see
that the correctly emulated P would never reach its “ret” instruction.

[olcott]

that the correctly emulated input to H(P,P) would never reach its “ret”

[Richard Damon]

And since the input is the SAME to both of these, the correct emulation
of that input must be the same, at least if H is a computation.

It is sounding very much like it isn't, so your whole argument falls
apart. Since you are claiming contray behaviors for H, (sometimes it
halts given H(P,P) and sometimes it doesn't) YOU need to actually PROVE
that you have meet that requirement, dispite the fact that it fails one
of the basic tests of a computation (always acting the same for the same
input).

>
> I can prove that both of these execution traces are correct on the basis
> of the behavior that is specified by the x86 source-code for P.

But since that the behavior of P is dependent on the behavior of H which
isn't shown, you can't actually verify what it does!

>
> We can't do any of these things with the purely imaginary Ha(Pa,Pa) and
> Hb(Pa,Pa). Dennis wants to keep things vague so that his deceptive and
> fake rebuttal is not exposed for what it is.

Except you just admitted that his Ha is your H, and his Hb is your H1,
so what isn't real about that.

[olcott]

So you disagree with the x86 langugae?

[Richard Damon]

Nope, but the x86 language doesn't say what you claim.

x86 says that P isn't fully defined as it uses a memory location with no
code defined for it.

Just shows that YOU don't really understand the x86 language.

[olcott]

On 5/25/2022 8:15 PM, Ben wrote:
> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>
>> On 25/05/2022 19:42, Ben wrote:
>>> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>>>
>>>> It's true we don't know the details of how PO is doing this, but we
>>>> can see what's effectively going on, I'd say. It is /as though/ there
>>>> is one "master trace" of all the nested simulations maintained by the
>>>> x86utm somewhere in the address space of its virtual x86 processor.
>>> Hmm... If I had to guess I'd put some store in a few phrases he's
>>> uttered that maybe give away more than he intends. Something along the
>>> line of recursion having the same execution pattern as nested
>>> simulations (that's not verbatim -- I'm not reading so much anymore).
>>
>> Well, he certainly argued with me a couple of years back that it
>> didn't make any difference to his rule whether the trace was direct
>> call or emulation recursion. He declined to provide any proof for the
>> soundness of his rule in either scenario (of course), instead
>> suggesting it was my responsibility to provide counter-examples where
>> his rule failed! (If nobody could do that, it would mean his rule was
>> sound, so he believed...) Oh, and we know that pointing out his H as
>> an actual counterexample goes nowhere...
>>
>>> This adds wight to my idea that he has only the top level simulation and
>>> to "speed up the work" and "make the trace simpler" what's being traced
>>> by the top-level H is a different H(X, Y) that just calls X(Y). I
>>> imagine that he thought he could, in principle, eventually make both H's
>>> the same, and that just calling the computation rather than simulating
>>> was just a sort of optimisation.
>>
>> I can't say "definitely not" to that, but my thinking would be that it
>> illustrates PO not appreciating the qualitative difference between
>> recursion in call vs simulation environments, rather than PO not
>> actually using simulation. Maybe a prototype test used direct call
>> and that might have reinforced his confusions.
>
> I'm not saying there is none, just that it's not nested. I posit one
> simulation in some "top-level H" that steps through the execution of the
> specified function call (or otherwise observes it) and stops when the
> magic condition is seen. But rather than build P from this top-level H
> so he builds P from a simpler H(X, Y) that just calls X(Y).
>
> I admit it's all guesswork though. I seriously lost interest when all I
> thought it worth doing was pointing out that if H(X,Y) does not report
> on the "halting" of X(Y) then it's not doing what everyone else is
> talking about.
>

There are two key points:
(1) The the C function named H correctly determines that the correct
simulation of its x86 machine-code input would never reach its "ret"
instruction. This is a simple verified fact that lying cheating bastards
continue to deny.

That they continue to deny this is of no great concern because even
moderately competent software engineers can easily confirm that I am
correct.

(2) That H(P,P) must compute the mapping from a non-input clearly
violates the definition of a computable function that must
*given an input of the function ... return the corresponding output*
and the definition of a decider compute the mapping of its input to an
accept or reject state.

It is *not* that the computer science textbook authors disagree with
this. It is only that they simply assumed that P(P) cannot possibly
specify a different sequence of configurations than the correct
simulation of the input to H(P,P).

These two may only differ in the case of pathological self-reference
(Olcott 2004). Since no one was every able to execute an input with PSR
previously (they simply assumed it was impossibe) they never noticed
this divergence.

The actual correct x86 emulation of the input to H1(P,P) and H(P,P)
conclusive proves that P does have different halting behavior between
them. The alternative is that the x86 language itself is not telling the
truth about their behavior.

Actual computer scientists that know these things much deeper than mere
rote memorization will understand that I am correct. The alternative to
this is that computer scientists believe that textbook authors can
contradict the principles of computer science and not be wrong.

When H that simulates P calls H(P,P) this H creates a whole new process
context that simulates its input all the way through to P calling H(P,P)
again.

>> I think my description of how it /could/ be coded (using a global
>> trace area etc.) is within PO's coding ability given how long he had
>> to sort it out. Also PO has definitely talked about such a global
>> trace, I think in relation to whether this use of globals broke the
>> "pure function" requirement (as he understood it). So if I had to
>> place a bet, I'd go with it working /something/ like this, rather than
>> the blatant faking of traces otherwise required.
>
> I don't think they are faked, at least not totally faked.
>

It can be verified that they are correct thus the issue of whether they
are faked or not (they are not faked) is moot. It was very very
difficult to make H re-entrant.

It was much easier to make x86utm actually be able to execute H in
infinitely nested simulation than it was to verify that it was correct
without actual code. I had far too many false starts with imaginary
code. I had to make real code so if needed I could make adjustments to
my analysis.

>> BTW, have you noticed that PO's traces are out-of-step regarding the
>> ESP column? It's like he prints details for the "current instruction"
>> about to be executed, but the ESP column is the ESP /after/
>> instruction execution. Not how traces normally work... (that's just a
>> curiosity, but it makes me wonder about his recent "TM transition
>> function" not working posts...)
>
> No, I'd not noticed that. Curious.

Each instruction is simply shown after it has been executed thus not
out-of-sync at all.

>>>> So the purpose of all the complicated and semi-secret H code is
>>>> ultimately just to give PO some excuse to confuse himself!
>>> The original purpose was to backtrack on the claim, made I think in a
>>> manic delusion, that he had an "actual Turing machine pair", H, Ĥ, "fully
>>> encoded", "exactly and precisely as in Linz" that correctly decides the
>>> H(Ĥ, Ĥ) case.
>>> This claim was walked back step by step. It was "an algorithm", then "a
>>> pair of virtual machines" then "a few lines of C-like pseudo code"
>>> until, finally, the dump truck arrived with the "x86 language code" to
>>> make it too complicated to post. The original claim was then declared
>>> to be using "poetic licence".
>>
>> Right - that's all true! But still I imagine he actually /does/ have
>> some existing H code that he doesn't want to reveal. Right now, I
>> imagine PO's genuine reason for refusing to post H would be a
>> combination of
>>
>> 1) The H code is a total dog's dinner from a C programming
>> perspective, and he's ashamed of the quality of the code!
>>
>> 2) Architecturally it will be rather naff, having obvious breaks with
>> TM capabilities: use of global variables to communicate across
>> emulation levels; use of its own address as a hidden input to the
>> function; hacks that are designed to "just make the right decion he
>> knows he wants to make", rather than general logic that would be
>> required in anything claiming to be a more general halt decider.
>> Bottom line: it won't be at all how we'd have done it! PO thinks
>> (rightly or wrongly) that those things do not affect his claims, and
>> so he wants to avoid months of discussion/argument over whether he's
>> "doing it the right way".
>>
>> 3) If he "published everything" (x86utm and H) like he steadfastly
>> maintained he would for the first couple of years, people would be
>> able to run and post their own tests/traces, easily highlighting why
>> PO's explanations of what's going on are rubbish. PO wants to retain
>> a tight control over allowed discussion paths! Funnily enough, one of
>> PO's original selling points for developing all this was that it would
>> all be published enabling people to run it and see for themselves the
>> undisputable evidence of his claims!
>
> These are all plausible.
>
>> [I think (3) is by far the main reason why PO decided to backpedal
>> from publishing x86utm and H here. His explanation of "when I take my
>> work to a journal, the publishers will only accept if I haven't
>> revealed utmx86 + H source code elsewhere on the Internet" seems like
>> one of those retro-explanations cooked up just to excuse his breaking
>> with previous commitments. Well, you would know more about whether
>> there would be such a condition from publishers?
>
> I've never come across that. Publishers used to want a paper that was
> not largely similar to one published elsewhere (by which I mean another
> journal) for copyright reasons. But self-publishing, and making code
> public domain, pose no problems for journals as far as I know. But I
> said "used to" because it's been a while!
>
>> And yes, if PO were
>> serious about publishing he'd have acted years (decades?) ago!
>> Perhaps he can put a clause in his will and testament to publish all
>> on UseNet, just in case...]
>
> I very much doubt anyone will ever see H...

[Richard Damon]

No, it has NOT been determined that it correctly determines this, and in
fact it has been proven that it can't, because it have been proven that
a REAL CORRECT simulation of the input WILL reach that return
instruction, by the simulation of H1.

It is YOU being a lying cheating bastard that refuses to accept this proof.

What you HAVE shown is that no possible H can itself simulate to that
point, but that doesn't prove that H is a correct simulation, and you
can't stipulate that it is, because you can't stipulate correctness. (If
you try to stipulate that H will correct simulate, you first need to
actually PROVE that such an H exists, which you can't, since that is
actually the goal of the proof).

You confuse the simulation done by H with a correct simulation of its
input. BY DEFINITION, if H is a Halting Decider, the interpreation of
its input must be the reprentation of a computational program and its
input, which we know will ALWAYS behave the same, so the fact that H1
can simulate it to its return says that is *THE* correct simulation, and
thus H's can't be.

>
> That they continue to deny this is of no great concern because even
> moderately competent software engineers can easily confirm that I am
> correct.

Nope, they will confirm that you are wrong.

>
> (2) That H(P,P) must compute the mapping from a non-input clearly
> violates the definition of a computable function that must
> *given an input of the function ... return the corresponding output*
> and the definition of a decider compute the mapping of its input to an
> accept or reject state.

Yes, H must compute a mapping from its input to its output, but the
mapping that it computes is not guarenteed to be the Halting Function,
in fact, that is a required goal, to PROVE that it is. The fact that
H(P,P) doesn't match the required answer of what P(P) does, says it can
not actually be a Halting decider.

>
> It is *not* that the computer science textbook authors disagree with
> this. It is only that they simply assumed that P(P) cannot possibly
> specify a different sequence of configurations than the correct
> simulation of the input to H(P,P).
>

Because is CAN'T and have H actually be a Halt Decider, since that is
the DEFINITION of a Halting Decider.

> These two may only differ in the case of pathological self-reference
> (Olcott 2004). Since no one was every able to execute an input with PSR
> previously (they simply assumed it was impossibe) they never noticed
> this divergence.

There is no exception in the definiton of a "something" decider. To be a
"something" decider, it must compute the "something" function for ALL
inputs, even "pathological" ones. If this isn't possible, the function
is just not computable.

>
> The actual correct x86 emulation of the input to H1(P,P) and H(P,P)
> conclusive proves that P does have different halting behavior between
> them. The alternative is that the x86 language itself is not telling the
> truth about their behavior.
>

Then P is not a Computation, and due to the way P was built, that proves
that H is not a Computation, and thus can not actually a Halt Decider,
as the Halt Decider needs to be a COMPUTATION that computes the Halting
Function.

You just proved that your H isn't a Halt Decider

> Actual computer scientists that know these things much deeper than mere
> rote memorization will understand that I am correct. The alternative to
> this is that computer scientists believe that textbook authors can
> contradict the principles of computer science and not be wrong.
>

Nope.

> When H that simulates P calls H(P,P) this H creates a whole new process
> context that simulates its input all the way through to P calling H(P,P)
> again.

So, since H isn't actually a computation, it doesn't matter. Note, your
trace doesn't show that behavior, so either the trace lies or you do
about what it does.

>
>>> I think my description of how it /could/ be coded (using a global
>>> trace area etc.) is within PO's coding ability given how long he had
>>> to sort it out.  Also PO has definitely talked about such a global
>>> trace, I think in relation to whether this use of globals broke the
>>> "pure function" requirement (as he understood it).  So if I had to
>>> place a bet, I'd go with it working /something/ like this, rather than
>>> the blatant faking of traces otherwise required.
>>
>> I don't think they are faked, at least not totally faked.
>>
>
> It can be verified that they are correct thus the issue of whether they
> are faked or not (they are not faked) is moot. It was very very
> difficult to make H re-entrant.

But it appears that it isn't actually a computation since the H called
by P doesn't compute the same answer as the H that is called
independently. This disqualifies it from being a Halting Decider.

>
> It was much easier to make x86utm actually be able to execute H in
> infinitely nested simulation than it was to verify that it was correct
> without actual code. I had far too many false starts with imaginary
> code. I had to make real code so if needed I could make adjustments to
> my analysis.
>

H doesn't work the way you describe. You have revealed that H is not a
computation, and you have made comments in the past showing that, and
have perhaps tried hard to make it SEEM to be one, but it clearly still
fails to be one.

>>> BTW, have you noticed that PO's traces are out-of-step regarding the
>>> ESP column?  It's like he prints details for the "current instruction"
>>> about to be executed, but the ESP column is the ESP /after/
>>> instruction execution.  Not how traces normally work... (that's just a
>>> curiosity, but it makes me wonder about his recent "TM transition
>>> function" not working posts...)
>>
>> No, I'd not noticed that.  Curious.
>
> Each instruction is simply shown after it has been executed thus not
> out-of-sync at all.

Except that the nested instruction should never actually be executed,
only simulated. This shows that H is flawed.

[olcott]

On 5/26/2022 6:21 AM, Ben wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>

>> On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
>>>
>>> I admit it's all guesswork though. I seriously lost interest when all I
>>> thought it worth doing was pointing out that if H(X,Y) does not report
>>> on the "halting" of X(Y) then it's not doing what everyone else is
>>> talking about.
>>>

>> To me, that's what retains the interest.
>> If someone claims that H_Hat(H_Hat) halts, and they have an H such
>> that H(Hat, H_Hat) reports "Halting", then they would say that,
>> wouldn't they?
>>
>> If it turns out that H isn't a Turing machine but a C/x86 program, and
>> that they are refusing to provide the source, then really the whole
>> thing must be dismissed.
>>
>> However if they say that H_Hat(H_Hat) halts, and H(H_Hat,H_Hat)
>> reports non-halting, and they can prove that H is correct.
>
> There's no reason at all to think that H is /not/ correct. But since H
> is not reporting on the halting of a call to H_Hat(H_Hat), I don't see
> what's interesting about it being correct. Do you really think it's
> "deciding" some interesting property of the "input"?
>

The only reason that you do not see the significance of this is that the
depth of your understanding is learned-by-rote.

Someone with a deeper understanding would realize that your
interpretation that a halt decider must compute its mapping from a
non-input would understand that this would violate the definition of a
computable function and the definition of a decider.

They would understand that a halt determiner must only compute the
mapping from its input to its own final accept or reject state on the
basis of the behavior that this input actually specifies.

If we take your interpretation as correct then computer scientists we be
agreeing that it is perfectly OK for the requirements of a decision
problem to violate the principles of computer science and still be a
valid decision problem.

Then we have other undecidable decision problems such as calculating
whether or not the square root of a plate of scrambled eggs > 5.

>> Well that's something a bit new and different.
>
> Being different is key for any Usenet maths crank. No two people who
> have "refuted Cantor" or "solved halting" will agree with each other for
> long. Fortunately there are infinitely many ways to be wrong, but only
> one way to be right so it's not hard to achieve.

[Richard Damon]

No, it only CAN compute what can be determined by its processing of the
input, but a "something" decider MUST compute the "something" mapping
defined, and if that is not possible, the mapping just isn't computable.

You err in presuming (incorrectly) that the Halting Mapping Must be
Computable, and thus feel the ability to redefine it when you find it isn't

That just proves that you don't know what you are doing.

>
> They would understand that a halt determiner must only compute the
> mapping from its input to its own final accept or reject state on the
> basis of the behavior that this input actually specifies.
>

No, to be "Just a Decider", then that is what it CAN do, but to claim to
be a Halt Decider, then the results must match the Halting Function.

What you are saying is like claiming to be immortal, but saying that
since human bodies will die, we just need to change the definition of
immortality,

> If we take your interpretation as correct then computer scientists we be
> agreeing that it is perfectly OK for the requirements of a decision
> problem to violate the principles of computer science and still be a
> valid decision problem.

And, it this sense, it is, because there is no requirement that Halt
Deciders actually need to exist, and a perfectly fine answer is that
there is no such thing.

>
> Then we have other undecidable decision problems such as calculating
> whether or not the square root of a plate of scrambled eggs > 5.

Nope, not the same. The Halting Function is well defined, and if an H
existed, then the Halting of H^ applied to <H^> would be well defined
for the H^ built on that H.

[olcott]

You just contradicted yourself.

The set of deciders only applies to input finite strings. It can apply
any computable criteria to these inputs. I know these things first-hand
not merely by the rote from textbooks.

[Richard Damon]

No, just shows you don't understand English.

I am pointing out the difference between what something is ABLE to do,
and what it is REQUIRED to do.

>
> The set of deciders only applies to input finite strings.  It can apply
> any computable criteria to these inputs. I know these things first-hand
> not merely by the rote from textbooks.
>

Right, and the finite string that descibes P is the FULL contents of the
memory including ALL the code that it executes.

This is BY DEFINITION a finite string, since there are a finite number
of bytes. Thus the behavior of that when run as a program is something
in the domain of what we MAY ask.

Then we get to your second statement, and that is the crux of the
proble, is the Halting Criteria computable? The Halting Function
Halting(M,w) is DEFINED to return True if M(w) will Halt, and False if
M(w) will never halt. Halting is clearly recognizable, as we can build a
machine that accepts (in finite time) all halting inputs, by just
simulating and accepting when the simulation halts.

This is just recognition, not deciding, as it just doesn't answer for
non-halting inputs.

The question comes can we do something to some how recognize these
non-halting and be able to REJECT them, rather than just looping on them.

The "Impossible Program" proves that this can't be done. It IS a finite
string input, at least if H is (and it must be to meet the requirements
to actually be a decider), and thus is a legal input.

It also presents a problem for the decider it is built on, as whatever
answer that decider gives, will be wrong, because of the ability to
refer to that decider inside the impossible program.

What this proves is that Halting isn't a computable function, and thus
(because it isn't computable, and what makes it non-computable) no
decider can be built to compute it.

Your logical flaw is that your start with the assumption that Halting
must be computable, when that is NOT an allowable assumption, in fact,
that is the QUESTION.

This means you don't get to redefine the meaning of the problem, to
something that is actually computable to answer the question.

That is like answering about how many Dogs you have when someone asks
about fleas, because fleas are just too hard to find to count. It just
isn't the right answer to the question.

[olcott]

You are requiring that a decider maps somethings that it does not have,
thus making your requirement incorrect. It is like I said give me the
$10 from your empty wallet.

[Richard Damon]

But it DOES have the representation of P, so it can map it.

YOU just don't know what you are talking about.

If you are saying the Halting Problem is impossible to make as a
requirement, you have just PROVED the Theorem.

AND FAILED at its disproof.

If you disalllow the asking of a question, you make it impossible to
give a correct answer, and thus a machine that answers the question
correcctly is impossible.

Halting Theorem Proved.

YOU FAIL.

[olcott]

On 5/27/2022 10:52 AM, Malcolm McLean wrote:
> On Friday, 27 May 2022 at 16:38:05 UTC+1, richar...@gmail.com wrote:
>> On 5/27/22 11:21 AM, olcott wrote:
>>> On 5/27/2022 2:48 AM, Mikko wrote:

>>>> On 2022-05-26 13:35:31 +0000, olcott said:
>>>>
>>>>> Someone with a deeper understanding would realize that your
>>>>> interpretation that a halt decider must compute its mapping from a
>>>>> non-input would understand that this would violate the definition of
>>>>> a computable function and the definition of a decider.
>>>>

>>>> The definition of "decider" does not require much, only that it must halt
>>>> and indicate the decision. This is not violated by the definition of
>>>> "halt
>>>> decider".
>>>>
>>>
>>> a function is computable if there exists an algorithm that can do the
>>> job of the function, i.e. given an input of the function domain it can
>>> return the corresponding output.
>>> https://en.wikipedia.org/wiki/Computable_function
>>>
>>> P(P) is not in the domain of H because it is not an input to H.
>> Wrong. IF that is true the a UTM can't exist, but you are baisng your
>> argument on that.
>>
>> The representation of P, in your case the object code of it. contains
>> all the data needed to determine the behavior of that computation, and
>> thus IS in the domain of H.
>>
>> In fact, saying that the representation of P(P) is not in the domain of
>> H is, by itself, enough to prove that H can not be a correct halt decider.
>>
>> You are just digging a deeper hole for yourself.
>>
>> You are just proving your ignorance.
>>
>> If H claims to be a Halt Decider, then we need to be able to ask it
>> about any computation, how do we ask it about P(P).
>>
>> If we can't, then it isn't one.
>>
> But declaring H_Hat(H_Hat) to be outside the domain of a halt decider
> would in fact achieve PO's broader objectives. It wouldn't "solve the
> halting problem", but it would redefine it for future workers.
>

Halt decider are required to decide the halt status of any finite
strings that specify a sequence of configurations.

Halt deciders are not required to decide that halt status of finite
strings of English poems nor are they required to compute the halt
status of anything that is not an input finite string.

For example H is not required to compute the halt status of the behavior
that a person imagines that P(P) has. H(P,P) is only required to compute
the halt state that its input actually specifies.

> However the question is how to do this in an interesting way. As Ben says,
> a lot of students, when introduced to this material, say "why not detect
> the H_Hat(H_Hat) pattern and special case it?". It's a natural reaction.
> But when you think about it a bit more deeply, you'll see that this strategy
> doesn't work.
>

It does work when H is defined to recognize the whole infinite recursion
pattern. I threw in infinite loops for good measure.

[olcott]

The correctly simulated input to H(P,P)==0
The correctly simulated input to H1(P,P)==1

[Richard Damon]

HOW?

It is the same input, so has the same correct simulation.

Do you really expect people to believe that that SAME program, when
simulated by two diffetent "correct" simulators have different behavior?

What definition of "correct" are you using, it must be something besides
matching the actual behavior of the code given to it.

All you have done is proven that you H isn't a computation, and thus not
eligible to be a decider.

FAIL

[Richard Damon]

Except there is no such universal correct pattern.

This is shown by the fact that H(P.P) says Non-Halting when P(P) Halts,
showing that H was wrong.

[olcott]

I know exactly how. When I explain exactly how my reviewers brains
short-circuit and they become utterly confused.

Instead of how we really only need to know that H(P,P)==0 and H1(P,P)==1
is easily verified as correct on the basis of the behavior of the
correct x86 emulation of these inputs.

[olcott]

H correctly recognizes the only infinite recursion pattern that it needs
to recognize and that is this one:

For any program H that might determine if programs halt, a
"pathological"
program P, called with some input, can pass its own x86 source and
its input to
H and then specifically do the opposite of what H predicts P will
do. No H
can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

> This is shown by the fact that H(P.P) says Non-Halting when P(P) Halts,
> showing that H was wrong.

The correct x86 emulation of the input to H(P,P) conclusively proves
that it DOES NOT HALT.

The correct x86 emulation of the input to H1(P,P) conclusively proves
that it HALTS.

When you disagree with this it is just like you are disagreeing with
arithmetic.

[Richard Damon]

In other words, you can't actually explain it.

You apparently THINK you know it, by epistomolgy, you can only know
something that is actually true, and whose truth you can prove.

The fact that you can't make a reasoned argument about the truth of this
statement shows you don't actually know it.

It is a mistaken BELIEF of yours, grounded in your own ignorance of what
Truth actually requires.

>
> Instead of how we really only need to know that H(P,P)==0 and H1(P,P)==1
> is easily verified as correct on the basis of the behavior of the
> correct x86 emulation of these inputs.
>

No, you make this CLAIM, that it totally not backed up by ANY proof,
just CLAIMS, that show you don't understand the maining of the words you
are speaking.

All your arguments have shown is that there are many things you just
don't understand, beginning with most of computation theory, the theory
of how logic works, and even the meaning of Truth and Knowledge itself.

You are just a lying fool who is a legend in his own minds.

[Richard Damon]

Except that the pattern isn't correct, as H says P(P) is non-halting
when in fact it is haltimg.

You mind has apparently imploded as it doesn't recognize this error.

>
>
>> This is shown by the fact that H(P.P) says Non-Halting when P(P)
>> Halts, showing that H was wrong.
>
> The correct x86 emulation of the input to H(P,P) conclusively proves
> that it DOES NOT HALT.

DEFINE CORRECT, since by the normal definition of a correct simulation
of that input, one that you have even posted yourself, it shows that it
does halt.

>
> The correct x86 emulation of the input to H1(P,P) conclusively proves
> that it HALTS.

Yes, and since it is the same input, that shows that H's simulation,
which was aborted before it reached its end, was not correct.

>
> When you disagree with this it is just like you are disagreeing with
> arithmetic.
>
>

What, that counting to ten by going 1, 2, 3, 4, 5 ABORT, isn't a correct
counting to 10?

You seem to think it is.

You don't seem to have a proper definition of correct, which isn't
surprising as you don't know what Truth is, and they are tied together.

[olcott]

On 5/27/2022 1:45 PM, André G. Isaak wrote:
> On 2022-05-27 12:37, Andy Walker wrote:
>> On 27/05/2022 18:57, André G. Isaak wrote:
>>> The (positive) square root function you talk about maps real numbers
>>> (not scrambled eggs and not finite strings) to real numbers (again,
>>> not finite string). Unlike the prime() function, however, the
>>> positive square root function is NOT computable.
>>
>>      Um.  This is technically true, but [IMO] misleading.  The reason
>> for the failure is that most [indeed, almost all] real numbers are not
>> computable.  But non-computable reals are of [almost] no interest for
>> practical applied maths and theoretical physics, and are the sorts of
>> object that give maths a bad name in the outside world.  If "x" is a
>> computable positive real, then "sqrt(x)" is also a computable real [eg
>> by using Newton-Raphson], which is all you really have any right to
>> expect.  If you can't compute "x", then what does it even mean to talk
>> about its "sqrt"?
>
> All I was really trying to get Olcott to see was a case where it really
> *isn't* possible to encode all elements of the domain or codomain as
> finite strings, which is rather different from his strange claim that
> computations like P(P) cannot be encoded as finite strings.
>

Computations like P(P) can be encoded as finite string inputs to H1,
they cannot be encoded as finite string inputs to H simply because the
behavior specified by the correctly emulated input to H(P,P) is entirely
different behavior than the correctly emulated input to H1(P,P).

We don't even need to understand why this is the case we only need to
understand that it is a verified fact.


> (And Newton-Raphson doesn't allow you to compute square roots; it allows
> you to compute arbitrarily precise approximations of those roots).
>
> André

[André G. Isaak]

Either something is encodable as a finite string or it isn't.

In much the same way, a particular integer is either encodable as a
16-bit twos complement number or it isn't. You won't find an integer
which can be encoded as as 16-bit twos complement number for one C
function but not for some other C function.

André

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

[olcott]

I just proved otherwise. This is a very rare exeception and only occurs
when H/P have a pathological self-reference (Olcott 2004) relationship
and H1/P does not.

>
> In much the same way, a particular integer is either encodable as a
> 16-bit twos complement number or it isn't. You won't find an integer
> which can be encoded as as 16-bit twos complement number for one C
> function but not for some other C function.
>
> André
>


--

[Richard Damon]

If P(P) can't be encoded to give to H, then H fails to be a (Universal)
Halt Decider from the begining, and can't be a counter example.

FAIL.

Just shows you still don't even understand what the problem is asking for.

[olcott]

Not at all. Halt deciders have sequences of configurations encoded as
finite strings as the domain of their computable function.

Halt deciders (like people) cannot possibly answer questions that have
not been asked. As long as they can answer every question that can be
asked then they are universal.

> FAIL.
>
> Just shows you still don't even understand what the problem is asking for.
>
>>> (And Newton-Raphson doesn't allow you to compute square roots; it
>>> allows you to compute arbitrarily precise approximations of those
>>> roots).
>>>
>>> André
>>>
>>
>>
>

[Richard Damon]

Nope, you don't understand what the word mean.

First, the "Question" is asked by giving the decider an
description/encoding of the machine/algorithm + the input to that.

The decider then generates the sequence of configurations, which if the
sequence of configurations the DECIDER generates isn't finite, means it
failed to be a decider and answer in finite time.

To be universal, H need to be able to be asked about ALL machines and
ALL inputs to those machines.

You definition is like the smart alec who says they know EVERY language
in the world except Greek, and when you ask them to translate something,
they just say "Thats Greek to Me".

You H just fails,, as does your argument, as do YOU.

[André G. Isaak]

This is an entirely mangled sentence. You really need to go back to the
basics:

First, a Turing Machine is *NOT* a computable function.

Second, A function (computable or otherwise) is NOT a Turing Machine.

Third, the domain of a computable function is NOT the same thing as the
input (or set of possible inputs) to a Turing Machine.

Until you actually get clear in your head the difference between a
Turing Machine and a computable function and how the two are related,
you really have no business make any claims whatsoever about the halting
problem. Once you get that distinction straight we can move on to:

Fourth, the input to a halt decider is NOT a 'sequence of configurations
encoded as finite strings'

[olcott]

On 5/27/2022 3:02 PM, Richard Damon wrote:
>
> On 5/27/22 3:53 PM, olcott wrote:

>>>> I can't follow all the arguments, and they seem to shift over time.
>>>
>>> I think it's important to separate out all the difference kinds of
>>> nonsense he has produced over the years because they require different
>>> responses.
>>>
>>
>> It actually makes more sense to simply drop endless rehashing of
>> points that have already been resolved and focus on what is currently
>> being proposed.
>
> Except none of your points HAVE been resolved, except to show that you
> are wrong about them.
>

There is only one point that is unresolved.

*This has been resolved despite that fact that liars disagree*
(1) Whether or not the C function H(P,P)==0 on the basis of whether or
not the correct x86 emulation of the input finite strings of machine
language of P would ever reach its "ret" instruction.

(2) Whether or not H(P,P) must report on anything other than the actual
behavior that its input actually specifies.

int sum(int X, int Y)
{
return X + Y;
}


Goofy people will say that it does, as if the function sum(4,3) must
always also derive the current price of tea in China.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

[Richard Damon]

That you are just a pathological liar.

>
> *This has been resolved despite that fact that liars disagree*

Maybe you have convinced yourself, but you haven't actually PROVED any
of them, so they are not really resolved

> (1) Whether or not the C function H(P,P)==0 on the basis of whether or
> not the correct x86 emulation of the input finite strings of machine
> language of P would ever reach its "ret" instruction.

Since the CORRECT x86 emulation of the input to H(P,P) IS the execution
of P(P), which Halts if H(P,P) returns 0, you haven't shown this.

Maybe you have some unfounded definition of some of the terms to allow
you to make the claims with a straight face, but they are not correct.

>
> (2) Whether or not H(P,P) must report on anything other than the actual
> behavior that its input actually specifies.

Since the "Actual Behavior" of the input to H(P,P), is BY DEFINITION,
the behavior of P(P), yes H MUST report on that.

Again, maybe you have some unfounded definitions of the terms to let you
try to make the claims, but they are not correct.

>
> int sum(int X, int Y)
> {
>   return X + Y;
> }
>
>
> Goofy people will say that it does, as if the function sum(4,3) must
> always also derive the current price of tea in China.

YOU are the only person who says that sum(4,3) shouldn't return 7, and
the fact you make this point just shows how out of whack your brain is.

>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>

No new comments, already has been shows to be just a bunch of garbage.

You are proving your ignorance and stupidity.

That is going to be your legacy, that Peter Olcott was a pathological
liar that didn't understand anytning he made claims about.

[olcott]

A Turing machine would compute only the inputs to a its corresponding
computable function that can be encoded as finite strings.

> Second, A function (computable or otherwise) is NOT a Turing Machine.
>
> Third, the domain of a computable function is NOT the same thing as the
> input (or set of possible inputs) to a Turing Machine.
>

A computable function only includes inputs in the domain of the function
that can be encoded as finite strings.

Any inputs that cannot be encoded as finite strings are excluded from
the domain of computable functions.

> Until you actually get clear in your head the difference between a
> Turing Machine and a computable function and how the two are related,
> you really have no business make any claims whatsoever about the halting
> problem. Once you get that distinction straight we can move on to:
>

[Richard Damon]

And P / H^ is encoded as a finite string, so is in the domain of the
function.

(You make it TOO small, but there is a finite string that represents it
as long as H is a proper computation too).

[André G. Isaak]

Computable functions don't have inputs, they have domains. And *all* of
the elements in the domain of a computable function can be encoded as
finite string. Otherwise it wouldn't be a computable function.

>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>
>> Third, the domain of a computable function is NOT the same thing as
>> the input (or set of possible inputs) to a Turing Machine.
>>
>
> A computable function only includes inputs in the domain of the function
> that can be encoded as finite strings.

Computable functions don't "include" inputs at all. You are writing in
gibberish.

> Any inputs that cannot be encoded as finite strings are excluded from
> the domain of computable functions.

Again, pure gibberish.

You *really* do not understand what terms like 'function', 'domain',
'input', 'logic', 'proof', etc. actually mean. You need to learn the
basic terminology before any sort of meaningful discussion is possible.

[olcott]

Computable functions are the basic objects of study in
computability theory.
Computable functions are the formalized analogue of the intuitive
notion of
algorithms, in the sense that a function is computable if there

exists an algorithm
that can do the job of the function, i.e. given an input of the
function domain it
can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function

*I am going by the above*

>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>
>>> Third, the domain of a computable function is NOT the same thing as
>>> the input (or set of possible inputs) to a Turing Machine.
>>>
>>
>> A computable function only includes inputs in the domain of the
>> function that can be encoded as finite strings.
>
> Computable functions don't "include" inputs at all. You are writing in
> gibberish.

a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an
input of the function domain it can return the corresponding
output.

>

>> Any inputs that cannot be encoded as finite strings are excluded from
>> the domain of computable functions.
>
> Again, pure gibberish.
>
> You *really* do not understand what terms like 'function', 'domain',
> 'input', 'logic', 'proof', etc. actually mean. You need to learn the
> basic terminology before any sort of meaningful discussion is possible.
>
> André
>


--

[André G. Isaak]

No. You're going by your *flawed* reading of the above. In the above
paragraph it is the algorithm which has an input, not the function. Any
arbitrary element of the functions domain can be used as an input to the
algorithm once suitably encoded.

>
>>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>>
>>>> Third, the domain of a computable function is NOT the same thing as
>>>> the input (or set of possible inputs) to a Turing Machine.
>>>>
>>>
>>> A computable function only includes inputs in the domain of the
>>> function that can be encoded as finite strings.
>>
>> Computable functions don't "include" inputs at all. You are writing in
>> gibberish.
>
>
>    a function is computable if there exists an algorithm
>    that can do the job of the function, i.e. given an
>    input of the function domain it can return the corresponding
>    output.

And where does the above entail that computable functions "include" inputs?

You need to actually understand a paragraph before you can use it to
support a position. To do that you need to know the terminology used in
the paragraph. You're still struggling with the latter so will never get
to the former.

[olcott]

*input of the function domain*

> not the function. Any
> arbitrary element of the functions domain can be used as an input to the
> algorithm once suitably encoded.
>

Sure and if it can't be suitably encoded it is excluded.

P(P) is suitably encoded as the actual machine language of P when
directly executed as P(P) or emulated by H1(P,P).

That its correct x86 emulation by H(P,P) differs from its correct x86
emulation by H1(P,P) is simply an established fact.

H is not supposed to compute the mapping from its input to its accept or
reject state on the basis of what you imagine its behavior should be.

Instead it must compute this mapping on the basis of what its correct
x86 emulation actually is.

>>
>>>>> Second, A function (computable or otherwise) is NOT a Turing Machine.
>>>>>
>>>>> Third, the domain of a computable function is NOT the same thing as
>>>>> the input (or set of possible inputs) to a Turing Machine.
>>>>>
>>>>
>>>> A computable function only includes inputs in the domain of the
>>>> function that can be encoded as finite strings.
>>>
>>> Computable functions don't "include" inputs at all. You are writing
>>> in gibberish.
>>
>>
>>     a function is computable if there exists an algorithm
>>     that can do the job of the function, i.e. given an
>>     input of the function domain it can return the corresponding
>>     output.
>
> And where does the above entail that computable functions "include" inputs?
>
> You need to actually understand a paragraph before you can use it to
> support a position. To do that you need to know the terminology used in
> the paragraph. You're still struggling with the latter so will never get
> to the former.
>
> André
>


--

[Richard Damon]

Says what?

And H^/P can be suitably encoded, you have shown a suitable encoding of P

>
> P(P) is suitably encoded as the actual machine language of P when
> directly executed as P(P) or emulated by H1(P,P).
>
> That its correct x86 emulation by H(P,P) differs from its correct x86
> emulation by H1(P,P) is simply an established fact.
>

By?

What changed the "Correct x86 emulaton"? Its the same program.

> H is not supposed to compute the mapping from its input to its accept or
> reject state on the basis of what you imagine its behavior should be.

Not "imagined", SPECIFIED.

>
> Instead it must compute this mapping on the basis of what its correct
> x86 emulation actually is.

And has been noted, CORRECT EMULATION shows HALTING.

Only H's INCORRECT (because it is incomplete) emulation shows
not-yet-halted, and its unsound/invalid logic deduced non-halting.

[André G. Isaak]

What that means is "input [to the algorithm] of [i.e. taken from] the
function domain".

>> not the function. Any arbitrary element of the functions domain can be
>> used as an input to the algorithm once suitably encoded.
>>
>
> Sure and if it can't be suitably encoded it is excluded.

But if there exist elements of the domain which cannot be suitably
encoded then we aren't dealing with a computable function in the first
place. By specifying that the function is computable it is implied that
*every* element of the domain *can* be suitably encoded.

> P(P) is suitably encoded as the actual machine language of P when
> directly executed as P(P) or emulated by H1(P,P).
>
> That its correct x86 emulation by H(P,P) differs from its correct x86
> emulation by H1(P,P) is simply an established fact.
>
> H is not supposed to compute the mapping from its input to its accept or
> reject state on the basis of what you imagine its behavior should be.
>
> Instead it must compute this mapping on the basis of what its correct
> x86 emulation actually is.

You really need to learn what the halting function (as opposed to a halt
decider -- you consistently confuse the two) actually is. A function
(computable or otherwise) is simply a *fixed* mapping from a domain to a
codomain. Crucially, a function exists *entirely* independently of any
Turing Machine, computer program, or any other type of algorithm.

When we ask whether a function is computable, we're asking whether an
algorithm exists which can compute that function, but the function IS
ALREADY THERE. THE MAPPING ALREADY EXISTS AND IS FIXED. The Mapping is
what it is regardless of which algorithm you use to compute it or
whether such an algorithm exists at all.

So if H(P, P) == false and H1(P, P) == true then either

(a) One of these is wrong, or

(b) H() and H1() are *not* computing the same function which means they
cannot *both* be halt deciders.

[olcott]

Thus mandating a bijection to finite strings.

[André G. Isaak]

There is no bijection (and bijections hold between things, not to
things). Every element of the function's domain can potentially be
encoded in an infinite number of different ways. And this has no
relevance to the particular confusion of yours that I was pointing out.

[olcott]

The simpler way around all this is to deduce that set of possible inputs
to a TM halt decider is the set of Turing machine descriptions.

This is fairly widely known as an aspect of the definition of a halt
decider.

[Richard Damon]

Right, so H can be given the description of ANY Turing Machine (even H^)
and an input for that, and needs to decide what that the Turing Machine
that input describes, applied to that input would do (Halt or Not) and
give the right answer to be correct.

THus H applied to <H^> <H^> has been given a VALID input, and needs to
output if H^ applied to <H^> would halt or not. (here <> means a
description of, being a finite string representation of the machine
within the <>s)

[olcott]

The ultimate measure of the behavior of an input its its correct
emulation. If the input to H(P,P) calls H(P,P) then P must actually call
H(P,P). If the fact that the input calls H(P,P) makes its correct x86
emulation never reach its "ret" instruction then this is the behavior
that H must report.

> THus H applied to <H^> <H^> has been given a VALID input, and needs to
> output if H^ applied to <H^> would halt or not.  (here <> means a
> description of, being a finite string representation of the machine
> within the <>s)

[Richard Damon]

Right, its CORRECT emulation (not neccessarily the emulation done by
that machine), which for a Halt Decider is the emulation done by a UTM.

For H(P,P) that is Halting if H(P,P) returns 0.

Until you actually provide a valid different definition, that is the
definition we need to use.

Why do you say that P calling H means it never gets to the ret instruction.

Are you saying that H will NEVER return? Then how does H(P,P) be correct
returning 0 if it never returns?

You have a problem there. Either H(P,P) returns 0, and thus P will halt,
or H(P,P) never returns, making P non-halting, but also making H fail to
answer.

Until you can show that H(P,P) can be an actual computation and do two
different actions on different calls with the same parameter (which
violates one of the first theorem of Computation Theory) you are just
showing that H isn't actually a computation, or is wrong.

People won't just take some handwaving for something like that, it needs
a REAL proof, and probably an actual example, FULLY spelled out and
shown how it executes.

Neither lets it be a counter example.

[olcott]

On 5/28/2022 11:25 AM, Malcolm McLean wrote:
> On Saturday, 28 May 2022 at 13:18:28 UTC+1, Andy Walker wrote:
>> On 28/05/2022 11:46, Mikko wrote:
>>> On 2022-05-28 08:41:42 +0000, Malcolm McLean said:
>> [... various restrictions ...]
>>>> Now, unless I've nodded, I ought to be able to produce a very simple Turing
>>>> machine which solves the halting problem for this domain.
>>> You must also exclude directly and indirectly recursive functions.
>>> In addition, the loop variable of a for loop must not be modified
>>> in the loop and its address must not be given to a function that
>>> does not promise to regard it as an address to a constant.
>> What the pair of you are saying is, in effect, that there is a
>> significant subset of programs which are guaranteed to halt, and for
>> which the HP is therefore trivial. Such programs even include many of
>> practical [eg engineering] interest. This is true, and uncontroversial.
>> There are also significant subsets of programs which are guaranteed not
>> to halt [at least in normal circumstances and short of hardware failure
>> or intervention]. But, no matter how you slice and dice, there is also
>> a substantial subset of programs whose behaviour cannot be determined
>> by an algorithmic examination of the code [inc input]; and the attack
>> on the HP via emulation and Busy Beavers shows clearly that a lot of
>> /very/ simple programs, and indeed problems, fall into this category.
>> [Not least because a UTM is a very simple program, and any complexity
>> relates to its input, which /could/ be a representation of a UTM and
>> /its/ input, which could be ....]
>>
>> As ever, although the HP is expressed in terms of halting, it
>> equally applies to problems such as "Does my program ever reach line
>> 23?", or "Does it ever produce any output?" or "Does it produce the
>> same output as your program?", which may be of more practical interest.
>> Yes, in line with what Malcolm is proposing, it's possible to produce
>> analysers, perhaps even of commercial interest, which often say useful
>> things about some code; but there are always areas of doubt, and
>> every time you explore one of these another can of worms opens up.
>>
>> A partial answer for practical programming lies in disciplined
>> code, with carefully designed pre- and post-conditions, etc., etc. But
>> that doesn't help with programs written without that discipline, and it
>> doesn't help to solve the Goldbach Conjecture.
>>
> PO seemed to be going down the route of saying that some programs
> are not in the domain of his halt decider. Whilst that prompted ridicule,
> it's not actually an inherently bad approach, depending what you want
> to achieve.


A halt decider must only compute the mapping from its input to an accept
or reject state based on the actual behavior specified by this input.

NON-INPUTS DO NOT COUNT
NON-INPUTS DO NOT COUNT
NON-INPUTS DO NOT COUNT

It is the case that the correct x86 emulation of the input to H(P,P) by
H would NEVER reach the "ret" instruction of P therefore H(P,P)==0 is
proved to be correct.

[Richard Damon]

And in what way is the "representation" or P/H^ not an input?

The problem is Given a representation, determine the halitng behavior.
Thus the behavior of the machine represented by the input not a
"non-input" but the goal of the decider itself. If it isn't, then it
isn't a Halt Decider.

"The Actual Behavior specified by this input" for H(M,w) is the behavior
of M(w) BY DEFINITION, so this CAN'T be just defined as a "NON-INPUT",
unless you want to just define that Halt Decider just can't exist.

FAIL.