On 2022-05-27 13:01, olcott wrote:
> On 5/27/2022 1:57 PM, Richard Damon wrote:

>> The input to H is NOT a "sequence of configuratios", but the
>> representation of an algorithm and its input.
>
> The finite string inputs to a halt decider specify (rather then merely
> represent) a sequence of configurations that may or may not reach their
> own final state.

I really don't think you have any idea what terms like 'represent',
'specify', or 'sequence of configurations' mean. Richard is perfectly
correct. You, as usual, are not.

Perhaps you can explain your own idiosyncratic usage of these terms.

André

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

On 27/05/2022 19:45, André G. Isaak wrote:
> 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.

Yes, but that applies to any uncountable set of elements, which
is not really an interesting reason why some functions are computable
and others aren't. So "prime" is computable [by general acclamation],
"halt" is not computable [for no /obvious/ reason, but by a theorem
that everyone with sufficient technical expertise accepts] [which is,
IMO, interesting], "heaviside" is uncomputable [as it's discontinuous,
which you may think interesting], and "sqrt" is uncomputable over the
reals [for an uninteresting reason] but computable over computable
reals [which is all you ever need for practical mathematics].

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

That is, by convention, what we normally mean by "computable";
there is a TM that will print those approximations as far as you want,
given sufficiently precise approximations of the parameter. [Further
details left to the imagination.]

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Goodban

On 2022-05-27 12:59, olcott wrote:
> 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).

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.

On 2022-05-27 13:16, Andy Walker wrote:
> On 27/05/2022 19:45, André G. Isaak wrote:
>> 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.
>
>     Yes, but that applies to any uncountable set of elements, which
> is not really an interesting reason why some functions are computable
> and others aren't.

Yes, I realise this. I never claimed there was anything terribly
interesting about this fact. For Olcott, we must start with very basic
things.

He seems to think that you can't represent the C function P(P) as a
finite string despite the fact that he presumably has some finite C
source code for this C function.

I'm trying to show him a case where it *really* isn't possible to encode
all inputs as finite strings even though this isn't normally the barrier
to computability that people are interested in.

André

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

On 27/05/2022 19:54, olcott wrote:
> On 5/27/2022 1:37 PM, Andy Walker wrote:
>> [...] The reason
>> for the failure is that most [indeed, almost all] real numbers are not
>> computable.
> Yes I was going to make this same point.
> Many of these are not computable because they have no exactly correct
> representation as a finite string.

No, no; or, at least, misleading. You may be thinking of numbers
such as "sqrt(2)"; this has no representation as an exact decimal or even
rational string, but it does have the exact representation "sqrt(2)", which
[together with properties such as monotonicity] tells you all you ever need
to know about the square root of 2 [viz that its square is 2]. OTOH, the
number "H", whose nth binary digit is 0 if the nth TM in some enumeration
halts when started with a blank tape and 1 if it doesn't, is not computable
[as if it was, we could use it to solve the halting problem], even though
it has an exact representation [which I've just given you]. It's all a
bit of a minefield.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Goodban

On 5/27/2022 2:16 PM, Andy Walker wrote:
> On 27/05/2022 19:45, André G. Isaak wrote:
>> 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.
>
>     Yes, but that applies to any uncountable set of elements, which
> is not really an interesting reason why some functions are computable
> and others aren't.  So "prime" is computable [by general acclamation],
> "halt" is not computable [for no /obvious/ reason, but by a theorem
> that everyone with sufficient technical expertise accepts] [which is,

When understood in the context of my work the HP counter-example pattern
is computable:

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

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
}

Halting problem undecidability and infinitely nested simulation (V5)

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

> IMO, interesting], "heaviside" is uncomputable [as it's discontinuous,
> which you may think interesting], and "sqrt" is uncomputable over the
> reals [for an uninteresting reason] but computable over computable
> reals [which is all you ever need for practical mathematics].
>
>> (And Newton-Raphson doesn't allow you to compute square roots; it
>> allows you to compute arbitrarily precise approximations of those
>> roots).
>
>     That is, by convention, what we normally mean by "computable";
> there is a TM that will print those approximations as far as you want,
> given sufficiently precise approximations of the parameter.  [Further
> details left to the imagination.]
>

--
Copyright 2022 Pete Olcott

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

On 5/27/2022 2:31 PM, Andy Walker wrote:
> On 27/05/2022 19:54, olcott wrote:
>> On 5/27/2022 1:37 PM, Andy Walker wrote:
>>> [...] The reason
>>> for the failure is that most [indeed, almost all] real numbers are not
>>> computable.
>> Yes I was going to make this same point.
>> Many of these are not computable because they have no exactly correct
>> representation as a finite string.
>
>     No, no;  or, at least, misleading.  You may be thinking of numbers
> such as "sqrt(2)";  this has no representation as an exact decimal or even
> rational string, but it does have the exact representation "sqrt(2)", which

You are assuming a TM that can understand English, I am not assuming this.

> [together with properties such as monotonicity] tells you all you ever need
> to know about the square root of 2 [viz that its square is 2].  OTOH, the
> number "H", whose nth binary digit is 0 if the nth TM in some enumeration
> halts when started with a blank tape and 1 if it doesn't, is not computable
> [as if it was, we could use it to solve the halting problem], even though
> it has an exact representation [which I've just given you].  It's all a
> bit of a minefield.
>

--
Copyright 2022 Pete Olcott

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>
> 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.

> But basically PO is trying to argue that H_Hat is an invalid input,
> on the analogue that a sentence like "this sentence is false" isn't
> a valid sentence.

That one comes and goes and my response depends on the context. For any
actual procedure or function F (and at the moment he is claiming to have
a some actual code) we can construct the "hat" version. Asking whether
that trivially modified version of F halts when passed its own address
it clearly not at all an invalid, nor, as it happens, is the result in
doubt. In fact PO has posted a trace of that execution and it halts.
What's more, he has repeatedly stated that H(H_Hat, H_Hat) == 0 /even
though/ H_Hat(H_Hat) halts.

He /used/ to tout this objection in a more general way, suggesting that
there are invalid halting questions that have no correct answer. My
response to that was to explain that every instance of the halting
problem has a correct yes/no answer. It took years to get PO to agree
to this trivial fact, and even then the agreement was not wholehearted.

But then there is the case of the H/H_Hat in the proof. PO used to
claim (and almost certainly will claim again somewhere down the line)
that H_Hat(H_Hat) is in some way "an unanswerable question" because of
the what the proof says. But in the /this/ context, there is no
question because there is no H from which H_Hat can be formed. The
argument in the proof is entirely hypothetical.

> He then makes the observation that a simulating halt decider will
> be thrown into infinitely nested simulations by H_Hat.

Why, when he says things like this do you not explain what's wrong with
using words like this?

A /simulator/ goes into a loop in this situation, but no decider can --
by definition. A decider always halts on any input. If he were
interested in an honest exchange of views, he would choose his words
better. A decider that does some simulation can't go into a loop in
this situation of it is not a decider.

> So its own
> behaviour is what is problematical, not the "invert the answer"
> step.
> I can't quite follow his next step of reasoning, which seems to be
> that because H aborts itself (the simulated copy of itself which it
> is running, which in PO's system is the icntical same physical
> machine code), the abort doesn't count as part of the behavior of
> the input. So "Non-halting" is correct even though H_Hat halts.
> PO will probably come in here as a mischaracterisation of his
> position.

I think you are being rather generous. For the last few years, PO's
goal has been entirely linguistic: can he find some phrasing that makes
what he's saying should just about plausible without saying enough for
it be obviously wrong. That's what the deliberately unexplained
"correct simulation of the inputs to H(P,P)" nonsense is all about.

Some time ago he was much clearer: H(H_Hat, H_Hat) == 0 is correct
because of what would happen if H didn't do what H does. He even
sketched out the code and explained that 0 is the right answer because
of what would happen if line 15 were commented out. But that's way too
clear and obviously bogus. We then had a whole sequence of convoluted
circumlocutions trying to say that without being clear about it. The
latest mantra is more of the same. The simulation would not end if it
were not ended so it's correct to declare it unending.

Of course, PO being PO, there a side errors as well. For example, the
whole "H_Hat(H_Hat) is not an input" and TMs can only decide on inputs
silliness and the claim that the fact that a computation halts does not
prove it is a halting computation.

> A simulator is a perfectly reasonable program to write, and there are
> many practical simulators. Adding a bit of simple loop detection to
> a simulator is also a reasonable thing to do, and might be of practical
> value. However it's not of much theoretical value, because however
> complicated you make the loop detection, there will always be some
> examples of unterminating loops it fails to catch.

In a way, that's a side issue. PO has the problem that any partial
decider will be wrong about some correctly constructed input.

> I'm sceptical that PO's H detects nested simulation rather than recursion,
> partly because he himself said it was infinite recursion before I pointed
> out that it was not, and partly because nested simulation is more
> challenging to detect, and he hasn't been forthcoming on how it is
> achieved. But since has hasn't yet made H available, there's no way of
> knowing.

I don't see how it matters. It can be 100% correct at detecting
/something/, but the Hat construction will exhibit an "input" it's wrong
about (as far as the rest of the world is concerned).

Part of PO's skill is in taking people down irrelevant error strewn
rabbit holes. The traces are a classic example. What they show is
irrelevant, since H is wrong by definition. I'm not sure why the only
answer to a PO post isn't simply that H is wrong according to PO's own
statements about H(H_Hat, H_Hat) and H_Hat(H_Hat).

> As for the "H_Hat is a form of invalid speech" argument, I don't
> really understand the philosophy of maths, but I don't see it myself.

I'm not sure he's said exactly that, but you are right think the related
things he's said are nonsense. There is no H_Hat (as defined by, say,
Linz), so nothing of or about it can be valid or invalid. And for any
/actual/ bit of code, F, F_Hat can be constructed and F_Hat(F_Hat) will
either halt or not, but nothing about asking that question is invalid in
any way.

--
Ben.

On 5/27/2022 2:10 PM, André G. Isaak wrote:
> On 2022-05-27 13:01, olcott wrote:
>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>
>>> The input to H is NOT a "sequence of configuratios", but the
>>> representation of an algorithm and its input.
>>
>> The finite string inputs to a halt decider specify (rather then merely
>> represent) a sequence of configurations that may or may not reach
>> their own final state.
>
> I really don't think you have any idea what terms like 'represent',
> 'specify', or 'sequence of configurations' mean. Richard is perfectly
> correct. You, as usual, are not.
>

The distinction that I make between represent and specify is that the
x86 source-code for P represents P(P) whereas the actual correct x86
emulation of the input to H(P,P) specifies the actual behavior of this
input. This is not the same behavior as the behavior specified by P(P).

A sequence of configurations means a list of x86 program steps executed
or emulated in the order that their source-code specifies.

Likewise with a TM or the UTM simulation of a TM description specifies a
sequence of state transitions.

This is more general than a computation in that every computation must
reach its own final state.

> Perhaps you can explain your own idiosyncratic usage of these terms.
>
> André
>

--
Copyright 2022 Pete Olcott

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

On 5/27/2022 2:18 PM, André G. Isaak wrote:
> On 2022-05-27 12:59, olcott wrote:
>> 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).
>
> Either something is encodable as a finite string or it isn't.

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

--
Copyright 2022 Pete Olcott

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

On 5/27/22 2:59 PM, olcott wrote:
> 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.
>
>

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.

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

On 5/27/2022 2:37 PM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>
>> 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.

>> But basically PO is trying to argue that H_Hat is an invalid input,
>> on the analogue that a sentence like "this sentence is false" isn't
>> a valid sentence.
>

I haven't had that view for a few years.

> That one comes and goes and my response depends on the context. For any
> actual procedure or function F (and at the moment he is claiming to have
> a some actual code) we can construct the "hat" version. Asking whether
> that trivially modified version of F halts when passed its own address
> it clearly not at all an invalid, nor, as it happens, is the result in
> doubt. In fact PO has posted a trace of that execution and it halts.
> What's more, he has repeatedly stated that H(H_Hat, H_Hat) == 0 /even
> though/ H_Hat(H_Hat) halts.
>

The actual correct x86 emulation of the input to H(P,P) specifies the
actual behavior of this input. This is not the same behavior as the
actual behavior specified by P(P).

> He /used/ to tout this objection in a more general way, suggesting that
> there are invalid halting questions that have no correct answer. My
> response to that was to explain that every instance of the halting
> problem has a correct yes/no answer. It took years to get PO to agree
> to this trivial fact, and even then the agreement was not wholehearted.
>
> But then there is the case of the H/H_Hat in the proof. PO used to
> claim (and almost certainly will claim again somewhere down the line)
> that H_Hat(H_Hat) is in some way "an unanswerable question" because of
> the what the proof says. But in the /this/ context, there is no
> question because there is no H from which H_Hat can be formed. The
> argument in the proof is entirely hypothetical.
>

H1(P,P)==1 is provably correct and H(P,P)==0 is provably correct.
The response should be: (a) lets see the proof and then (b) OK you are
correct.

That this is not the response seems to prove that my reviewers have no
intention what-so-ever for any honest dialogue.

My reviewers keep assuming that when their intuition contradicts the x86
language that the x86 language is wrong.

--
Copyright 2022 Pete Olcott

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

On 5/27/22 3:01 PM, olcott wrote:
> On 5/27/2022 1:57 PM, Richard Damon wrote:
>> On 5/27/22 1:20 PM, olcott wrote:
>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>
>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>>>>>
>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>> a valid sentence.
>>>>>
>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>> or the current way of saying that input to H(P,P) specifies
>>>>> behavior to H that would never reach its under its correct x86
>>>>> emulation by H.
>>>>
>>>> But the question isn't does *H* reach the final state of the input
>>>> in its processing, it is does the computation the input represents
>>>> reach its final state.
>>>>
>>>> You are just admitting to trying to answer the WRONG question.
>>>
>>> Does the correct simulation of the input to H(P,P) ever reach its
>>> "ret" instruction? No, therfore non-halting.
>>>
>>>>
>>>>>
>>>>> _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]
>>>>>
>>>>> When the above is correctly emulated by H the first seven
>>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>>> emulate the first seven instructions again. This infinite emulation
>>>>> never stops unless aborted. Whether or not it is aborted the
>>>>> emulated P never reaches its "ret" instruction thus never halts.
>>>>> The H(P,P)==0 is proved to be correct.
>>>>>
>>>>
>>>> But H can't correctly emulate all of the input, and give an answer.
>>>> That is your problem
>>>>
>>>
>>> The set of valid inputs to the algorithm that computes the halt
>>> status of its inputs is the set of sequences of configurations that
>>> can be encoded as finite string inputs to H.
>>>
>>>
>>
>> The input to H is NOT a "sequence of configuratios", but the
>> representation of an algorithm and its input.
>
> The finite string inputs to a halt decider specify (rather then merely
> represent) a sequence of configurations that may or may not reach their
> own final state.

And there is no requirement that a finite string representation yields a
finite sequence of configuarions for that machine.

If it did, then ALL compuations would halt.

The input to H is a representation of a machine/algorithm and its input.

The x86 byte string for ALL of the program P meets your definition of an
input to H, and thus P,P is in the domain of H.

It may be that H can't correctly compute the results of that input, but
that is the question of the problem (and in fact, we know it can't).

The fact that H can't answer the question correctly (and will either go
into a infinite loop or return a wrong answer) doesn't give it a "Get
out of Jail Free" card to avoid the question, it just makes it WRONG,
and thus not the required counter example.

>
>>
>> Sounds like your H isn't even close to being a Halt Decider.
>>
>> Seems like you really don't understand a thing that you are talking
>> about but just word jumbling from stuff you have read,
>>
>> H takes in a finite string that represents the compuation it is to
>> decider on. That exists, as in your example, that string can be the
>> binary code of ALL the memory that the function P will execute (that
>> is the code of P, H, and all that H calls). Since you claim this
>> program exists, there is a finite string that represents it, or you
>> couldn't run it.
>>
>> H, when it runs, creates a sequence of configurations as it progresses
>> through its processing, but that sequence isn't the "input" to H, it
>> is the processing of H.
>>
>> Since the program P can be fully expressed as a finite string to H, as
>> can its input (another copy of that exact same input), then H can
>> definitely be given the string that represent the computation P(P),
>> via the pointers P and P (with the proper interpretation of those
>> pointers providing access to all that representation).
>>
>> This means that you claim that P(P) can't be an input is just FALSE,
>> it is fully representable to H.
>>
>> THe problem is that H can't actually compute the needed results,
>> because it will take an infinite number of steps, which just shows
>> that Halting is NOT a Computable Funcition, which is exactly what the
>> Theorem says.
>>
>> You are just proving how stupid you are, and how much your statements
>> are based on lying.
>
>

On 5/27/2022 2:46 PM, Richard Damon wrote:
> On 5/27/22 2:59 PM, olcott wrote:
>> 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.
>>
>>
>
> 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.
>

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

--
Copyright 2022 Pete Olcott

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

On 5/27/22 3:53 PM, olcott wrote:
> On 5/27/2022 2:37 PM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>>
>>> 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.

>
>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>> on the analogue that a sentence like "this sentence is false" isn't
>>> a valid sentence.
>>
>
> I haven't had that view for a few years.

Nope, you keep on saying that P(P) isn't in the range of H.

>
>> That one comes and goes and my response depends on the context.  For any
>> actual procedure or function F (and at the moment he is claiming to have
>> a some actual code) we can construct the "hat" version.  Asking whether
>> that trivially modified version of F halts when passed its own address
>> it clearly not at all an invalid, nor, as it happens, is the result in
>> doubt.  In fact PO has posted a trace of that execution and it halts.
>> What's more, he has repeatedly stated that H(H_Hat, H_Hat) == 0 /even
>> though/ H_Hat(H_Hat) halts.
>>
>
> The actual correct x86 emulation of the input to H(P,P) specifies the
> actual behavior of this input. This is not the same behavior as the
> actual behavior specified by P(P).

Why not? they are the exact same input to the x86 processor?

Do YOU have a CPU that behaves diffferently for different programs?

Or, is the problem that H doesn't meet the requirements of being a
Computation, and gives different behaviors for the same input under
different conditions (that are not inputs to the function).

>
>> He /used/ to tout this objection in a more general way, suggesting that
>> there are invalid halting questions that have no correct answer.  My
>> response to that was to explain that every instance of the halting
>> problem has a correct yes/no answer.  It took years to get PO to agree
>> to this trivial fact, and even then the agreement was not wholehearted.
>>
>> But then there is the case of the H/H_Hat in the proof.  PO used to
>> claim (and almost certainly will claim again somewhere down the line)
>> that H_Hat(H_Hat) is in some way "an unanswerable question" because of
>> the what the proof says.  But in the /this/ context, there is no
>> question because there is no H from which H_Hat can be formed.  The
>> argument in the proof is entirely hypothetical.
>>
>
> H1(P,P)==1 is provably correct and H(P,P)==0 is provably correct.
> The response should be: (a) lets see the proof and then (b) OK you are
> correct.

BY WHAT DEFINITIONO.

I say, YOU LIE.

We have asked for (a) Lets see the proof, and none has been given, just
spurious claims with NO proof.

>
> That this is not the response seems to prove that my reviewers have no
> intention what-so-ever for any honest dialogue.
>
> My reviewers keep assuming that when their intuition contradicts the x86
> language that the x86 language is wrong.
>
>

Just shows how little you value the truth when you can't even describe
correctly what has been goiing on in the view of the public.

The x86 says that the input to H(P,P) behaves identical to P(P), unless
you want to try to actually explain, based on the properties of the
actual x86 process, what is different.

The ONLY optiion that make sense so far is that you lie that H is a
computatation, and that H(P,P) behaves differently based on conditions
that don't actually affect the input to the funcition.

You have in fact, state that you don't believe it needs to, but have
offered NO proof of that claim.

That is like saying you can PROVE that RED is BLUE, but people will just
need to trust you.

FAIL, IDIOT.

On 5/27/2022 2:54 PM, Richard Damon wrote:
> On 5/27/22 3:01 PM, olcott wrote:
>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>> On 5/27/22 1:20 PM, olcott wrote:
>>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>>
>>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>>>>>>
>>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>>> a valid sentence.
>>>>>>
>>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>>> or the current way of saying that input to H(P,P) specifies
>>>>>> behavior to H that would never reach its under its correct x86
>>>>>> emulation by H.
>>>>>
>>>>> But the question isn't does *H* reach the final state of the input
>>>>> in its processing, it is does the computation the input represents
>>>>> reach its final state.
>>>>>
>>>>> You are just admitting to trying to answer the WRONG question.
>>>>
>>>> Does the correct simulation of the input to H(P,P) ever reach its
>>>> "ret" instruction? No, therfore non-halting.
>>>>
>>>>>
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> When the above is correctly emulated by H the first seven
>>>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>>>> emulate the first seven instructions again. This infinite
>>>>>> emulation never stops unless aborted. Whether or not it is aborted
>>>>>> the emulated P never reaches its "ret" instruction thus never
>>>>>> halts. The H(P,P)==0 is proved to be correct.
>>>>>>
>>>>>
>>>>> But H can't correctly emulate all of the input, and give an answer.
>>>>> That is your problem
>>>>>
>>>>
>>>> The set of valid inputs to the algorithm that computes the halt
>>>> status of its inputs is the set of sequences of configurations that
>>>> can be encoded as finite string inputs to H.
>>>>
>>>>
>>>
>>> The input to H is NOT a "sequence of configuratios", but the
>>> representation of an algorithm and its input.
>>
>> The finite string inputs to a halt decider specify (rather then merely
>> represent) a sequence of configurations that may or may not reach
>> their own final state.
>
> And there is no requirement that a finite string representation yields a
> finite sequence of configuarions for that machine.
>

There is a requirement that a finite string specifies a sequence of
configurations for the machine.

--
Copyright 2022 Pete Olcott

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

On 2022-05-27 13:41, olcott wrote:
> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>> On 2022-05-27 13:01, olcott wrote:
>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>
>>>> The input to H is NOT a "sequence of configuratios", but the
>>>> representation of an algorithm and its input.
>>>
>>> The finite string inputs to a halt decider specify (rather then
>>> merely represent) a sequence of configurations that may or may not
>>> reach their own final state.
>>
>> I really don't think you have any idea what terms like 'represent',
>> 'specify', or 'sequence of configurations' mean. Richard is perfectly
>> correct. You, as usual, are not.
>>
>
> The distinction that I make between represent and specify is that the
> x86 source-code for P represents P(P) whereas the actual correct x86
> emulation of the input to H(P,P) specifies the actual behavior of this
> input. This is not the same behavior as the behavior specified by P(P).
>
> A sequence of configurations means a list of x86 program steps executed
> or emulated in the order that their source-code specifies.
>
> Likewise with a TM or the UTM simulation of a TM description specifies a
> sequence of state transitions.

And this decidedly is *not* what a halt decider is given as its input.
It is not given a sequence of state transitions. It is given a
representation of a computation.

If it were given a sequence of state transitions as its input, then it
would only be possible to ask it about finite computations which would
entirely defeat the purpose of having a halt decider.

> This is more general than a computation in that every computation must
> reach its own final state.

You keep conflating two entirely different definitions which Linz gave
in entirely different contexts. When talking about halting, it is *not*
the case that every computation must reach a final state. Otherwise
there would be no halting problem to discuss.

Words often have different definitions in different fields, or even in
different subfields. You seem to have serious problems with this
concept. When using a term you must consider only the *relevant* definition.

André

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

On 5/27/22 3:58 PM, olcott wrote:
> On 5/27/2022 2:46 PM, Richard Damon wrote:
>> On 5/27/22 2:59 PM, olcott wrote:
>>> 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.
>>>
>>>
>>
>> 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.
>>
>
> 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.

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.

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

On 5/27/22 4:03 PM, olcott wrote:
> On 5/27/2022 2:54 PM, Richard Damon wrote:
>> On 5/27/22 3:01 PM, olcott wrote:
>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>> On 5/27/22 1:20 PM, olcott wrote:
>>>>> On 5/27/2022 12:00 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 5/27/22 11:54 AM, olcott wrote:
>>>>>>> On 5/27/2022 4:36 AM, Malcolm McLean wrote:
>>>>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>>>>>>>
>>>>>>>> I can't follow all the arguments, and they seem to shift over time.
>>>>>>>> But basically PO is trying to argue that H_Hat is an invalid input,
>>>>>>>> on the analogue that a sentence like "this sentence is false" isn't
>>>>>>>> a valid sentence.
>>>>>>>
>>>>>>> No that is not what I am saying. I am saying that H(H_Hat, H_Hat)
>>>>>>> or the current way of saying that input to H(P,P) specifies
>>>>>>> behavior to H that would never reach its under its correct x86
>>>>>>> emulation by H.
>>>>>>
>>>>>> But the question isn't does *H* reach the final state of the input
>>>>>> in its processing, it is does the computation the input represents
>>>>>> reach its final state.
>>>>>>
>>>>>> You are just admitting to trying to answer the WRONG question.
>>>>>
>>>>> Does the correct simulation of the input to H(P,P) ever reach its
>>>>> "ret" instruction? No, therfore non-halting.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> When the above is correctly emulated by H the first seven
>>>>>>> instructions are emulated then P calls H(P,P) which causes H to
>>>>>>> emulate the first seven instructions again. This infinite
>>>>>>> emulation never stops unless aborted. Whether or not it is
>>>>>>> aborted the emulated P never reaches its "ret" instruction thus
>>>>>>> never halts. The H(P,P)==0 is proved to be correct.
>>>>>>>
>>>>>>
>>>>>> But H can't correctly emulate all of the input, and give an
>>>>>> answer. That is your problem
>>>>>>
>>>>>
>>>>> The set of valid inputs to the algorithm that computes the halt
>>>>> status of its inputs is the set of sequences of configurations that
>>>>> can be encoded as finite string inputs to H.
>>>>>
>>>>>
>>>>
>>>> The input to H is NOT a "sequence of configuratios", but the
>>>> representation of an algorithm and its input.
>>>
>>> The finite string inputs to a halt decider specify (rather then
>>> merely represent) a sequence of configurations that may or may not
>>> reach their own final state.
>>
>> And there is no requirement that a finite string representation yields
>> a finite sequence of configuarions for that machine.
>>
>
> There is a requirement that a finite string specifies a sequence of
> configurations for the machine.
>
>
>

WHERE?

The requirement for the execution of the decider to be finite is on the
DECIDER, not the input.

If H doesn't have finite behavior on some inputs, that means H fails,
not that the input isn't allowed.

You fail basic requirements understanding.

PROOF INVALID.

On 2022-05-27 13:58, olcott wrote:
> On 5/27/2022 2:46 PM, Richard Damon wrote:
>> On 5/27/22 2:59 PM, olcott wrote:
>>> 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.
>>>
>>>
>>
>> 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.
>>
>
> Not at all. Halt deciders have sequences of configurations encoded as
> finite strings as the domain of their computable function.

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'

André

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

On 5/27/2022 3:02 PM, Richard Damon wrote:
>
> On 5/27/22 3:53 PM, olcott wrote:
>> On 5/27/2022 2:37 PM, Ben wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>>>
>>>> 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

--
Copyright 2022 Pete Olcott

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

On 5/27/2022 3:06 PM, André G. Isaak wrote:
> On 2022-05-27 13:41, olcott wrote:
>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>> On 2022-05-27 13:01, olcott wrote:
>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>
>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>> representation of an algorithm and its input.
>>>>
>>>> The finite string inputs to a halt decider specify (rather then
>>>> merely represent) a sequence of configurations that may or may not
>>>> reach their own final state.
>>>
>>> I really don't think you have any idea what terms like 'represent',
>>> 'specify', or 'sequence of configurations' mean. Richard is perfectly
>>> correct. You, as usual, are not.
>>>
>>
>> The distinction that I make between represent and specify is that the
>> x86 source-code for P represents P(P) whereas the actual correct x86
>> emulation of the input to H(P,P) specifies the actual behavior of this
>> input. This is not the same behavior as the behavior specified by P(P).
>>
>> A sequence of configurations means a list of x86 program steps
>> executed or emulated in the order that their source-code specifies.
>>
>> Likewise with a TM or the UTM simulation of a TM description specifies
>> a sequence of state transitions.
>
> And this decidedly is *not* what a halt decider is given as its input.
> It is not given a sequence of state transitions. It is given a
> representation of a computation.
>

No it is not and you know that it is not. A halt decider is given a
finite string TM description that specifies a sequence of configurations.

--
Copyright 2022 Pete Olcott

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

On 5/27/22 4:21 PM, olcott wrote:
> On 5/27/2022 3:02 PM, Richard Damon wrote:
>>
>> On 5/27/22 3:53 PM, olcott wrote:
>>> On 5/27/2022 2:37 PM, Ben wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On Thursday, 26 May 2022 at 12:21:07 UTC+1, 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"?
>>>>>>
>>>>> 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.

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.

On 5/27/2022 3:19 PM, André G. Isaak wrote:
> On 2022-05-27 13:58, olcott wrote:
>> On 5/27/2022 2:46 PM, Richard Damon wrote:
>>> On 5/27/22 2:59 PM, olcott wrote:
>>>> 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.
>>>>
>>>>
>>>
>>> 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.
>>>
>>
>> Not at all. Halt deciders have sequences of configurations encoded as
>> finite strings as the domain of their computable function.
>
> This is an entirely mangled sentence. You really need to go back to the
> basics:
>
> First, a Turing Machine is *NOT* a computable function.
>

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

--
Copyright 2022 Pete Olcott

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

On 5/27/22 4:38 PM, olcott wrote:
> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>> On 2022-05-27 13:41, olcott wrote:
>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>> On 2022-05-27 13:01, olcott wrote:
>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>
>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>> representation of an algorithm and its input.
>>>>>
>>>>> The finite string inputs to a halt decider specify (rather then
>>>>> merely represent) a sequence of configurations that may or may not
>>>>> reach their own final state.
>>>>
>>>> I really don't think you have any idea what terms like 'represent',
>>>> 'specify', or 'sequence of configurations' mean. Richard is
>>>> perfectly correct. You, as usual, are not.
>>>>
>>>
>>> The distinction that I make between represent and specify is that the
>>> x86 source-code for P represents P(P) whereas the actual correct x86
>>> emulation of the input to H(P,P) specifies the actual behavior of
>>> this input. This is not the same behavior as the behavior specified
>>> by P(P).
>>>
>>> A sequence of configurations means a list of x86 program steps
>>> executed or emulated in the order that their source-code specifies.
>>>
>>> Likewise with a TM or the UTM simulation of a TM description
>>> specifies a sequence of state transitions.
>>
>> And this decidedly is *not* what a halt decider is given as its input.
>> It is not given a sequence of state transitions. It is given a
>> representation of a computation.
>>
>
> No it is not and you know that it is not. A halt decider is given a
> finite string TM description that specifies a sequence of configurations.
>

So, you don't even know how to parse English.

Look at your sentence, what was the Halt Decider Given:

[a finite string TM description]

and what does the Decider do with that:

[that specifies a sequence of cnfigurations]

The input is JUST "A finite String TM Description", that is ALL the
input is.

yes, as a computation, when we run that TM described (with the input) we
get a sequence of state transistion, that the decider needs to figure
out if it will be a finite sequence (because the TM halted) or an
infinite sequence (because it didn't).

Giving H the input P,P does EXACTLY THAT.

The input exactly specifies what the behavior is of the computation, and
H has to be a computation and thus have a FIXED, DEFINED, algorithm of
what it does.

If that algorith DOES abort it simulation of that input, then when we
look at the sequence of configurations the input actually specifies, we
see it tracing through all the steps that H went through to make that
decision, then it aborting its processing, and returning to P and P halting.

Thus the string of configurations that the input specifies is FINITE,
and thus HALTING.

Now, H can't actually simulate the input that far, because the number of
steps that H uses to decide is more than the number of steps of its
input it processes, so it needs to decide somehow what to do.

The designer of H has a couple of options.

1) They can make H refuse to be wrong, and keep on simulating until H
actually CAN prove that the input either Halts or will never halt, and n
that case, H will just never halt and fails to decide, and thus fails to
be a decider.

2) They can choose a pattern that is in the simulation, and presume
(incorrectly) that this pattern indicates non-halting behavior, which
seems to be what you have done, and then we get the case above, that
pattern is shown to NOT conclusively prove non-halting, as P will
generate that pattern and the later halt.

3) An option you haven't tried, is to choose a pattern in the
simulation, and presume (incorrectly) that this pattern will lead to
HALTING behavior, at which point the pattern is proved wrong as in the
above case, P will get the answer and enter a tight loop.

THERE IS NO RIGHT ANSWER FOR H.

The input is absolutely correcct, H just can not correctly simulate that
input and give an answer in finite time and be correct, because P will
be contrary.