On 5/24/22 5:34 PM, olcott wrote:
On 5/24/2022 4:27 PM, Mr Flibble wrote:
On Tue, 24 May 2022 16:12:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/24/2022 3:54 PM, Mr Flibble wrote:
On Tue, 24 May 2022 09:40:02 -0500
olcott <NoOne@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
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.
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.
On 5/24/2022 8:12 PM, Richard Damon wrote:
On 5/24/22 5:34 PM, olcott wrote:
On 5/24/2022 4:27 PM, Mr Flibble wrote:
On Tue, 24 May 2022 16:12:13 -0500
olcott <NoOne@NoWhere.com> wrote:
On 5/24/2022 3:54 PM, Mr Flibble wrote:
On Tue, 24 May 2022 09:40:02 -0500
olcott <NoOne@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
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.
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.
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.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 25/05/2022 19:42, Ben wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
It's true we don't know the details of how PO is doing this, but weHmm... If I had to guess I'd put some store in a few phrases he's
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.
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.
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.
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.
So the purpose of all the complicated and semi-secret H code isThe original purpose was to backtrack on the claim, made I think in a
ultimately just to give PO some excuse to confuse himself!
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...
On 5/25/2022 8:15 PM, Ben wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 25/05/2022 19:42, Ben wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
It's true we don't know the details of how PO is doing this, but weHmm... If I had to guess I'd put some store in a few phrases he's
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.
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...
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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"?
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.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
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,
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
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,
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.
On 5/26/22 11:06 PM, olcott wrote:
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
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,
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.
On 5/27/2022 7:50 AM, Richard Damon wrote:
On 5/26/22 11:06 PM, olcott wrote:
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
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,
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.
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.
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.
On 5/27/22 11:24 AM, olcott wrote:
On 5/27/2022 7:50 AM, Richard Damon wrote:
On 5/26/22 11:06 PM, olcott wrote:
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
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,
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.
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.
But it DOES have the representation of P, so it can map it.
On 5/27/2022 10:53 AM, Richard Damon wrote:
On 5/27/22 11:24 AM, olcott wrote:The correctly simulated input to H(P,P)==0
On 5/27/2022 7:50 AM, Richard Damon wrote:
On 5/26/22 11:06 PM, olcott wrote:
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:No, it only CAN compute what can be determined by its processing
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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. >>>>>>
of the input, but a "something" decider MUST compute the
"something" mapping defined,
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.
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.
But it DOES have the representation of P, so it can map it.
The correctly simulated input to H1(P,P)==1
On 5/27/22 12:06 PM, olcott wrote:I know exactly how. When I explain exactly how my reviewers brains short-circuit and they become utterly confused.
On 5/27/2022 10:53 AM, Richard Damon wrote:
On 5/27/22 11:24 AM, olcott wrote:The correctly simulated input to H(P,P)==0
On 5/27/2022 7:50 AM, Richard Damon wrote:
On 5/26/22 11:06 PM, olcott wrote:
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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.
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,
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.
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.
But it DOES have the representation of P, so it can map it.
The correctly simulated input to H1(P,P)==1
HOW?
It is the same input, so has the same correct simulation.
On 5/27/2022 12:03 PM, Richard Damon wrote:
On 5/27/22 12:06 PM, olcott wrote:I know exactly how. When I explain exactly how my reviewers brains short-circuit and they become utterly confused.
On 5/27/2022 10:53 AM, Richard Damon wrote:
On 5/27/22 11:24 AM, olcott wrote:The correctly simulated input to H(P,P)==0
On 5/27/2022 7:50 AM, Richard Damon wrote:
On 5/26/22 11:06 PM, olcott wrote:
On 5/26/2022 9:50 PM, Richard Damon wrote:
On 5/26/22 9:35 AM, olcott wrote:You just contradicted yourself.
On 5/26/2022 6:21 AM, Ben wrote:
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:There's no reason at all to think that H is /not/ correct. >>>>>>>>>> But since H
To me, that's what retains the interest.
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.
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. >>>>>>>>>>
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.
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,
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.
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.
But it DOES have the representation of P, so it can map it.
The correctly simulated input to H1(P,P)==1
HOW?
It is the same input, so has the same correct simulation.
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.
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.
(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 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é
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 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).
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é
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é
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.
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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 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.
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:I can't follow all the arguments, and they seem to shift over time.
On Thursday, 26 May 2022 at 02:15:36 UTC+1, Ben wrote:
To me, that's what retains the interest.
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.
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 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
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:
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:
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.
On 2022-05-27 15:04, olcott wrote:
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.
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.
André
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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.
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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*
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.
André
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the above
paragraph it is the algorithm which has an input,
*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é
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the above
paragraph it is the algorithm which has an input,
*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.
On 2022-05-27 16:01, olcott wrote:Thus mandating a bijection to finite strings.
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the above
paragraph it is the algorithm which has an input,
*input of the function domain*
What that means is "input [to the algorithm] of [i.e. taken from] the function domain".
On 5/27/2022 5:15 PM, André G. Isaak wrote:
On 2022-05-27 16:01, olcott wrote:Thus mandating a bijection to finite strings.
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the above
paragraph it is the algorithm which has an input,
*input of the function domain*
What that means is "input [to the algorithm] of [i.e. taken from] the
function domain".
On 2022-05-27 16:20, olcott wrote:
On 5/27/2022 5:15 PM, André G. Isaak wrote:
On 2022-05-27 16:01, olcott wrote:Thus mandating a bijection to finite strings.
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the
above paragraph it is the algorithm which has an input,
*input of the function domain*
What that means is "input [to the algorithm] of [i.e. taken from] the
function domain".
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.
André
On 5/27/2022 5:31 PM, André G. Isaak wrote:
On 2022-05-27 16:20, olcott wrote:
On 5/27/2022 5:15 PM, André G. Isaak wrote:
On 2022-05-27 16:01, olcott wrote:Thus mandating a bijection to finite strings.
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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 numbersUm. This is technically true, but [IMO] misleading. >>>>>>>>>>>>>>> The reason
(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. >>>>>>>>>>>>>>>
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the
above paragraph it is the algorithm which has an input,
*input of the function domain*
What that means is "input [to the algorithm] of [i.e. taken from]
the function domain".
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.
André
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.
On 5/27/22 6:52 PM, olcott wrote:
On 5/27/2022 5:31 PM, André G. Isaak wrote:
On 2022-05-27 16:20, olcott wrote:
On 5/27/2022 5:15 PM, André G. Isaak wrote:
On 2022-05-27 16:01, olcott wrote:Thus mandating a bijection to finite strings.
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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 numbersUm. This is technically true, but [IMO] >>>>>>>>>>>>>>>> misleading. The reason
(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. >>>>>>>>>>>>>>>>
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the
above paragraph it is the algorithm which has an input,
*input of the function domain*
What that means is "input [to the algorithm] of [i.e. taken from]
the function domain".
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.
André
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.
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)
On 5/27/2022 6:11 PM, Richard Damon wrote:
On 5/27/22 6:52 PM, olcott wrote:
On 5/27/2022 5:31 PM, André G. Isaak wrote:
On 2022-05-27 16:20, olcott wrote:
On 5/27/2022 5:15 PM, André G. Isaak wrote:
On 2022-05-27 16:01, olcott wrote:Thus mandating a bijection to finite strings.
On 5/27/2022 4:34 PM, André G. Isaak wrote:
On 2022-05-27 15:27, olcott wrote:
On 5/27/2022 4:19 PM, André G. Isaak wrote:
On 2022-05-27 15:04, olcott wrote:
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,Um. This is technically true, but [IMO] >>>>>>>>>>>>>>>>> misleading. The reason
not finite string). Unlike the prime() function, >>>>>>>>>>>>>>>>>> however, the
positive square root function is NOT computable. >>>>>>>>>>>>>>>>>
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.
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.
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*
No. You're going by your *flawed* reading of the above. In the >>>>>>>> above paragraph it is the algorithm which has an input,
*input of the function domain*
What that means is "input [to the algorithm] of [i.e. taken from]
the function domain".
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. >>>>
André
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.
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.
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)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 384 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 60:35:33 |
| Calls: | 8,173 |
| Calls today: | 5 |
| Files: | 13,113 |
| Messages: | 5,864,381 |